今天下午运维反馈说我们这一个pod一天重启了8次,需要排查下原因。一看Kiban日志,jvm没有抛出过任何错误,服务就直接重启了。显然是进程被直接杀了,初步判断是pod达到内存上限被K8s oomkill了。
因为我们xmx和xsx设置的都是3G,而pod的内存上限设置的是6G,所以出现这种情况还挺诡异的。
先找运维拉了一下pod的描述,关键信息在这里
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
但是运维反馈说无法再扩大pod的内存限制,因为宿主机的内存已经占到了99%了。
然后结合pod的内存监控,发现pod被杀前的内存占用只到4G左右,没有达到上限的6G,pod就被kill掉了。
于是问题就来了,为啥pod没有达到内存上限就被kill了呢。
带着疑问,我开始在google里寻找答案,也发现了一些端倪:
最终还是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来释放资源。
QoS,指的是Quality of Service,也就是k8s用来标记各个pod对于资源使用情况的质量,QoS会直接影响当节点资源耗尽的时候k8s对pod进行evict的决策。官方的描述在这里.
k8s会以pod的描述文件里的资源限制,对pod进行分级:
QoS | 条件 |
---|---|
Guaranteed | 1. pod里所有的容器都必须设置cpu和内存的request和limit,2. pod里所有容器设置的cpu和内存的request和容器设置的limit必须相等(容器自身相等,不同容器可以不等) |
Burstable | 1. pod并不满足Guaranteed的条件,2. 至少有一个容器设置了cpu或者内存的request或者limit |
BestEffort | pod里的所有容器,都没有设置任何资源的request和limit |
当节点资源耗尽的时候,k8s会按照BestEffort->Burstable->Guaranteed这样的优先级去选择杀死pod去释放资源。
从上面运维给我们的pod描述可以看到,这个pod的资源限制是这样的:
Limits: cpu: 8 memory: 6Gi Requests: cpu: 100m memory: 512Mi
显然符合的是Burstable的标准,所以宿主机内存耗尽的情况下,如果其他服务都是Guaranteed,那自然会一直杀死这个pod来释放资源,哪怕pod本身并没有达到6G的内存上限。
但是和运维沟通了一下,我们集群内所有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 anoom_score
based on the percentage of memory it's using on the node, and then adds theoom_score_adj
to get an effectiveoom_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计算出来的一个偏移值,计算方法:
QoS | oom_score_adj |
---|---|
Guaranteed | -997 |
BestEffort | 1000 |
Burstable | min(max(2, 1000 - (1000 × memoryRequestBytes) / machineMemoryCapacityBytes), 999) |
从这个表格可以看出:
至此已经可以基本上定位出Pod被反复重启的原因了:
那么如何解决呢?