報障：

    今日上午，值班同學發(fā)現(xiàn)airflow無法使用。查看時其部署的Node節(jié)點NotReady了。

分析：

    馬上查看K8S集群節(jié)點的狀態(tài)，發(fā)現(xiàn)這個節(jié)點已經(jīng)是NotReady狀態(tài)了。第一反應就是ping下節(jié)點看是否宕機了？ping正常，于是登錄到該節(jié)點查看kubelet狀態(tài)。發(fā)現(xiàn)kubelet報runtime不可用，查看containerd的狀態(tài)，一直在不斷的重啟，而且啟動不成功。為了盡快恢復業(yè)務，決定先將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í)行的時間很長，超過幾分鐘。通過du命令統(tǒng)計該目錄的大小也很久，我判斷是這個目錄下的小文件太多了。于是我ctrl+c掉rm和du命令。直接將該目錄改個名字后重新創(chuàng)建一個目錄。然后重新拉起containerd和kubelet進程后節(jié)點Ready了。pod也正常了。

    然后接著再來刪除之前的數(shù)據(jù)目錄，執(zhí)行刪除后經(jīng)過30min-60min才刪除完成。通過rm -rfv 參數(shù)可以看到打印出來刪除的文件信息，是pod中存在大量的python，go的.cache和.git的小文件。查看containerd的報錯：

    猜測是因為小文件數(shù)量過多，導致節(jié)點containerd停止后重啟失敗，不斷重啟導致節(jié)點NotReady的。

    恢復一段時間后，airflow跑任務時，拉起個別的pod沒有問題，但是當同時拉起幾十個pod跑任務的時候有很多的pod無法啟動。報如下錯誤：

    該節(jié)點的pod網(wǎng)段IP地址已經(jīng)用完，無法分配IP了。集群設計的時候給每個Node的子網(wǎng)掩碼是25。可以部署125個pod。但是現(xiàn)在節(jié)點上的pod才十幾個。猜測是之前節(jié)點故障的時候，直接刪除了元數(shù)據(jù)后拉起containerd導致原來的pod在系統(tǒng)上的網(wǎng)絡信息沒有被刪除。導致IP被占用了。我們的集群采用了flannel組件，并且開啟了--kube-subnet-mgr參數(shù)。所以IP分配信息不會記錄到etcd，而是直接記錄到Node節(jié)點上的。

# 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上的網(wǎng)絡信息主要有兩點：

        1）容器在Node側(cè)的vethxxx接口；

        2）容器在Node側(cè)的IP地址；

    所以，只要我們刪除舊Pod的容器殘留在Node上的以上網(wǎng)絡信息應該就可以恢復了。

解決：

    1）找到容器在Node側(cè)的vethxxx接口并刪除

        我們知道，veth對一側(cè)在容器里面，一側(cè)在Node側(cè)。通過命令ip addr可以查看到。這里我們需要找到不存在容器遺留在Node的vethxxx接口。

    如上圖所示，每個vethxxx接口都有一個Node側(cè)的index ID（第一列數(shù)字），而vethxxx@if后面的數(shù)字3是該veth接口對應在容器側(cè)的eth0網(wǎng)卡在容器內(nèi)的index ID。容器和Node的veth接口對應關系如下：

    通過這樣的方式找到其映射關系的。有了這個信息之后，我就可以去到該Node上所有的容器中拿到eth0對應的在Node的index ID，從而在Node側(cè)過濾找出已經(jīng)無效的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)有的容器不多，十幾個所以通過這種方式逐一登錄拿到對應的index ID。如果容器較多，需要結合expect工具做自動識別處理。這里沒有做。拿到所有有效的veth的index ID后報錯到veth_yes文件中，把Node側(cè)所有的veth信息報錯到veth_all文件中：

ip add | grep veth > veth_all

    然后根據(jù)有效的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側(cè)只剩下當前running容器的vethxxx接口了。 

    2）找到容器在Node側(cè)記錄的IP地址并刪除

    veth接口處理完，那么IP地址沒有釋放該如何處理呢？

   查閱資料后得知，IPAM插件已分配的IP地址保存在/var/lib/cni/networks/cbr0文件中。如下：

    于是，將其中未真正在使用的IP地址文件刪除即可。刪除后如下：

    此時，所有無法分配IP的Pod都可以正常獲取IP從creating狀態(tài)變?yōu)镽unning狀態(tài)了。

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