深色模式
Cluster Autoscaler 节点伸缩
摘要：本文面向生产 SRE / 平台工程师，解释 Cluster Autoscaler（CA）如何依据调度压力而非资源利用率来增减节点：当 Pod 因资源不足
Pending时扩容，当节点长期低利用率且可安全排空时缩容。覆盖扩容/缩容逻辑、PDB 与本地存储对缩容的阻断、版本兼容规则、云厂商差异及与 HPA 的协同。适用 Kubernetes v1.28+。
适用版本与前提
- Kubernetes：v1.28+（CA 自 1.0 起 GA；CA 的次版本应与集群次版本匹配，允许 ±1 偏差 ——
[厂商特定]/版本相关） - 工具：
kubectl、对kube-system中 CA Deployment 的读权限与节点annotate权限 - 前提：集群运行于受支持的云（GCE/GKE、AWS、Azure 等），节点组/伸缩组已配置 min/max
背景与问题
Pod 级弹性（HPA/VPA）解决"副本/规格"问题，但节点总数是独立维度：HPA 把副本从 20 扩到 80，若现有节点放不下，多出的 30 个 Pod 会永久 Pending。CA 补上最后一层：在调度压力下加减节点。
关键设计点：CA 反应的是调度压力（Pending Pod），不是 CPU/内存利用率指标。因此它不会"为了利用率高一点"去搬迁 Pod，也不会误删带系统关键 Pod 的节点（区别于基于监控指标的节点伸缩，见下）。
CA 与监控指标式伸缩互斥
基于监控指标的节点伸缩不考虑 Pod，可能加一个空节点、也可能删掉带 kube-dns 等关键 Pod 的节点，Kubernetes 不鼓励。不要把 CA 与基于 CPU 利用率的节点伸缩同时启用，二者会冲突。[版本相关]
核心概念
CA 围绕"节点组"（node group）运作，不同云映射到不同概念：GCE/GKE 的 Managed Instance Group、AWS 的 Auto Scaling Group、Azure 的 VM Scale Set。每个节点组有独立 min/max，CA 永不会越界。
架构与原理
扩容：当存在因资源不足无法调度的 Pod，CA 模拟"给某节点组加一个同类节点能否解决"，能则调云 API 增大期望容量。延迟 SLO：小集群（<100 节点）≤30s、大集群（100~1000）≤60s（前提是未使用 Pod 亲和/反亲和——亲和谓词慢约 3 个数量级）。
缩容：节点连续 unneeded 超过 --scale-down-unneeded-time（默认 10 分钟），且其上所有 Pod 可安全迁移，CA 在尊重 PDB 的前提下排空并删除实例。以下情形会阻止缩容：
- 受限的 PodDisruptionBudget
- kube-system 中无 PDB 或 PDB 过严的 Pod（CA 0.6+）
- 无控制器托管的"裸" Pod
- 使用本地存储（如非空
emptyDir）的 Pod - 因亲和/资源/反亲和无法迁移的 Pod
- 带注解
cluster-autoscaler.kubernetes.io/safe-to-evict: "false"的 Pod（除非显式"true"）
生产实践
- 所有 Pod 必须设准确 requests：CA 扩容模拟完全基于 requests，不基于实际用量。漏设 requests = 不可调度。
- 关键负载配 PDB：既保护可用性，也避免 CA 因无 PDB 而误删带关键 Pod 的节点。
- 多节点组按硬件分池：通用池、GPU 池分开，各配 taints/labels，让 CA 为对应负载扩对的池。
- 防止误缩容：对绝不可动的节点加注解
cluster-autoscaler.kubernetes.io/scale-down-disabled: "true"。
操作步骤
步骤 1：验证 CA 运行状态
bash
kubectl get deployment -n kube-system | grep cluster-autoscaler
kubectl logs -n kube-system -l app=cluster-autoscaler --tail=501
2
2
步骤 2：查看扩容事件与原因
bash
kubectl get events -n kube-system --sort-by=.lastTimestamp | grep -i scale
# TriggeredScaleUp: 此 Pod 触发扩容
# NotTriggerScaleUp: 找不到可扩容的节点组使该 Pod 可调度
# ScaleDown / ScaleDownFailed1
2
3
4
2
3
4
步骤 3：保护特定节点不被缩容（示例注解）
bash
kubectl annotate node node-07 cluster-autoscaler.kubernetes.io/scale-down-disabled=true1
步骤 4：CA 关键参数（部署 manifest 片段，云厂商路径不同）
yaml
# 以自托管 CA 的 Deployment container args 为例；托管集群通过厂商控制台/Helm 配置
containers:
- name: cluster-autoscaler
image: registry.k8s.io/autoscaling/cluster-autoscaler:v1.28.X # 与集群次版本匹配
command:
- ./cluster-autoscaler
- --cloud-provider=aws
- --nodes=2:20:general-purpose-pool
- --nodes=0:10:gpu-pool
- --scale-down-unneeded-time=10m
- --scale-down-utilization-threshold=0.5
- --skip-nodes-with-system-pods=true
- --max-graceful-termination-sec=6001
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
生产危险
--cloud-provider 与节点组参数高度依赖云平台。在 AWS/GCP/Azure 上实际通过厂商自带 manifest（带 auto-discovery 标签）部署，上述 --nodes 写法仅为说明概念。错误配置会导致 CA 扩错节点组或无法扩容。生产请使用对应云厂商官方 manifest 并按其文档填入 tag/ASG/MIG。[厂商特定]
验证
bash
kubectl get nodes
# 制造调度压力(临时调大某 Deployment replicas)后观察新节点加入
kubectl get events -n kube-system | grep TriggeredScaleUp
# 缩容: 降低负载并等待 > 10min 后观察 ScaleDown 事件与节点数1
2
3
4
2
3
4
回滚与清理
bash
# 紧急停止缩容(全局): 给所有节点加注解
kubectl get nodes -o name | xargs -I{} kubectl annotate {} cluster-autoscaler.kubernetes.io/scale-down-disabled=true
# 降低某节点组上限以回收容量(云厂商控制台/CA 参数)
# 彻底禁用 CA: 删除/停止其 Deployment
kubectl delete deployment cluster-autoscaler -n kube-system1
2
3
4
5
2
3
4
5
故障排查
| 现象 | 根因 | 处理 |
|---|---|---|
| 有 Pending 但不扩容 | 节点组 max 已满 / 无匹配节点组 | 提高 max 或新增节点组 |
| 扩容慢 | 云实例供应 + 节点 Ready 通常 1~数分钟 | 评估预热节点 / Karpenter [厂商特定] |
| 不缩容 | PDB/本地存储/注解阻止 | 见上表 |
| 节点 NotReady 后缩容慢 | 默认 20min 后才触发（[厂商特定]/版本相关） | 检查 --ok-total-unready-count |
与 HPA 的协同
HPA 决定副本数，CA 决定有没有节点放这些副本。二者通过"Pending Pod"这一信号自然衔接：HPA 扩副本 → 部分 Pod 因无容量 Pending → CA 加节点 → 落位。
容量失配
若 HPA maxReplicas 远超节点组能容纳的 Pod 总数，达到上限后多余副本将永久 Pending。规划时让 HPA 上限与节点组容量（× 单节点可调度 Pod 数）对齐。详见 capacity.md。
安全与合规
- CA 删除节点时会排空并终止底层实例，不可逆。务必配 PDB 与
scale-down-disabled保护关键节点。 --max-graceful-termination-sec（默认 10min，CA 1.0+）给 Pod 优雅退出时间，超时则强制终止节点。对长事务负载要调大或配合preStop/SIGTERM 处理。- CA 仅删"它管理的节点组内的节点"，控制台手动加入的节点不会被 CA 缩容（
[厂商特定]）。
性能、容量与成本
- CA 扩容延迟取决于云实例供应（通常 1~数分钟），对亚分钟级尖峰不友好；可结合 HPA 预热副本、或用 Karpenter（AWS 生态）做更快/更灵活的无节点组供应。
- 缩容直接省成本，但过激缩容会造成节点抖动（thrashing）。让利用率阈值与 unneeded 时间略保守。
云厂商差异速查
| 维度 | GCP/GKE | AWS | Azure |
|---|---|---|---|
| 节点组概念 | Managed Instance Group | Auto Scaling Group | VM Scale Set |
| 配置方式 | 标签/控制台 | --aws-use-static-instance-list 或 tag 自动发现 | 类似 |
| 官方测试覆盖 | e2e 覆盖 | 社区生产使用多，非标准 release 流程 | 社区生产使用多 [厂商特定] |
| 托管集成 | GKE 内置 | EKS 可装/Cluster Autoscaler for EKS | AKS 可装 |
多数云厂商兼容性测试不在 CA 标准 release 流程内，实际行为以对应云文档为准。
[厂商特定]
替代方案与权衡
| 方案 | 适用 | 不适用 |
|---|---|---|
| Cluster Autoscaler | 已有固定节点组、主流云 | 需要无节点组灵活供应（见 Karpenter） |
| Karpenter | AWS 等，按需供应任意实例 | 深度绑定厂商、需迁移 |
| 固定节点 + HPA | 负载稳定、可预测 | 明显波峰波谷 |
FAQ
Q：CA 会基于 CPU 利用率缩容吗？ A：不会。CA 基于调度压力与"节点是否 unneeded（低利用率且可迁移）"，不直接按 CPU 指标决策。
Q：CA 版本怎么选？ A：CA 次版本应与 K8s 次版本一致（允许 ±1）。例如 K8s 1.28 用 CA v1.28.x。
参考资料
- Kubernetes Autoscaler - Cluster Autoscaler FAQ，访问日期：2026-10-08。
- 腾讯云 TKE - 扩容缩容相关，访问日期：2026-10-08（
[厂商特定]行为以厂商文档为准）。 - Codartium - Kubernetes Cluster Autoscaler Management，访问日期：2026-10-08（社区实践，经验判断参考）。