requests 和 limits 都写 64Mi，Pod 运行十分钟后 OOMKilled，exit code 137，节点内存还有 9G 空闲。碰到这种情况，我一般先确认改动有没有真的生效。
原因不复杂，cgroup 的内存上限取 limits，和节点剩余内存无关。requests 写太小只影响调度，limits 跟着写 64Mi 会让进程一过阈值就被内核杀掉。
碰到「requests 过小」这类问题，我习惯先把当前配置原样备份一份，改坏了立刻换回来，不用现场推。别只看报错的最后一行，往上看几行，真正的起因通常在上面。
kubectl top pod api-6b8d7f5c9-9x2vr kubectl describe pod api-6b8d7f5c9-9x2vr | grep -A3 'Last State'
同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。
改完隔一天再看一次，当场正常不代表能稳住。测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。
具体做法是，用 kubectl top pod 看真实常驻内存 别按空跑数据估；把 requests 调到 P95 用量 limits 留 1.5 倍余量；Java 或 Node 还要同步改堆上限 否则容器没挂进程先 OOM；压测一轮确认没有再次出现 137。
最后用这个标准收尾，连续跑一小时 kubectl top 稳定在 220Mi 左右 不再出现 OOMKilled。