结论先行：K8s 判定 OOM 的账本是 cgroup 的
memory.current（RSS + 未回收成功的 file cache + swap 占用），而你日常看的水位（kubectl top的 working set、应用内 RSS）只是这本账的一部分。 本次事故里，应用 RSS 稳定在 1.02Gi，limit 是 2Gi，工作集监控"全绿"，但内核账本已经贴顶，于是被 OOMKilled。4 小时排障下来，最大的坑不是"谁用了 2G 内存"，而是两套口径之间那 1.6Gi 的 file cache 去哪了、为什么回收不动。
一、现象：水位 63%，Pod 却被杀了 5 次
背景环境：
- 集群：Kubernetes 1.28.9，containerd 1.7.13，节点 16C64G，内核 5.10.134（cgroup v2 only，无 v1 兼容层）
- 服务：Java 17（Spring Boot 3.2），
-Xmx1536m，Pod 规格requests=limits=2Gi（Guaranteed QoS），单副本先挂了一个 4 副本的灰度 - 业务特征：每 10 分钟从上游拉一批约 1.2Gi 的报文文件，解压后逐条消费，文件保留在节点盘目录里不删，用于审计回溯
事故表现（灰度窗口 2 小时内）：
- Pod 共被 OOMKilled 5 次，
kubectl get events全是OOMKilled，容器日志里 JVM 没有任何 GC 异常，-Xmx水位最高只到 1.1Gi； - Grafana 上
container_memory_working_set_bytes（即kubectl top同源数据）峰值 1.28Gi，只有 limit 的 64%； memory.events里oom_kill从 0 跳到 5，max事件同步 +5——说明内核确实认为这个 cgroup 触顶了，不是节点级 OOM；- 节点本身
free -h还有 40Gi+ 空闲，排除宿主机内存不足。
矛盾点很清楚：监控说 64%，内核说 100%+，两个都是"事实"。
二、根因：cgroup v2 的记账口径与回收顺序
三个机制叠在一起，才造成"看着没满却 OOM"：
1. memory.current 的组成 ≠ 你理解的 RSS。
cgroup v2 中 memory.current = 匿名页（RSS 主体）+ file page cache + swap 占用。file cache 是"可回收但尚未回收"的部分。working_set_bytes 的算法（containerd/cAdvisor 基于 memory.stat 里的 cache - inactive_file 近似）会把"近期还热"的 cache 扣掉，所以它天然比内核账本小。
2. 内核回收 file cache 的前提是"页真的脏得少、且回收有收益"。
我们的服务是顺序写 + 立即回读校验的访问模式：文件刚写完就要重新 mmap/读取校验，file page 处于 active 状态。内核回收时若发现这些页马上会被再次 fault-in，等于"回收了又换进来"，reclaim 效率极低（每次 reclaim 尝试后立刻被重新分配，pgscan 涨而 pgsteal 不涨）。此时 cgroup 触顶，回收又拿不出内存，内核直接走 oom_kill 路径。"缓存是热的"在 OOM 语境下反而是最坏情况——冷 cache 会被无痛回收，热 cache 会把你拖进 OOM。
3. 审计文件"不删"放大了 file cache 占用。
1.2Gi 文件 × 反复读写，file cache 稳定在 1.5~1.7Gi；叠加 1.02Gi 的 RSS 和约 100Mi 的 Metaspace/线程栈，memory.current 常态就在 2.6Gi 上下，长期高于 2Gi 的 limit，只是热页比例波动时有时能撑过 reclaim、有时不能——这就是"间歇性 OOM、且每次间隔 20~40 分钟（恰好是批处理周期）"的原因。
一句话根因：我们把 resources.limits 设成了"应用 RSS 预算"，但内核按"RSS + 热 file cache"记账，两者之间 1.6Gi 的差值就是事故本身。
三、具体做法：定位命令 + 修复配置（可复现）
定位：三步看穿两套口径的差异
# 1. 找到 Pod 对应 cgroup 路径（K8s 1.28 默认路径规则）
POD_UID=$(kubectl get pod <pod> -o jsonpath='{.metadata.uid}')
CGROUP=/sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod${POD_UID}.slice/cri-containerd-<id>.scope
# 更省事：crictl inspect <container-id> | grep -i cgroup
# 2. 对比内核账本与 working set
cat $CGROUP/memory.current # 事故时 ≈ 2.75Gi（> limit）
cat $CGROUP/memory.max # 2147483648
cat $CGROUP/memory.stat # 重点看 file、anon、slab、sock 四项
cat $CGROUP/memory.events # oom_kill / max 计数
# 3. 看回收是否在"空转"：pgscan 涨、pgsteal 不涨 = 热 cache 回收不动
watch -n 2 'grep -E "pgscan|pgsteal" $CGROUP/memory.stat'
事故现场实测：memory.stat 里 file ≈ 1.6Gi、anon ≈ 1.1Gi，pgsteal 在 2 分钟内只动了 300 页，而 pgscan 动了 40 万页——回收空转实锤。
修复（按落地成本从低到高）
方案 A：抬高 limit，把热 cache 计入预算（0 代码改动，0.5 人时）
resources:
requests: { memory: 1536Mi } # request 保持真实 RSS 预算，调度不受影响
limits: { memory: 4Gi } # 2Gi RSS 预算 + 1.6Gi 热 cache + 余量
注意：request 不用跟着抬——调度器按 request 排布，抬高 request 会导致节点可调度容量虚降、集群装箱率下降。limit 抬高后 QoS 从 Guaranteed 降为 Burstable，对"本来就会 OOM"的服务是净收益。
方案 B：把审计文件改成 tmpfs + sizeLimit（治访问模式，1 人时）
volumes:
- name: audit-cache
emptyDir: { medium: Memory, sizeLimit: 1Gi }
文件不落盘后，cache 归属更明确、节点盘 IO 也省了。但要注意：tmpfs 的占用同样计入挂载容器的 memory.max，所以 A 的预算仍然要做，B 只是把"不可预测的盘上热 cache"变成"有 sizeLimit 的显式预算"。
方案 C：加 PSI 预警，把下一次 OOM 提前 30 秒暴露（0.5 人时）
# Prometheus 规则（cgroup v2，PSI 内核 5.2+ 稳定）
- alert: CgroupMemoryPressureBeforeOOM
expr: rate(node_pressure_memory_full_seconds{cgroup=~".*pod.*"}[2m]) > 0.10
for: 60s
memory.pressure 的 full 是"所有线程都被迫脱机等待内存"的累计占比，它涨说明内核已经在替你干活了，比 RSS 水位早、比 OOM 稳。这条规则我直接参考了社区里苏知远同学的 PSI 落地文章（cited below），阈值 10%×60s 在他们的 1.28.9 集群上验证过能稳定早于 oom_kill 20~30s。
最终组合
A + C 全量上线，B 在审计文件访问模式稳定后二期做。上线两周后：同规格服务 OOM 0 次，memory.events 的 max 事件偶发 +1~2（说明预算贴顶但 reclaim 来得及），PSI 告警触发 3 次、均早于任何 OOM，值班从"事后重启"变成"事前调参"。
四、踩过的坑与反直觉之处
kubectl top永远不会告诉你真相的下限：working set 是"扣掉冷 cache 后的估计值"，事故时它 1.28Gi，内核账本 2.75Gi，差 2 倍。把top当内存水位看，等于只看了一半的账。- 热 cache 比冷 cache 危险得多：直觉上"缓存多 = 性能好事"，在 cgroup 触顶语境下，热 cache 恰恰是 OOM 的直接推手——因为它不可回收。
memory.current超过memory.max是合法状态：内核允许 file cache 暂时越界（等 reclaim 追上来），所以你会看到"current > max"的读数，这不是 bug，而是 OOM 前的最后窗口。- request 和 limit 的语义完全不同：request 是调度器的"占座"，limit 是内核的"死刑线"，两者之间没有换算关系。本次事故里 request=limit=2Gi 的"Guaranteed"配置反而掩盖了问题——Guaranteed 的 OOM 优先级最高，一触发就是先死。
-Xmx与 limit 的余量公式要重算：JVM 场景下，limit 至少 = Xmx + Metaspace + 线程栈(线程数×1Mi) + 堆外 + 该服务会持有的热 file cache。最后这项是最容易被漏掉的。
五、结论与可复用清单
核心结论：cgroup v2 的内存预算单位不是"应用内存"，而是"内核账本内存"。给容器设 limit 之前，先回答一个问题：这个服务会持有多少"热"的 file cache？答不上来，limit 就是拍脑袋。
可复用清单（按优先级）：
- [ ] 每个内存敏感服务，用
memory.stat的file/anon拆分记账，而不是只看 working set； - [ ] 出现间歇性 OOM 时，第一反应查
pgscan/pgsteal比值，>100 即热 cache 回收空转； - [ ] limit 预算公式显式包含 file cache 项，并写进服务 README；
- [ ] 给 Guaranteed QoS 的 Java 服务标配 PSI
full > 10%×60s告警； - [ ] 审计/日志类"写后回读"的文件，评估 tmpfs + sizeLimit 或改 append-only 访问模式；
- [ ] 排障 SOP 里固化
memory.events（oom_kill/max 计数）作为第一现场证据，先于看应用日志。
成本收益一句话：这次排障花了 4 小时 + 0 代码改动 + 0.5 人时配置，换来的是同规格 4 副本两周零 OOM；而它暴露的"limit 预算漏项"问题，按我们集群 300+ 服务的规模，大概率不是孤例。建议每个团队的容量评审表里加一行："热 file cache 预算 = ?"