新聞中心
記一次 Kubernetes 排錯實戰(zhàn)
作者:kaliarch 2021-11-11 16:14:04
云計算 數(shù)據(jù)的不一致性(inconsistent)指對象的大小不正確、恢復(fù)結(jié)束后某副本出現(xiàn)了對象丟失的情況。數(shù)據(jù)的不一致性會導(dǎo)致清理失敗(scrub error)。

背景
收到測試環(huán)境集群告警,登陸Kubernetes集群進(jìn)行排查。
故障定位
查看Pod
查看kube-system node2節(jié)點(diǎn)calico pod異常。
查看詳細(xì)信息,查看node2節(jié)點(diǎn)沒有存儲空間,cgroup泄露。
查看存儲
登陸node2查看服務(wù)器存儲信息,目前空間還很充足。
集群使用到的分布式存儲為Ceph,因此查看Ceph集群狀態(tài)。
操作
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)致清理失敗(scrub error)。
Ceph在存儲的過程中,由于特殊原因,可能遇到對象信息大小和物理磁盤上實際大小數(shù)據(jù)不一致的情況,這也會導(dǎo)致清理失敗。
數(shù)據(jù)的不一致性(inconsistent)指對象的大小不正確、恢復(fù)結(jié)束后某副本出現(xiàn)了對象丟失的情況。數(shù)據(jù)的不一致性會導(dǎo)致清理失敗(scrub error)。
Ceph在存儲的過程中,由于特殊原因,可能遇到對象信息大小和物理磁盤上實際大小數(shù)據(jù)不一致的情況,這也會導(dǎo)致清理失敗。
由圖可知,pg編號1.7c 存在問題,進(jìn)行修復(fù)。
pg修復(fù):
- ceph pg repair 1.7c
進(jìn)行修復(fù)后,稍等一會,再次進(jìn)行查看,Ceph集群已經(jīng)修復(fù)。
進(jìn)行Pod修復(fù)
對異常Pod進(jìn)行刪除,由于有控制器,會重新拉起最新的Pod。
查看Pod還是和之前一樣,分析可能由于Ceph異常,導(dǎo)致node2節(jié)點(diǎn)cgroup泄露,網(wǎng)上檢索重新編譯。
Google一番后發(fā)現(xiàn)與https://github.com/rootsongjc/kubernetes-handbook/issues/313這個同學(xué)的問題基本一致。存在的可能有:
- Kubelet宿主機(jī)的Linux內(nèi)核過低 - Linux version 3.10.0-862.el7.x86_64
- 可以通過禁用kmem解決
查看系統(tǒng)內(nèi)核卻是低版本。
故障再次定位
最后,因為在啟動容器的時候runc的邏輯會默認(rèn)打開容器的kmem accounting,導(dǎo)致3.10內(nèi)核可能的泄漏問題。
在此需要對no space left的服務(wù)器進(jìn)行reboot重啟,即可解決問題,出現(xiàn)問題的可能為段時間內(nèi)刪除大量的Pod所致。
初步思路,可以在今后的集群管理匯總,對服務(wù)器進(jìn)行維修,通過刪除節(jié)點(diǎn),并對節(jié)點(diǎn)進(jìn)行reboot處理。
對node2節(jié)點(diǎn)進(jìn)行維護(hù)
標(biāo)記node2為不可調(diào)度
- kubectl cordon node02
驅(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ù)終端是不可避免的。
對node02進(jìn)行重啟
重啟后node02已經(jīng)修復(fù)完成。
對node02進(jìn)行恢復(fù):
恢復(fù)node02可以正常調(diào)度。
- kubectl uncordon node02
反思
后期可以對部署Kubernetes集群內(nèi)核進(jìn)行升級。
集群內(nèi)可能Pod的異常,由于底層存儲或者其他原因?qū)е拢枰唧w定位到問題進(jìn)行針對性修復(fù)。
原文鏈接:https://juejin.cn/post/6969571897659015205
當(dāng)前題目:記一次Kubernetes排錯實戰(zhàn)
當(dāng)前URL:http://fisionsoft.com.cn/article/dhjggec.html


咨詢
建站咨詢
