K8s 共享 Pod 里 Java 服务 + Envoy sidecar：主容器堆监控全绿，Pod 还是 OOMKilled——sidecar 内存怎么观测和预算？

【背景】 我在一个 K8s 1.28 集群（14 节点，16C64G，cgroup v2，containerd 1.7）里跑一套 Java 17 无状态订单服务。Pod 里有两个容器：

• 主容器：Java 17 / Spring Boot 3，request=2C/4G，limit=2C/4G，-Xmx3.5g -XX:+UseG1GC
• sidecar：Envoy（Istio 1.19），request=0.5C/512M，limit=0.5C/512M Pod 总 limit = 2.5C / 4.5G。日均 QPS 约 5000，峰值约 12000。

社区里「Java 堆没满但 OOMKilled」的文章和提问已经很多（比如 id=166 那篇堆外内存预算复盘讲得很细），但我们的问题不在 Java 进程自身——主容器 heap 峰值 3.2G / 3.5G、GC 干净、没有 Full GC，我怀疑内存是被 sidecar 吃掉的，但 sidecar 的 RSS 在主容器的监控体系里完全不可见。

【现象】 过去两周，该 Pod 每天被 OOMKilled 1~2 次（dmesg 显示 cgroup OOM，不是 JVM 自己抛 OOM）。但：

• 主容器 JVM 监控全绿：heap 峰值 3.2G / 3.5G，GC log 干净，没有 Full GC，Metaspace 稳定；
• sidecar 的 Envoy /stats/prometheus 看不到异常：heap_allocated 稳定在 180~220M，downstream_cx_active 正常；
• 节点内存水位正常（<60%），不是节点级压力；
• 复现不出来：自己压测到 2 万 QPS 也没触发，只在生产真实流量下偶发。

【已尝试的排查与结果】

1. 把主容器 -Xmx 从 3.5g 降到 3.0g，无效，照样 OOMKilled——说明问题不在 Java 堆；
2. 查 sidecar Envoy stats，heap_allocated、heap_used 都在正常范围，看不到内存膨胀；
3. 看节点内存水位，正常；
4. 抓 dmesg 只看到 cgroup OOM 事件，看不到具体是哪个进程 / 哪个 cgroup 吃掉了内存——sidecar 的 RSS 在主容器的监控里完全不可见；
5. 怀疑是 Envoy 的 connection buffer / upstream buffer 在突发流量时膨胀（Istio 默认 per_connection_buffer_limit_bytes=1MiB，连接一多就放大），但抓不到现场；
6. 想直接 cat /sys/fs/cgroup/.../memory.current 看 sidecar 容器的实际 RSS，但不知道 cgroup v2 下 sidecar 容器的 cgroup 路径怎么找、怎么和 Pod cgroup 区分。

【期望得到的答案形态】

1. cgroup v2 下怎么观测 sidecar 容器的实际内存用量（RSS，不是 limit）？ 具体命令 / 路径是什么？（比如 memory.current、memory.stat 在容器内的 cgroup 路径怎么找？有没有比"进容器 cat"更好的办法？Prometheus / cAdvisor 能不能按容器粒度抓？）
2. Pod 内存 limit 应该怎么预算？ 主容器 + sidecar 的内存预算公式是什么？特别是 Envoy sidecar 的 buffer 内存（connection buffer、upstream buffer、route cache 等）怎么估？有没有一个"sidecar 内存预算 checklist"可以照着做？
3. 如果 sidecar 的内存用量不稳定（突发流量时 Envoy buffer 膨胀），怎么防止它"偷走"主容器的内存配额？ 有没有 sidecar 内存隔离的具体做法？（比如 cgroup memory.high、Istio 的 resourceLimits、还是必须拆成两个 Pod？）
4. 踩过类似坑的同学，欢迎直接甩你们当时的排查路径和最终解法，哪怕没定位到根因、只排除了哪些方向，也对我很有用。

【相关阅读】

• id=166《容器 OOMKilled 但 Java 堆没满：一次堆外内存撞穿 memory limit 的预算复盘》——讲的是 Java 进程自身的堆外内存，我们的问题在 sidecar 侧，思路类似但对象不同。