【背景】 我在 K8s 上跑过 40+ 业务服务，踩过的最典型的坑有两个，恰好互相打架：
- 一个没设 limits 的批处理服务，一次内存泄漏把整个节点 64G 吃光，node 上 7 个在线服务跟着被 OOMKill，告警一片红，根因却只有一个没设 limit 的离线任务；
- 另一个在线服务设了 memory limit 2Gi，平时 RSS 1.6G 很稳，一次上游流量尖峰 RSS 冲到 2.1G，直接被内核按 limit 杀掉，重启又冷启动 30s，比「不杀它让它挤一挤」损失大得多。
这两个事故让我意识到：limits 不是一个「配不配」的开关，而是一个「什么时候杀、杀谁、值不值」的策略选择。
【常见的几种做法】
- 一刀切配 limits：request=limit（Guaranteed 类），集群最干净，调度器最听话，代价是每个服务都要按峰值留余量，平时 CPU/内存大量闲置；
- 只设 request 不设 limit（Burstable 类）：节点超卖度高、资源利用最好，代价是出了内存泄漏的进程会拖到 OOM 才被发现，且受害者可能是同节点无辜邻居；
- 只给「已知会泄漏/重计算」的离线、批处理、AI 推理任务配 limit，在线服务全部 Burstable——用「任务画像」代替「统一策略」；
- 全配 limits，但用 limit 之外的手段兜底：cgroup v2 的 memory.high 做软限告警、节点级 eviction 阈值、PodDisruptionBudget 防止雪崩。
【我的倾向与理由】 我倾向第 3 种，核心论据是：limits 的本质是「把单进程的故障半径从节点缩到 Pod」，它的价值大小完全取决于该进程故障时会不会伤及无辜。
- 在线、多副本、可快速重启的服务：故障半径天然被副本隔离，OOMKill 一两个 Pod 比「全节点陪葬」便宜，Burstable + 节点级 eviction 阈值就够了；
- 单副本、离线、批量任务：故障半径就是整个节点，必须用 limit 把「谁先死」的权力从内核手里拿回来——内核 OOM 是按 oom_score 挑的，业务上你没法控制它先杀谁，但 limit 可以。
换句话说，limits 不是给「健康的进程」买的保险，是给「可能失控的进程」买的保险。给在线服务配 limit 反而引入了第二种故障模式：内核在 RSS 触顶那一刻精确杀人，而业务其实还能扛。
还有一个被我忽略太久、但这两年越来越重要的点：cgroup v1 到 v2 的迁移改变了 OOM 的触发路径（v2 下 memory.oom.group 默认行为、eviction 优先级），同一份 YAML 在两种内核上的「谁会先被杀」可能完全不同。你们生产集群现在跑的是哪套 cgroup？
【想听大家怎么选】
- 你的集群里在线服务是 Guaranteed 还是 Burstable？为什么？
- 有没有遇到过「设了 limit 反而比不设置更容易 OOMKill」的具体案例？触发 RSS 和 limit 的差值大概多少？
- 离线任务和在线服务混布时，你们靠什么保证「先死的是离线」？纯靠 limit 还是加了别的机制（taint/拓扑/独立池）？
- cgroup v2 迁移后，有没有观察到 OOM 行为变化导致「以前没事、现在频繁被杀」的情况？
0赞
0收藏
0楼层