K8s resources 到底怎么设：requests/limits 是"必答题"还是"选答题"？

背景

干了 8 年嵌入式出身，习惯了"资源就是钱"——MCU 上每 KB 的 RAM、每个周期的 CPU 都要算清楚，超了就掉进 hard fault，没有"再给点"的余地。后来转容器化和 K8s 运维，反而发现一个更魔幻的现象：同一个集群里，有人 resources 一行不写，有人 requests 和 limits 设成一样，有人 limits 是 requests 的 2 倍、有人 4 倍，还有人干脆只设 CPU limits 不设 memory limits。同一个调度器、同一个内核，写法五花八门，但大家似乎都"跑得挺好"。

直到一次真实事故：某服务没设 memory limit，宿主机内存压力触发 OOM killer，杀的不是它自己——是邻居容器里 JVM 的 metaspace 撑爆。事后复盘，锅其实不在代码，而在"limits 到底该怎么设"这件事上，我们从来没有过一次认真的团队讨论，全是抄的别人博客。

常见分歧（我看到的至少四种做法）

1. 激进派：requests = limits（Guaranteed QoS）。理由：可预测性最高，不会被邻居挤兑；缺点：调度器按 requests 装箱，limits 等于 requests 意味着"你申请多少就给你多少，一点弹性都没有"，突发流量直接 OOMKill。
2. 务实派：limits = 2× requests（Burstable QoS）。理由：留 100% 突发余量，绝大多数业务够用；缺点：这个"2"是拍的，没有依据。
3. 保守派：只设 requests，不设 limits。理由：K8s 官方文档暗示 limits 会触发 OOMKill，不设反而让内核 OOM killer 更"公平"地挑；缺点：宿主机被打满时，OOM 选谁杀全凭内核心情，不可控。
4. 躺平派：什么都不设。理由：小集群、信任应用自己；缺点：一个内存泄漏就能带走整台宿主机。

我的倾向（带理由，欢迎拍砖）

我现在的默认策略是：CPU 设 requests + limits（limits ≈ 峰值压测的 1.5×），memory 设 requests（≈ p99 实际占用 + 20% 余量）+ limits（≈ 2× requests，但绝不超过宿主机单核能承载的上限）。核心考虑是落地成本——limits 设太紧，一次 GC 抖动就是 OOMKill；设太松，等于没设。所以我会用压测数据 + 一周线上 p99 取 max，再留 20% 余量。关键不是那个倍数，而是"这个数字有压测依据"，而不是抄博客抄来的 2。

想听大家聊聊

• 你们团队对 limits 的态度是"必设"还是"可选"？有没有明文规范？
• 突发型负载（比如批处理、报表生成）和稳态型负载（API 服务），你们会设成同一套比例吗？
• 有没有"limits 设了反而更惨"的真实案例？想听听具体数字，不只是结论。
• 你们用 cAdvisor / Prometheus 的 working_set 还是 RSS 做 p99 依据？这两个数差多少？

期待不同规模（3 节点自建 vs 几十节点托管集群）的同学都来聊两句，我想看看"规范"到底是不是规模到了一定阈值才值得写。