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