CCE 弹性伸缩实战：HPA + 节点池自动扩缩容的落地做法

一、为什么弹性伸缩总在关键时刻掉链子

很多团队的弹性伸缩是这样上线的：配一个 HPA，设一个 CPU 80% 的阈值，就以为大促和流量高峰稳了。结果真到高峰时，要么扩容太慢、服务已经超时了，要么节点不够、Pod 一直 Pending，要么流量一退就缩容过猛、又触发新一轮扩容——来回抖动。

问题不在 HPA 本身，而在于只做了 Pod 层伸缩，没做节点层伸缩，也没把指标、资源请求和扩容速度串起来。弹性伸缩是一个分层系统：HPA 管 Pod 数量，节点池自动伸缩管节点数量，指标和资源配置决定它反应得快不快、准不准。下面按这三层展开。

二、第一层：HPA——先把“扩容依据”选对

HPA（Horizontal Pod Autoscaler）按指标自动调整副本数。最常见的误区是只用 CPU 利用率：

• CPU 利用率会骗人：它是相对 requests 计算的。如果 requests 设得太低，CPU 利用率一到 80% 就扩容，其实机器还很空；设得太高，又可能一直不扩容，直到服务已经变慢。
• 不同业务看不同指标：Web 服务看 QPS 和请求延迟更直接；队列消费型服务看队列深度；内存型服务看内存使用量。只盯 CPU，等于只用一个刻度量所有业务。
• 自定义指标要先打通：想用 QPS、队列长度这类指标，需要先把指标接到 metrics-server 或自定义指标适配器上，否则 HPA 根本读不到。

关键动作：先校准 requests 和 limits，再选指标。requests 应该接近业务的日常实际用量（用监控的 P50/P95 来定），limits 留出突发余量；指标优先选和用户体验直接相关的那一个，而不是最容易配的那一个。

三、第二层：节点池自动伸缩——Pod 扩出来了，节点要跟得上

HPA 把副本数从 3 扩到 10，集群里如果没有空闲节点，多出来的 Pod 只能 Pending。节点池自动伸缩（Cluster Autoscaler）就是补这一层的：

• 触发条件：有 Pod 因为资源不足无法调度时，自动给节点池加节点；节点长期空闲、上面的 Pod 可以被驱逐重调度时，再缩掉节点。
• 节点池要分组：不要把所有业务混在一个节点池里。按业务类型、规格、可用区分组，扩容时才不会出现“加了节点却不合用”的情况。
• 留一点缓冲：完全“按需加节点”在突发流量下会慢一拍，因为拉起节点、装组件、Ready 需要时间。给核心业务的节点池留少量缓冲节点，或者提前做定时扩容，能把这段时间补上。

关键动作：把 HPA 和节点池伸缩当成一对来配。只配 HPA 不配节点池，扩容会在节点这一层卡住；只配节点池不配 HPA，节点扩了也不知道要扩多少 Pod。

四、第三层：防抖动——扩得快，也要缩得稳

弹性伸缩最容易翻车的地方是抖动：流量一波动就扩容，刚扩完又缩容，反复折腾还浪费资源。三个做法可以压住抖动：

• 扩容快、缩容慢：HPA 的扩容可以激进一点，缩容要留冷却时间。流量高峰过去后，先观察几分钟再缩，避免刚缩完又要扩。
• 设好最小副本数：核心服务不要缩到 1 个副本，至少留 2 个，跨可用区分布。缩到 1 副本时一旦节点出问题，服务就直接中断。
• 用多指标互相印证：CPU 和 QPS 同时满足条件再扩容，单一指标抖动时不容易误触发。也可以给关键指标加平滑窗口，避免瞬时毛刺触发扩缩容。

关键动作：上线前做一次压测演练。模拟流量翻倍，看从触发扩容到 Pod 就绪、节点就绪一共要多久，缩容后会不会抖动。没跑过压测的伸缩配置，等于没配。

五、一个可落地的检查清单

1. 每个服务的 requests 是否按监控 P95 校准过，而不是拍脑袋填的？
2. HPA 用的指标是不是和用户体验直接相关（QPS、延迟、队列深度）？
3. 节点池自动伸缩开了吗？节点池有没有按业务分组？
4. 核心业务有没有留缓冲节点或定时扩容，应对突发流量？
5. 缩容冷却时间、最小副本数设好了吗？
6. 有没有做过一次流量翻倍的压测，验证扩容全链路耗时？

一句话总结：弹性伸缩不是配一个 HPA 就完事，而是 Pod 伸缩、节点伸缩、防抖动三层配合。指标决定扩得准不准，节点池决定扩不扩得动，防抖动决定扩完稳不稳，三层缺一不可。