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 后端和任务队列，业务队列、等待时间和任务成本更有价值。扩容前确认瓶颈，缩容时优雅退出，扩容速度要保护下游。
能自动扩缩容不代表系统可靠，按对的指标扩缩容才可靠。
