一次意想不到的pod內存驅逐問題
處理項目上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: 253Allocatable下的內存表示可分配的資源
60G和98G差了接近40G的資源，那么離真相已經很近了
和現場同學確認，問題出現前由于內存占用很高，做過一次在線擴容。
故障復盤：故障原因為前期內存資源不足后，虛擬機采用在線擴容內存的方式，服務器沒有重啟，并且K8S的kubelet服務也沒有重啟，獲取到的內存配置仍然是60G，所以當主機內存達到60G的時候出現pod由于內存不足產生驅逐。
至于監控，node-exporter可以動態獲取主機物理資源，所以過于依賴監控卻忽略了檢查kubelet。
另外一個原因是之前擴容內存都是重啟服務器，忽略了這種異常場景
最后客戶重啟kubelet服務后，獲取到了新的配額，問題解決！
責任編輯：龐桂玉
來源：
運維之美
