記一則K8S Node NotReady故障
報障：
今日上午，值班同學發現airflow無法使用。查看時其部署的Node節點NotReady了。
分析：
馬上查看K8S集群節點的狀態，發現這個節點已經是NotReady狀態了。第一反應就是ping下節點看是否宕機了？ping正常，于是登錄到該節點查看kubelet狀態。發現kubelet報runtime不可用，查看containerd的狀態，一直在不斷的重啟，而且啟動不成功。為了盡快恢復業務，決定先將containerd的數據目錄清空后重新拉起。于是刪除containerd數據目錄下的文件夾：
# 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/*發現執行的時間很長，超過幾分鐘。通過du命令統計該目錄的大小也很久，我判斷是這個目錄下的小文件太多了。于是我ctrl+c掉rm和du命令。直接將該目錄改個名字后重新創建一個目錄。然后重新拉起containerd和kubelet進程后節點Ready了。pod也正常了。
然后接著再來刪除之前的數據目錄，執行刪除后經過30min-60min才刪除完成。通過rm -rfv 參數可以看到打印出來刪除的文件信息，是pod中存在大量的python，go的.cache和.git的小文件。查看containerd的報錯：
猜測是因為小文件數量過多，導致節點containerd停止后重啟失敗，不斷重啟導致節點NotReady的。
恢復一段時間后，airflow跑任務時，拉起個別的pod沒有問題，但是當同時拉起幾十個pod跑任務的時候有很多的pod無法啟動。報如下錯誤：
該節點的pod網段IP地址已經用完，無法分配IP了。集群設計的時候給每個Node的子網掩碼是25。可以部署125個pod。但是現在節點上的pod才十幾個。猜測是之前節點故障的時候，直接刪除了元數據后拉起containerd導致原來的pod在系統上的網絡信息沒有被刪除。導致IP被占用了。我們的集群采用了flannel組件，并且開啟了--kube-subnet-mgr參數。所以IP分配信息不會記錄到etcd，而是直接記錄到Node節點上的。
# 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上的網絡信息主要有兩點：
1）容器在Node側的vethxxx接口；
2）容器在Node側的IP地址；
所以，只要我們刪除舊Pod的容器殘留在Node上的以上網絡信息應該就可以恢復了。
解決：
1）找到容器在Node側的vethxxx接口并刪除
我們知道，veth對一側在容器里面，一側在Node側。通過命令ip addr可以查看到。這里我們需要找到不存在容器遺留在Node的vethxxx接口。
如上圖所示，每個vethxxx接口都有一個Node側的index ID（第一列數字），而vethxxx@if后面的數字3是該veth接口對應在容器側的eth0網卡在容器內的index ID。容器和Node的veth接口對應關系如下：
通過這樣的方式找到其映射關系的。有了這個信息之后，我就可以去到該Node上所有的容器中拿到eth0對應的在Node的index ID，從而在Node側過濾找出已經無效的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上現有的容器不多，十幾個所以通過這種方式逐一登錄拿到對應的index ID。如果容器較多，需要結合expect工具做自動識別處理。這里沒有做。拿到所有有效的veth的index ID后報錯到veth_yes文件中，把Node側所有的veth信息報錯到veth_all文件中：
ip add | grep veth > veth_all然后根據有效的index ID把其信息從veth_all中刪除，得到所有要刪除的vethxxx接口信息并刪除：
// 刪除有效的veth信息
#!/bin/bash
for i in $(cat veth_yes)
do
grep $i veth_all; sed -i "/$i/d" veth_all
done
// 刪除所有無效的vethxxx接口信息
#!/bin/bash
for i in $(cat veth_all | awk '{print $2}' | awk -F@ '{print $1}')
do
ip link delete $i
done刪除后，Node側只剩下當前running容器的vethxxx接口了。
2）找到容器在Node側記錄的IP地址并刪除
veth接口處理完，那么IP地址沒有釋放該如何處理呢？
查閱資料后得知，IPAM插件已分配的IP地址保存在/var/lib/cni/networks/cbr0文件中。如下：
于是，將其中未真正在使用的IP地址文件刪除即可。刪除后如下：
此時，所有無法分配IP的Pod都可以正常獲取IP從creating狀態變為Running狀態了。
至此，問題修復！略略略略略~~~
