K8s 上 JVM 服务内存 limit 怎么定？堆外 + 节点开销没算清导致频繁 OOMKilled

背景 我在一个 1.28 的 K8s 集群（containerd 1.7，节点 16C64G，跑 Java 17 / Spring Boot 3 的无状态服务）里，团队之前按「limit = 2 × 堆」的土办法给 Pod 设内存：JVM 配 -Xmx4g，Pod limit 设 8Gi。结果过去一个月同一个 Deployment 触发 OOMKilled 11 次，重启后 10~30 分钟内再炸，明显不是偶发泄漏。

现象

• kubectl describe pod 显示 Last State: Terminated, Reason: OOMKilled，Exit Code: 137；
• 炸前 kubectl top pod 看到的 USED 已经贴近 8Gi，但 jstat / JMX 里 Heap Used 长期只在 2.5~3.5G，堆没满；
• pmap 抓下来的 RSS 比 -Xmx 高出约 1.8G，大头在 Metaspace（~1.2G）+ DirectBuffer（~0.4G）+ 线程栈（~0.2G，220 线程）+ JIT CodeCache（~0.15G）；
• 节点 cgroup memory.events 里 oom_kill 计数和 Pod 重启次数对得上，说明是 cgroup 级 OOM，不是 JVM 自己抛 OOM。

已尝试的排查

1. 把 -Xmx 从 4g 降到 3g、limit 不动 → 缓解了 2~3 天又炸，没根治；
2. 把 limit 直接拉到 12Gi → 一周没炸，但节点其它 Pod 被挤走，运维不答应；
3. 给 Metaspace 加 -XX:MaxMetaspaceSize=512m → RSS 峰值降了 0.7G，但 DirectBuffer 那块还是随流量浮动，没法定死；
4. 看了一圈 container_memory_rss 和 container_memory_working_set_bytes，两个指标差 200~400MB，不确定 K8s 驱逐/OOM 到底看哪个。

期望得到的答案形态

1. 一个可复现的公式或经验值：给定 -Xmx、JDK 版本（17）、线程数、是否用 NIO DirectBuffer，怎么算 Pod 的 request / limit？希望包含 Metaspace / DirectBuffer / CodeCache / 线程栈各自的预算项，以及节点侧（kubelet / runtime / OS page cache）要预留多少；
2. 监控上应该盯哪个指标（RSS vs working_set vs JVM Heap）来判断「离 OOMKilled 还有多远」，以及对应的 Prometheus 告警规则写法；
3. 对于 DirectBuffer 这种随流量浮动的堆外内存，有没有比「拍脑袋留 buffer」更工程化的做法（比如 -XX:MaxDirectMemorySize 上限 + 监控、或干脆换 Reactor 模型）；
4. 顺带问一句：ZGC / Shenandoah 在容器里对堆外内存的占用有没有实际可感知的差异，还是只影响 GC 停顿？

最好能贴一段真实 YAML / JVM 参数 / PromQL 作为参考，空对空的「留点余量」就略过了。