Request、Limit、HPA 怎么配合容量治理

Kubernetes 资源治理最容易出现一种错觉：

• Pod 能跑起来
• HPA 也在自动扩缩容

于是大家会觉得容量治理已经做完了。

但真实线上里，很多服务抖动恰恰来自这三件事没有配合好：

• request 配得不准
• limit 配得太死或太松
• HPA 指标和业务负载特征不匹配

先说结论

• request 决定调度和 HPA 基线，limit 决定资源上限和节流边界，HPA 决定副本数调整节奏
• 三者必须成体系设计，单独调其中一个通常会造成新问题
• 资源治理不是把 limit 配满，而是让 Pod 在正常波动、峰值流量和扩容窗口里都可控
• CPU 型、内存型、IO 型服务的配置思路不能照抄

先分清三者分别在干什么

Request

request 是 Pod 向调度器声明的“我至少需要这些资源”。
它主要影响：

• Pod 能否被调度
• 节点资源是否足够
• HPA 基于资源利用率时的分母

Limit

limit 是 Pod 允许使用的资源上限。
主要影响：

• CPU 是否被 throttle
• 内存是否可能 OOMKilled

HPA

HPA 根据指标动态调整副本数。
常见是 CPU 利用率，也可以是自定义指标、QPS、消息积压等。

所以它们三者并不是同类配置，而是：

• request 负责“起得来”
• limit 负责“别失控”
• HPA 负责“量不够时扩起来”

为什么 request 特别关键

很多团队把 request 配得很低，觉得这样更容易把 Pod 塞进节点。
短期看资源利用率好像变高了，长期往往会带来更大的抖动。

原因有两个：

1. 调度器会误判资源充足

结果是节点上塞了太多 Pod，一到流量高峰，大家一起抢资源。

2. HPA 会失真

如果 HPA 基于 CPU utilization，而 request 又配得特别小，实际一点点 CPU 使用就会显得利用率很高，导致：

• 过早扩容
• 副本数抖动

所以 request 不是“越小越省”，而是应该尽量贴近稳定运行的基础消耗。

limit 配错会出现什么

CPU limit 太低

服务会被明显 throttle，表现成：

• CPU 看起来没满
• 但 RT 抖动
• Java / Go 线程明明在跑，吞吐却上不去

内存 limit 太低

一旦超过就可能 OOMKilled。
这类问题最常见于：

• JVM 堆参数和容器内存不匹配
• 突发批处理或缓存膨胀

limit 完全不配

在某些场景也未必稳。
因为少数 Pod 可能会在节点上异常吃资源，影响其他工作负载。

HPA 为什么常常“看起来工作了，但业务还是抖”

因为 HPA 有天然滞后性：

• 指标采集有延迟
• 扩 Pod 有时间
• 新 Pod 启动还要通过 readiness

所以 HPA 不是流量突刺的第一道防线。
它更像中短周期调节器，而不是瞬时冲击保险丝。

如果你的业务是秒杀、突发推送、极短周期流量暴涨，单靠 HPA 通常不够，还要考虑：

• 预扩容
• 本地/边缘缓存
• 限流降级

为什么 CPU 型和内存型服务不能一套配置走天下

CPU 型服务

比如 API 网关、无状态计算服务。
更适合基于 CPU 或 QPS 做 HPA，request 和 limit 重点关注 CPU throttle。

内存型服务

比如缓存代理、JVM 大堆服务、数据处理任务。
重点是避免 OOM 和过度压缩 request，HPA 也未必适合只看 CPU。

IO / 外部依赖型服务

比如 heavily RPC / DB-bound 的服务。
CPU 不高不代表没压力，这类更适合看：

• QPS
• 响应时间
• 队列长度
• 消息积压

一套更稳的实践方式

通常建议这样做：

1. 用历史监控看服务的稳定区间
2. 把 request 设在稳定运行的基础值附近
3. limit 预留峰值空间，但不要无限放开
4. HPA 指标选最能反映真实负载的那个
5. 结合 readiness、启动耗时和扩容速度评估弹性窗口

一个实际例子

假设一个 Java API 服务：

• 平时单 Pod 稳定 CPU 在 300m 到 500m
• 高峰会到 900m
• JVM 实际内存稳定在 800Mi 到 1.2Gi

这类服务如果配成：

• request: 50m / 256Mi
• limit: 1 / 1Gi

很可能会出现：

• 调度过密
• CPU 利用率虚高导致 HPA 抖动
• 内存高峰时 OOM

更稳的思路通常是：

• request 接近日常稳定值
• limit 给峰值留空间
• HPA 结合 CPU 或自定义指标做弹性

最常见的误区

1. 觉得 request 越小越划算

短期看像省资源，长期看容易把节点变成“过度承诺战场”。

2. limit 配得过死

尤其 CPU limit 太低时，业务抖动会非常隐蔽，因为你看到的未必是“CPU 满了”，而是被 throttle 了。

3. HPA 指标和业务瓶颈不匹配

数据库瓶颈型服务只盯 CPU，常常会发现副本加了，吞吐并没有明显提升。

总结

Request、Limit 和 HPA 不是三个独立配置项，而是一套容量治理闭环：

• request 决定资源基线
• limit 决定安全边界
• HPA 决定弹性节奏

只有把这三者放在同一个业务负载模型里看，Kubernetes 的资源治理才会真正稳定。