容器资源限制怎么配置，是 Kubernetes 生产环境最容易被低估的问题之一。Request 写得太小，会让调度器误以为节点还有很多容量，结果运行时发生资源争抢；Limit 写得太紧，应用会被 CPU 限流或内存 OOM；完全不写资源配置，又会让单个应用影响整台节点稳定性。资源配置不是 YAML 里的形式字段，而是调度、扩缩容、稳定性和成本之间的共同约束。
很多团队在早期会直接复制模板，例如所有 Java 服务都写 500m CPU、1Gi 内存。这个做法可以作为起点，但不能长期替代资源画像。生产环境需要根据真实流量、启动峰值、GC行为、批处理并发和历史监控持续校准。
Request和Limit分别控制什么
Request 主要影响调度。调度器根据 Pod 的资源 Request 判断某个节点是否有足够可分配资源。它不是保证应用永远只能使用这么多资源，而是告诉 Kubernetes 这个容器至少需要多少资源才能合理运行。
Limit 主要影响运行时边界。CPU Limit 会限制容器可使用的 CPU 上限，内存 Limit 则定义容器可使用的内存上限。超过内存 Limit 时，容器可能被 OOMKilled；CPU 超过 Limit 时，通常表现为被限流，应用延迟上升但进程不一定退出。
因此，Request 太低会影响集群整体稳定，Limit 太低会影响应用自身稳定。资源治理要同时考虑调度层和运行时层，不能只看其中一个字段。
CPU配置不要只看平均值
CPU Request 的设置要参考稳定负载、峰值波动和扩容策略。对于在线服务，如果日常 CPU 使用在 300m 左右，峰值在 800m，直接把 Request 写成 100m 会让调度过度密集；如果写成 800m，又可能造成资源利用率偏低。更合理的做法是结合服务等级、延迟敏感度和 HPA 策略设定。
CPU Limit 是否设置，需要结合场景判断。对延迟敏感的在线服务，过低 CPU Limit 可能造成 CFS throttling，表现为 CPU 使用率看似没有打满，但请求延迟明显增加。对批处理任务，设置 Limit 可以防止任务抢占过多资源。对核心服务，可以先通过 Request 和节点池隔离保障资源，再谨慎设置 Limit。
可以用以下命令观察容器资源使用：
kubectl top pod -n <namespace>
kubectl describe pod <pod_name> -n <namespace>如果监控系统支持，还应查看 CPU throttling 指标，而不是只看 CPU 使用率。
内存Limit要关注峰值和增长趋势
内存与 CPU 最大的区别是不可压缩。CPU 不够通常表现为变慢，内存超过 Limit 则可能直接 OOM。设置内存 Limit 时，要考虑应用启动峰值、缓存、语言运行时、连接池、批处理数据和异常流量。
Java、Go、Node.js 等不同运行时对内存的使用方式不同。Java 服务还要考虑堆内、堆外、线程栈、元空间和容器感知参数。只把 JVM 最大堆设置为容器 Limit 的同等大小，很容易忽略堆外内存，最终仍然 OOM。
内存 Request 可以反映应用稳定运行所需的基础内存，内存 Limit 则应留出合理峰值空间。对核心在线服务，不建议为了节省少量资源把 Limit 压得过低；对批处理任务，则要防止单任务异常占用过多节点内存。
QoS等级会影响驱逐优先级
Kubernetes 会根据资源配置把 Pod 划分为 Guaranteed、Burstable 和 BestEffort。Guaranteed 表示每个容器都设置了 CPU 和内存 Request、Limit，且 Request 等于 Limit；BestEffort 表示没有设置资源；介于两者之间的是 Burstable。
当节点发生资源压力时，不同 QoS 的 Pod 被驱逐优先级不同。BestEffort 风险最高，Burstable 根据资源使用与 Request 的关系判断，Guaranteed 相对更稳定。但 Guaranteed 并不意味着一定更适合所有业务，因为 Request 等于 Limit 可能降低资源弹性。
生产环境通常不建议关键服务使用 BestEffort。多数在线服务可以采用 Burstable，通过合理 Request 保证调度基线，再通过 Limit 或节点池策略控制风险。对于极关键基础组件，可以评估 Guaranteed 或专用节点池。
资源配置会影响HPA
HPA 使用 CPU 利用率指标时，通常会基于 CPU Request 计算利用率。如果 Request 写得过低，HPA 会过早认为 CPU 利用率很高，从而频繁扩容；如果 Request 写得过高，HPA 可能迟迟不扩容。很多 HPA 抖动问题，本质上是资源 Request 不准确。
这意味着自动扩缩容不是资源治理的替代品，而是依赖资源治理。上线 HPA 前，应先校准 Request，并观察扩容后下游依赖是否能承接新增并发。否则扩容可能只是把压力从应用转移到数据库、缓存或消息队列。
一套生产校准流程
建议按四步建立资源校准流程。第一步收集历史监控，至少覆盖工作日、周末、活动峰值和发布窗口。第二步区分启动资源、稳定资源和峰值资源。第三步按服务等级设置默认区间，例如核心在线服务、普通在线服务、后台任务、批处理任务分别使用不同策略。第四步在上线后持续观察 OOM、CPU 限流、Pending、节点水位和扩缩容行为。
资源配置不是一次性完成的。业务流量、代码版本、依赖服务和数据规模都会变化。平台团队可以定期输出资源建议，但最终要与业务负责人确认服务等级和成本目标。
常见误区
不要只为了提高利用率而压低 Request。短期看节点装得更多，长期看会造成资源争抢和排障复杂度上升。不要把 Limit 当成万能保护，过低 Limit 会直接制造稳定性问题。不要用平均值配置所有服务，平均值会掩盖峰值、启动和异常场景。
也不要把资源配置完全交给业务团队自由填写。平台应提供默认模板、建议范围和异常检测，业务团队负责根据应用特性调整。资源治理需要平台和业务共同负责。
常见问题
CPU Limit一定要设置吗？
不一定。对于延迟敏感的在线服务，过低 CPU Limit 可能造成明显限流，反而影响体验。可以先设置合理 CPU Request，并结合节点池和 HPA 控制资源，再根据企业治理要求决定是否设置 Limit。对于批处理、低优先级任务或容易抢占资源的任务，CPU Limit 更有必要。
内存Limit可以不设置吗？
生产环境通常建议设置内存 Limit，因为内存不可压缩，异常增长可能影响节点上其他 Pod。但 Limit 不能拍脑袋设置，要留出启动和峰值空间。频繁 OOM 时，不应只简单增大 Limit，还要排查内存泄漏、缓存策略和运行时参数。
Request越高是不是越稳定？
Request 越高，调度层面获得的资源预留越多，但也会降低集群利用率，并可能让 Pod 因资源不足而 Pending。合理 Request 应基于真实资源画像，而不是越高越好。关键服务可以提高保障等级，但仍要结合成本和容量规划。
如何发现资源配置不合理？
可以观察几个信号：Pod 经常 OOMKilled、CPU throttling 明显、HPA 频繁扩缩容、Pod 长时间 Pending、节点资源水位很高但业务仍慢、同类服务资源差异过大。这些都说明资源配置需要重新评估。
结语
容器资源限制配置的核心，是让调度器、运行时和平台治理看到接近真实的资源需求。Request 影响调度与扩缩容，Limit 影响运行边界和故障隔离。只有基于资源画像持续校准，才能在稳定性、成本和弹性之间取得平衡。
转载请注明出处：https://www.cloudnative-tech.com/p/7477/
