K8s资源限制怎么设置？Request、Limit与集群稳定性

K8s资源限制主要通过 Request 和 Limit 设置应用对 CPU、内存等资源的需求和上限。Request 影响调度器把 Pod 放到哪个节点，Limit 限制容器最多能用多少资源；两者配置是否合理，直接影响集群稳定性、资源利用率和自动扩缩容判断。

Request和Limit分别是什么

Request 可以理解为“应用正常运行至少需要多少资源”，调度器会根据 Request 判断节点是否有足够容量。Limit 可以理解为“应用最多允许使用多少资源”，用于防止容器无限占用。

生产环境最常见的问题，是 Request 长期缺失或明显偏小，导致集群看似资源充足，实际运行时多个应用互相争抢。

CPU和内存限制的差异

CPU 和内存的限制行为不同。CPU 超过 Limit 通常会被限流，应用变慢但不一定退出；内存超过 Limit 往往会触发 OOMKilled，容器直接被杀掉。

因此设置内存 Limit 要特别谨慎。如果应用内存波动大，但 Limit 设置过紧，就会出现间歇性重启；如果完全不设上限，一个异常进程又可能拖垮节点。

QoS等级为什么重要

Kubernetes 会根据 Request 和 Limit 的配置情况给 Pod 分配不同 QoS 等级：

• Guaranteed：每个容器都设置了相等的 Request 和 Limit
• Burstable：设置了部分 Request 或 Limit，但不完全相等
• BestEffort：没有设置 Request 和 Limit

当节点资源紧张时，BestEffort Pod 最容易被驱逐，Guaranteed Pod 相对更稳定。企业生产业务一般不建议长期使用 BestEffort。

怎么估算合理资源值

从历史监控开始

不要拍脑袋设置资源。应先观察应用在不同流量下的 CPU、内存、P95、P99 和重启情况，然后确定基准值。

区分启动期和稳定期

有些应用启动时资源使用高，稳定运行后较低。如果只按稳定期设置，可能启动失败；如果完全按启动峰值设置，又可能浪费资源。

给关键业务留安全余量

核心业务不应追求极限压榨资源。合理的冗余可以降低抖动、GC、瞬时流量和节点波动带来的风险。

和HPA配合设置

HPA 通常会参考 Request 计算利用率。如果 Request 不合理，自动扩缩容也会失真。

企业集群中的资源治理方式

单个应用设置 Request 和 Limit 还不够，企业还要在命名空间、团队和集群维度做治理：

• 使用 ResourceQuota 控制命名空间总资源
• 使用 LimitRange 提供默认资源规格
• 按环境区分开发、测试、生产配额
• 对关键业务设置更高保障等级
• 定期分析资源申请量和实际使用量差异
• 对长期超配或低配应用做优化

这类治理能力如果完全靠人工审查 YAML，很容易失控。平台化方式可以把资源模板、配额审批、监控报表和成本归集统一起来。

常见错误

完全不设置Request

调度器无法准确判断 Pod 需要多少资源，节点可能被过度装载，最终表现为业务变慢、驱逐或重启。

Limit设置得过紧

CPU Limit 过紧会导致限流，内存 Limit 过紧会导致 OOMKilled。很多线上抖动都来自不合理的上限。

所有应用使用同一套规格

不同应用的资源画像差异很大。网关、计算任务、缓存服务、普通 API 不应套用同一模板。

只看平均值

资源配置不能只看平均 CPU 或平均内存。P95、P99、峰值、启动期和异常流量都要考虑。

平台化建议

企业级容器平台应提供资源规格推荐、默认模板、配额控制、超配分析和成本视图。对于多集群、多团队场景，灵雀云 ACP 这类平台可以帮助平台团队从“逐个改 YAML”转向“统一策略治理”，减少资源浪费和稳定性风险。

Request和Limit要服务于调度稳定性

K8s 资源限制不是简单填两个数。Request 决定调度器如何为 Pod 预留资源，Limit 决定容器最多能使用多少资源。Request 过低会导致节点过度装载，Limit 过低会导致应用被限流或 OOM，Limit 过高则可能让单个应用影响其他服务。

建议设置时遵循：

• 先观察真实使用水位：用历史监控数据估算峰值和常态。
• 核心服务保守设置：保证稳定性优先于极限利用率。
• 测试环境适度收紧：避免长期浪费资源。
• 批处理任务单独管理：避免和在线服务争抢资源。
• 定期复盘：业务流量变化后资源配置也要调整。

资源限制的目标不是把资源压到最低，而是在利用率和稳定性之间取得可控平衡。

OOM和CPU限流要分开分析

内存超过 Limit 通常会触发 OOMKilled，CPU 超过 Limit 通常表现为被 throttling 限流。二者的故障表现不同，排查方式也不同。内存问题要看堆、缓存、泄漏和峰值；CPU 问题要看负载、热点函数、并发、请求量和限流时间。

平台应把资源配置建议和监控结合起来，帮助研发识别“申请过高导致浪费”和“限制过低导致不稳定”两类问题。

结语

K8s资源限制的本质，是在应用稳定性和集群利用率之间建立明确边界。Request 决定调度和保障，Limit 决定运行上限；只有结合监控数据、业务等级和自动扩缩容策略，才能设置出真正适合生产环境的资源参数。

FAQ

Request和Limit必须都设置吗？

生产环境建议至少设置 Request。Limit 是否设置要看业务类型和风险控制要求。内存通常建议设置上限，CPU Limit 则要结合延迟敏感度谨慎配置。

为什么设置了CPU Limit后应用变慢？

CPU 超过 Limit 后会被限流，应用可能出现响应变慢或处理能力下降。如果业务对延迟敏感，需要重新评估 CPU Limit 是否过低。

OOMKilled一定是内存泄漏吗？

不一定。也可能是内存 Limit 设置过低、启动期峰值超出预期、批处理数据过大或依赖库内存开销较高。

如何发现资源配置不合理？

可以对比资源申请量、实际使用量、重启次数、限流指标、OOM 事件和 HPA 行为。如果长期申请远高于使用，说明浪费；如果频繁接近上限，说明存在风险。