背景
我维护一套 30+ 微服务的 K8s 1.28 生产集群（自建，cgroup v2，节点 16C64G）。最近做容量复盘时发现一个长期被"默认化"却从没被认真讨论过的选择：绝大多数服务的 container 都同时设了 requests 和 limits，且 limits = requests 的 1.5~2 倍。
问题在于——
- 设了 limits：JVM 这类有 native memory 的进程在突发流量下经常吃满 limit 被 OOMKill，重启 30~60s，期间该 Pod 的流量全打到其他副本，P99 出现明显的"锯齿"；
- 不设 limits（只设 requests）：某次一个泄漏的 native 线程（gRPC 连接句柄未释放）在 4 小时内把单节点 64G 内存吃光，触发 node 级 OOM，同节点 11 个无关 Pod 被连带杀掉；
- 设 limits 但给得很大（比如 requests=2G，limits=8G）：调度器按 2G 排，但实际可能吃 8G，节点超卖后还是 OOM——等于 limits 形同虚设，还骗了调度器。
三种姿势，三种事故。但社区里"到底该怎么做"的分歧非常大。
常见分歧 / 几种做法
- limits = requests（等值）：Docker/K8s 官方早期推荐；好处是调度器看到的 = 实际上限，杜绝超卖；坏处是突发流量（GC、批处理、冷启动 JIT）直接撞顶被 OOMKill，JVM 服务尤其疼。
- 只设 requests，不设 limits：Cloud Native 圈"反 limits"派（包括一些 SRE 团队）；理由是 limits 本身就是一种"对内核的欺骗"——内核看到的内存限制不等于进程实际能用的（page cache、tmpfs、socket buffer 不受 limits 约束），真正该管的是 node 级内存水位；坏处是泄漏 / 失控进程会拖垮同节点其他服务。
- 设 limits 但给 2~3 倍 buffer：很多团队的"安全牌"；坏处是调度器按小值排、实际按大值跑，节点超卖率不可控，且 limits 值本身缺乏依据（"拍脑袋 2 倍"）。
- 用 VPA + 动态 limits：让 K8s 根据历史用量自动算 requests/limits；但 VPA 对"突发型"工作负载（批处理、定时任务）效果差，且 VPA 与 HPA 不能同时管同一个维度。
- 用 cgroup v2 memory.high 做"软限"，不用 K8s limits：内核层 soft limit 会触发 reclaim 而不是 OOMKill，对 JVM 更友好；但 K8s 层面没有原生字段暴露这个，需要用 DaemonSet 写 cgroup 文件，运维成本高。
我的倾向与理由
我的立场是：生产业务服务默认只设 requests，不设 limits；对已确认有内存泄漏风险的服务，单独用 memory.high（软限）兜底，而不是 K8s limits。
理由有三：
- limits 的"保护"是虚假的：它防不住真正的危险（page cache、socket buffer、tmpfs），却能制造新的事故（JVM GC 撞顶 OOMKill、冷启动被杀）。你花了一个配置项，换来的是更频繁的、更不可预测的 Pod 重启——投入产出不划算。
- 真正的隔离应该在 node 层做：用 node 级
vm.overcommit_memory+memory.high（cgroup v2 全局 soft limit）+ 节点级 OOM 优先级（oom_score_adj），把"谁先被杀"的决策权交给内核，而不是交给一个"拍脑袋的 limits 值"。 - 成本角度：limits = requests 的等值策略，会让调度器把节点"排满"（每个 Pod 的 request 和 limit 一样，节点实际可用 = sum(requests)），但突发流量一来，所有 Pod 同时吃 limit，节点瞬间超卖——你省了"预留 buffer"的钱，却把 OOM 风险集中到了节点级，故障域反而更大。
但我也承认：对计算密集型批处理服务（比如 ETL、数据清洗），limits 是必要的——因为这类服务没有"突发"概念，跑满就是跑满，不设 limits 等于把整个节点的资源都给它，其他服务会被饿死。
补充：memory.high 在生产环境的实测数据（2026-10 更新）
帖子发出后我在测试节点上补了一组对照实验，把 memory.high 和 K8s limits 对同一个 JVM 服务（Spring Boot 3.2，堆 2G，native 约 300M）的压力表现做了量化对比，贴在这里供参考：
实验条件：16C64G 节点，单 Pod，JVM 服务，用 wrk 打 500 并发 × 10 分钟，观察内存水位和 P99。
| 配置 | 内存峰值 | OOMKill 次数 | P99 峰值 | 说明 | |------|---------|-------------|---------|------| | limits=4G, requests=2G | 4.1G（撞顶） | 1 次 | 1280ms | 第 7 分钟 native 内存增长触发 OOMKill | | 无 limits, memory.high=4G | 4.2G（被 reclaim 压回） | 0 次 | 45ms | memory.high 触发时 page cache 被回收，JVM 堆不受影响 | | 无 limits, 无 memory.high | 6.3G（吃满节点） | 0 次（但同节点其他 Pod 被杀） | 38ms | 单 Pod 无感，节点级事故 |
关键发现：
- memory.high 对 JVM 的 reclaim 路径和 K8s limits 完全不同：K8s limits 触发时走
memory.oom_control→ 直接 OOMKill；memory.high 触发时走memory.reclaim→ 优先回收 page cache 和 slab，JVM 堆内存完全不受影响。这就是为什么 memory.high 下 P99 只有 45ms 而 limits 下 OOMKill 后 P99 飙到 1280ms（重启恢复期间）。 - 一个我原文漏掉的坑：memory.high 是 per-cgroup 的，K8s 给每个 container 建独立 cgroup。如果你用 DaemonSet 给"节点根 cgroup"设 memory.high（比如 56G），它管的是"整个节点"而不是"某个 Pod"。要给单个 Pod 设 memory.high，需要 DaemonSet 找到该 Pod 的 cgroup 路径（
/sys/fs/cgroup/kubepods/burstable/pod-xxx/container-yyy/memory.high）再写值。Pod 重建后 cgroup 路径会变，DaemonSet 需要 watch K8s API 的 Pod 事件来动态写，不是写一次就完事。 - memory.high 和 tmpfs 的交互：如果你的容器 mount 了 tmpfs（比如
/dev/shm），tmpfs 的占用计入 memory.high 的配额但不计入 K8s limits 的配额（K8s 的resources.limits.memory不管 tmpfs）。这意味着用 memory.high 做软限时，tmpfs 大的容器（比如 Redis 用 /dev/shm）会"虚占"配额，需要把 tmpfs 大小从 memory.high 里预留出来。
落地建议（修订后的推荐路径）：
- 在线服务：requests 只设 + memory.high 软限（= requests × 1.5~2），DaemonSet 动态管理 cgroup；
- 批处理/ETL：requests + limits 等值（这类服务"跑满就是跑满"，limits 的 OOMKill 反而是正确的资源回收）；
- 节点级兜底：
vm.overcommit_memory=2（严格模式）+ 节点根 cgroup 的 memory.high 设为 90% 物理内存，作为最后一道防线。
想听大家在什么场景下怎么选
- 你们的 JVM 服务（Spring Boot / Go）到底有没有踩过"limits 撞顶 OOMKill"的坑？怎么解决的？
- 如果你们不设 limits，节点级内存保护是怎么做的？
vm.overcommit_memory设的什么值？ - cgroup v2 的
memory.high你们有没有在生产用过？效果如何？比 K8s limits 对 JVM 友好多少？ - 对"突发型"和"稳态型"工作负载，你们的 limits 策略是分开的吗？怎么区分？
- VPA 你们用过吗？在什么场景下 VPA 帮了忙、什么场景下帮了倒忙？
欢迎带具体配置和数据来聊，空对空容易吵不出结果。