为什么库伯内特斯会杀死一个暂停容器？

Question

偶尔，我们的库伯内特斯星系团（GKE上为1.12.7）会发出如下事件：

1 OOMKilling: Memory cgroup out of memory: Kill process 605624 (pause) score 0 or sacrifice child
Killed process 605624 (pause) total-vm:1024kB, anon-rss:4kB, file-rss:0kB, shmem-rss:0kB

与此同时，我们看到Docker的一个事件：

datadog/agent@sha256:904c18135ec534fc81c29a42537725946b23ba19ac3c0a8b2e942fe39981af20 1 oom 1 kill 1 die 1 stop 1 destroy 1 create 1 start on gke-prod-pool-1-dc20d284-sjwm...

OOM     k8s_datadog-agent_datadog-agent-76v8c_default_bf678779-c318-11e9-b064-42010a9a0059_7  
KILL    k8s_datadog-agent_datadog-agent-76v8c_default_bf678779-c318-11e9-b064-42010a9a0059_7  
...

datadog代理pod也会重新启动。

此特定pod配置有保证的QoS。根据本页节点OOM行为下的表格，保证的pod应该具有-998的oom分数。

为什么暂停容器在这里被杀死？既然它似乎是datadog代理的暂停容器，为什么oom分数是0，而不是-998？

Answer 1

库伯内特斯有它的机制来指定容器的最小和最大要求；例如，您可以有：

 resources:
    limits: 150M
 requests:
    memory: 50M

当你的豆荚越过最大“限制”线时，豆荚将被杀死并报告为OOM死亡，你是否有足够的内存并不重要；由于您已经通过给他们打分来调查了这一过程，分数越高，该过程终止的可能性越大，反之，分数越低，该过程被送到屠宰场的可能性越小（因此，对于您想要保存的过程，使用负值）；由于这并不是全部，内核也有一些oom_score_adj需要调整和控制，比如说，人为地控制分数，并在杀戮线中保留或不保留进程。

当为pod设置内存限制时，K8s根据您正确的状态QoS（可爆）发出OOM_SCORE_ADJ值，以确保OOMK选择特定的容器并杀死它。

最后，为了回答分数问题，关于为什么会得到这样的分数，这个“表格”可能对你有用：

 +------------------+------------------------+
 |     QoS          |           Score        |
 |  (Setting)       |     (Value or formula) |
 +-------------------------------------------+
 | Guaranteed       |           -998         |
 +-------------------------------------------+
 | Best effort      |           1000         |
 +-------------------------------------------+
 | Burstable        |          Formula       |
 +------------------+------------------------+

分值公式为暴躁es等于：

 min( max(2, 1000 - (1000 * mRB) / mMCB), 999)
 mRB = Memory Request Bytes.
 mMCB = Machine Memory Capacity Bytes

由于GKE/Kubernetes的QoS是稳定的，所以这就是它在杀戮室中的作用。

我相信这些信息会对您有用，但我也建议您查看以下链接：[1]OOR节点OOM行为（Kubernetes.io）[2]容器和pod内存分配

问候！

[1] https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#node-oom行为

[2] https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/#exceed-a-容器-内存限制