OOMKIlling 事件与实际被杀死的 pod 之间的关联

Question

我正在使用 Kubernetes 事件 API 来检查我的集群是否有任何 OOM 事件。如果确实如此，我将发送有关此事件的警报。

现在我必须发送的唯一信息是节点名称、事件名称、原因（例如 OOMKilling）和事件消息，对于 OOM 通常会终止进程以及进程中的命令行名称，例如：

"(combined from similar events): Memory cgroup out of memory: Killed process 3448515 (stress) total-vm:1536784kB, anon-rss:522964kB, file-rss:332kB, shmem-rss:0kB, UID:0 pgtables:1064kB oom_score_adj:871"

我希望能够准确地指出哪个 pod 被杀死和 哪个 pod，如果可能的话导致了这个 OOM（这取决于优先级配置可能是两个不同的 pod）。

我现在能看到的唯一方法是将

OOMKilling

事件与 Pod 在 OOM 发生时应该具有的

BackOff

事件关联起来。但这感觉可能会导致一些错误的启发式和时间问题（我是否过早发送了 API 调用？

也许我现在只看到OOM事件，而没有看到

BackOff

事件），即使我这样做，我也只能找到被杀死的pod，而不是事件的罪魁祸首——当罪魁祸首的pod具有更高的优先级时类，并杀死另一个 pod 足以满足节点中的内存需求。

API 中有什么我遗漏的吗？也许我可以使用其他一些 API 来找到它？

我还考虑过使用 kube-state-metrics，因为它们有 OOM 事件的指标，但是对于我的系统结构，KSM 并不能完全帮助我，但是在 KSM 中，它们有每个 POD 而不是每个节点的 OOM 事件，所以这应该也是可能的。

使用事件API和k8s项目的核心API来获取OOM事件。

我查看了 KSM 和其他各种来源，试图找出哪个 pod 是节点上发生 OOM 事件的罪魁祸首。