当Kubernetes 环境中的 pod 或容器超过分配给它们的内存量时，将触发退出代码 137 。通常，此退出代码伴随或简称为 OOMKilled。这里描述的killed是指这个错误的结果，它导致一个pod终止。
首字母缩略词 OOM 代表内存不足，这是由 pod 超出设置的内存限制引起的。如果您不确定 pod 终止的原因，最简单的找出方法之一是运行“kubectl get pods command”，然后会在特定 pod 上调用状态更新。然后，您会在其中找到 OOMKilled，它会提醒您退出代码 137 已被触发。
OOMKilled 从何而来？
虽然 OOMKilled 是您可能会在 Kubernetes 环境中看到的响应，但它实际上并不是该系统的原生响应。事实上，它是Linux 编程的一个核心特性
，已被转移到 Kubernetes 以帮助促进这个系统。在 Linux 内核中，OOMKilled 被称为 OOM Killer，提供与 Kubernetes 中相同的警告和响应。
通常，如果一个平台在某个系统上占用了过多的内存，Linux 将遍历不同的节点并决定杀死哪个节点，并使用 oom_score 对所有节点进行评分，以评估哪些节点占用了最多的内存。最少的内存。占用内存最多的节点最有可能被终止，退出代码 137 是为此给出的推理。
OOMKilled 的原因是什么？
如果您的 Kubernetes 生态系统返回 'exited with code 137
'，那么您很可能在该系统中面临内存问题。虽然这可能是一个令人沮丧的问题，但这并不是世界末日，因为这是一个相当容易解决的问题。
通常，在 Kubernetes 环境中，OOMKilled 有几个核心原因：
- 内存限制——在运行 Kubernetes 环境时，通常有数百个节点都在为共同利益而工作。虽然此系统有效，但内存限制可能会导致出现退出代码 137，这将终止您正在其中工作的 pod。造成这种情况的最常见原因之一是 pod 内的内存限制。在每个 Kubernetes pod 中，您可以指定对 pod 的内存限制。如果超过此值，您将收到 OOMKilled 错误。
- 内存泄漏——如果一个容器有一定的内存限制，那么它有时会达到限制，然后开始泄漏到其他进程中。这将被标记为错误，然后终止。
- Overcommitted Nodes –当 pod 使用的内存超过分配给它的内存时，您将收到此特定错误。
由于这是一个基于内存的错误，因此此退出代码的任何原因都与 Kubernetes 生态系统中的内存管理或使用不善有关。
如何修复退出代码 137？
如前所述，退出代码 137 是最容易修复的错误之一，因为它归结为减少进程或增加每个节点分配的内存量。
如果您尝试修复退出代码 137，请尝试以下三件事：
- 增加磁盘空间——很简单，修复任何连接到内存的内存的最简单方法是增加 Kubernetes 环境必须使用的磁盘空间。这是一揽子解决方案，因为增加空间量将确保您的生态系统不再达到其最大值。但是，如果您一直遇到此问题，那么您应该尝试尝试以下两个修复程序，以确保您创建一个内存高效的系统。
- 添加额外的 pod 卷——在 Kubernetes 的每个 pod 中，您可以设置某个 pod 允许使用的最小和最大内存量。如果一些 pod 一直收到退出代码 137 返回给它们，那么这表明您需要增加为 pod 提供的空间量。通过在压力最大的吊舱中手动增加最大限制，您将能够降低发生此问题的频率。
- 减少并行运行器——并行处理是您一次运行两个系统以修复或维护不同功能的地方。虽然这提高了 Kubernetes 的效率和你可以用它实现的目标，但它也给整个生态系统的内存带来了更大的压力。通过减少并行运行频率
，您将能够保持系统的整体内存使用量较低，从而有助于减少您遇到的退出代码 137 的数量。
通过这三个步骤，您很可能会增加系统的内存量，并优化各个 pod 以确保它们有足够的内存来完成所有功能而不会意外终止。
最后的想法
如果您在 Kubernetes 中遇到退出代码 137，那么您的 Kubernetes 环境如何管理其 pod、节点和容器的空间可能存在问题。作为基准，Kubernetes 建议您为集群中的每个节点提供大约 300 MIB 的内存，这应该足以让节点正常运行。
但是，根据 Kubernetes 生态系统的复杂性，拥有尽可能多的内存总是一个更好的主意。如果您的系统有足够的空间，则指定更高的存储量以帮助每个节点运行，而无需出现退出代码 137。
