爱宝妈1. 理解OOMKilled的本质：为什么是Exit Code 137？
当你在Kubernetes集群中看到Pod状态显示OOMKilled，并且容器退出码为137时，这实际上是Linux内核和Kubernetes协同工作的结果。让我用一个真实的案例来解释这个机制：
去年我们在生产环境部署了一个Java应用，Pod频繁被终止。kubectl describe pod显示Last State: Terminated with Exit Code 137，事件日志中明确标注Reason: OOMKilled。这就像你的手机在内存不足时会强制关闭最耗电的APP一样，Kubernetes在容器超过内存限制时也会采取类似措施。
Exit Code 137的计算方式很有讲究：
- Linux进程被信号终止时，退出码是
128 + 信号编号 - OOM Killer发送的信号是
SIGKILL（编号9） - 因此退出码为
128 + 9 = 137
关键提示：不是所有137退出码都代表OOM。如果人为执行
kill -9也会产生137，需要结合kubectl describe pod中的Reason字段确认。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 完整排障流程：从报警到根因定位
2.1 第一步：获取基础信息
当收到告警后，我通常会按这个顺序收集信息：
bash复制# 查看Pod状态（重点关注Events部分）
kubectl describe pod <pod-name> -n <namespace>
# 获取容器日志（可能因OOM来不及写日志，但总要试试）
kubectl logs <pod-name> -c <container-name> --previous
# 检查Pod的YAML定义（特别是resources部分）
kubectl get pod <pod-name> -o yaml
2.2 第二步：分析内存监控数据
如果集群安装了Prometheus，可以用这些PromQL查询历史内存使用：
promql复制# 容器内存使用量
container_memory_working_set_bytes{pod="<pod-name>", container="<container-name>"}
# 内