HPA 扩缩容：CPU 指标不够，业务队列也要进来

HPA 扩缩容：CPU 指标不够，业务队列也要进来

Kubernetes HPA 很常见，但很多服务只按 CPU 扩缩容。对普通 HTTP 服务，CPU 有时够用；对 AI 后端、任务 worker、网关队列，CPU 往往不是最早暴露压力的指标。队列已经堆了，CPU 还不高，用户已经开始等。

扩缩容要服务业务目标。看 CPU 是手段，看队列等待、请求延迟和任务积压才更接近真实体验。

一、先判断瓶颈在哪里

扩容不是万能药。如果瓶颈在数据库、模型服务或外部 API，只扩应用 Pod 可能让下游更痛。HPA 前要先确认 worker 增加后能真正消化队列。

flowchart TD A[延迟升高] --> B{CPU 是否高} B -->|高| C[CPU HPA 有意义] B -->|不高| D{队列是否堆积} D -->|是| E[按队列指标扩容] D -->|否| F[查下游或锁等待]

这张图提醒我们，HPA 只是执行动作，不是诊断工具。诊断错了，扩容会变成放大器。

二、用外部指标驱动 HPA

队列型服务可以通过 Prometheus Adapter 把自定义指标暴露给 HPA，例如每个 Pod 平均待处理任务数。

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: summary-worker spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: summary-worker minReplicas: 2 maxReplicas: 20 metrics: - type: Pods pods: metric: name: pending_jobs_per_pod target: type: AverageValue averageValue: "10"

这个配置比纯 CPU 更贴近 worker 的真实压力。队列堆积时扩容，队列消化后缩容。

三、缩容要考虑任务生命周期

Worker 处理任务时，不能被随便杀掉。要设置优雅退出：收到 SIGTERM 后停止拉新任务，处理完当前任务再退出，超过宽限时间则释放锁让其他 worker 接手。

func runWorker(ctx context.Context) { for { select { case <-ctx.Done(): return default: job := fetchJob() process(job) } } }

实际代码里还要处理锁续期和失败重试。缩容如果不优雅，会制造重复任务和半成品。

四、扩容速度要受下游保护

HPA 一次扩太快，可能把数据库、向量库或模型网关打爆。可以设置扩容策略和最大增长比例，让系统平滑进入新容量。

扩容不是越快越好。基础设施要保护全链路，而不是只让某个 Deployment 变大。

还要避免指标抖动导致频繁扩缩。可以设置稳定窗口和缩容延迟，让 HPA 不要因为短暂波动来回调整。尤其是 AI 任务队列，任务耗时本来就有长尾，缩容太快会让刚恢复的队列再次堆起来。

behavior: scaleUp: stabilizationWindowSeconds: 60 scaleDown: stabilizationWindowSeconds: 300

上线前要用压测验证扩缩容曲线，而不是只看 YAML 能不能 apply。观察从队列堆积到扩容生效需要多久，缩容后是否有任务被中断，这些才是 HPA 真正的验收内容。

五、总结

HPA 不应该只盯 CPU。对 AI 后端和任务队列，业务队列、等待时间和任务成本更有价值。扩容前确认瓶颈，缩容时优雅退出，扩容速度要保护下游。

能自动扩缩容不代表系统可靠，按对的指标扩缩容才可靠。