k8s pod exit code137 | kubelet invoked oom-killer

一次K8S的pod无限重启的解决思路。

本文研究的都是确定性的问题，好像没有什么意义，话说回来，如果没有学习这些确定性问题的积累，又如何去应对不确定的问题呢？作者：免帅叫哥链接：https://www.jianshu.com/p/0a9718199428来源：简书著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

当 Kubernetes 集群中的容器超过其内存限制时，Kubernetes 系统可能会终止该容器并显示“OOMKilled”错误，这表明该进程由于内存不足而被终止。此错误的退出代码是 137。

现象 k8s pod一直在重启，调度不起来 排查 1. 首先看状态 这个比较简单，我直接在页面上的(rancher查看api、查看/编辑yaml等都能看) 如图，找到containerStatuses，里面有个exitCode：137 网上搜了下错误码的意思： 退出代码 0：一般为容器正常退出 退出代码 1：由于容器中 pid 为 1 的进程错误而失败 退出代码 137：由于容器收到 SIGKILL 信号而失败（手动执行或“oom-killer” [OUT-OF-MEMORY]） = 退出代码 139：

当Kubernetes 环境中的 pod 或容器超过分配给它们的内存量时，将触发退出代码 137 。通常，此退出代码伴随或简称为 OOMKilled。这里描述的killed是指这个错误的结果，它导致一个pod终止。首字母缩略词 OOM 代表内存不足，这是由 pod 超出设置的内存限制引起的。如果您不确定 pod 终止的原因，最简单的找出方法之一是运行“kubectl get pods command”，然后会在特定 pod 上调用状态更新。然后，您会在其中找到 OOMKilled，它会提醒您退出代码 137

某天查看线上服务，发现有个服务平均每天重启一次，通过k8s descripe pod podName 命令发现exit code： 137 reason: OOM Killed. 提示比较明显OOM（当时查了失败的容器内服务日志，发现没有异常信息，有点疑惑的）,然后果断在jvm配置里添加OOM自动dump日志参数，-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof，等着问题后分析日志原因（我们体量不大，同时又是多节点，所.

发现原因：红框里的信息OOMKilled，退出的提示码是137，经过查询发现是部署服务时的yaml文件里的限制内存写的有点小，简单来说就是：你运行项目需要的内存比你设置的内存大，在你运行项目的时候申请内存超过了你限制的内存就会报错退出，然后重启。一开始以为是程序中下载的训练模型太大了，每天都下载一遍模型并且不会删除，导致内存溢出服务挂掉然后重启。在自己文件中把这个改大了一些，观察了一段时间，暂时还没有遇到重启。网上看到有人说可能是服务部署设置的问题，使用命令。问题：发现部署到k8s上的服务一直在自动重启。

程序正确运行结束的提示是：Process finished with exit code 0。如果程序出现Process finished with code 137 (interrupted by signal 9: SIGKILL)。程序并没有运行完，系统强制杀死进程，一般来说是因为内存不足或者CPU不够用。 出现这个信息说明发生了内存不足的问题，需要让程序少一些内存占用，在keras中，可以选择小的batch_size，不要把一整个大的文件一次性读到内存里。 loss或者网络的输出不断积累导致计算图

docker容器莫名挂掉，docker ps -a 查看后报错：Exited (137) *** ago 这时通过docker logs查看容器内查不到任何报错日志，从mesos上看stderr相关的只有一句 I0409 16:56:26.408077 8583 executor.cpp:736] Container exited with status 137 通过docker inspect查看container状态为 "State": { "Status": "exited",

最近公司用户量暴涨，老板笑嘻嘻，但是搬砖的心里MMP，服务器压力骤然上升，最近大数据集群在跑spark任务时老是报“Container exited with a non-zero exit code 137”这样的错误，详细日志如下： 22/04/29 11:02:27 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Requesting driver to remove executor 4 for reason Container marked a

退出，这反而不正常！这说明你的应用程序可能在启动后错误地执行完了某个逻辑就退出了，比如一个 Web 服务器启动脚本在启动完守护进程后自己就退了。操作系统和 Shell 只需要检查这个最高位，就能瞬间判断出进程是“寿终正寝”还是“意外身亡”，这是一种非常高效的约定！如果 退出码 & 128 的结果是 1 (或者说非0) -> 说明进程是被信号杀死的。: 这是最常见的错误码，通常意味着程序捕获到了一个异常但并未处理（或处理后决定退出）。这是一个“优雅退出”的终止信号，它告诉程序“请你准备一下，然后正常退出”。

Linux环境下pycharm报错：Process finished with exit code 137 (interrupted by singal 9: SIGKILL) 报错情况如下图所示： 环境：VMware16 ubuntu 我在做nemo项目的时候，运

当容器（Spark 执行程序）内存不足时，YARN 会自动将其终止。这会导致“Container killed on request.Exit code is 137”（根据要求终止容器。退出代码为 137）错误。这些错误可能发生在不同的作业阶段，无论是否发生shuffle

docker-compose up时，报了某Container exited with code 137… 我怀疑该容器被Linux进行OOMKille了...

Exited(137)，docker exec -it 容器名 /bin/bash 无法进入

通过 SSH 远程连接一台服务器，然后运行 Docker 容器，容器最终停掉并显示。容器显示：Stopped for 6 hours with exit code 137。

logstash 常见问题排查处理

问题：Ubuntu20.04,在pycharm中运行程序报错退出，pycharm Process finished with exit code 137 (interrupted by signal 9: SIGKIL）