K8S容器 exitCode:137 OOM 导致节点重启 Kibana排查过程

原创 已于 2022-05-09 13:48:13 修改 · 置顶 · 2.4k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#k8s #Kibana #重启 #exitCode 137 #OOM

于 2021-11-30 19:12:33 首次发布
本文详细记录了一次K8S容器由于exitCode 137 OOM问题导致节点重启的排查过程。通过分析Kibana日志，发现日志中存在错误信息，如配置服务获取失败，可能由网络抖动和配置中心网络不稳引起。最终，问题定位为项目接入配置中心时因网络问题导致的配置获取失败。

Kibana日志信息：

2021-11-15 14:38:43.650 DEBUG 7 — [ main] o.s.c.e.PropertySourcesPropertyResolver : Found key ‘spring.cloud.stream.bindings.*****************’ in PropertySource ‘bootstrapProperties’ with value of type String

2021-11-15 15:23:36.304 ERROR 7 — [47caafe6f7]-1-4] c.c.p.p.s.e.b.h.ErrorNotificationHandler : SAMPLE: Host javahost-*************************** received general error notification during Renewing Lease : {}

2021-11-15 15:23:43.210 ERROR 7 — [ monitor-send26] c.p.p.s.e.b.p.EventHubsStreamProvisioner : Error initializing EventHubs link,producerConnectionStr:Endpoint=… * …

2021-11-15 15:23:42.767 ERROR 7 — [io-8080-exec-32] c.p.a.dot.aop.GlobalExceptionHandler : GlobalException

2021-11-15 15:23:42.768 ERROR 7 — [io-8080-exec-32] c.p.a.dot.aop.GlobalExceptionHandler : java.io.IOException: Broken pipe

2021-11-15 15:23:23.859 ERROR 7 — [scoveryClient-1] c.netflix.discovery.TimedSupervisorTask : task supe

最低0.47元/天 解锁文章
k8s：pod被kill，显示command terminated with exit code 137
mzhan017的博客
02-10 1099
9 (SIGKILL)：表示 进程被强制终止（通常由 kill -9、OOM Killer 或 systemd 触发）。检查日志：dmesg -T | grep -i “killed” 查看是否是 OOM 导致的。128：Linux 规定，如果进程因信号终止，退出码就是 128 + 信号编号。如果是 OOM 问题，建议优化程序内存管理，或者增加可用资源！增加可用内存：释放或分配更多 RAM，或优化程序内存使用。ulimit -u unlimited # 取消进程限制。是使用tmp目录的大小超出了限制。
Vscode: reason: oom, code: -536870904
嘉禾天成‘s Blog
09-27 2353
现象是：每次打开vscode后正常，且打开其他文件夹，再打开chat窗口运行正常。但当再次打开原来的文件夹并打开chat窗口时，则出现此崩溃问题。再次使用vscode打开改完名字后的文件夹，打开github copilot chat窗口，不再崩溃。最近使用github+插件github copilot开发时遇到这个问题，4、彻底删除github copilot插件；怀疑：vscode在本地有另外的真正的备份文件，修改出现崩溃问题的文件夹名字。出现原因：在chat窗口输入了过大的内容。
k8s重启Exit Code: 137；Reason: OOMKilled
AXingSong的博客
04-27 1878
发现原因：红框里的信息OOMKilled，退出的提示码是137，经过查询发现是部署服务时的yaml文件里的限制内存写的有点小，简单来说就是：你运行项目需要的内存比你设置的内存大，在你运行项目的时候申请内存超过了你限制的内存就会报错退出，然后重启。一开始以为是程序中下载的训练模型太大了，每天都下载一遍模型并且不会删除，导致内存溢出服务挂掉然后重启。在自己文件中把这个改大了一些，观察了一段时间，暂时还没有遇到重启。网上看到有人说可能是服务部署设置的问题，使用命令。问题：发现部署到k8s上的服务一直在自动重启。
容器显示：Stopped for 6 hours with exit code 137
最新发布
weixin_42052249的博客
11-17 550
通过 SSH 远程连接一台服务器，然后运行 Docker 容器，容器最终停掉并显示。容器显示：Stopped for 6 hours with exit code 137。
k8s pod exit code137 | kubelet invoked oom-killer
qq_15138049的博客
06-05 931
k8s pod CrashLoopBackOff
如何分析K8S中的OOMKilled问题(Exit Code 137)
summer_fish的专栏
10-17 7067
当 Kubernetes 集群中的容器超过其内存限制时，Kubernetes 系统可能会终止该容器并显示“OOMKilled”错误，这表明该进程由于内存不足而被终止。此错误的退出代码是 137。
k8s容器 pod OOM, exit code:137
feichen2016的博客
11-02 1万+
某天查看线上服务，发现有个服务平均每天重启一次，通过k8s descripe pod podName 命令发现exit code： 137 reason: OOM Killed. 提示比较明显OOM（当时查了失败的容器内服务日志，发现没有异常信息，有点疑惑的）,然后果断在jvm配置里添加OOM自动dump日志参数，-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof，等着问题后分析日志原因（我们体量不大，同时又是多节点，所.
通过 Exit Code 定位 Pod 异常退出和重启原因
2401_89314348的博客
11-30 1551
本文介绍如何根据 Pod 异常状态信息中的 Exit Code 进一步定位问题。
怎么定位K8s容器中运行的JAVA程序OOM异常（一）
计算科学
06-26 2912
一.前置环境 1. 运行在k8s集群上的Pod服务（Java程序） 2. MAT分析工具 二.利用Jmap工具导出Heap Dump 1.执行命令进入pod容器 kubectl exec -itn {namespace} {pod}} sh 2.利用jmap生成java程序的Dump文件 jps | grep {jar} ./jmap -dump:live,format=b,file=haep.hprof 8 3.利用k8s命令导出Dump文件到本地 kubectl cp -n
K8s故障排查手册：从Pod崩溃到网络不通
水务人
03-27 1264
本文基于数百个真实生产环境案例，系统化梳理Kubernetes集群的故障排查方法论。涵盖Pod生命周期异常、服务发现失效、存储卷挂载失败、网络策略冲突等核心故障场景，结合Prometheus监控指标、eBPF深度追踪、CNI插件分析等技术手段，为企业运维团队提供从现象定位到根因分析的全链路解决方案。
k8s pod 一直重启 code 137 排查记录
热门推荐
真正的大师永远怀着一颗学徒的心
02-10 1万+
现象 k8s pod一直在重启，调度不起来 排查 1. 首先看状态 这个比较简单，我直接在页面上的(rancher查看api、查看/编辑yaml等都能看) 如图，找到containerStatuses，里面有个exitCode：137 网上搜了下错误码的意思： 退出代码 0：一般为容器正常退出 退出代码 1：由于容器中 pid 为 1 的进程错误而失败 退出代码 137：由于容器收到 SIGKILL 信号而失败（手动执行或“oom-killer” [OUT-OF-MEMORY]） = 退出代码 139：
kubernetes pod内容器状态OOMKilled和退出码137全流程解析
大叶子不小的博客
02-01 6501
本文研究的都是确定性的问题，好像没有什么意义，话说回来，如果没有学习这些确定性问题的积累，又如何去应对不确定的问题呢？作者：免帅叫哥链接：https://www.jianshu.com/p/0a9718199428来源：简书著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
java exit code 137_运维：k8s pod erro exit code 137
weixin_42122878的博客
02-24 2485
原标题：运维：k8s pod erro exit code 137该问题由于引用触发oom，进而因为kill 信号，致使pod 终端停止。IssueIf a container is no longer running, use the following command to find the status of the container:docker container ls -aThis ...
Process finished with exit code 137 调试错误
THE XING
12-10 9507
docker中运行报了一堆子很奇怪的info。 最后来一句Process finished with exit code 137 这个大概率是内存问题，被系统kill了，所以你没有ctrl c，系统强制ctrl c了。
java exit code 137_k8s pod OOMKill Exit Code: 137
weixin_39978276的博客
03-06 1006
Identify it is OOMKillReason should be OOMKill and the time is Finishedkubectl get pods testapp-v092-p8czf -o yaml | less -i…Last State: TerminatedReason: OOMKilledExit Code: 137Started: ...
开源帮助：什么是退出代码 137，你能修复它吗？
开源直播系统源码
06-29 4872
当Kubernetes 环境中的 pod 或容器超过分配给它们的内存量时，将触发退出代码 137 。通常，此退出代码伴随或简称为 OOMKilled。这里描述的killed是指这个错误的结果，它导致一个pod终止。首字母缩略词 OOM 代表内存不足，这是由 pod 超出设置的内存限制引起的。如果您不确定 pod 终止的原因，最简单的找出方法之一是运行“kubectl get pods command”，然后会在特定 pod 上调用状态更新。然后，您会在其中找到 OOMKilled，它会提醒您退出代码 137
k8s部署失败常见原因
xiaoyi52的专栏
10-22 5664
1. 错误的容器镜像/非法的仓库权限 其中两个最普遍的问题是： 指定了错误的容器镜像。 使用私有镜像却不提供仓库认证信息。 这在首次使用 Kubernetes 或者绑定 CI/CD 环境时尤其棘手。 让我们看个例子。首先我们创建一个名为 fail 的 deployment，它指向一个不存在的 Docker 镜像： $ kubectl run fail --image=rosskukulinski/dne:v1.0.0 然后我们查看 Pods，可以看到有一个状态为ErrImagePull或者ImageP
docker容器Exited(137)状态，用docker exec无法直接进
handsomehaha的博客
06-14 2522
Exited(137)，docker exec -it 容器名 /bin/bash 无法进入
k8s 简介
weixin_33758863的博客
04-01 409
1.什么是Kubernetes Kubernetes 是一个跨主机集群的 开源的容器调度平台，它可以自动化应用容器的部署、扩展和操作 , 提供以容器为中心的基础架构。(官方文档第一行) 1.1 Kubernetes服务于微服务 每个微服务都是独立的进程，通过定义好的接口(restful api ,amqp)互相调用 1.1.1 微服务常见的问题 不同服务依赖库导致的混乱，需要将每个服...
k8s中pod中的容器被oom机制杀死，pod会重启吗
11-14
<think> 嗯，用户的问题很明确：想知道Kubernetes中当Pod里的容器被OOM杀死后，Pod是否会重启。这是个经典的运维问题，需要结合K8s的底层机制来解释。 用户引用了三份站内资料，其中引用[1]提到容器内存限制接近时内核会回收内存并可能触发OOM，这正好是问题发生的场景。引用[2]关于控制器的说明和引用[3]关于kubelet驱逐机制的内容虽然相关，但当前问题更聚焦在容器级别的OOM后行为。 从技术原理来看，需要分两层回答：首先是容器被OOM杀死后的默认行为，其次是控制器如何介入。关键点在于： 1. 容器被内核OOM killer杀死属于异常退出（exit code 137），这会触发kubelet的容器重启机制 2. restartPolicy决定了是否重启，Deployment等控制器默认Always会无限重启 3. 重启不等于恢复服务，业务代码需要自己处理OOM后的状态恢复 用户可能还隐含想知道“为什么有时看到Pod卡在CrashLoopBackOff”，这其实是重启策略和退避算法的共同作用结果。需要强调多次OOM会导致重启间隔指数级增长，看似Pod“没重启”实际是被暂停重启了。 考虑到用户是运维人员，补充两个实践细节会更有帮助：如何查看OOM后的exit code（kubectl describe pod），以及如何区分容器OOM和节点OOM的日志特征差异。这些在之前的对话历史中用户表现出兴趣。 最后生成的相关问题要延续这个技术脉络：OOM后的故障排除（问题1）、重启策略优化（问题2）、资源限制配置（问题3）都是自然延伸。特别加入问题4关于状态保留，因为这是有状态服务常遇到的坑。 </think>在 Kubernetes 中，**当 Pod 中的容器被 OOM 机制杀死后，Pod 是否会重启取决于其配置的 `restartPolicy`**。以下是具体机制分析： --- ### 一、OOM 触发后的行为流程 1. **OOM 事件发生** 当容器内存使用超过其 `limits.memory` 限制时，Linux 内核 OOM Killer 会强制终止容器内占用内存最多的进程（通常为业务进程），并记录事件： ```bash # 节点日志示例 Memory cgroup out of memory: Kill process 2151 (java) ``` 2. **容器状态变更** 容器退出码为 **`137`**（128 + 9，9 代表 `SIGKILL` 信号），Kubelet 检测到该状态： ```bash kubectl describe pod my-pod ``` ```yaml Containers: my-container: State: Terminated Reason: OOMKilled # 关键标识 Exit Code: 137 ``` 3. **Pod 重启决策** | `restartPolicy` 策略 | 是否重启容器 | 典型场景 | 引用依据 | |----------------------|--------------|------------------------|----------| | `Always` (默认) | ✅ 自动重启 | Deployment/StatefulSet | [^2] | | `OnFailure` | ✅ 自动重启 | Job/CronJob | [^2] | | `Never` | ❌ 不重启 | 特殊调试场景 | [^2] | --- ### 二、重启过程中的关键现象 1. **重启延迟与退避策略** Kubelet 采用指数退避（Exponential Backoff）算法控制重启间隔，避免频繁 OOM 导致雪崩： - 首次重启：立即 - 第二次重启：延迟 10 秒 - 第三次重启：延迟 20 秒 - 后续重启：延迟时间按 `2^n` 指数增长 2. **CrashLoopBackOff 状态** 当容器因 OOM 反复重启时，Pod 进入此状态： ```bash kubectl get pods ``` ``` NAME READY STATUS RESTARTS AGE my-pod 0/1 CrashLoopBackOff 3 2m ``` 此状态表示：**容器仍在尝试重启，但持续失败**。 --- ### 三、OOM 与驱逐（Eviction）的区别 | 机制 | 触发层级 | 结果 | 日志特征 | |-------------|--------------|-----------------------|-------------------| | **容器 OOM**| 容器级别 | 仅重启单个容器 | `OOMKilled` | | **节点驱逐**| 节点资源不足 | 整 Pod 被删除并迁移 | `Evicted` | 如引用[3]所述，节点驱逐由 kubelet 在资源不足时触发，与容器 OOM 机制独立[^3]。 --- ### 四、运维建议 1. **确认根本原因** 检查容器内存限制是否合理： ```bash kubectl get pod my-pod -o jsonpath='{.spec.containers[0].resources.limits.memory}' ``` 2. **调整内存配置** 在 Deployment 中增加内存限制与请求： ```yaml resources: requests: memory: "512Mi" # 保证调度时预留内存 limits: memory: "1Gi" # 硬性上限 ``` 3. **监控与告警** 配置 Prometheus 规则捕获 `OOMKilled` 事件： ```yaml - alert: ContainerOOM expr: kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1 for: 1m ``` > 💡 **经验总结**：容器 OOM 后默认会重启（除非 `restartPolicy: Never`），但需警惕高频重启导致的 `CrashLoopBackOff`，本质仍需解决内存超限问题[^1][^3]。 --- ### 五、相关问题延伸 1. 如何区分 `CrashLoopBackOff` 是由 OOM 还是其他原因导致？ 2. 容器内存限制设置过小会引发哪些副作用？ 3. Kubernetes 的 QoS 等级（Guaranteed/Burstable/BestEffort）如何影响 OOM 优先级？ 4. 如何通过 `kubectl events` 快速定位 OOM 事件？ [引用依据] [^1]: Kubernetes 内存管理机制 [^2]: Pod 生命周期与控制器行为规范 [^3]: 节点压力驱逐与 OOM 的区别
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Adam`南帝·梁

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值