谁在调节点数量
Cluster Autoscaler 管的是节点维度：Pod 因资源不足一直 Pending 时，它尝试扩容节点池；节点长期低负载且上面的 Pod 可以迁移时，它缩容回收节点。它和 HPA 的分工不同——HPA 调副本数，Cluster Autoscaler 调节点数，两者配合才能既扩出容量又有地方落地。云上通常是托管组件或独立部署的控制器，工作效果依赖节点池的标签、污点与云侧配额设置。
基本信息
| 适用场景 | 具备弹性节点池的集群，云上与自建环境形态不同 |
|---|---|
| 扩容触发 | Pod 因资源不足 Pending，且现有节点无法容纳 |
| 缩容触发 | 节点长期低负载且上面的 Pod 可以被迁移 |
| 关键依赖 | 节点池标签与污点需匹配 Pod 的调度约束 |
| 观察入口 | Pending 的 Pod 事件与控制器日志 |
典型使用场景
- 突发流量：副本扩出来后需要新节点承接，避免长期 Pending
- 夜间收敛：低峰期回收空闲节点降低资源成本
- 节点池分层：按机型划分池子，让不同任务落到合适机型
- 容量告警：借扩容动作发现容量规划与业务增长的偏差
- 演练容灾：观察节点不可用时 Pod 能否被重新调度到新节点
观察链路
观察链路
kubectl get pod -A --field-selector status.phase=Pending
kubectl describe pod pending-x | grep -A3 Events # 区分资源不足与约束不匹配
kubectl get nodes -L topology.kubernetes.io/zone -L node.kubernetes.io/instance-type
kubectl get events -A --field-selector reason=NotTriggerScaleUp | tail -5
kubectl -n kube-system logs deploy/cluster-autoscaler --tail=30常见现象与确认方向
| 现象 | 可能原因 | 确认方向 |
|---|---|---|
| Pod 长期 Pending | 节点容量不足或调度约束过严 | 看事件是资源不足还是约束不匹配 |
| 扩了节点仍然 Pending | 新节点标签或污点不匹配 | 核对节点池模板与 Pod 约束 |
| 节点不缩容 | 存在不可迁移的 Pod 或预算保护 | 查预算、本地存储与 DaemonSet |
| 完全没有扩容动作 | 云侧配额或节点池上限 | 看控制器日志与云配额余量 |
只配 HPA 不管节点容量，副本扩出来照样没有地方调度，最终还是停在 Pending：副本弹性与节点弹性要作为一件事来评估。
缩容受可用性约束：有本地存储、被可用性预算保护、或无法迁移的 Pod 都会阻滞回收，节点长期回收不掉时优先检查这些原因。