一次意想不到的pod記憶體驅逐問題
公眾號關注 「運維之美」
設為「星標」,每天帶你玩轉 Linux
處理專案上K8S叢集pod驅逐問題也算不少了,不過此次產生pod驅逐的原因卻是意想不到,最後覆盤原因很簡單,定位故障時候卻是忽略了,不過也算豐富了處理故障的案例。
案發現場
客戶現場反饋入口網站無法開啟,有很多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>
根據以往經驗,驅逐問題讓現場的實施同學檢視監控,一般是磁碟或者記憶體會導致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: 2Gi
從上面的配置來看,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: 253
Allocatable下的記憶體表示可分配的資源
60G和98G差了接近40G的資源,那麼離真相已經很近了
和現場同學確認,問題出現前由於記憶體佔用很高,做過一次線上擴容。
故障覆盤:故障原因為前期記憶體資源不足後,虛擬機器採用線上擴容記憶體的方式,伺服器沒有重啟,並且K8S的kubelet服務也沒有重啟,獲取到的記憶體配置仍然是60G,所以當主機記憶體達到60G的時候出現pod由於記憶體不足產生驅逐。
至於監控,node-exporter可以動態獲取主機物理資源,所以過於依賴監控卻忽略了檢查kubelet。
另外一個原因是之前擴容記憶體都是重啟伺服器,忽略了這種異常場景
最後客戶重啟kubelet服務後,獲取到了新的配額,問題解決!
堅持更新不易
如果覺得今天的分享對您有所幫助
歡迎分享給更多的朋友
看完了別忘了送給我一個四連點
支援鼓勵一下