GeoXMind

资源请求与限制承担调度和运行时两种职责

说明 CPU 与内存 request、limit 怎样影响调度、竞争、节流和 OOM，并形成可用容量边界。

资源请求与限制承担调度和运行时两种职责

Kubernetes 中的资源 request 和 limit 经常一起出现，但它们回答不同问题。request 主要告诉调度器一个工作负载需要多少资源才能被放到节点上，也参与资源竞争时的保障与权重；limit 则交给节点和容器运行时，对实际使用设置边界。把两者设成同一个固定值并不天然正确，省略它们也会把风险转移给同节点的其他工作负载。

CPU 与内存的运行性质不同。CPU 可以被节流和分享，内存在压力下不能用“稍后再执行”归还，超限或节点不足可能触发终止和驱逐。

request 决定调度可容纳性

调度器根据节点可分配资源与已调度 Pod 的 request 判断是否还能放置新 Pod。它主要看声明值，不因当前监控显示 CPU 很空就忽略已承诺容量。这使节点能够承受工作负载同时接近其请求量的情况。

request 设得过高会造成表面利用率低、Pod 长期 Pending 或集群过度扩容；设得过低则允许过多实例挤在同一节点，峰值时产生竞争。正确数值应来自一段代表性负载下的使用分布、启动峰值和服务目标，而不是复制示例配置。

Pod 的多个容器都要纳入预算。边车代理、日志收集和初始化任务会消耗资源。只估算主业务容器会让调度模型低估总需求。不同 Kubernetes 版本对 Pod 级资源等特性支持不同，生产设计应以当前集群稳定能力为准。

request 不是每个时刻独占的一块 CPU 或物理内存。节点空闲时，容器可以使用超过 CPU request 的算力；发生竞争时，request 影响相对份额。内存 request 则参与调度和压力决策，但进程实际分配仍由使用行为决定。

CPU limit 通过节流限制计算时间

CPU 是可压缩资源。容器达到 CPU limit 时通常被调度机制节流，而不是立即终止。应用仍在运行，但请求延迟和任务完成时间会增长。平均 CPU 看似未满时，短周期突发也可能触发节流。

对低延迟服务，过紧 CPU limit 会把可用的空闲节点能力挡在容器之外，制造尾延迟。取消 CPU limit 可以利用空闲资源，但需要合理 request、租户隔离和节点容量控制，避免一个工作负载长期占满处理器。

CPU 密集批任务和在线服务适合不同策略。批任务可以接受节流，在线服务更关心尾延迟。设置前应观察 throttling 指标、队列时间和响应分位数，而不是只看使用核数。

内存 limit 形成不可跨越的风险边界

内存是不可压缩资源。进程使用超过容器 limit 时可能被 OOM 终止；节点整体内存不足时，还会依据压力和服务质量等级驱逐 Pod。重启不一定能解决持续内存需求，反复 OOM 会形成不可用循环。

内存 request 应覆盖常态工作集和必要波动，limit 要考虑峰值、缓存、运行时堆外内存和启动行为。只根据语言堆大小设置 limit 可能漏掉线程栈、直接缓冲、共享库和文件缓存。

把内存 limit 设得极高可以减少容器级 OOM，却扩大节点级故障范围。完全不设限制会让泄漏进程影响其他服务。合适边界需要结合单实例故障隔离、自动扩缩和节点预留。

OOM 原因要从事件、容器退出码、节点压力和应用指标共同判断。仅看到“重启”不能区分容器超限、节点驱逐、探针失败或人工操作。

QoS 是配置结果而非性能等级

Kubernetes 根据资源配置把 Pod 划入不同 QoS 类别，用于节点压力下的处理优先级。它不承诺网络、磁盘或应用延迟，也不能替代优先级、配额和服务级别目标。

多个容器的 request 与 limit 组合会影响类别。为了获得某一类别而机械地让所有值相等，可能牺牲资源效率。应先确定服务风险和容量策略，再检查配置产生的 QoS 是否符合预期。

命名空间的 ResourceQuota 和 LimitRange 可以约束总量、最小最大值或默认值。默认注入能防止无边界容器，但默认数值不一定适合每个工作负载，应用团队仍要显式校准。

自动扩缩依赖可信的资源基线

水平 Pod 自动扩缩常以 CPU 使用相对 request 的比例计算目标。request 过小会让利用率看似很高并频繁扩容，过大则可能掩盖压力。扩容还受启动时间、就绪探针、节点容量和下游瓶颈约束。

垂直建议工具可以根据历史使用提出 request，但突发、季节和发布变化需要人工判断。自动修改资源可能触发重建，且历史数据不能保证未来峰值。

容量规划要同时看 request 总和、实际分位数、limit、节点预留、系统守护进程和故障余量。正常情况下刚好装满的集群，在一个节点失效时可能没有空间重调度关键 Pod。

用负载试验校准而不是猜测

资源边界应在代表性请求、数据规模和并发下测试。记录吞吐、延迟、CPU 节流、内存工作集、垃圾回收、OOM 和扩缩时序，再逐步调整。

发布新版本可能改变运行时和内存模型，旧基线不能永久复用。每次显著依赖升级或功能变化都应比较资源曲线，并在生产设置告警。

request 和 limit 共同把应用需求翻译为平台决策。只有理解调度、运行时执行和故障恢复三层作用，资源配置才是容量与隔离契约，而不是 YAML 中为了通过检查而填写的数字。

资料依据