一次意想不到的pod内存驱逐问题-51CTO.COM

案发现场

客户现场反馈门户网站无法打开，有很多pod状态为Evicted

kubectl get pods -A | grep 0/1
 web-nginx-865674789f-c7bv4  0/1   Evicted       0   25h   <none>  192.168.3.10  <none>
 web-nginx-865674789f-ggb27  0/1   Evicted       0   25h   <none>  192.168.3.10  <none>
 web-nginx-865674789f-fwp94  0/1   Evicted       0   25h   <none>  192.168.3.10  <none>
 web-nginx-865674789f-djj46  0/1   Evicted       0   25m   <none>  192.168.3.10  <none>
 web-nginx-865674789f-dmhmp  0/1   OOmMKilled    0   25h   <none>  192.168.3.10  <none>
 web-nginx-865674789f-1v6x4  0/1   Evicted       0   25h   <none>  192.168.3.10  <none>
 web-nginx-865674789f-ct66c  0/1   Evicted       0   25h   <none>  192.168.3.10  <none>
 web-nginx-865674789f-jk7ca  0/1   Evicted       0   25h   <none>  192.168.3.10  <none>1.
2.
3.
4.
5.
6.
7.
8.
9.

根据以往经验，驱逐问题让现场的实施同学查看监控，一般是磁盘或者内存会导致pod驱逐。客户的磁盘一直很充足，所以排除

如果内存占用达到90%之上，就拿着监控找客户扩容内存就好了

监控数据如下

节点内存为98G，故障时刻内存占用虽有上升，但是也在70%之下，看来此次问题并不如开始猜测的一样

那么kubectl describe pods web-nginx-xxx查看日志（或者查看集群events事件，操作系统messages日志也）

从日志上可以看出来是内存不足导致了驱逐，问题在于我们没有从监控上找到内存不足的证据。

破案

看来此次的问题和之前经验并不相同驱逐说明

我们来思考pod驱逐的原因。K8S通过kubelet来配置pod的驱逐参数，我们检查下驱逐阈值

evictionHard:
  imagefs.available: "2Gi"
  memory.available: "200Mi"  #剩余200m才驱逐
  nodefs.available: "1Gi"
  nodefs.inodesFree: "5%"
evictionPressureTransitionPeriod: 5m0s  #设置kubelet离开驱逐压力状况之前必须要等待的时长。
.....
kubeReserved:  #给K8S组件运行预留的资源
  cpu: 400m
  memory: 800Mi
  ephemeral-storage: 300Mi
kubeReservedCgroup: /kube.slice
systemReserved: #非kubernetes组件预留资源
  memory: 3Gi
  cpu: 500m
  ephemeral-storage: 2Gi1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

从上面的配置来看，K8S可用内存=总内存-（3G+800m+200m）

通过kubectl describe node 192.168.3.10查看节点分配的总内存

Capacity:
  cpu:                16
  ephemeral-storage:  1047015936Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             65806460Ki
  pods:               253
Allocatable:
  cpu:                15400m
  ephemeral-storage:  1043358208Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             63242364Ki  #可分配60G内存
  pods:               2531.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

Allocatable下的内存表示可分配的资源

60G和98G差了接近40G的资源，那么离真相已经很近了

和现场同学确认，问题出现前由于内存占用很高，做过一次在线扩容。

故障复盘：故障原因为前期内存资源不足后，虚拟机采用在线扩容内存的方式，服务器没有重启，并且K8S的kubelet服务也没有重启，获取到的内存配置仍然是60G，所以当主机内存达到60G的时候出现pod由于内存不足产生驱逐。

至于监控，node-exporter可以动态获取主机物理资源，所以过于依赖监控却忽略了检查kubelet。

另外一个原因是之前扩容内存都是重启服务器，忽略了这种异常场景

最后客户重启kubelet服务后，获取到了新的配额，问题解决！