容器被 OOMKilled 后 kubectl logs 停在半小时前 现场去哪看

Pod 状态是 OOMKilled，退出码 137，kubectl logs 最后一行停在 21:04 的一条普通访问日志。之后没有任何异常输出。第一次遇到会往复杂处想，其实漏掉的多是个小前提。

kubectl describe pod api-7f9 | grep -A6 'Last State'
dmesg -T | grep -i 'killed process'
cat /sys/fs/cgroup/memory.events

内存超限时内核直接发 SIGKILL，进程没有机会刷缓冲，应用日志缓冲区里的内容全丢。真正的记录在节点内核日志和 cgroup 的 memory.events 里。这一点先确认清楚，后面就不用反复试。

「OOMKilled 日志缺失」这类改动最怕改一半，回滚脚本先准备好，再动生产。新版本先放一台机器上跑一天再全量，问题一般在这段时间暴露。

备份不是备了就行，恢复一次才算数，很多备份文件打开才发现是空的。接口问题先分清是没发出去、发出去了没收到，还是收到了处理失败。

偶发问题先统计频率，一小时几次和一天一次，查法完全不同。

具体做法是，先看 Pod 的 lastState 和 reason 确认确实是被 OOM 杀掉的；去所在节点的 dmesg 里找 killed process 那几行 对上 RSS；查 cgroup 的 memory.events 看 oom_kill 计数；把应用内存上限和 JVM 堆一起往下调 留出系统开销。

改完照着核一遍，dmesg 里能看到被杀进程的 RSS，调整后 oom_kill 计数不再增长。