Kubernetes生产运维05：看到OOMKilled先别急着调大内存，怎么区分被杀、泄漏和配置过低

Kubernetes生产运维05看到OOMKilled先别急着调大内存怎么区分被杀、泄漏和配置过低写在前面看到容器OOMKilled最常见的处理是把内存limit调大重新发布然后期待它不再被杀。有时这能暂时缓解但它跳过了一个关键问题这次被杀到底是应用真的需要更多内存、代码存在泄漏、limit配得过低还是节点整体内存压力导致的驱逐。不同原因对应完全不同的修复盲目调大limit可能只是把问题推迟甚至掩盖真正的泄漏。因此OOMKilled排查要沿着下面这条链路容器被OOMKilled → 确认是容器级超限还是节点级驱逐 → 读取Last State的Reason、Exit Code和终止时间 → 用工作集内存和历史曲线判断是波动、泄漏还是limit过低 → 结合QoS和节点压力理解为什么是它被杀 → 针对性修复并验证 → 补容量基线与监控本文按照Kubernetes官方机制和命令参考整理。由于当前没有连接可验证的实验集群命令没有在统一版本的真实集群完整执行案例和终端输出均为C级生产化重建不是生产原始记录。不同Kubernetes版本、容器运行时、cgroup版本、监控组件和云厂商可能改变字段、指标名和行为执行前应以目标集群的kubectl explain、命令帮助和实际状态为准。一、先理解OOMKilled到底是什么1.1 OOMKilled是被内核杀死的结果当容器使用的内存超过它的cgroup内存上限时Linux内核的OOM killer会向容器内进程发送SIGKILL。进程立即死亡容器的Last State记录Reason: OOMKilled退出码通常是137。这里的关键是OOMKilled是内核层面的强制终止结果不是应用自己抛出的错误。应用往往来不及打印有意义的崩溃日志就被杀这也是为什么不能只靠应用日志排查。1.2 exit 137不等于一定是OOM137等于128加9表示进程收到编号为9的信号即SIGKILL。OOMKilled是137的常见来源但不是唯一来源内核OOM killer杀死超限容器Reason为OOMKilledliveness探针失败后kubelet强制杀死优雅终止宽限期超时后被SIGKILL人为或运行时发起的强制终止所以看到137不能直接下结论必须查Last State的Reason字段是否为OOMKilled。只有Reason确认才支持这是一次内存超限终止。1.3 容器级OOM与节点级驱逐是两回事两种都会让容器停止但机制和处理不同类型触发条件典型标志影响范围容器级OOM容器内存超过自身limitLast State ReasonOOMKilled通常只影响该容器节点级内存驱逐节点整体内存不足kubelet按优先级驱逐Pod被EvictedNode有MemoryPressure可能影响节点上多个Pod节点内存压力驱逐由kubelet的节点压力驱逐机制触发会优先驱逐超出requests较多或QoS较低的Pod被驱逐Pod通常标记为Evicted而不是简单的OOMKilled。排查时要先判断是单容器超限还是整节点承压。1.4 requests、limits与QoS内存的requests和limits共同决定Pod的QoS等级也影响被杀顺序Guaranteed每个容器都设置了相等的requests和limits。Burstable至少一个容器设置了requests或limits但不满足Guaranteed。BestEffort没有设置任何requests和limits。节点内存压力时BestEffort和超出requests较多的Burstable Pod更可能先被驱逐。理解QoS有助于解释为什么在同一节点上是某个Pod被杀。二、OOMKilled排查决策树容器停止或反复重启 │ ├─ 确认是OOMKilled还是其他137 │ └─ 查Last State Reason只有OOMKilled才按内存查 │ ├─ 判断容器级还是节点级 │ ├─ Pod被Evicted且Node有MemoryPressure → 节点压力 │ └─ 单容器ReasonOOMKilled节点内存充足 → 容器超限 │ ├─ 看内存趋势 │ ├─ 工作集持续单调上升到limit → 疑似泄漏 │ ├─ 周期性尖峰越过limit → 峰值负载或批处理 │ └─ 稳定贴近limit → limit配得过低 │ ├─ 结合QoS和requests理解被杀顺序 │ ├─ 针对性修复并验证 │ └─ 补容量基线与监控先用一条命令确认阶段NSnamespacePODpod-namekubectl get pod$POD-n$NS\-ojsonpath{range .status.containerStatuses[*]}{.name}{ restarts}{.restartCount}{ reason}{.lastState.terminated.reason}{ exitCode}{.lastState.terminated.exitCode}{\n}{end}只有reasonOOMKilled时才继续按内存排查否则回到CrashLoopBackOff或其他路径。三、取证从状态、事件到内存曲线3.1 确认OOMKilled证据kubectl describe pod$POD-n$NS在容器Last State里关注Reason: OOMKilledExit Code: 137Finished时间用于对齐监控同时看Events和Pod状态里是否有Evicted以区分节点驱逐。3.2 查看limit和requestskubectl get pod$POD-n$NS\-ojsonpath{range .spec.containers[*]}{.name}{ req}{.resources.requests.memory}{ lim}{.resources.limits.memory}{\n}{end}kubectl get pod$POD-n$NS\-ojsonpath{.status.qosClass}{\n}如果没有设置memory limit容器理论上可以用到节点上限更容易触发节点级压力而不是容器级OOM。3.3 用工作集内存而不是RSSkubectl top和监控通常展示工作集内存working set它更接近内核判断OOM时使用的口径。kubectltoppod$POD-n$NS--containers这只能看到当前实例的近期用量。真正判断是否泄漏需要历史曲线container_memory_working_set_bytes 按容器随时间的变化 对比 kube_pod_container_resource_limits 中的内存limit历史监控展示随时间的工作集曲线才能区分是稳态贴近limit、周期尖峰还是单调上升。当前top一个数值不足以定性。3.4 内存日志的边界被OOM杀死的进程往往来不及打印崩溃日志--previous可能只有正常运行日志甚至为空。这不代表没有问题而是SIGKILL不给进程清理机会。应以Last State、内核OOM证据和内存曲线为主日志为辅。四、区分泄漏、峰值与limit过低同样是OOMKilled内存曲线形态指向不同原因曲线形态更可能的原因优先动作不能直接得出的结论工作集持续单调上升到limit内存泄漏或缓存无上限定位增长来源、堆分析不能只靠调大limit解决周期性尖峰越过limit批处理、大请求、并发峰值评估峰值容量或限流不一定是泄漏长期稳定贴近limitlimit配得过低按真实工作集调整limit不一定是应用异常发布后立刻上升被杀新版本内存需求变化或配置回退对比新旧版本和配置不一定是老问题复发对于运行时自带内存模型的应用如JVM、Node、Go还要注意运行时堆和容器limit的关系。运行时的堆上限如果高于容器limit进程可能在到达自己认为的上限前就先被容器cgroup杀掉。这类应用要让运行时感知容器limit或显式设置合理堆上限。五、C级生产化重建案例发布后容器周期性被OOMKilled5.1 先说明哪些是真的哪些是重建的下面不是作者声称亲历的生产事故而是根据Kubernetes内存限制、QoS和OOM机制构造的生产化重建用于展示从OOMKilled走到可验证根因的取证过程。内容证据属性OOMKilled、退出码137、cgroup limit和工作集之间的机制Kubernetes与Linux官方机制发布后容器周期性被杀、重启计数上升机制一致的重建场景Namespace、资源名、内存数值、相对时间和终端输出为讲解构造的说明性信息新版本内存limit被下调模拟根因不是作者生产记录修正单一变量后验证不再被杀受控验证设计不声称已在当前集群执行所有输出按真实对象关系编排但没有连接实际集群采集读者不能把下面的时间、数值或输出引用为真实事故数据。5.2 现场卡片一个Deployment运行3个副本。一次发布后副本开始间歇性重启kubectl get偶尔显示OOMKilled。团队最初怀疑应用出现了内存泄漏。重建的相对时间线相对时间观察或动作当时能够得出的结论T00发布更新Deployment只能确认发生了配置变更T03副本间歇重启偶见OOMKilled存在内存超限终止原因未知T05有人怀疑内存泄漏待验证假设T08内存曲线显示每次尖峰后回落不是单调上升不支持持续泄漏T12对比新旧版本发现limit被下调得到可验证的主假设T验证只恢复limit观察是否还被杀单变量验证相对时间只表示排查顺序不代表真实恢复时长。5.3 确认是OOMKilled而非其他137NSexample-prodPODreport-worker-newhash-a1 kubectl get pod$POD-n$NS\-ojsonpath{range .status.containerStatuses[*]}{.name}{ restarts}{.restartCount}{ reason}{.lastState.terminated.reason}{ exitCode}{.lastState.terminated.exitCode}{ finished}{.lastState.terminated.finishedAt}{\n}{end}机制一致的说明性输出report-worker restarts4 reasonOOMKilled exitCode137 finished...Reason明确是OOMKilled退出码137支持这是内存超限终止而不是探针强杀或宽限超时。5.4 确认容器级而非节点驱逐kubectl get pod$POD-n$NS-ojsonpath{.status.phase}{\t}{.status.reason}{\n}kubectl describenodenode-name|sed-n/Conditions:/,/Events:/p机制一致的说明性输出Running MemoryPressure FalsePod没有被标记为Evicted节点也没有MemoryPressure因此这是容器级OOM问题在容器自身limit与用量的关系上不是整节点承压。5.5 看limit、QoS和内存曲线kubectl get pod$POD-n$NS\-ojsonpath{range .spec.containers[*]}{.name}{ req}{.resources.requests.memory}{ lim}{.resources.limits.memory}{\n}{end}kubectl get pod$POD-n$NS-ojsonpath{.status.qosClass}{\n}kubectltoppod$POD-n$NS--containers机制一致的说明性输出report-worker req256Mi lim384Mi Burstable NAME CPU MEMORY report-worker-newhash-a1 120m 372Mi当前工作集372Mi已经贴近384Mi的limit。再看历史曲线的形态描述工作集在每个批处理周期出现尖峰接近或越过384Mi后被杀 随后新实例回落到约250Mi不是持续单调上升。这更像周期尖峰加limit偏低而不是单调泄漏。5.6 对比新旧版本配置helm list-n$NShelm get valuesrelease-name-n$NSrelease-values.yamlgrep-n-A4resourcesrelease-values.yamlgitdiffknown-good-ref..candidate-ref-- values-prod.yaml机制一致的说明性差异limits: - memory: 512Mi memory: 384Mi证据链Reason确认OOMKilled容器级而非节点驱逐 内存曲线是周期尖峰后回落不是单调上升 尖峰接近旧版本512Mi但超过新版本384Mi 本次发布把limit从512Mi下调到384Mi 强烈支持本次limit下调导致周期性OOMKilled这仍是主假设验证前不写成根因已闭环。也要留意反证如果尖峰其实在持续变高则可能同时存在增长问题需要继续观察。5.7 止损与单变量验证当前部分副本仍在服务最安全的止损通常是回滚到已知可用版本或在变更窗口恢复limit。回滚和修正都属于变更操作执行前确认可用副本、PDB、maxUnavailable、maxSurge、兼容性和可回退版本。验证时只把内存limit从384Mi恢复到512Mi不同时改代码、副本和其他资源resources:requests:memory:256Milimits:memory:512Mi验证并保存修复后证据kubectl rollout status deployment/report-worker-n$NS--timeout5m kubectl get pod$POD-n$NS\-ojsonpath{range .status.containerStatuses[*]}{.name}{ restarts}{.restartCount}{ reason}{.lastState.terminated.reason}{\n}{end}kubectltoppod-n$NS-lappreport-worker--containers机制一致的说明性输出deployment report-worker successfully rolled out report-worker restarts0 reason NAME CPU MEMORY report-worker-fixedhash-b2 118m 372Mi report-worker-fixedhash-c3 121m 360Mi这些输出分别证明不同范围的事实输出能够支持不能单独证明rollout成功Deployment满足滚动完成条件所有业务链路绝对正常restarts0且无OOMKilled恢复limit后一段时间未再被杀极端峰值下一定不会再超工作集稳定在limit内当前容量足够承载观测到的尖峰长期负载增长下仍然足够5.8 根因闭环条件修正版与失败版只有内存limit这一项主要差异。恢复limit后OOMKilled停止重启计数不再增长。内存曲线是周期尖峰而非单调上升支持limit偏低而非泄漏。不需要修改应用代码即可稳定。观察窗口覆盖至少一个完整批处理周期没有再次被杀。如果恢复limit后仍被杀或曲线其实持续升高就要停止把limit当作唯一原因转向堆分析和泄漏排查。六、修复方案要分六层层次本文场景中的动作关键边界应急止损回滚到已知可用版本或恢复合理limit先查可用副本、PDB、兼容性和回退版本现场取证保存Last State、Reason、Exit Code、limit、QoS和内存曲线OOM进程日志可能缺失以状态和监控为主根因验证只改内存limit一个变量并观察是否再被杀不同时改代码、副本和其他资源永久修复按真实工作集设置limit或修复泄漏与运行时堆配置泄漏不能靠调大limit长期掩盖监控预防监控工作集、limit使用率和OOMKilled次数告警区分周期尖峰和持续增长运行治理内存基线、压测、发布前资源校验和Runbooklimit变更纳入容量评审调大limit只是众多修复之一且只适用于确实是容量不足的情况。对泄漏应定位增长来源对运行时应用应让堆配置与容器limit协调对节点压力应从调度、requests和节点容量入手。七、可直接使用的只读OOMKilled采集脚本脚本只读取对象、状态和资源指标不删除Pod、不重启、不改limit、不扩缩容。#!/usr/bin/env bashset-uset-opipefailNS${1:?用法:$0 namespace pod-name}POD${2:?用法:$0 namespace pod-name}STAMP$(date%Y%m%d-%H%M%S)OUToom-evidence-${NS}-${POD}-${STAMP}mkdir-p$OUTumask077capture(){localfile$1shiftprintf采集 %s\n$fileif!$$OUT/$file2$OUT/$file.err;thenprintf失败: %s查看 %s.err\n$file$file2fi}capture context.txt kubectl config current-context capture version.txt kubectl version capture pod.yaml kubectl get pod$POD-n$NS-oyaml capture pod-describe.txt kubectl describe pod$POD-n$NScapture container-state.txt kubectl get pod$POD-n$NS\-ojsonpath{range .status.containerStatuses[*]}{.name}{ restarts}{.restartCount}{ reason}{.lastState.terminated.reason}{ exitCode}{.lastState.terminated.exitCode}{ finished}{.lastState.terminated.finishedAt}{\n}{end}capture resources.txt kubectl get pod$POD-n$NS\-ojsonpath{.status.qosClass}{\n}{range .spec.containers[*]}{.name}{ req}{.resources.requests.memory}{ lim}{.resources.limits.memory}{\n}{end}capture events.txt kubectl get events-n$NS\--field-selectorinvolvedObject.kindPod,involvedObject.name$POD\--sort-by.metadata.creationTimestampifkubectltoppod$POD-n$NS--containers/dev/null21;thencapture pod-top.txt kubectltoppod$POD-n$NS--containerselseprintfMetrics API不可用或无权限\n$OUT/errors.txtfiprintf采集完成: %s\n$OUTprintf内存趋势需结合历史监控当前top只反映近期用量\nprintf分享前请检查日志、地址和配置引用中的敏感信息\n使用方式bashcollect-oom-evidence.shnamespacepod-name脚本边界OOM进程日志可能缺失脚本不强行依赖崩溃日志top只反映当前实例近期用量泄漏判断需历史曲线脚本用于保存首轮现场不能替代容量分析和根因验证八、监控、容量与治理8.1 监控什么容器工作集内存与limit使用率OOMKilled次数与被杀速率节点MemoryPressure和Pod被Evicted事件发布前后内存基线对比运行时堆使用如JVM堆告警不能只匹配一次OOMKilled。周期尖峰、发布抖动和持续泄漏应通过使用率趋势、被杀速率和曲线形态区分。8.2 发布前校验内存limit不低于真实工作集的合理峰值requests与limits关系符合期望的QoS运行时堆上限与容器limit协调变更内存资源时经过容量评审高峰负载有压测或历史数据支撑8.3 容量与QoS治理关键服务考虑Guaranteed QoS降低被驱逐概率用历史工作集设定requests避免过度超卖批处理和峰值型应用单独评估容量建立内存基线limit调整有依据而非拍脑袋九、常见误区误区1看到OOMKilled直接调大limit调大limit只适用于容量不足。对泄漏这只是推迟被杀。误区2看到137就认定是OOM137是SIGKILL探针强杀和宽限超时也会137必须看Reason字段。误区3把节点驱逐当成容器OOMPod被Evicted且节点MemoryPressure是节点级问题处理路径不同。误区4用当前top一个数值判断泄漏泄漏要看随时间的工作集曲线单点数值不足以定性。误区5忽略运行时堆与容器limit的关系JVM等运行时堆若高于容器limit进程会先被cgroup杀掉。误区6靠OOM时的应用日志找原因被SIGKILL的进程往往来不及打印崩溃日志应以状态和监控为主。误区7同时改limit、代码和副本即使不再被杀也无法判断是哪一项起作用。误区8把内存请求设成0或不设不设requests和limits是BestEffort节点压力时最先被驱逐。十、面试怎么说60秒版本OOMKilled我不会直接调大内存。先确认Last State的Reason确实是OOMKilled因为137也可能是探针强杀。再判断是容器超过自身limit还是节点MemoryPressure导致的驱逐两者处理不同。确认容器级后我看工作集内存的历史曲线单调上升偏向泄漏周期尖峰偏向峰值或limit过低稳定贴limit偏向配置过低。结合QoS理解为什么是它被杀。定位后只改一个变量验证泄漏要修代码不能只调limit最后补内存基线和OOM监控。3分钟场景版本假设发布后副本周期性OOMKilled。我先确认Reason是OOMKilled、退出码137Pod没有被Evicted、节点无MemoryPressure说明是容器级超限。看limit和QoS工作集已经贴近新版本的limit。历史曲线显示每个批处理周期出现尖峰后回落不是单调上升所以更像峰值加limit偏低而不是泄漏。对比新旧版本发现这次把内存limit从512Mi下调到384Mi。我只恢复limit一个变量滚动完成后观察至少一个完整批处理周期OOMKilled停止、工作集稳定在limit内。这样我能区分是limit配置问题而不是泄漏也不会用无依据地调大内存来掩盖真正的容量或代码问题。十一、延伸问答1. OOMKilled时Pod的phase是什么容器被杀后按restartPolicy重启phase通常仍是Running反复被杀时STATUS可能显示CrashLoopBackOff。2. exit 137一定是OOM吗不一定。137是SIGKILLOOM是常见来源但探针强杀、宽限超时也会137要看Reason。3. 容器OOM和节点驱逐怎么区分容器OOM是Last State ReasonOOMKilled且节点内存充足节点驱逐是Pod被Evicted且节点有MemoryPressure。4. 为什么不能只看kubectl top判断泄漏top只反映当前实例近期用量。泄漏要看随时间的工作集曲线单点不足以定性。5. JVM应用为什么容易OOMKilled如果JVM堆上限高于容器limit进程在到达自认为上限前就被cgroup杀掉。应让堆配置感知容器limit。6. QoS和被杀顺序有什么关系节点内存压力时BestEffort和超出requests较多的Burstable更可能先被驱逐Guaranteed相对靠后。7. 调大limit是不是万能修复不是。它只适用于容量不足。泄漏、运行时配置和节点压力需要不同修复。8. 为什么OOM后常常没有崩溃日志SIGKILL不给进程清理和打印机会所以应以Last State、内核OOM证据和内存曲线为主。小结OOMKilled是容器被内核按内存超限杀死的结果不是应用主动抛出的错误。exit 137是SIGKILLOOM是常见来源但不是唯一必须看Reason。容器级OOM与节点级驱逐机制不同先区分再排查。requests和limits决定QoS影响节点压力下的被杀顺序。判断泄漏要用随时间的工作集曲线不是当前一个数值。运行时堆若高于容器limit会先被cgroup杀掉。修复只改一个变量并验证泄漏不能靠调大limit长期掩盖。长期治理覆盖内存基线、QoS设计、发布校验和OOM监控。下一篇预告下一篇进入Service访问异常。我们会沿着Selector、EndpointSlice、端口、kube-proxy和网络策略区分没有Endpoint、Pod未就绪和网络策略拦截等情况并整理一份服务链路排查图。参考资料Kubernetes官方文档Pod LifecycleKubernetes官方文档Resource Management for Pods and ContainersKubernetes官方文档Pod Quality of Service ClassesKubernetes官方文档Node-pressure EvictionKubernetes官方文档Assign Memory Resources to Containers and PodsKubernetes官方文档Configure Minimum and Maximum Memory Constraints for a NamespaceKubernetes官方文档Debug Running PodsKubernetes官方文档Resource metrics pipelineKubernetes官方文档Tools for Monitoring ResourcesKubernetes官方文档kubectl top pod