HPA 还在只看 CPU 利用率吗？聊聊自定义指标该在什么场景下才值得上

【背景】 做云原生 15 年，最近一年带团队做 K8s 1.28 生产集群（40+ 节点、200+ 服务）的容量治理，翻了一遍 HPA 配置，发现一个很尴尬的事实：80% 以上的 Deployment 还是 type: Resource + resource: cpu + target: Utilization，少数几个 Java 服务加了 memory，再少数几个上了 PodMetrics（QPS、线程池占用），几乎没有服务用 External（Kafka lag、RabbitMQ queue depth）。

我理解为什么大家默认 CPU——它免费、通用、和 requests 天然对齐、Prometheus 里现成。但过去一年我们踩过的坑，几乎都不是「CPU 不够」，而是「CPU 没满、但业务已经慢」：连接池打满、GC 频繁、下游限流、队列积压。这些场景下，HPA 看到 CPU 30% 就纹丝不动，P99 已经飙到秒级。

【常见分歧（至少四种做法，我见过的都有人坚持）】

1. 「CPU 就够」派：CPU 是最终瓶颈，其他指标都是它的代理。省一套 Prometheus Adapter、少一类故障面。小团队、CPU-bound 服务（计算密集型批处理、渲染、加解密）我认同。
2. 「CPU + Memory 双保险」派：Java/Go 服务加一条 memory 规则，防止堆外/OOM 提前触发扩容。合理，但 memory 在 K8s 里语义模糊（page cache、slab、临时 mmap），阈值很难定，实际效果看运气。
3. 「按负载类型分档」派：CPU-bound 用 CPU，IO-bound / 有下游依赖的用自定义指标（QPS、队列深度、线程池占用），有状态服务干脆不上 HPA、用 Cluster Autoscaler + 手动扩。最贴近物理事实，但维护成本最高——每个服务都要写 metrics 暴露 + Adapter + SLO 对齐。
4. 「HPA 只是兜底，靠上游限流 + 容量预留」派：认为 HPA 的响应速度（分钟级）根本接不住秒级流量，与其调 HPA 不如把入口限流和容量规划做扎实。这个观点在 ToC 高并发场景我基本认同，但 ToB 多租户、长尾流量场景下不成立。

【我的倾向（先给结论，欢迎打脸）】

• 默认 CPU，但只对 CPU-bound 服务。判据很朴素：压测时 CPU 到 70% 之前 P99 是否已经越过 SLO。如果越过，说明瓶颈不在 CPU，CPU 指标就是错的。
• IO-bound / 有强下游依赖的服务，必须上自定义指标，且指标要选「离用户感知最近」的那个：能选 QPS 不选线程池，能选业务队列深度不选 QPS。理由是离用户远的指标会先饱和、先失真。
• 有状态服务不上 HPA（Kafka consumer、带本地状态的服务），靠 CA + 手动扩 + 副本冗余。HPA 对这类服务只会带来「扩缩容期间的数据倾斜」。
• HPA 不是 SLA 的兜底，SLA 的兜底永远是入口限流 + 容量预留。HPA 只解决「稳态漂移」，不解决「突发」。

【想听大家怎么选】

1. 你的生产集群里，有多少比例的服务用的是自定义指标？选的是什么？Prometheus Adapter 的稳定性怎么样？
2. 有没有人把「队列深度 / lag」直接作为 HPA 指标跑过半年以上的？阈值怎么定的，抖动怎么处理的？
3. Java 服务上 HPA，你们用 CPU、memory 还是自定义？GC 时间占比多少以上你才会考虑上自定义指标？
4. 批处理 / Spark / 训练任务，你们是彻底放弃 HPA，还是用 KEDA 之类的方案？效果如何？
5. 有没有人试过「HPA + 预测式扩容」的组合（基于历史流量曲线提前扩）？ROI 到底值不值？

抛砖引玉，期待看到不同规模（50 服务 vs 500 服务）、不同负载类型（ToC 高并发 vs ToB 长尾）下的真实取舍。