記一次靠譜的 K8S 排錯實戰(zhàn)過程，硬核！
一 背景
收到測試環(huán)境集群告警，登陸 K8s 集群進(jìn)行排查。
二 故障定位
2.1 查看 Pod
查看 kube-system node2 節(jié)點(diǎn) calico pod 異常。
查看詳細(xì)信息，查看node2節(jié)點(diǎn)沒有存儲空間，cgroup泄露。
2.2 查看存儲
登陸 node2 查看服務(wù)器存儲信息，目前空間還很充足。
集群使用到的分布式存儲為ceph，因此查看ceph集群狀態(tài)。
三 操作
3.1 ceph修復(fù)
目前查看到 ceph 集群異常，可能導(dǎo)致 node2 節(jié)點(diǎn) cgroup 泄露異常，進(jìn)行手動修復(fù)ceph集群。
數(shù)據(jù)的不一致性（inconsistent）指對象的大小不正確、恢復(fù)結(jié)束后某副本出現(xiàn)了對象丟失的情況。數(shù)據(jù)的不一致性會導(dǎo)致清理失?。╯crub error）。
由圖可知，pg編號1.7c 存在問題，進(jìn)行修復(fù)。
- pg修復(fù)
ceph pg repair 1.7c進(jìn)行修復(fù)后，稍等一會，再次進(jìn)行查看，ceph 集群已經(jīng)修復(fù)
3.2 進(jìn)行 Pod 修復(fù)
對異常pod進(jìn)行刪除，由于有控制器，會重新拉起最新的 Pod。
查看 Pod 還是和之前一樣，分析可能由于ceph異常，導(dǎo)致node2節(jié)點(diǎn)cgroup泄露，網(wǎng)上檢索重新編譯
Google 一番后發(fā)現(xiàn)存在的可能有：
- Kubelet 宿主機(jī)的 Linux 內(nèi)核過低 - Linux version 3.10.0-862.el7.x86_64
- 可以通過禁用kmem解決
查看系統(tǒng)內(nèi)核卻是低版本
3.3 故障再次定位
3.4 對 node2 節(jié)點(diǎn)進(jìn)行維護(hù)
3.4.1 標(biāo)記 node2 為不可調(diào)度
kubectl cordon node023.4.2 驅(qū)逐 node2 節(jié)點(diǎn)上的 Pod
kubectl drain node02 —delete-local-data —ignore-daemonsets —force- --delete-local-data ?刪除本地數(shù)據(jù)，即使emptyDir也將刪除；
- --ignore-daemonsets ?忽略 DeamonSet，否則 DeamonSet 被刪除后，仍會自動重建；
- --force ?不加 force 參數(shù)只會刪除該 node 節(jié)點(diǎn)上的 ReplicationController， ReplicaSet，DaemonSet，StatefulSet or Job，加上后所有 pod 都將刪除；
目前查看基本 node2 的 pod 均已剔除完畢
此時與默認(rèn)遷移不同的是，Pod 會先重建再終止，此時的服務(wù)中斷時間=重建時間+服務(wù)啟動時間+ readiness探針檢測正常時間，必須等到1/1 Running服務(wù)才會正常。因此在單副本時遷移時，服務(wù)終端是不可避免的。
3.4.3 對 node02 進(jìn)行重啟
重啟后 node02 已經(jīng)修復(fù)完成。
對 node02 進(jìn)行恢復(fù)
- 恢復(fù) node02 可以正常調(diào)度
kubectl uncordon node02四 反思
后期可以對部署 K8s 集群內(nèi)核進(jìn)行升級。
集群內(nèi)可能 Pod 的異常，由于底層存儲或者其他原因?qū)е?，需要具體定位到問題進(jìn)行針對性修復(fù)。
原文鏈接：https://juejin.cn/post/6969571897659015205