问题描述

 pod 达到内存上限被 K8s 杀了。

进一步分析

于是问题就来了，为啥 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

  Last State:     
  Terminated      
  Reason:       
  Error      
  Exit Code:    
  137

什么是K8s的QoS？

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

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

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

QoS相同的情况，肯定还是会有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.

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。

• 宿主机内存扩容，不然杀死pod这样的事情无法避免，无非就是杀哪个的问题；

• 对于关键服务的pod，要把 request 和 limit 设置为完全一致，让 pod的 QoS 置为Guaranteed，尽可能降低pod被杀的几率。