在大内存节点上,小型/中型容器的 Kubelet OOM 分数计算结果降为 999,且忽略了对每个容器的内存保证

目前，GetContainerOOMScoreAdjust 为 Burstable 容器计算 oom_score_adj 如下：

oom_score_adj = 1000 - (1000 * memoryRequest) / memoryCapacity

被限制在 [3, 999] 之间，而 Linux 内核则计算进程的坏点数如下：

points = oom_score_adj + (usage_bytes * 1000) / memoryCapacity

在 2015 年编写此启发式方法时，节点通常具有 4 GiB–64 GiB 的 RAM。在运行微服务的现代 1 TiB–4 TiB 节点上，此公式以三种方式崩溃：

1. 整数量化崩溃 ("一切都是 999")

由于公式在整数算术中按 1000 个桶进行除法，因此任何请求少于 memoryCapacity / 1000 的容器都会评估为：

(1000 * memoryRequest) / memoryCapacity == 0  =>  oom_score_adj = 999

• 在 1 TiB (1024 GiB) 节点上，每个请求 < 1.024 GiB 的容器都会得到 oom_score_adj = 999。一个请求 50 MiB、256 MiB 或 1 GiB 的容器也会得到相同的分数（999）。
• 在 4 TiB 节点上，每个请求 < 4.096 GiB 的容器都会得到 oom_score_adj = 999。
• 注意：虽然 #111356 观察到了此症状，并且 PR #128029 通过复制常规容器的最小分数来缓解原生副程序，但常规容器本身在大节点上仍会崩溃到 999（这也使副程序调整无效）。

2. 丢失容器级别的内存保证（R / L）

由于 Kubernetes QoS 在 CPU 和内存上均在 Pod 级别进行评估，因此明确设置 memory.requests == memory.limits（零内存超额）的容器在以下情况下被强制进入 Burstable QoS：

• Pod 中存在另一个可突发的容器（例如，一个 Orchestrator + Executor Pod）。
• CPU 限制未设置或与之不同。 …