3. 集群节点管理：Kubernetes集群架构、Node与Pod的关系、节点生命周期管理
3.1 Kubernetes 集群架构概览
在 Serverless 场景下，Kubernetes 集群是承载用户 Pod 的“计算底座”。理解集群架构是进行容量规划与节点自动扩缩容的前提。一个标准的 Kubernetes 集群由 控制平面（Control Plane） 和 工作节点（Worker Nodes） 两部分组成。
3.2 Node 与 Pod 的关系
Node 是集群中的工作节点，Pod 是 Kubernetes 中最小的调度和部署单元。理解二者关系是容量规划的基础：Pod 运行在 Node 之上，一个 Node 可以运行多个 Pod，但一个 Pod 只能被调度到一个 Node 上。
| 维度 | Node（节点） | Pod（容器组） |
|---|---|---|
| 定义 | 物理机或虚拟机，提供计算资源 | 一个或多个容器的逻辑组合，共享网络和存储 |
| 生命周期 | 长期存在，由集群管理 | 临时性，可被创建、销毁、迁移 |
| 资源单位 | CPU、内存、磁盘、网络带宽 | Requests 和 Limits（资源预留与上限） |
| 调度关系 | 被动接受 Pod 调度 | 主动请求资源，由 Scheduler 分配 |
| Serverless 场景 | 通常由云厂商弹性实例（ECI/Fargate）充当，对用户透明 | 用户直接创建，无需关心底层 Node |
maxPods 参数和实际资源余量。
3.3 节点生命周期管理
节点的生命周期管理是自动扩缩容的核心操作。Kubernetes 通过 Node Controller 监控节点状态，并触发相应的生命周期事件。在 Serverless 场景下，节点生命周期通常与弹性伸缩策略紧密绑定。
3.3.1 节点状态流转
节点在生命周期中会经历多个状态，理解这些状态有助于诊断扩缩容过程中的异常。
3.3.2 节点扩缩容操作流程
在 Serverless 集群中，节点扩缩容通常由 Cluster Autoscaler 或云厂商的弹性伸缩组件驱动。以下是标准操作流程：
- 扩容触发： Pod 因资源不足处于 Pending 状态，触发扩容评估。
- 节点创建： 调用云 API 创建新的弹性实例（如 ECI），节点状态变为
Pending。 - 节点就绪： kubelet 完成注册，节点状态变为
Running，可调度 Pod。 - Pod 调度： Scheduler 将 Pending Pod 绑定到新节点上。
- 缩容评估： 节点利用率低于阈值（如 50%）且持续一段时间，触发缩容。
- Pod 驱逐： 节点上的 Pod 被优雅驱逐（Graceful Shutdown），重新调度到其他节点。
- 节点删除： 节点状态变为
Terminated，释放云资源。
PodDisruptionBudget 策略生效，避免一次性驱逐过多 Pod 导致服务不可用。同时，节点从 Running 到 Terminated 的冷却时间（Cooldown）需要合理配置，防止频繁震荡。
3.3.3 节点健康监控与自动修复
节点生命周期管理还包括健康监控。Node Controller 每隔 --node-monitor-period（默认 5s）检查节点状态。如果节点在 --node-monitor-grace-period（默认 40s）内未上报心跳，则标记为 NotReady。超过 --pod-eviction-timeout（默认 5m）后，开始驱逐节点上的 Pod。
| 参数 | 默认值 | 说明 | Serverless 建议 |
|---|---|---|---|
node-monitor-period |
5s | 节点监控检查周期 | 保持默认 |
node-monitor-grace-period |
40s | 节点心跳超时宽限期 | 可缩短至 20s，加速故障检测 |
pod-eviction-timeout |
5m | 节点不可用后驱逐 Pod 的等待时间 | 建议缩短至 1-2m，减少冷启动延迟 |
node-monitor-grace-period 和 pod-eviction-timeout，以更快响应节点故障，提升整体调度效率。
3.4 本章小结
本章深入剖析了 Kubernetes 集群架构、Node 与 Pod 的依赖关系，以及节点生命周期的完整管理流程。这些知识是后续进行容量规划、配置自动扩缩容策略的基础。理解节点状态流转和健康监控参数，能帮助你在 Serverless 场景下更精准地控制集群规模，避免资源浪费或调度延迟。