K8s 资源 limit 到底要不要设？三种流派吵了三年还没吵出结论

楼主苏砚舟

Kubernetes云原生资源调度QoScgroup

先抛结论（我目前的倾向，欢迎打脸）：对绝大多数有状态、长生命周期的后端服务，limit 应该设；对批处理、Spark、ML 训练这类任务型负载，limit 不该设，甚至应该用 Burstable + request 兜底。但社区里这三种流派谁也没说服谁，我开这个帖就是想收集不同场景下的真实取舍。

背景。K8s 的资源模型是 request 决定调度、limit 决定运行时上限，两者解耦是设计上的亮点，也是实践上的坑。我见过三类典型姿势：

流派 A「双 1:1」：request 和 limit 设成一样，跑 Guaranteed QoS。理由是 QoS 等级高、节点压力下 OOMKiller 不会先杀我们、CPU 不会被邻居抢。代价是：JVM 应用冷启动 JIT 预热期 CPU 需求会瞬时冲到稳态的 2–3 倍，limit 卡死之后表现为「P99 抖动 + CPU throttling」，CPU Throttling 的指标 cgroup 里 cpu.stat 的 nr_throttled 会持续上涨，但应用侧完全感知不到，只能从延迟反推。

流派 B「只设 request」：limit 不写，跑 Burstable。理由是 limit 本质是「人为给业务划天花板」，而业务的真实峰值你根本不知道，设了就是埋雷。代价是：节点压力大的时候，没有 limit 的 Pod 会吃到节点剩余资源，一旦 OOM，K8s 的 OOMKiller 选择顺序在 1.25 之后是按 oom_score 算的，Burstable 的 oom_score 计算方式对大内存 Pod 并不友好，容易被误杀。

流派 C「只设 limit、不设 request」：调度按 limit 算，运行时按 limit 卡。这个流派我实际只在早期项目里见过，问题最明显——调度器把 Pod 铺满之后，节点实际可用资源可能远小于 limit 之和，一旦大家同时跑满直接集体 OOM。

我的倾向与理由：

后端服务（QPS 稳定、可压测）：双设，且 limit = 压测 P99 × 1.5，给 JIT、GC、突发流量留 buffer。CPU 的 limit 对 Java 应用是双刃剑，但内存的 limit 几乎必须设，否则 OOM 就是节点级事故。
批处理 / Spark / ML 训练：只设 request，limit 留空，让任务自己吃满节点。这类负载本来就是「跑完就走」，throttling 反而是损失。
关键判据：看 cpu.stat 的 nr_throttled 和 memory.events 的 oom 计数。前者高说明 CPU limit 太紧，后者出现说明内存 limit 已经救不回来了。

想听大家说：

你们生产环境里，CPU limit 和内存 limit 的设定策略分别是什么？是按容器、按工作负载类型，还是按 QoS 等级？
有没有人真的跑过「不设 limit + 节点级 cgroup 兜底」这套？效果如何？
JVM 应用的 limit 你们怎么算的？-XX:MaxRAMPercentage 和 limit 的关系你们怎么对齐？
有没有人因为 limit 设错背过锅？（欢迎匿名吐槽）

我会在本帖持续更新我这边收集到的案例，包括一段 cgroup v2 下 throttling 的观测脚本。

赞 0 · 收藏 0 · 楼层 1

楼层

#20 苏砚舟

补充一个 K8s 侧的量化判据，跟帖里 cpu.stat / memory.events 的观测思路对齐：

Guaranteed QoS 的「隐性代价」——节点级 OOM 时的 kill 顺序： K8s 1.25+ 的 OOMKiller 按 oom_score 排序，但 oom_score 的计算是 oom_score_adj + 实际内存用量 / 总内存。Guaranteed Pod 的 oom_score_adj = -1000，但这是「保护」不是「豁免」——如果节点 cgroup 整体 OOM（不是单 Pod 超限），Guaranteed Pod 也会被杀，只是最后被杀。

实操建议：对关键服务，除了 limit 之外，加一层「节点级 cgroup 兜底」：

# node-level cgroup（/sys/fs/cgroup/kubepods.slice/ 下）
# 限制所有 Pod 的内存总和不超过节点物理内存的 85%
# 剩下 15% 留给 kubelet、systemd、page cache
MemoryMax: 85%

这样即使所有 Guaranteed Pod 同时跑满，节点也不会 OOM，OOMKiller 有「选择权」而不是「被迫杀」。

量化判据：

node_memory_MemAvailable / node_memory_MemTotal < 0.10 持续 5 分钟 → 告警
container_oom_events_total 5 分钟 > 3 → 立即介入
node_cpu_throttled_seconds_total 增量 / node_cpu_seconds_total 增量 > 0.3 → CPU limit 太紧

这条跟帖里「看 cpu.stat 的 nr_throttled 和 memory.events 的 oom 计数」完全一致，只是把判据量化到了 Prometheus 指标层面。