Kubernetes 资源请求与限制（Requests & Limits）实战入门

在 Kubernetes 中调度 Pod 时，最容易踩的坑之一就是 Requests 和 Limits 的配置。很多初学者把这两个概念混为一谈，或者干脆不填，结果集群跑着跑着就开始出现 OOMKilled 或者节点争抢资源导致的抖动。今天用实际场景把两者的区别、调度影响和推荐实践梳理一遍，少走弯路。

一、基本概念

Requests 是 Pod 向调度器声明的「保底资源」。调度器在做放置决策时，会把节点上所有 Pod 的 Requests 累加，和节点的 allocatable 对比，只有满足时才会把 Pod 调度到该节点。换句话说，Requests 决定了 Pod 能不能被调度上去，也决定了节点能容纳多少 Pod。

Limits 是 Pod 运行时使用的「上限」，由 kubelet 和容器运行时（cgroup）在节点本地强制执行。当容器使用量触及 Limits，CPU 会被限流（throttle），内存则直接触发 OOM 被杀死。Limits 不影响调度，但直接影响运行稳定性。

二、CPU 和内存的不同表现

CPU 的 Request 和 Limit 行为差异很明显。当容器 CPU 使用量超过 Request 但未到 Limit 时，Kubernetes 不会限制它，只是把它放到 cgroup 的 best-effort 队列里，在节点空闲时可以获得更多 CPU；一旦超过 Limit，容器就会被 throttle，调度片（cfs_quota）不足时会感到卡顿。

内存则更加严格。Linux 的 OOM 机制会在容器超过 Limit 时直接 kill，所以内存的 Limit 通常不建议比 Request 高出太多，否则一旦突发用满，容器就会被直接回收。经验做法是让内存的 Request 和 Limit 尽量一致（Guaranteed 策略），尤其是对数据库、缓存等不能容忍 OOM 的工作负载。

三、QoS 等级

Kubernetes 会根据 Request 和 Limit 的组合把 Pod 划分到三个服务质量等级，直接影响驱逐优先级：

• Guaranteed：所有容器的 CPU 和内存 Request 等于 Limit。节点内存压力时最后被驱逐。
• Burstable：至少一个容器的 Request 小于 Limit，但仍设置了 Request。中等优先级。
• BestEffort：所有容器都没有设置 Request 和 Limit。节点资源紧张时最先被驱逐，生产环境应避免。

四、实战建议

生产环境建议始终为每个容器设置 Request，并尽量让内存的 Request 与 Limit 相同。CPU 可以适当给一些弹性，Limit 设为 Request 的 1.5～2 倍，既能容纳突发，又不会无限消耗节点资源。对于 Batch 类型的短时任务（例如离线训练、日志解析），可以放宽 Limit，但也要设置 Request，以免大量任务同时启动把节点打满。

如果不确定合适的数值，可以先用 Vertical Pod Autoscaler（VPA）的 Recommendation 模式跑几天，观察建议值后再写回 Deployment。搭配 Horizontal Pod Autoscaler（HPA）时，注意 HPA 是基于 CPU/内存使用率对 Request 做比值的，因此 Request 设得过大，HPA 会认为负载很低而不触发扩容。

五、常见错误示例

很多团队只在 Deployment 里写了 limits 而漏了 requests，调度器会把 Pod 当 BestEffort 看待，节点稍微忙碌就容易被其他 Guaranteed Pod 挤出。另一个典型错误是把 Limit 设成节点的核数或内存总量，结果一个 Pod 把整台节点吃满，同一节点上的其他 Pod 全部受到影响。

总结一句话：Request 写给调度器看，决定 Pod 住在哪里；Limit 写给运行时看，决定 Pod 能占多少。两者配合，才是集群稳定运行的基础。