一次意想不到的pod內(nèi)存驅(qū)逐問(wèn)題
案發(fā)現(xiàn)場(chǎng)
客戶(hù)現(xiàn)場(chǎng)反饋門(mén)戶(hù)網(wǎng)站無(wú)法打開(kāi)，有很多pod狀態(tài)為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>根據(jù)以往經(jīng)驗(yàn)，驅(qū)逐問(wèn)題讓現(xiàn)場(chǎng)的實(shí)施同學(xué)查看監(jiān)控，一般是磁盤(pán)或者內(nèi)存會(huì)導(dǎo)致pod驅(qū)逐?？蛻?hù)的磁盤(pán)一直很充足，所以排除
如果內(nèi)存占用達(dá)到90%之上，就拿著監(jiān)控找客戶(hù)擴(kuò)容內(nèi)存就好了
監(jiān)控?cái)?shù)據(jù)如下
節(jié)點(diǎn)內(nèi)存為98G，故障時(shí)刻內(nèi)存占用雖有上升，但是也在70%之下，看來(lái)此次問(wèn)題并不如開(kāi)始猜測(cè)的一樣
那么kubectl describe pods web-nginx-xxx查看日志（或者查看集群events事件，操作系統(tǒng)messages日志也）
從日志上可以看出來(lái)是內(nèi)存不足導(dǎo)致了驅(qū)逐，問(wèn)題在于我們沒(méi)有從監(jiān)控上找到內(nèi)存不足的證據(jù)。
破案
看來(lái)此次的問(wèn)題和之前經(jīng)驗(yàn)并不相同 驅(qū)逐說(shuō)明
我們來(lái)思考pod驅(qū)逐的原因。K8S通過(guò)kubelet來(lái)配置pod的驅(qū)逐參數(shù)，我們檢查下驅(qū)逐閾值
evictionHard:
imagefs.available: "2Gi"
memory.available: "200Mi" #剩余200m才驅(qū)逐
nodefs.available: "1Gi"
nodefs.inodesFree: "5%"
evictionPressureTransitionPeriod: 5m0s #設(shè)置kubelet離開(kāi)驅(qū)逐壓力狀況之前必須要等待的時(shí)長(zhǎng)。
.....
kubeReserved: #給K8S組件運(yùn)行預(yù)留的資源
cpu: 400m
memory: 800Mi
ephemeral-storage: 300Mi
kubeReservedCgroup: /kube.slice
systemReserved: #非kubernetes組件預(yù)留資源
memory: 3Gi
cpu: 500m
ephemeral-storage: 2Gi從上面的配置來(lái)看，K8S可用內(nèi)存=總內(nèi)存-（3G+800m+200m）
通過(guò)kubectl describe node 192.168.3.10查看節(jié)點(diǎn)分配的總內(nèi)存
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內(nèi)存
pods: 253Allocatable下的內(nèi)存表示可分配的資源
60G和98G差了接近40G的資源，那么離真相已經(jīng)很近了
和現(xiàn)場(chǎng)同學(xué)確認(rèn)，問(wèn)題出現(xiàn)前由于內(nèi)存占用很高，做過(guò)一次在線(xiàn)擴(kuò)容。
故障復(fù)盤(pán)：故障原因?yàn)榍捌趦?nèi)存資源不足后，虛擬機(jī)采用在線(xiàn)擴(kuò)容內(nèi)存的方式，服務(wù)器沒(méi)有重啟，并且K8S的kubelet服務(wù)也沒(méi)有重啟，獲取到的內(nèi)存配置仍然是60G，所以當(dāng)主機(jī)內(nèi)存達(dá)到60G的時(shí)候出現(xiàn)pod由于內(nèi)存不足產(chǎn)生驅(qū)逐。
至于監(jiān)控，node-exporter可以動(dòng)態(tài)獲取主機(jī)物理資源，所以過(guò)于依賴(lài)監(jiān)控卻忽略了檢查kubelet。
另外一個(gè)原因是之前擴(kuò)容內(nèi)存都是重啟服務(wù)器，忽略了這種異常場(chǎng)景
最后客戶(hù)重啟kubelet服務(wù)后，獲取到了新的配額，問(wèn)題解決！
