遇到 OOMKilled 报错，最稳妥的做法是先确认内存增长是业务正常需求还是内存泄漏，再针对性调整 limits 值或优化代码。
先说结论：调整内存限制只是临时止血手段，根本解决需要结合监控数据判断是容量不足还是代码问题。
- 先确认：查看 Pod 重启原因和历史内存使用峰值，区分是突发流量还是内存泄漏。
- 先处理：根据监控峰值适当调大 limits 值，同时检查应用内部内存配置（如 JVM Heap）。
- 再验证：观察重启次数是否归零，并持续监控内存使用率是否趋于稳定。
命令速用版
快速查看 Pod 重启原因和当前资源配置：
kubectl describe pod <pod-name> -n <namespace> | grep -A 5 "Last State"
kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A 10 "resources"临时调整部署内存限制（示例为 512Mi）：
kubectl set resources deployment <deployment-name> -c <container-name> `--limits`=memory=512Mi -n <namespace>为什么会这样
容器内存限制是通过 Linux cgroups 机制实现的。当容器内进程使用的内存超过 Kubernetes 配置的 resources.limits.memory 值时，操作系统内核的 OOM Killer 会强制杀死该进程，导致容器重启，状态显示为 OOMKilled。
这通常由两种情况引起：一是业务量增长导致原有配额不足，属于正常容量问题；二是应用存在内存泄漏，即使调大限制，最终仍会再次触发报错。公开资料中没有看到可靠的量化数据表明调大多少比例能彻底避免泄漏，因此必须结合监控判断。
分步处理
1. 确认当前状态
使用 kubectl describe pod 查看 Last State 是否为 OOMKilled，并记录 Reason 字段。同时检查 Ready 状态和 Restarts 次数。
2. 分析内存使用趋势
如果有 metrics-server 或 Prometheus，查看过去 24 小时的内存使用曲线。找到峰值水位，确保新的 limit 值高于历史峰值，并预留一定缓冲空间。如果没有监控，可暂时按当前 limit 的 1.5 倍调整，但需密切观察。
3. 修改资源配置
编辑 Deployment 或 StatefulSet 的 YAML 文件，调整 resources 部分。建议同时设置 requests 和 limits，避免节点调度问题。
resources:requests:memory: "256Mi"limits:memory: "512Mi"应用变更：kubectl apply -f deployment.yaml。
4. 检查应用内部配置
对于 Java 应用，容器内存限制不等于 JVM 堆内存。如果容器 limit 是 512Mi，JVM -Xmx 应设置为略小于该值（例如 400Mi），否则容器未超限但 JVM 已尝试申请更多内存，仍可能触发 OOM。
怎么验证是否生效
1. 观察重启计数
执行 kubectl get pod -n <namespace>，观察 RESTARTS 列是否停止增长。如果调整后长时间不再增加，说明临时措施生效。
2. 监控内存水位
通过监控面板观察内存使用率。如果使用率长期接近 limit 值（例如超过 90%），说明限制仍然偏紧，需要继续调整或优化代码。
3. 检查事件日志
使用 kubectl get events -n <namespace> `--sort-by`='.lastTimestamp' 查看是否有新的 OOMKilling 事件产生。
常见坑
1. Limits 设置过小或过大
设置过小会导致频繁重启；设置过大会导致节点内存超卖，引发节点级别的 OOM，影响同一节点上的其他 Pod。公开资料中没有看到可靠的量化数据支持具体的超卖比例，建议根据节点实际容量规划。
2. Requests 与 Limits 差距过大
如果 requests 远小于 limits，调度器可能将 Pod 调度到内存不足的节点上，导致启动失败或运行不稳定。建议两者保持合理比例，例如 1:2 以内。
3. 忽略非堆内存
除了应用堆内存，还要考虑线程栈、直接缓冲区、元空间等开销。仅调整 JVM Heap 而忽略容器总限制，依然可能触发 OOMKilled。
参考来源
- Kubernetes Documentation, "Manage Resources for Containers", https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
- Kubernetes Documentation, "Debug Pods and ReplicationControllers", https://kubernetes.io/docs/tasks/debug/debug-application/debug-pod-replication-controller/
原文链接：https://www.zjcp.cc/ask/10299.html