報障：

    今日上午，值班同學發現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-mgr

    Pod在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狀態了。

    至此，問題修復！略略略略略~~~