Go 服务上 Kubernetes 后 HPA 为什么不扩容：requests、CPU 和并发指标怎么选

不少团队把 Go API 服务迁移到 Kubernetes 后，都会碰到这类状况：流量直接涨了一倍，接口 P99 延迟从几十毫秒飙到三百多毫秒，HPA 却纹丝不动保持两个 Pod。点开监控面板一看，平均 CPU 占用才 45%，当初设的扩容阈值是 60%。这根本不是 HPA 出故障，它完全是按配置规则在执行判断：CPU 使用率没到预设门槛，扩容条件自然不满足；真正拖慢服务的原因，大概率是下游 I/O 阻塞、连接并发堆积或者内部任务排队这类和 CPU 无关的瓶颈。

先用一份最小 HPA 配置，把 CPU 统计口径说清楚

如果 Go 服务的主要瓶颈确实是 JSON 编解码、数据压缩、签名校验这类纯计算逻辑，先从 CPU 利用率指标入手是最省心的。前提条件是 Deployment 里已经给对应容器配好了 CPU request，Kubernetes 官方规则写得很明确：资源利用率的计算基准，就是当前使用量和 request 的比值。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: quote-api
spec:
  minReplicas: 2
  maxReplicas: 12
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: quote-api
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300

resources:
  requests:
    cpu: "500m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

这里的 500m、60 和 300 只是举例用的参考值，绝对不是所有 Go 服务都能直接照搬的标准答案。CPU request 的数值要从压测结果和历史负载数据里推导：设得太大，实际运行时利用率百分比就会显得偏低，很难触发扩容；设得太小，Kubernetes 的调度逻辑和 HPA 的扩容判断都会失真。毕竟集群调度 Pod 本来就是靠 requests 参数做资源分配，它根本就不只是 HPA 这一个组件的配置项。

CPU 使用率不高，不代表 Go 服务没有跑满饱和

很多 Go 服务的运行时间根本不是花在计算上，而是花在等待上面：HTTP 请求卡在下游服务没返回、数据库连接池在排队、WebSocket 连接大量堆积，或者内部限流器把请求暂时挂起。这类场景下 CPU 可能一直维持在很低的水平，但活跃请求数、等待队列长度和接口 P99 延迟已经明显恶化。这时候你就算把 CPU 扩容目标从 60% 往下调到 40%，最多也只能让 HPA 更早一点加副本，完全没找到真正拖慢服务的根因。

打算选并发或者队列类指标之前，先确认一个前提：副本数变多之后，这个指标的数值会按预期下降。Kubernetes HPA 的 API 文档也提到过，用来做扩缩容判断的指标，必须和副本数存在明确的反向关联关系，否则 HPA 算出来的副本数建议看起来没问题，实际跑起来会非常不稳定。不用急着接入一堆自定义指标，先在现有监控里验证它比 CPU 指标更早、更稳定地反映服务负载饱和，再接入也不迟。

多个指标同时配置时，哪一个会先触发扩容

在 autoscaling/v2 里可以同时配置 CPU 指标和自定义业务指标，HPA 的官方计算逻辑是每个指标单独算出对应的期望副本数，最后取所有结果里最大的那个值作为最终副本数。这个设计刚好适配“CPU 跑满了要扩、并发数太高也要扩”的服务场景，不过也意味着配置里最敏感的那个指标，会主导大部分时候的扩缩容结果。

in_flight_requests 只是用来演示的命名示例。真正上线之前要确认指标采集链路正常、标签范围配置正确、指标空值的时候逻辑符合预期。有个很实用的核对点：如果部分指标临时取不到值，其他剩下的指标又只支持缩容建议的话，HPA 会直接跳过这次缩容操作，不要看到副本数没下降就直接判定是配置字段失效。

别让自动扩容把下游服务和集群节点一起推到极限

HPA 的能力范围只是修改目标副本数，它没法自动帮你把数据库、消息队列或者集群节点的容量同步变大。Go 服务如果每个 Pod 开的数据库连接池都很大，副本数一旦涨上去，总连接数会直接突破数据库的最大连接限制；如果集群里没有空余资源，新扩容出来的 Pod 也会长时间处于 Pending 状态没法启动。做容量规划的时候，要把单 Pod 的下游连接预算、下游服务限流规则和节点总容量放在一起对齐。

• 给每个 Pod 的下游连接数设置总上限，避免副本数增加之后，总连接数跟着成倍上涨。
• 检查 maxReplicas 在当前节点池配置和已设置资源 request 的前提下，集群能不能真正放下这么多副本。
• 给启动耗时比较久的 Go 服务设置符合实际情况的 readiness 就绪检查规则，避免还没准备好处理请求的 Pod，被过早算进有效服务容量里。
• 把限流、超时和退避逻辑留在应用层处理，扩容本身解决不了下游故障引发的全链路重试风暴。

碰到缩容抖动问题，先查 behavior 配置再改目标值

线上流量出现短时间尖刺是很正常的事。如果每一波短峰值过去就立刻缩容，下一波流量上来又马上触发扩容，Pod 会反复在启动、预热和终止的状态间来回切换。Kubernetes HPA 的 behavior 可以分别单独设置扩容和缩容的策略，官方默认的缩容稳定窗口是 300 秒，可以先拿这个值作为基线跑一段时间观察。

behavior:
  scaleUp:
    policies:
    - type: Percent
      value: 50
      periodSeconds: 60
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
    - type: Percent
      value: 20
      periodSeconds: 60
    selectPolicy: Min

这段配置表达的逻辑是“扩容速度有上限，缩容操作更保守”。具体数值最终还是要结合业务服务的启动耗时、缓存预热需要的时间、能接受的成本和下游服务的承载能力，一起压测验证之后再确定。生产环境里更稳妥的做法是先把缩容节奏放慢，观察至少一周的峰谷流量曲线，再逐步调整，反复改 CPU 目标阈值，往往只会掩盖真正的指标选择问题。

上线前用这张清单做复核

1. 确认 metrics.k8s.io 或者对应的自定义指标采集链路正常，HPA 状态里没有持续出现取值错误的提示。
2. 确认每个被 HPA 监控的容器，都配置了和之前容量规划结果一致的 CPU、内存 requests 参数。
3. 分别压测 CPU 密集计算、下游等待和队列积压三类典型场景，记录下哪个指标会最早体现服务负载饱和。
4. 检查 maxReplicas、节点总容量、下游连接预算和数据库限流规则几个配置是不是互相匹配。
5. 灰度上线的时候同时观察副本数、接口 P99、错误率、队列深度和下游资源使用情况，不要只盯着 CPU 曲线判断效果。

相关问题

只设置 HPA 的 CPU 指标，必须配 requests 吗？

使用 CPU 利用率百分比做判断的话，必须配置合理的 CPU request，它就是百分比计算的分母。没有这个值，指标根本没法稳定表达“当前负载相对于单 Pod 的预设容量用了多少”这个含义。

Go 服务 P99 很高但 CPU 很低，直接把目标 CPU 阈值调低可以吗？

可以临时这么操作做短期验证，但先排查清楚 P99 延迟高的原因是下游等待、连接池锁竞争还是应用自身计算逻辑导致的。如果主要瓶颈是 I/O 等待，单纯提前扩容只会更快把压力全部转移给同一个下游服务。

HPA 同时看 CPU 和并发两个指标时，最终会以哪个指标的结果为准？

每个指标都会单独算出期望副本数，HPA 最终选择其中更大的那个结果。配置之前要确认两个指标代表的负载压力，都是可以通过增加副本得到缓解的，避免某个波动大的噪声指标长期主导扩容操作。

HPA 显示已经扩容了，为什么新 Pod 迟迟接不到流量？

可以顺着镜像拉取、调度资源、readiness 就绪条件、Service Endpoints 更新和节点容量这几个方向逐一排查。副本数变化只说明控制器已经修改了目标数量，新 Pod 要真正接流量，还要走完调度、启动就绪的完整链路。

用可解释的指标做容量决策

HPA 根本不是一个“流量大就自动多开 Pod”的魔法按钮。对于 Go 服务来说，CPU 指标的优势是逻辑简单、生态成熟，前提是它真的能描述服务的主要工作量；当等待和积压才是服务的核心瓶颈时，更有价值的指标是那些副本数增加之后就能直接缓解的并发或者队列信号。把 requests 参数、判断指标、behavior 配置和下游容量预算放在一起对齐考量，扩缩容操作才能变成可解释的容量决策，而不是反复试错凑百分比的猜谜游戏。

参考：Kubernetes 官方 HPA 文档、HPA v2 API 参考、Pod 资源管理文档。