📚 课程目录第4章自动节点扩容（Cluster Autoscaler）

4. 自动节点扩容（Cluster Autoscaler）：工作原理、云提供商集成与扩缩容策略

Cluster Autoscaler（CA）是 Kubernetes 集群实现弹性伸缩的核心组件。它负责在 Pod 因资源不足而无法调度时自动增加节点，并在节点利用率持续偏低时安全地移除节点。CA 与云提供商的 API 深度集成，直接管理底层计算资源，是生产集群必须掌握的运维工具。

4.1 工作原理：从 Pod 调度失败到节点就绪

CA 的工作流程可以概括为“检测-模拟-执行”三个步骤。它不直接监控 CPU 或内存使用率，而是以 Pod 调度状态 为触发条件。

  核心触发条件： 当 Pod 因节点资源不足（CPU、内存、GPU 等）而处于 Pending 状态，且调度器返回“不可调度（unschedulable）”时，CA 才会启动扩容流程。

4.2 云提供商集成：AWS / Azure / GCP

CA 通过 云提供商接口（Cloud Provider Interface） 与底层基础设施交互。不同云厂商的集成方式、节点组概念和标签要求略有差异，但核心逻辑一致。

云提供商	节点组概念	核心配置	标签要求
AWS	AWS Auto Scaling Group (ASG)	`--cloud-provider=aws` IAM 角色需 `autoscaling:DescribeAutoScalingGroups` 等权限	ASG 标签 `k8s.io/cluster-autoscaler/<cluster-name>` 必须为 `owned`
Azure	VMSS (Virtual Machine Scale Set)	`--cloud-provider=azure` 服务主体需 `Virtual Machine Scale Sets Contributor` 角色	VMSS 标签 `k8s.io/cluster-autoscaler/enabled` 必须为 `true`
GCP	MIG (Managed Instance Group)	`--cloud-provider=gce` 服务账号需 `compute.instanceGroups.update` 权限	MIG 名称需匹配 `k8s.io/cluster-autoscaler/node-template/label/` 前缀

最佳实践： 在 AWS 上，建议为每个节点组（ASG）设置独立的 instance-type 标签，以便 CA 在扩容时选择正确的实例规格。Azure 上则推荐使用 vmss 作为节点池，避免使用可用性集。

4.3 扩缩容策略：参数调优与安全边界

CA 的扩缩容行为由一组启动参数控制。错误的配置可能导致频繁抖动（flapping）或扩容延迟。以下是生产环境中必须掌握的关键策略参数。

4.3.1 扩容策略

扩容触发延迟（--scale-up-delay）： 默认 0 秒。建议设置为 30-60 秒，避免因短暂调度波动触发不必要的扩容。
最大节点数（--max-nodes-per-group）： 默认 1000。根据云配额设置合理上限，防止意外创建过多实例。
扩容顺序（--expander）： 支持 random、most-pods、least-waste、priority。生产推荐 least-waste 或 priority。

4.3.2 缩容策略

缩容阈值（--scale-down-utilization-threshold）： 默认 0.5（50%）。当节点资源利用率低于此值且持续一段时间，CA 会考虑缩容。
缩容延迟（--scale-down-delay-after-add）： 默认 10 分钟。新节点加入后至少等待此时间才开始评估缩容，防止刚扩容就缩容。
缩容非必要 Pod（--scale-down-unneeded-time）： 默认 10 分钟。节点被标记为“不需要”后，需等待此时间才真正删除。

避坑指南： 不要将 --scale-down-utilization-threshold 设置过高（如 0.8），否则会导致节点频繁缩容，引发 Pod 重新调度风暴。同时，务必为关键工作负载设置 PodDisruptionBudget，防止缩容时中断所有副本。

4.4 扩缩容策略对比表

策略维度	参数	推荐值	说明
扩容触发	`--scale-up-delay`	30s	避免瞬时 Pod 抖动触发扩容
扩容选择	`--expander`	`least-waste`	优先选择资源浪费最少的节点组
缩容阈值	`--scale-down-utilization-threshold`	0.5	低于 50% 利用率才考虑缩容
缩容等待	`--scale-down-delay-after-add`	10min	新节点加入后等待期
缩容确认	`--scale-down-unneeded-time`	10min	节点不再需要后的等待期
最大节点组	`--max-nodes-per-group`	根据云配额	防止资源超限

4.5 生产部署示例（AWS）

以下是一个在 AWS EKS 集群中部署 CA 的典型配置片段，使用 IAM 角色和 ASG 标签实现自动发现。

# Cluster Autoscaler Deployment 关键参数
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cluster-autoscaler
  namespace: kube-system
spec:
  template:
    spec:
      containers:
      - image: k8s.gcr.io/autoscaling/cluster-autoscaler:v1.28.0
        name: cluster-autoscaler
        command:
          - ./cluster-autoscaler
          - --cloud-provider=aws
          - --namespace=kube-system
          - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/<cluster-name>
          - --scale-down-delay-after-add=10m
          - --scale-down-unneeded-time=10m
          - --scale-down-utilization-threshold=0.5
          - --expander=least-waste
          - --max-nodes-per-group=100
        env:
          - name: AWS_REGION
            value: us-east-1

  关键检查点： 部署后，使用 kubectl logs -n kube-system deployment/cluster-autoscaler 查看日志。如果出现 No node groups found，说明 ASG 标签未正确设置。如果出现 Scale up: 1 pod pending，说明 CA 已正常工作。

4.6 常见问题与排查思路

扩容不触发： 检查 Pod 的 kubectl describe pod 是否显示 0/1 nodes are available。确认 CA 日志中是否有 skip scaling up 字样，通常是因为节点组已达上限或云配额不足。
缩容不执行： 检查节点上是否有 cluster-autoscaler.kubernetes.io/safe-to-evict: false 注解的 Pod。确认 --scale-down-unneeded-time 是否已超时。
频繁扩缩容（flapping）： 增大 --scale-down-delay-after-add 和 --scale-down-unneeded-time，或降低 --scale-down-utilization-threshold。