requests 与 limits 各自决定什么
requests 决定调度器给 Pod 找什么样的节点，也是 cgroup 权重与 QoS 划分的依据；limits 决定容器最多能用多少资源。设低了，节点超卖严重，高峰互相争抢导致延迟抖动；设高了，节点利用率低、扩容成本上升，还会把 Pod 挤到没有节点可调度。可行做法是用压测和监控数据校准：requests 参考稳态用量，limits 在峰值上留出余量，并按运行时特性（GC、线程池、缓存）修正。
基本信息
| 适用对象 | 所有声明 resources 的工作负载（Deployment、StatefulSet、Job 等） |
|---|---|
| 关键字段 | containers[].resources.requests 与 limits 下的 cpu、memory |
| 数据来源 | kubectl top、监控系统历史曲线、上线前压测报告 |
| 常见单位 | cpu 用 m（1000m 等于 1 核），memory 用 Mi、Gi |
| 相关机制 | QoS 等级、LimitRange 默认值、HPA 利用率口径 |
典型使用场景
- 新服务上线：压测阶段采集用量曲线，给出第一版 requests 与 limits
- 容量治理：节点利用率偏低或长期超卖时，按监控数据重新校准
- 故障复盘：出现 OOMKilled 或 CPU 限流后回归资源声明
- 大版本升级后：运行时或依赖变化会改变资源画像，需要复测
- 成本优化：在不牺牲稳定性的前提下压出真实所需资源
取证与校准路径
取证与校准路径
kubectl top pod -l app=web --containers # 当前用量，可判断是否严重超卖
kubectl get pod web-x -o jsonpath='{.spec.containers[*].resources}'
kubectl describe node node1 | sed -n '/Allocated resources/,/Events/p' # 节点已分配 vs 可分配
# 口径参考（按容器分别统计）：
# requests ≈ 稳态 P95；CPU limits ≈ 峰值 × 1.2-1.5；内存 limits ≈ 峰值 + 明确余量资源校准口径
| 资源 | requests 参考 | limits 参考 | 注意 |
|---|---|---|---|
| CPU | 稳态 P95 用量 | 峰值乘 1.2-1.5 | 可压缩资源，超限被限流而非杀进程 |
| 内存 | 常驻内存 P95 | 峰值加余量 | 不可压缩，超限直接触发 OOMKilled |
| 并发相关 | 按并发模型评估 | 随连接数上升 | 线程池与连接池会放大内存峰值 |
| 缓存 | 按常驻缓存量 | 按最大缓存 | 缓存策略变化时需重新评估 |
QoS 取决于声明组合：所有容器都写 requests 且与 limits 相等是 Guaranteed；只写 limits 时 requests 会自动取相同值；完全没写才是 BestEffort，节点内存紧张时最先被驱逐。
校准不是一次性工作：大版本升级、依赖变化、流量结构改变都会让资源画像漂移，建议按季度或重大变更后回归一次。