一次性意想不到的pod内存驱逐疑问

客户现场反应门户网站无法关上，有很多pod形态为Evicted

kubectl get pods -A | grep 0/1 web-nginx-865674789f-c7bv40/1Evicted025h<none>192.168.3.10<none> web-nginx-865674789f-ggb270/1Evicted025h<none>192.168.3.10<none> web-nginx-865674789f-fwp940/1Evicted025h<none>192.168.3.10<none> web-nginx-865674789f-djj460/1Evicted025m<none>192.168.3.10<none> web-nginx-865674789f-dmhmp0/1OOmMKilled025h<none>192.168.3.10<none> web-nginx-865674789f-1v6x40/1Evicted025h<none>192.168.3.10<none> web-nginx-865674789f-ct66c0/1Evicted025h<none>192.168.3.10<none> web-nginx-865674789f-jk7ca0/1Evicted025h<none>192.168.3.10<none>

依据以往阅历，驱逐疑问让现场的实施同窗检查监控，普通是磁盘或许内存会造成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: mmemory: 800Miephemeral-storage: 300MikubeReservedCgroup: /kube.slicesystemReserved: #非kubernetes组件预留资源memory: 3Gicpu: 500mephemeral-storage: 2Gi

从上方的性能来看，K8S可用内存=总内存-（3G+800m+200m）

经过kubectl describe node192.168.3.10检查节点调配的总内存

Capacity:cpu:16ephemeral-storage:1047936Kihugepages-1Gi:0hugepages-2Mi:0memory:65806460Kipods:253Allocatable:cpu:15mephemeral-storage:1043358208Kihugepages-1Gi:0hugepages-2Mi:0memory:63242364Ki#可调配60G内存pods:253

Allocatable下的内存示意可调配的资源

60G和98G差了凑近40G的资源，那么离假相曾经很近了

和现场同窗确认，疑问发生前由于内存占用很高，做过一次性在线扩容 。

缺点复盘：缺点要素为前期内存资源无余后，虚构机驳回在线扩容内存的方式，主机没有重启，并且K8S的kubelet服务也没有重启，失掉到的内存性能依然是60G，所以当主机内存到达60G的时刻发生pod由于内存无余发生驱逐。

至于监控，node-exporter可以灵活失掉主机物理资源，所以过于依赖监控却疏忽了审核kubelet。

另外一个要素是之前扩容内存都是重启主机，疏忽了这种异常场景

最后客户重启kubelet服务后，失掉到了新的配额，疑问处置！