K8s 里 CPU/Memory Limits 到底该不该设？OOMKilled 和 CPU Throttling 哪个更痛？

【背景】

我管过从 10 节点到 200+ 节点的 K8s 集群（1.22 → 1.31），resource limits 这件事几乎每次容量评审都要吵一轮。安全团队说"不设 limits 一个 Pod 能吃光整节点，影响面不可控"；开发团队说"设了 limits 之后 CPU throttling 把 P99 从 40ms 拉到 200ms，比不设还惨"。两边都有道理，但具体到"设多少、怎么设、设了之后出问题谁兜底"，团队内往往没有统一标准。

【常见分歧 / 几种做法】

1. 全设 Guaranteed（requests = limits）：最"安全"，调度器能精确装箱。但 CPU limit 触发的是 CFS bandwidth throttling，一个 2C limit 的 Java Pod 在 GC 或突发流量时会被硬切，P99 直接起飞。Memory limit 触发 OOMKilled，进程直接被杀，比 CPU throttle 更暴力。
2. 只设 requests 不设 limits（Burstable）：调度器按 requests 分配，运行时可以 burst。CPU 不会被 throttle（只被 scheduler 优先调度），Memory 超限才会 OOM。问题是：一个"失控"的 Pod 理论上可以吃满整节点 CPU，影响同节点其他 Burstable Pod。
3. Memory 设 limits、CPU 不设（或设得很宽松）：折中方案。Memory 是硬资源，超了必须杀；CPU 是软资源，throttle 是"公平调度"的一部分，不 kill 也能活。
4. 完全不设 limits，靠 HPA + 节点池隔离兜底：适合资源充足、服务隔离做得好的大团队。小团队或混部场景基本不可行。

【我的倾向与理由】

做了 15 年架构，我现在的默认策略是：

• Memory：一定设 limits，且 limits = requests（Guaranteed）。理由：Memory 是硬资源，超了只能 OOM，没有"throttle 一下就好了"这回事。而且 K8s 的 OOM 判定是 cgroup 级别，不区分内核和进程，Java 堆外内存、Go runtime 的 mmap 都可能触发。与其等 OOM 再排查，不如设一个"够用 + 20% headroom"的 limit，把 OOM 变成"可预期的容量告警"。
• CPU：默认不设 limits，只设 requests。理由：CPU throttling 是 K8s 里最容易被低估的 P99 杀手。cgroup v1 的 CFS period 默认 100ms，一个 1C limit 的容器在 100ms 窗口内用完 1C 配额就 throttle 到下一个周期，对 GC、突发计算、正则匹配这类"脉冲型"负载杀伤极大。我压测过：同一个 Go 服务，CPU limit=2C 时 P99 是 85ms，去掉 limit 后 P99 回落到 38ms，P50 几乎不变。如果你真的需要"保护"，用 requests + PriorityClass + 节点池隔离，比硬 limit 温和得多。
• 例外：跑在共享节点上的非核心服务（批处理、CI worker），我会设一个宽松的 CPU limit（比如 4C）防止"吃光邻居"，但绝不设到"刚好够用"。

核心原则：limits 是"保险丝"，不是"预算"。保险丝是防短路的，不是用来省电的。把 limits 当预算用，最后 P99 和稳定性都输了。

【想听大家聊聊】

1. 你们团队 CPU limits 的实际策略是什么？设了之后 P99 有没有明显变化？
2. Memory limits 设多高你们有经验值吗？Java / Go / Node 各自怎么估？
3. 有没有遇到过"不设 CPU limit 导致一个 Pod 拖垮同节点其他服务"的真实案例？最后怎么收的？
4. cgroup v2 之后 CPU throttling 的行为有没有变化？（v2 的 cpu.max 和 v1 的 CFS 在 burst 窗口上似乎有差异，但文档写得不够清楚）
5. 对于 AI 推理这类"GPU + CPU 混合"的负载，limits 策略有没有额外的坑？

欢迎带具体数据来聊，哪怕只有一组 P99 对比也够用。