一 背景

收到測試環境集群告警，登陸 K8s 集群進行排查。

二 故障定位

2.1 查看 Pod

查看 kube-system node2 節點 calico pod 異常。

查看詳細信息，查看node2節點沒有存儲空間，cgroup泄露。

2.2 查看存儲

登陸 node2 查看服務器存儲信息，目前空間還很充足。

集群使用到的分布式存儲為ceph，因此查看ceph集群狀態。

三 操作

3.1 ceph修復

目前查看到 ceph 集群異常，可能導致 node2 節點 cgroup 泄露異常，進行手動修復ceph集群。

數據的不一致性（inconsistent）指對象的大小不正確、恢復結束后某副本出現了對象丟失的情況。數據的不一致性會導致清理失敗（scrub error）。

由圖可知，pg編號1.7c 存在問題，進行修復。

• pg修復

ceph pg repair 1.7c

進行修復后，稍等一會，再次進行查看，ceph 集群已經修復

3.2 進行 Pod 修復

對異常pod進行刪除，由于有控制器，會重新拉起最新的 Pod。

查看 Pod 還是和之前一樣，分析可能由于ceph異常，導致node2節點cgroup泄露，網上檢索重新編譯

Google 一番后發現存在的可能有：

• Kubelet 宿主機的 Linux 內核過低 - Linux version 3.10.0-862.el7.x86_64
• 可以通過禁用kmem解決

查看系統內核卻是低版本

3.3 故障再次定位

3.4 對 node2 節點進行維護

3.4.1 標記 node2 為不可調度

kubectl cordon node02

3.4.2 驅逐 node2 節點上的 Pod

kubectl drain node02 —delete-local-data —ignore-daemonsets —force

• --delete-local-data ?刪除本地數據，即使emptyDir也將刪除；
• --ignore-daemonsets ?忽略 DeamonSet，否則 DeamonSet 被刪除后，仍會自動重建；
• --force ?不加 force 參數只會刪除該 node 節點上的 ReplicationController， ReplicaSet，DaemonSet，StatefulSet or Job，加上后所有 pod 都將刪除；

目前查看基本 node2 的 pod 均已剔除完畢

此時與默認遷移不同的是，Pod 會先重建再終止，此時的服務中斷時間=重建時間+服務啟動時間+ readiness探針檢測正常時間，必須等到1/1 Running服務才會正常。因此在單副本時遷移時，服務終端是不可避免的。

3.4.3 對 node02 進行重啟

重啟后 node02 已經修復完成。

對 node02 進行恢復

• 恢復 node02 可以正常調度

kubectl uncordon node02

四 反思

后期可以對部署 K8s 集群內核進行升級。

集群內可能 Pod 的異常，由于底層存儲或者其他原因導致，需要具體定位到問題進行針對性修復。

原文鏈接：https://juejin.cn/post/6969571897659015205