容器内存 limit 到底该设成多少？limit=requests、2×requests 还是干脆不设？

背景

最近给一个 200+ Pod 的 K8s 集群做容量审计，发现一个很有意思的现象：同一个团队的 Java 服务，A 团队 limit=requests，B 团队 limit=2×requests，C 团队干脆不写 limit 只写 requests，D 团队 limit=requests 但 requests 直接拍脑袋定。四种做法都有，没有一种是"错的"，但在同一个集群里混着跑，调度器和 kubelet 看到的世界是完全不同的。

我最近一次线上事故，根因就藏在这个分歧里：一个 Go 服务，requests=512Mi、limit=1Gi（2×），平时 RSS 稳定在 600Mi，看起来"很安全"。某次上游推送一批大对象，RSS 在 30 秒内从 600Mi 飙到 980Mi，还没到 1Gi 的 limit，cgroup 的 memory pressure 已经触发 page cache 回收，P99 从 18ms 抖到 140ms——limit 没爆，但"安全余量"被 page cache 吃掉了。这不是 OOMKilled，但比 OOMKilled 更隐蔽。

社区里的几种流派，我观察到至少四种

• 派 A「limit=requests」：最保守，调度器和 kubelet 看到的世界一致，Pod 不会"超卖"。代表：很多金融、合规强要求的团队。优点是资源可预测，缺点是Java 堆外内存、Go runtime 的 GC headroom、page cache 这些"合法波动"会被 OOM 杀掉——我见过 limit=requests 的 JVM 服务，堆设 512Mi、limit 也 512Mi，Metaspace 一涨就 OOM。
• 派 B「limit=2×requests」：留一倍余量给波动。代表：很多互联网团队。优点是给 GC、page cache、临时对象留空间，缺点是调度器按 requests 算，实际可能用到 2×，节点超卖时邻居 Pod 互相挤，CFS 节流和内存压力都会放大。
• 派 C「只写 requests，不设 limit」：完全弹性，Pod 可以用到节点上所有可用内存。代表：一些"信任内核调度"的团队。优点是简单、不 OOM，缺点是一个失控的 Pod 可以拖垮整个节点，尤其在混部场景下，高优先级 Pod 会被低优先级的"内存大户"挤出去。
• 派 D「按语言/运行时分策略」：Java 用 2×、Go 用 1.5×、Node 用 1.2×、C++ 用 1×。这是我现在最倾向的做法，下面展开。

我的倾向与理由

我倾向派 D + 一条硬底线：limit 不是"拍一个倍数"，而是从运行时的内存模型反推。

判断标准我一般看三条：

1. 运行时是否有"合法波动"。JVM 的 Metaspace、DirectByteBuffer、GC headroom 都是合法波动，limit 必须给空间；Go 的 GC 是增量的，headroom 相对小；C++ 的内存基本是确定的。波动越大，limit 越要留余量。
2. 是否有 page cache 依赖。读大文件、做数据预热的服务，page cache 是性能的一部分，limit 必须给 page cache 留空间——否则 page cache 被回收，P99 抖动。
3. 节点超卖比例。如果节点超卖 2×（requests 总和 = 节点容量 × 2），那 limit 不能是 2×requests，否则一个 Pod 波动就吃光节点。超卖比例和 limit 倍数必须联动，这是我见过最多团队忽略的。

落到操作上，我团队的规矩：

• Java 服务：limit = 堆大小 × 1.5 + Metaspace × 1.2 + DirectMemory + 256Mi（page cache 余量）。不是 2×requests，是从堆配置反推。
• Go 服务：limit = RSS 稳态 × 1.3 + 128Mi。Go 的 GC headroom 小，不需要 2×。
• limit 必须在 CI 里校验：Helm chart 里加一个 kubectl dry-run + 自定义 lint，limit < requests 直接 fail。
• 季度做一次 RSS 审计：kubectl top pod + cgroup v2 memory.current 对比，limit 长期 < 实际 RSS × 1.1 的 Pod 必须调。

想听大家聊的

1. 你们团队现在 prod 里 limit 和 requests 的比例是多少？是统一倍数还是按服务分？
2. 有没有 limit 没爆但 P99 抖了的案例？（page cache 被回收、CFS 节流这类"软 OOM"）
3. 你们节点超卖比例是多少？limit 倍数和超卖比例有没有联动过？
4. 派 C「不设 limit」在你们团队能落地吗？混部场景下谁敢这么干？
5. 有没有用 VPA（Vertical Pod Autoscaler）替代人工定 limit 的？推荐还是踩坑？

欢迎贴你们的 limit 配置和 RSS 监控数据，数字比观点更有用。