华为云 CCE 弹性伸缩实战：HPA 和节点池为什么必须一起配？

上个月接手了一个运行在华为云 CCE 上的在线服务，业务有明显的峰谷特征：白天 QPS 是夜间的 5 倍，大促期间还会瞬间翻 10 倍。原来只配了 HPA（Pod 层自动扩缩容），结果流量高峰时 Pod 确实从 2 个扩到了 10 个，但一半的 Pod 一直 Pending，服务实际可用容量并没有增加。排查后发现，问题出在只做了 Pod 层弹性、没做节点层弹性。把节点池自动伸缩补齐之后，不仅扛住了大促，日常资源成本还降了约 25%。

一、 CCE 弹性的两个层次，缺一不可

CCE 的弹性分为** Pod 层和节点层**。Pod 层由 HorizontalPodAutoscaler 负责，根据 CPU、内存或自定义指标调整副本数；节点层由节点池的弹性伸缩策略负责，在 Pod 因资源不足进入 Pending 时增加节点，在节点长期空闲时缩容。两层必须同时配置，否则就会出现“Pod 扩了但没地方调度”或者“节点扩了但长期空跑”的局面。

我当时的配置就是一个典型反例：HPA 的 maxReplicas 设到了 20，但节点池没有开启弹性伸缩，集群固定只有 3 个 8C16G 的节点。Pod 扩容到第 6 个就开始 Pending，HPA 的指标继续上涨，副本数继续加，但新增的 Pod 全部卡在调度阶段。

二、 HPA 的关键参数：别贴着峰值设

HPA 配得好不好，直接决定弹性的“跟手程度”。几个踩坑后的取值经验：

CPU 目标利用率不要设 80% 以上。看起来“榨得更狠”，实际上一旦流量爬升速度快于扩容速度，CPU 会瞬间打满，用户请求直接超时。设 60%~70% 比较稳妥。

必须设置 stabilizationWindowSeconds。扩容窗口可以短（0~30 秒），但缩容窗口建议 300 秒以上，否则流量稍微抖一下副本数就反复增减，既浪费又影响稳定性。

minReplicas 和 maxReplicas 必须有硬边界，防止异常指标把副本数推到集群承载能力之外。

Pod 的 resources.requests 必须设置。HPA 计算 CPU 利用率是相对于 request 的，没设 request 时 HPA 会显示 unknown，根本不会工作。

yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 65
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
    scaleDown:
      stabilizationWindowSeconds: 300
三、 节点池弹性伸缩的坑：不是开了就万事大吉

节点池开启弹性伸缩后，扩容时优先选择与现有节点同规格、同可用区的节点，减少调度碎片。缩容时集群会检查节点上的 Pod 能否被驱逐，带有本地存储、HostNetwork 或未被控制器管理的 Pod 会阻止缩容。我们有一批跑 DaemonSet 的日志采集 Pod 没有打容忍配置，导致节点池该缩的时候缩不下去，白白多付了半个月的节点费用。给这类工作负载打上固定标签、配置节点亲和，把它们集中在固定的“常驻节点池”里，弹性节点池只跑无状态业务，问题才解决。

四、 成本上的意外收获

把 HPA 和节点池伸缩都调好之后，除了稳定性提升，成本也降了不少。我们配合 CCE 的成本洞察，把无状态服务的 request 从“拍脑袋写的 2C4G”修正到了实际用量约 1.2 倍的水平，日常节点数从固定的 3 台降到了弹性区间 1~3 台，夜间低峰自动缩到 1 台。整体资源成本下降了约 25%。另外，离线批处理任务切换到竞价实例节点池后，那部分成本又降了超过 50%。

五、 总结

CCE 弹性伸缩的核心不是“把参数调大”，而是让 HPA 的指标、节点池的容量和业务的真实负载形成闭环。先确保 Pod 层 HPA 的 request 和阈值合理，再让节点池跟着 Pod 的 Pending 信号扩缩，最后用成本洞察持续修正 request/limit。两层都配齐，弹性才真正可用。