一次 K8s Pod 频繁被“驱逐”，结果竟是这样的？

问题描述

某天下午运维反馈说我们这一个pod一天重启了8次，需要排查下原因。一看 Kibana 日志，jvm 没有抛出过任何错误，服务就直接重启了。显然是进程被直接杀了，初步判断是 pod 达到内存上限被 K8s oomkill 了。

Containers:  container-prod--:    Container ID:   --    Image:          --    Image ID:       docker-pullable://--    Port:           8080/TCP    Host Port:      0/TCP    State:          Running      Started:      Fri, 05 Jan 2024 11:40:01 +0800    Last State:     Terminated      Reason:       Error      Exit Code:    137      Started:      Fri, 05 Jan 2024 11:27:38 +0800      Finished:     Fri, 05 Jan 2024 11:39:58 +0800    Ready:          True    Restart Count:  8    Limits:      cpu:     8      memory:  6Gi    Requests:      cpu:        100m      memory:     512Mi

可以看到 Last State：Terminated，Exit Code: 137。这个错误码表示的是 pod进程被 SIGKILL 给杀掉了。一般情况下是因为 pod 达到内存上限被 K8s 杀了。

因此得出结论是生产环境暂时先扩大下 pod 的内存限制，让服务稳住。然后再排查为啥 pod 里会有这么多的堆外内存占用。

进一步分析

但是运维反馈说无法再扩大 pod 的内存限制，因为宿主机的内存已经占到了99%了。

然后结合pod的内存监控，发现pod被杀前的内存占用只到4G左右，没有达到上限的6G，pod 就被 kill 掉了。

于是问题就来了，为啥 pod 没有达到内存上限就被kill了呢。

带着疑问，我开始在google里寻找答案，也发现了一些端倪：

如果是 pod 内存达到上限被 kill，pod 的描述里会写 Exit Code: 137，但是Reason 不是 Error，而是 OOMKilled；
宿主机内存已经吃满，会触发 k8s 的保护机制，开始 evict 一些 pod 来释放资源；
但是为什么整个集群里，只有这个 pod 被反复 evict，其他服务没有影响？

谜题解开

最终还是google给出了答案：

Why my pod gets OOMKill (exit code 137) without reaching threshold of requested memory

链接里的作者遇到了和我一样的情况，pod还没吃到内存上限就被杀了，而且也是：

  Last State:     Terminated      Reason:       Error      Exit Code:    137

作者最终定位的原因是因为k8s的QoS机制，在宿主机资源耗尽的时候，会按照QoS机制的优先级，去杀掉pod来释放资源。

什么是K8s的QoS？

QoS，指的是Quality of Service，也就是 K8s 用来标记各个pod对于资源使用情况的质量，QoS会直接影响当节点资源耗尽的时候k8s对pod进行evict的决策。官方的描述在这里。

K8s会以pod的描述文件里的资源限制，对pod进行分级：

当节点资源耗尽的时候，k8s会按照BestEffort->Burstable->Guaranteed这样的优先级去选择杀死pod去释放资源。

从上面运维给我们的pod描述可以看到，这个 pod 的资源限制是这样的：

  Limits:      cpu:     8      memory:  6Gi    Requests:      cpu:        100m      memory:     512Mi

显然符合的是Burstable的标准，所以宿主机内存耗尽的情况下，如果其他服务都是Guaranteed，那自然会一直杀死这个pod来释放资源，哪怕pod本身并没有达到6G的内存上限。

QoS相同的情况下，按照什么优先级去Evict？

但是和运维沟通了一下，我们集群内所有pod的配置，limit和request都是不一样的，也就是说，大家都是Burstable。所以为什么其他pod没有被evict，只有这个pod被反复evict呢？

QoS相同的情况，肯定还是会有evict的优先级的，只是需要我们再去寻找下官方文档。

关于Node资源耗尽时候的Evict机制，官方文档有很详细的描述。

其中最关键的一段是这个：

If the kubelet can’t reclaim memory before a node experiences OOM, the oom_killer calculates an oom_score based on the percentage of memory it’s using on the node, and then adds the oom_score_adj to get an effective oom_score for each container. It then kills the container with the highest score.

This means that containers in low QoS pods that consume a large amount of memory relative to their scheduling requests are killed first.

简单来说就是pod evict的标准来自oom_score，每个pod都会被计算出来一个oom_score，而oom_score的计算方式是：pod使用的内存占总内存的比例加上pod的oom_score_adj值。

oom_score_adj 的值是 k8s 基于 QoS 计算出来的一个偏移值，计算方法：

从这个表格可以看出：

首先是BestEffort->Burstable->Guaranteed这样的一个整体的优先级
然后都是Burstable的时候，pod实际占用内存/pod的request内存比例最高的，会被优先Evict

总结

至此已经可以基本上定位出 Pod 被反复重启的原因了：

K8s 节点宿主机内存占用满了，触发了Node-pressure Eviction；
按照Node-pressure Eviction的优先级，k8s选择了oom_score最高的pod去evict；
由于所有pod都是Burstable，并且设置的request memery都是一样的512M，因此内存占用最多的pod计算出来的oom_score就是最高的；
所有 pod 中，这个服务的内存占用一直都是最高的，所以每次计算出来，最后都是杀死这个pod。

那么如何解决呢？