記一則K8S Node NotReady故障
報(bào)障：
今日上午，值班同學(xué)發(fā)現(xiàn)airflow無(wú)法使用。查看時(shí)其部署的Node節(jié)點(diǎn)NotReady了。
分析：
馬上查看K8S集群節(jié)點(diǎn)的狀態(tài)，發(fā)現(xiàn)這個(gè)節(jié)點(diǎn)已經(jīng)是NotReady狀態(tài)了。第一反應(yīng)就是ping下節(jié)點(diǎn)看是否宕機(jī)了？ping正常，于是登錄到該節(jié)點(diǎn)查看kubelet狀態(tài)。發(fā)現(xiàn)kubelet報(bào)runtime不可用，查看containerd的狀態(tài)，一直在不斷的重啟，而且啟動(dòng)不成功。為了盡快恢復(fù)業(yè)務(wù)，決定先將containerd的數(shù)據(jù)目錄清空后重新拉起。于是刪除containerd數(shù)據(jù)目錄下的文件夾：
# ls -lrth /xpu-k8s-data/containerd/
total 0
drwx------ 2 root root 6 Apr 28 10:54 io.containerd.snapshotter.v1.btrfs
drwx------ 3 root root 31 Apr 28 10:54 io.containerd.snapshotter.v1.aufs
drwx------ 3 root root 31 Apr 28 10:54 io.containerd.snapshotter.v1.native
drwx--x--x 2 root root 29 Apr 28 10:54 io.containerd.metadata.v1.bolt
drwx--x--x 2 root root 6 Apr 28 10:54 io.containerd.runtime.v1.linux
drwxr-xr-x 4 root root 45 Apr 28 10:54 io.containerd.content.v1.content
drwx------ 3 root root 54 Apr 28 10:54 io.containerd.snapshotter.v1.overlayfs
drwx--x--x 3 root root 28 Apr 28 10:54 io.containerd.runtime.v2.task
drwxr-xr-x 4 root root 53 Apr 28 10:55 io.containerd.grpc.v1.cri
drwx------ 2 root root 6 Apr 28 14:49 tmpmounts
# rm -rf /xpu-k8s-data/containerd/*發(fā)現(xiàn)執(zhí)行的時(shí)間很長(zhǎng)，超過(guò)幾分鐘。通過(guò)du命令統(tǒng)計(jì)該目錄的大小也很久，我判斷是這個(gè)目錄下的小文件太多了。于是我ctrl+c掉rm和du命令。直接將該目錄改個(gè)名字后重新創(chuàng)建一個(gè)目錄。然后重新拉起containerd和kubelet進(jìn)程后節(jié)點(diǎn)Ready了。pod也正常了。
然后接著再來(lái)刪除之前的數(shù)據(jù)目錄，執(zhí)行刪除后經(jīng)過(guò)30min-60min才刪除完成。通過(guò)rm -rfv 參數(shù)可以看到打印出來(lái)刪除的文件信息，是pod中存在大量的python，go的.cache和.git的小文件。查看containerd的報(bào)錯(cuò)：
猜測(cè)是因?yàn)樾∥募?shù)量過(guò)多，導(dǎo)致節(jié)點(diǎn)containerd停止后重啟失敗，不斷重啟導(dǎo)致節(jié)點(diǎn)NotReady的。
恢復(fù)一段時(shí)間后，airflow跑任務(wù)時(shí)，拉起個(gè)別的pod沒(méi)有問(wèn)題，但是當(dāng)同時(shí)拉起幾十個(gè)pod跑任務(wù)的時(shí)候有很多的pod無(wú)法啟動(dòng)。報(bào)如下錯(cuò)誤：
該節(jié)點(diǎn)的pod網(wǎng)段IP地址已經(jīng)用完，無(wú)法分配IP了。集群設(shè)計(jì)的時(shí)候給每個(gè)Node的子網(wǎng)掩碼是25。可以部署125個(gè)pod。但是現(xiàn)在節(jié)點(diǎn)上的pod才十幾個(gè)。猜測(cè)是之前節(jié)點(diǎn)故障的時(shí)候，直接刪除了元數(shù)據(jù)后拉起containerd導(dǎo)致原來(lái)的pod在系統(tǒng)上的網(wǎng)絡(luò)信息沒(méi)有被刪除。導(dǎo)致IP被占用了。我們的集群采用了flannel組件，并且開(kāi)啟了--kube-subnet-mgr參數(shù)。所以IP分配信息不會(huì)記錄到etcd，而是直接記錄到Node節(jié)點(diǎn)上的。
# ps -ef | grep flannel
root 6450 45116 0 14:59 pts/4 00:00:00 grep --color=auto flannel
root 53065 52700 0 13:02 ? 00:00:43 /opt/bin/flanneld --ip-masq --kube-subnet-mgrPod在Node上的網(wǎng)絡(luò)信息主要有兩點(diǎn)：
1）容器在Node側(cè)的vethxxx接口；
2）容器在Node側(cè)的IP地址；
所以，只要我們刪除舊Pod的容器殘留在Node上的以上網(wǎng)絡(luò)信息應(yīng)該就可以恢復(fù)了。
解決：
1）找到容器在Node側(cè)的vethxxx接口并刪除
我們知道，veth對(duì)一側(cè)在容器里面，一側(cè)在Node側(cè)。通過(guò)命令ip addr可以查看到。這里我們需要找到不存在容器遺留在Node的vethxxx接口。
如上圖所示，每個(gè)vethxxx接口都有一個(gè)Node側(cè)的index ID（第一列數(shù)字），而vethxxx@if后面的數(shù)字3是該veth接口對(duì)應(yīng)在容器側(cè)的eth0網(wǎng)卡在容器內(nèi)的index ID。容器和Node的veth接口對(duì)應(yīng)關(guān)系如下：
通過(guò)這樣的方式找到其映射關(guān)系的。有了這個(gè)信息之后，我就可以去到該Node上所有的容器中拿到eth0對(duì)應(yīng)的在Node的index ID，從而在Node側(cè)過(guò)濾找出已經(jīng)無(wú)效的vethxxx接口并刪掉。操作如下：
for pid in $(for i in $(crictl ps | awk '{print $1}'); do crictl inspect $i | grep -i pid|grep , | awk '{print $2}' | sed 's/,//';done);do nsenter -t $pid --net ;done由于Node上現(xiàn)有的容器不多，十幾個(gè)所以通過(guò)這種方式逐一登錄拿到對(duì)應(yīng)的index ID。如果容器較多，需要結(jié)合expect工具做自動(dòng)識(shí)別處理。這里沒(méi)有做。拿到所有有效的veth的index ID后報(bào)錯(cuò)到veth_yes文件中，把Node側(cè)所有的veth信息報(bào)錯(cuò)到veth_all文件中：
ip add | grep veth > veth_all然后根據(jù)有效的index ID把其信息從veth_all中刪除，得到所有要?jiǎng)h除的vethxxx接口信息并刪除：
// 刪除有效的veth信息
#!/bin/bash
for i in $(cat veth_yes)
do
grep $i veth_all; sed -i "/$i/d" veth_all
done
// 刪除所有無(wú)效的vethxxx接口信息
#!/bin/bash
for i in $(cat veth_all | awk '{print $2}' | awk -F@ '{print $1}')
do
ip link delete $i
done刪除后，Node側(cè)只剩下當(dāng)前running容器的vethxxx接口了。
2）找到容器在Node側(cè)記錄的IP地址并刪除
veth接口處理完，那么IP地址沒(méi)有釋放該如何處理呢？
查閱資料后得知，IPAM插件已分配的IP地址保存在/var/lib/cni/networks/cbr0文件中。如下：
于是，將其中未真正在使用的IP地址文件刪除即可。刪除后如下：
此時(shí)，所有無(wú)法分配IP的Pod都可以正常獲取IP從creating狀態(tài)變?yōu)镽unning狀態(tài)了。
至此，問(wèn)題修復(fù)！略略略略略~~~
