k8s pod被驅(qū)逐問(wèn)題分析及解決方法是什么

1、問(wèn)題現(xiàn)象及分析

環(huán)境說(shuō)明

環(huán)境說(shuō)明：

• centos7.3
• Kubernetes1.14
• docker 1.18.9

異常信息：kubectl get pod發(fā)現(xiàn)服務(wù)被驅(qū)逐，然后在調(diào)度到其它節(jié)點(diǎn)過(guò)程中出現(xiàn)問(wèn)題，之所以出現(xiàn)問(wèn)題是因?yàn)榫幣盼募刑砑恿宋埸c(diǎn)，已經(jīng)標(biāo)注該P(yáng)od不能被調(diào)度到其它節(jié)點(diǎn)。但是為什么會(huì)出現(xiàn)Pod被驅(qū)逐，這倒是個(gè)問(wèn)題？查看/var/log/messages中日志，發(fā)現(xiàn)大量鏡像無(wú)法被拉取的錯(cuò)誤，如下所示：

鏡像被刪除問(wèn)題

Nov  7 06:20:49 k8work2 kubelet: E1107 06:20:49.829886   13241 remote_image.go:113] PullImage "k8s.gcr.io/kube-proxy:v1.14.2" from image service failed: rpc error: code = Unknown desc = Error response from daemon: Get https://k8s.gcr.io/v2/: dial tcp 74.125.204.82:443: connect: connection timed out
Nov  7 06:20:49 k8work2 kubelet: E1107 06:20:49.866132   13241 pod_workers.go:190] Error syncing pod 4fedf7b3-207e-11eb-90a3-2c534a095a16 ("kube-proxy-pqvvb_kube-system(4fedf7b3-207e-11eb-90a3-2c534a095a16)"), skipping: failed to "StartContainer" for "kube-proxy" with ErrImagePull: "rpc error: code = Unknown desc = Error response from daemon: Get https://k8s.gcr.io/v2/: dial tcp 74.125.204.82:443: connect: connection timed out"

這段日志的意思是因?yàn)殓R像無(wú)法拉取，所以啟動(dòng)出現(xiàn)啟動(dòng)失敗問(wèn)題，除此之外還有coredns、Controller等，也出現(xiàn)此類(lèi)鏡像無(wú)法拉取問(wèn)題。

出現(xiàn)這個(gè)問(wèn)題，很容易理解，內(nèi)網(wǎng)集群，在集群安裝過(guò)程中，鏡像是通過(guò)復(fù)制過(guò)來(lái)的，但是執(zhí)行docker images|grep k8s發(fā)現(xiàn)k8s的鏡像全不在了，難道有人為刪除，要不然鏡像為什么會(huì)無(wú)緣無(wú)故消失呢？

于是又開(kāi)始查看日志，又發(fā)現(xiàn)日志中存在此類(lèi)信息，確認(rèn)不是人為刪除，而是kubelet回收掉了，具體日志如下所示：

Nov  7 05:44:51 k8work2 kubelet: I1107 05:44:51.041315   13241 image_gc_manager.go:317] attempting to delete unused images
Nov  7 05:44:51 k8work2 kubelet: I1107 05:44:51.083785   13241 image_gc_manager.go:371] [imageGCManager]: Removing image "sha256:6858809bf669cc5da7cb6af83d0fae838284d12e1be0182f92f6bd96559873e3" to free 1231725 bytes

為什么要把k8s自身運(yùn)行需要的鏡像回收掉呢？這里先不過(guò)多解釋?zhuān)唧w原因，且看下文。

找不到manifests問(wèn)題

Nov  7 06:20:47 k8work2 kubelet: E1107 06:20:47.943073   13241 file_linux.go:61] Unable to read config path "/etc/kubernetes/manifests": path does not exist, ignoring

其實(shí)看了下網(wǎng)上這個(gè)問(wèn)題，也挺多的，因?yàn)槭怯?jì)算節(jié)點(diǎn)，不包含manifests，但是日志中一直在提示這個(gè)錯(cuò)誤，這種噪音日志看著就難受，我是直接在/etc/kubernetes/創(chuàng)建了manifests文件夾，問(wèn)題直接解決。此錯(cuò)誤跟本文中的Pod驅(qū)逐應(yīng)該沒(méi)什么關(guān)系，看了看其它計(jì)算接單存在同樣問(wèn)題。

孤兒Volume問(wèn)題

Nov  7 09:32:03 k8work2 kubelet: E1107 09:32:03.431224   13241 kubelet_volumes.go:154] Orphaned pod "f6a977f4-2098-11eb-90a3-2c534a095a16" found, but volume paths are still present on disk : There were a total of 1 errors similar to this. Turn up verbosity to see them.

進(jìn)入到/var/lib/kubelet/pods/，通過(guò)id號(hào),進(jìn)入kubelet的目錄,可以發(fā)現(xiàn)里面還存在容器的數(shù)據(jù)，etc-hosts文件中還保留著pod名稱等信息。

從錯(cuò)誤信息可以推測(cè)，這臺(tái)計(jì)算節(jié)點(diǎn)存在一個(gè)孤兒Pod,并且該P(yáng)od掛載了數(shù)據(jù)卷(volume)，阻礙了Kubelet對(duì)孤兒Pod正常的回收清理。所以一直在提示上面錯(cuò)誤信息，我在確認(rèn)該P(yáng)od確認(rèn)該P(yáng)od確實(shí)已經(jīng)不在運(yùn)行，并且沒(méi)有數(shù)據(jù)丟失的風(fēng)險(xiǎn)，直接執(zhí)行了rm -rf f6a977f4-2098-11eb-90a3-2c534a095a16，刪除過(guò)后，不在刷此類(lèi)錯(cuò)誤。

驅(qū)逐問(wèn)題

Nov  7 07:21:19 k8work2 kubelet: E1107 07:21:19.021705   13241 eviction_manager.go:576] eviction manager: pod es-0_log(aa41dd4c-2085-11eb-90a3-2c534a095a16) failed to evict timeout waiting to kill pod
Nov  7 07:21:22 k8work2 kubelet: I1107 07:21:22.883681   13241 image_gc_manager.go:300] [imageGCManager]: Disk usage on image filesystem is at 86% which is over the high threshold (85%). Trying to free 21849563955 bytes down to the low threshold (80%).
Nov  7 07:21:22 k8work2 kubelet: E1107 07:21:22.890923   13241 kubelet.go:1278] Image garbage collection failed multiple times in a row: failed to garbage collect required amount of images. Wanted to free 21849563955 bytes, but freed 0 bytes

日志大概提示意思是磁盤(pán)壓力過(guò)大，已經(jīng)超過(guò)閾值，于是df -h查看了下磁盤(pán)，果然這臺(tái)機(jī)器服務(wù)產(chǎn)生了大量日志，導(dǎo)致磁盤(pán)占用過(guò)高，但是磁盤(pán)雖然占用過(guò)高，為什么要回收鏡像呢？在官網(wǎng)查詢了下，大概是這樣介紹的：

垃圾回收是kubelet的一個(gè)有用功能，它將清理未使用的鏡像和容器。kubelet將每分鐘對(duì)容器執(zhí)行一次垃圾回收，每五分鐘對(duì)鏡像執(zhí)行一次垃圾回收。

鏡像垃圾回收策略只考慮兩個(gè)因素：HighThresholdPercent和LowThresholdPercent。磁盤(pán)使用率超過(guò)上限閾值（HighThresholdPercent）將觸發(fā)垃圾回收。垃圾回收將刪除最近最少使用的鏡像，直到磁盤(pán)使用率滿足下限閾值（LowThresholdPercent）。

容器垃圾回收策略考慮三個(gè)用戶定義變量。MinAge是容器可以被執(zhí)行垃圾回收的最小生命周期。MaxPerPodContainer是每個(gè)pod內(nèi)允許存在的死亡容器的最大數(shù)量。MaxContainers是全部死亡容器的最大數(shù)量。可以分別獨(dú)立地通過(guò)將MinAge設(shè)置為0，以及將MaxPerPodContainer和MaxContainers設(shè)置為小于0來(lái)禁用這些變量。kubelet 將處理無(wú)法辨識(shí)的、已刪除的以及超出前面提到的參數(shù)所設(shè)置范圍的容器。最老的容器通常會(huì)先被移除。

對(duì)于k8s用戶來(lái)說(shuō)上述kubelet參數(shù)都是可以調(diào)整的，具體調(diào)整方式請(qǐng)參考：https://kubernetes.io/zh/docs/concepts/cluster-administration/kubelet-garbage-collection/這里不在過(guò)多贅述。

說(shuō)到這里大概已經(jīng)找到原因，之所以出現(xiàn)Pod被驅(qū)逐，原因是因?yàn)榇疟P(pán)壓力超過(guò)閾值，在k8s看來(lái)，這個(gè)計(jì)算節(jié)點(diǎn)已經(jīng)不正常，所以開(kāi)啟垃圾回收機(jī)制，按照默認(rèn)回收策略首先刪除了自身的鏡像信息，然后導(dǎo)致內(nèi)網(wǎng)鏡像拉取失敗問(wèn)題，然后開(kāi)始重新調(diào)度Pod，但是因?yàn)樵揚(yáng)od中添加了污點(diǎn)，不能被調(diào)度到其它節(jié)點(diǎn)，最后導(dǎo)致啟動(dòng)失敗。

2、問(wèn)題解決

解決過(guò)程

于是找到占用磁盤(pán)數(shù)據(jù)所在文件夾，是一個(gè)以pod PVC命名的文件，確認(rèn)里面的數(shù)據(jù)可以刪除之后，我直接把PVC文件夾以及內(nèi)容，全部都給刪掉了，再次啟動(dòng)Pod，一直處于init狀態(tài)，event事件提示無(wú)法找到PVC，仔細(xì)看了下該P(yáng)od所在編排文件內(nèi)容，發(fā)現(xiàn)該P(yáng)od是有狀態(tài)應(yīng)用，以sts進(jìn)行編排，我們知道sts以特定順序啟動(dòng)，并且擁有穩(wěn)定網(wǎng)絡(luò)身份標(biāo)識(shí)、寫(xiě)入固定的存儲(chǔ)，現(xiàn)在我把存儲(chǔ)名稱都給干掉了，所以導(dǎo)致無(wú)法啟動(dòng)，大家引以為戒。

但是之所以會(huì)出現(xiàn)上面有狀態(tài)Pod無(wú)法啟動(dòng)的問(wèn)題，究其原因是因?yàn)閺?fù)用了過(guò)去的PVC，我只要把PVC、PV刪除了，重新創(chuàng)建，一切萬(wàn)事大吉，于是我開(kāi)始使用kubectl delete pvc pvc_name -n log，有趣的一幕又發(fā)生了，PVC一直卡在Terminating無(wú)法刪除。

網(wǎng)上查了查解決方式，大概兩種：

• 直接到etcd中刪除

• 使用kubectl patch

kubectl delete pvc pvc_name -n log
kubectl patch pvc pvc_name  -p '{"metadata":{"finalizers":null}}' -n log

之所以需要強(qiáng)制執(zhí)行，因?yàn)樵鷎8s不允許執(zhí)行刪除后的回滾動(dòng)作。這大概就是k8s最終一致性原則的體現(xiàn)。

再次重新啟動(dòng)Pod，啟動(dòng)成功，已經(jīng)重新創(chuàng)建PVC和PV。

3、總結(jié)

通過(guò)本文可以看出兩點(diǎn)：

• 當(dāng)k8s集群出現(xiàn)問(wèn)題時(shí)一定要仔細(xì)查看日志，先看k8s本身事件信息，如果不能找到線索，緊接著查看內(nèi)核日志，出現(xiàn)問(wèn)題之后，正常情況下一定能夠找到問(wèn)題日志。
• 不要盲目刪除數(shù)據(jù)，一定搞明白東西的原理之后再做刪除操作，否則會(huì)帶來(lái)不必要的麻煩。

當(dāng)然要徹底解決此類(lèi)問(wèn)題，還是需要監(jiān)控巡邏系統(tǒng)，出現(xiàn)磁盤(pán)告警之后能夠立馬通知到系統(tǒng)管理員或者自動(dòng)做出進(jìn)一步數(shù)據(jù)處理，不至于服務(wù)掛掉。如有問(wèn)題，請(qǐng)關(guān)注公眾號(hào)，加我微信，一起討論！