requests 与 limits 是什么
资源请求决定调度结果与水平扩缩容的基准，资源上限是运行时的硬边界：内存超过上限会被强制终止，CPU 超过上限会被限流而不会被杀。两者的组合还决定服务质量等级与驱逐优先级，因此只写其中一个往往会在容量或稳定性上留下问题。
基本信息
| 资源请求 | 调度依据与利用率分母，同时影响服务质量等级 |
|---|---|
| 内存上限 | 超限即被强制终止，退出码通常为一百三十七 |
| CPU 上限 | 超限被限流，延迟升高但进程不会被杀 |
| 服务质量等级 | 请求与上限都设置且相等最高，其次是部分设置，全部不设置最低 |
| 经验比例 | 内存请求与上限设得接近更稳，CPU 可以留出突发空间 |
| 默认行为 | 只设上限不设请求时，请求会默认等于上限 |
典型使用场景
- 稳定调度：给实例声明合理的资源请求，避免节点被超额分配
- 防止单实例拖垮节点：用内存上限约束异常内存增长
- 控制延迟抖动：为 CPU 密集服务设置合理上限与请求比例
- 水平扩缩容基准：扩缩容按请求值计算利用率，请求写错会得出错误结论
- 故障分析：结合是否被内存超限终止，快速区分崩溃与资源不足
- 容量规划：把各工作负载的请求值加总，评估节点池是否需要扩容
字段行为对照
| 字段 | 作用 | 超限后果 |
|---|---|---|
| CPU 请求 | 调度与扩缩容基准 | 不会超限，仅影响调度 |
| CPU 上限 | 运行时上限 | 被限流，延迟升高但不被杀 |
| 内存请求 | 调度依据 | 不会超限，影响调度与等级 |
| 内存上限 | 运行时上限 | 被强制终止，退出码一百三十七 |
| 全部设置且相等 | 服务质量最高等级 | 资源紧张时最后被驱逐 |
资源配置示例
资源配置示例
resources:
requests:
cpu: 200m
memory: 256Mi
limits:
cpu: 1000m
memory: 512Mi
# 内存请求与上限设得接近更稳，CPU 留出突发空间减少限流只写上限不写请求时请求会默认等于上限：调度水位被虚高占用，集群看起来资源不足，实际利用率却不高。
内存上限压得太紧的症状很典型：流量一抖就被强制终止，重启次数持续增长，日志里往往找不到明确异常。
CPU 上限设得过小不会报错，只会变慢：表现为没有错误但延迟持续偏高，排查时容易被当成代码性能问题。
扩缩容按请求值计算利用率：请求值偏离实际用量时，扩容会过早触发或迟迟不触发，容量与成本同时失衡。
配置时的判断依据
- 按压测与线上观测值设置资源请求，而不是按峰值拍脑袋
- 内存请求与上限设得接近更稳，减少被驱逐的概率
- CPU 上限留出突发空间，避免高峰期被持续限流
- 为关键服务设置更严格的资源约束，减少相互影响
- 定期复核实际用量，长期偏离说明配置已经过时
- 把资源请求纳入容量评估，避免节点被超额分配
资源配置调整后要观察一段时间再下结论：短时间内看不出效果，至少覆盖一个业务高峰周期再评估是否合理。