Kubernetes pod 内存与 cgroup答案

【问题标题】：Kubernetes pod memory vs cgroupKubernetes pod 内存与 cgroup
【发布时间】：2021-02-14 23:59:10
【问题描述】：

我在 Kubernetes pod 中运行 apache，我对 apache 进程的随机 OOM 终止感到困扰，我不确定原因。

Pod 有 600M 的内存限制，即使 PHP 每次运行有 128 MB 的限制，它似乎也可以很容易地消耗它。在观察dmesg -w时，我可以经常看到：

[4019392.626796] Memory cgroup out of memory: Kill process 4178127 (apache2) score 1137 or sacrifice child
[4019392.636520] Killed process 4178127 (apache2) total-vm:143960kB, anon-rss:22856kB, file-rss:10472kB, shmem-rss:28228kB

如何确定此 OOM 终止与机器或 pod 限制有关？
有几个 apache pod，我不确定如何识别该进程所属的 pod。有办法吗？
如果这些可以在 pod 中访问，那就太好了，这样人们就可以看到实际上属于 pod 的已终止线程（最好是在错误输出中）。有可能吗？

【问题讨论】：

你能分享 apache pod 的 kubectl get pods、kubectl logs ${POD_NAME} ${CONTAINER_NAME} 和 kubectl describe pod <pod_name> 的输出吗？
这些日志中没有任何内容 - 这只发生在节点级别。 pod 本身没有被杀死，这些日志中绝对没有错误。

标签： kubernetes out-of-memory cgroups

【解决方案1】：

按相同顺序回答您的问题：

kubectl get events 在您运行 pod 的命名空间中。您将看到 Kubernetes OOM 事件等。如果什么都没有，那就是内核本身。
有一个 project called pid2pod，但它仅 greps 仍在运行的内容。另一种选择是将 dmesg 路由到标准输出（在容器操作系统级别）并实现centralized log collection with Kubernetes metadata enrichment。那么每个日志事件的元数据中都会有 pod id。
不确定您要在这里解决什么问题。通常，一个 pod（我假设是一个容器）是一个进程。一旦它被 OOM 杀死，在 pod 内就没有其他东西可以对此采取行动了。对此事件做出反应并重新创建 pod 是控制器 (Deployment) 的责任。

如果您只想查看剩余 pod 中的 OOM，您可以实现类似 kubewatch 的方法。不幸的是，我没有可以让您直接在 pod 中订阅的项目，但这可以用作示例。或者在集中式日志记录的情况下，您可以订阅 pod 内的日志流。

【讨论】：

1. get events 只返回不相关的日志。这些似乎只是节点级别的事件。如果这是内核 - 为什么会发生这种情况？这是否意味着节点本身内存不足？我试过describe nodes 并且有：memory request:4728813952 (33%) limit:7493386752 (53%) 所以我想这不应该发生，因为还有足够的内存？
这很可能是由于 pod 限制给节点内存利用率造成的。您是否在名称空间中寻找事件？另外，请注意事件仅存在 1 小时。你也可以通过查看kubectl get po <restarted-pod-id> -oyaml来证明它是kubernetes OOM，在status字段中会有：Reason: OOMKilled
<restarted-pod-id> 注意 - pod 本身没有重新启动。它只是杀死了它里面的 apache 进程。奇怪的是该节点不在其限制和kubectl top pods 相似。
我明白了。一个 pod 内是否有多个 apache 进程？通常，容器是单个进程，一旦存在，pod 也应该退出
Apache fork 到几个进程 - 所以它不会杀死主进程。但是为什么这没有记录在 pod 日志或 kube 事件中呢？