Kubernetes 的 requests 和 limits 为什么不能互相替代

Pod 一直 Pending，但节点监控看起来并不忙；容器已经运行，接口却在高峰期变慢；内存还没达到配置上限，Pod 又被驱逐。这些现象涉及调度、运行时限制和节点压力等不同环节。对于 Linux 节点上按容器配置的 CPU 与内存，requests 和 limits 各有职责，调整时需要先找到问题发生在哪一层。

requests 参与调度，实际用量另算

调度器依据资源请求判断节点是否还有容量容纳新 Pod，而不是只看当前 CPU 或内存使用率。[1][2] 例如，只考虑 CPU，一个节点可供 Pod 使用的容量为 4 CPU，已有 Pod 的请求合计为 3 CPU，新 Pod 请求 2 CPU，就无法通过这个节点的容量检查。即使此时实际只用了 1 CPU，也不能据此判断新 Pod 一定能放进去。

请求值也不是运行用量的上限。在节点资源和相应 limit 允许的范围内，容器可以使用超过 request 的资源。[1] 声明 512Mi 内存请求，不意味着进程启动后就立即使用了 512Mi。请求值用于资源安排，进程实际消耗多少，仍需要通过监控持续观察。

把请求值压低可以让更多 Pod 通过容量检查，但业务高峰不会因此消失。多个容器同时增长时，仍可能争用节点资源。请求值过高则会减少可调度空间，因此需要结合正常负载、峰值持续时间和副本数量估算，而不是单纯追求让 Pod 尽快运行。

CPU 和内存的 limits 执行方式不同

CPU limit 通过节流限制 CPU 使用。容器请求 500m、限制 1 CPU 时，可以在资源允许的情况下使用超过请求值的 CPU，但仍受上限约束。[2] 限制过紧时，即使节点整体尚有空闲，应用也可能等待更多 CPU 时间，表现为处理速度下降或延迟增加。排查时应结合容器的 CPU 节流情况和请求延迟，而不能只看节点平均利用率。

内存限制通过 OOM 机制反应式执行，超过限制后可能有进程被内核终止，不能理解为“超过一字节就立即重启”。[1] 内存用量还会随并发、缓存和应用自身的内存管理变化。设置上限时，需要给运行峰值和必要开销留下空间，并核对容器终止原因，区分应用主动退出与内存相关终止。

节点压力是另一条处理路径

节点内存紧张时，kubelet 可以驱逐 Pod 来回收资源。选择驱逐对象时，会考虑使用量是否超过请求、Pod 优先级以及使用量相对请求的情况。[3] 因此，Pod 也可能在未达到自身内存上限时被驱逐。提高单个容器的内存 limit，并不会增加节点的实际内存，也不能消除节点压力。

排查时，应分别查看容器终止状态、Pod 事件和节点状态。容器因内存限制发生 OOM，与节点压力导致整个 Pod 被驱逐，处理方向不同。前者需要检查容器的内存需求和约束，后者还要检查同节点负载、请求配置及节点剩余资源。

省略字段之前，先看默认值

只为某项资源设置 limit，却没有设置 request，并且准入阶段也没有为它设置默认 request 时，Kubernetes 会把该 limit 复制为 request。[1] 原本想“只限制峰值”，实际可能同时提高了调度请求。

命名空间中的 LimitRange 还可以注入默认请求与限制，并检查最小值、最大值和两者比例。相关检查发生在 Pod 准入阶段；新增或修改 LimitRange，不会自动改写已经存在的 Pod。[4] 排查配置差异时，应查看集群里实际保存的 Pod 资源字段，同时核对命名空间策略，避免只依据提交前的模板判断。

调整资源配置时，先确定目标：解决 Pending，需要检查请求值和节点可调度容量；处理 CPU 延迟，需要观察节流与业务负载；处理内存终止，需要分析内存峰值及终止原因。每次调整保留配置前后值、观察时段、并发量和业务指标，让后续调整有可比较的依据。

参考资料
[1] Resource Management for Pods and Containers
https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
[2] Assign CPU Resources to Containers and Pods
https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/
[3] Node-pressure Eviction
https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/
[4] Limit Ranges
https://kubernetes.io/docs/concepts/policy/limit-range/