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