Kubernetes 集群扩容与缩容的完整流程与设计逻辑

Kubernetes 集群扩容与缩容的完整流程与设计逻辑

在云原生架构中，弹性伸缩（Scaling）是 Kubernetes 最核心的能力之一。合理地进行集群及应用层面的扩缩容，不仅能保障业务在高峰期的稳定性，还能在低谷期有效降低基础设施成本。

本文将详细探讨 K8S 扩缩容的必要性、核心维度、完整工作流程以及在实际生产环境中的注意事项。

---

一、 为什么要进行集群扩缩容？

在传统的物理机或固定虚拟机架构中，资源通常是按照“峰值流量”来规划的，这往往导致资源在非高峰期大量闲置。K8S 的自动扩缩容机制主要为了解决以下核心问题：

1. 保障高可用性（Availability）： 当业务流量突增（如电商活动、突发新闻）时，系统能自动补充计算资源，避免因资源耗尽（OOM、CPU 跑满）导致服务崩溃。
2. 优化 IT 成本（Cost Efficiency）： 在夜间或业务低谷期，自动释放闲置的节点和容器实例，实现“按需付费”，降低云服务商账单或物理资源消耗。
3. 提升运维效率（Operational Efficiency）： 减少人工监控和手动调整节点/实例的工作量，将响应时间从“分钟/小时级”（人工干预）缩短至“秒级”（自动响应）。

---

二、 扩缩容的两个核心维度

K8S 的弹性伸缩通常分为应用层（Pod）和基础设施层（Node）两个维度，两者紧密联动：

• 应用层（Pod）伸缩：
  • HPA (Horizontal Pod Autoscaler)： 水平 Pod 自动扩缩，通过增加或减少 Pod 的副本数来应对负载变化。
  • VPA (Vertical Pod Autoscaler)： 垂直 Pod 自动扩缩，通过调整单个 Pod 的 CPU 和内存 Request/Limit 来应对负载变化（较少用于生产环境，因更新配置通常需要重启 Pod）。
• 基础设施层（Node）伸缩：
  • CA (Cluster Autoscaler)： 监控集群中因资源不足而处于 Pending 状态的 Pod，自动向云厂商申请增加 Node，或在 Node 长期闲置时将其释放。
  • Karpenter（渐成主流的替代方案）： 相比 CA 更加快速和灵活，能根据 Pod 需求直接创建最合适的实例类型。

---

三、 扩容（Scale-Out）的完整流程

当集群负载上升时，系统会触发扩容。以下是典型的 HPA + CA 联动扩容流程：

1. 指标触发阶段

• 数据收集： Metric Server 或 Prometheus 持续收集 Pod 的资源占用指标（如 CPU、内存占用率，或自定义的 QPS 指标）。
• 阈值判断： HPA 控制器定期（默认每 15 秒）轮询这些指标。当指标超过设定的阈值（例如 CPU 使用率 > 70%）时，计算所需的 Pod 副本数。

2. Pod 扩容阶段

• 更新副本数： HPA 更新对应 Deployment/StatefulSet 的 Replicas 数量。
• 创建新 Pod： 副本控制器（ReplicaSet）检测到预期副本数增加，向 API Server 申请创建新的 Pod。

3. 调度与瓶颈出现阶段

• 调度尝试： K8S Scheduler 尝试为新创建的 Pod 选择合适的 Node 运行。
• 资源不足： 如果当前集群所有 Node 的剩余可用资源（Request）不足以容纳新 Pod，这些 Pod 将会被标记为 Pending 状态，调度器在事件中记录 FailedScheduling。

4. 节点（Node）扩容阶段

• 检测 Pending： Cluster Autoscaler (CA) 发现集群中存在因为资源不足而处于 Pending 状态的 Pod。
• 申请新节点： CA 调用云服务商（如 AWS、阿里云、腾讯云等）的 API，请求在节点组（Node Group / ASG）中增加新的虚拟机实例。
• 节点加入集群： 新节点启动并初始化，Kubelet 服务启动，向 K8S Master 注册自己。节点状态变为 Ready。

5. 最终调度阶段

• Pod 绑定： Scheduler 重新评估处于 Pending 状态的 Pod，将其调度到新加入的 Ready 节点上。
• 流量接入： Pod 内的容器启动并通过 Readness Probe（就绪探针）检测后，Service 对应的 Endpoint 更新，外部流量（如 Ingress）开始分发到新 Pod。

---

四、 缩容（Scale-In）的完整流程

当流量回落时，为了节约成本，系统会触发缩容。缩容相比扩容更为复杂，因为需要保证业务无损。

1. 指标回落与 Pod 缩容

• 缩容触发： 监控指标持续低于设定的缩容阈值，并超过了 HPA 的冷却窗口期（防止因指标波动导致频繁扩缩容，即“震荡”）。
• 减少副本： HPA 降低 Deployment 的 Replicas 数量。
• 优雅停机（Graceful Shutdown）：
  • 被选中的 Pod 状态变更为 Terminating，并从 Service 的 Endpoint 列表中移除，停止接收新流量。
  • K8S 向 Pod 内的容器发送 SIGTERM 信号。
  • 容器执行平滑退出逻辑（如处理完存量连接、关闭数据库连接）。
  • 超过 terminationGracePeriodSeconds（默认 30 秒）后，若容器未退出，K8S 发送 SIGKILL 强制终止。

2. 节点闲置检测

• 监控利用率： Cluster Autoscaler (CA) 持续监控各节点的资源分配率（Requests 占总容量的比例）。
• 锁定候选节点： 如果某节点的资源利用率长期（默认 10 分钟以上）低于设定阈值（例如 50%），且该节点上运行的 Pod 可以被安全地移动到其他节点，该节点会被标记为“缩容候选节点”。

3. 节点排水（Draining）

• 不可调度标记： CA 将该节点标记为不可调度（Unschedulable，即打上 Drain 污点），防止新 Pod 被调度到该节点。
• 驱逐 Pod（Eviction）： 将该节点上的现有 Pod 安全地驱逐。这些 Pod 会在其他仍有空余资源的节点上重建。
  • 注意：此阶段会严格遵守 PodDisruptionBudget (PDB) 限制，确保服务的最低可用副本数。

4. 节点移除

• 销毁实例： 当节点上只剩下 DaemonSet 等系统级 Pod 时，CA 调用云服务商 API 释放该虚拟机实例。
• 清理资源： K8S Master 将该 Node 节点对象从集群中删除。

---

五、 生产环境中的注意事项与最佳实践

为了确保扩缩容过程平稳，在配置时建议参考以下实践：

1. 配置合理的 Request 与 Limit： HPA 和 CA 的计算主要依赖于 Request 指标。如果 Request 设置过小，可能导致节点实际负载极高但无法触发扩容；设置过大则会导致资源浪费。
2. 设置合理的冷却时间（Cooldown Window）： 避免“缩容后立刻又扩容”的震荡现象。K8S 默认缩容稳定窗口通常为 5 分钟。
3. 配置 PodDisruptionBudget (PDB)： 为关键业务设置 PDB（例如：保证至少有 80% 的副本存活），防止节点缩容排水时一次性驱逐过多 Pod 导致业务中断。
4. 配置优雅退出（PreStop Hook & terminationGracePeriodSeconds）： 确保应用在接收到 SIGTERM 时有足够的时间处理完未完成的请求。
5. 限制扩缩容边界： 务必为 HPA 设置合理的 minReplicas 和 maxReplicas，同时为云厂商的 Autoscaling Group 设置最大和最小节点数，防止因配置错误导致账单超支或集群崩溃。

---

六、 总结

Kubernetes 的自动扩缩容机制提供了一种动态平衡“业务高可用”与“资源低成本”的有效手段。理解其背后的 HPA 与 CA 联动逻辑、掌握扩容的触发路径与缩容的安全释放流程，是保障生产集群稳定运行的基础。在实际应用中，建议结合业务特性进行精细化参数调优，以达到更符合预期的弹性效果。