這篇文章給大家介紹k8s故障檢測(cè)與自愈的示例分析，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比哈密網(wǎng)站開(kāi)發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式哈密網(wǎng)站制作公司更省心,省錢(qián),快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋哈密地區(qū)。費(fèi)用合理售后完善，10年實(shí)體公司更值得信賴。

組件故障

組件故障可以認(rèn)為是節(jié)點(diǎn)故障的子類，只是故障來(lái)源是K8S基礎(chǔ)組件的一部分。

DNS故障：6個(gè)DNS Pod中的2個(gè)出現(xiàn)無(wú)法解析外部DNS名稱的情況。后果是大量線上業(yè)務(wù)因域名解析。

CNI故障：少數(shù)幾個(gè)節(jié)點(diǎn)的容器網(wǎng)絡(luò)和外部斷開(kāi)，節(jié)點(diǎn)訪問(wèn)自身的Pod IP沒(méi)有問(wèn)題，但是其它節(jié)點(diǎn)無(wú)法訪問(wèn)故障節(jié)點(diǎn)的Pod  IP。這種情況下，Pod本機(jī)的健康檢查無(wú)效，導(dǎo)致故障實(shí)例持續(xù)存在，一定比例的業(yè)務(wù)請(qǐng)求失敗。

kubenurse會(huì)對(duì)ingress、dns、apiserver、kube-proxy進(jìn)行網(wǎng)絡(luò)探測(cè)。

使用KubeNurse進(jìn)行集群網(wǎng)絡(luò)監(jiān)控

節(jié)點(diǎn)故障

• 硬件錯(cuò)誤: CPU/Memory/磁盤(pán)故障

• kernel問(wèn)題: kernel deadlock/corrupted file systems

• 容器運(yùn)行時(shí)錯(cuò)誤: Docker假死

• 基礎(chǔ)設(shè)施服務(wù)故障: NTP故障

node-problem-detector

• 根源:  在kubernetes集群上，通常我們只是管制集群本身以及容器的穩(wěn)定運(yùn)行。但是這些穩(wěn)定性都是強(qiáng)依賴節(jié)點(diǎn)node的穩(wěn)定的?？墒莕ode的管理，在kubernetes是比較弱的，因?yàn)榭赡軐?duì)于kubernetes的初始設(shè)計(jì)來(lái)說(shuō)，這些應(yīng)該是IaaS的事。但是隨著kubernetes的發(fā)展，它越來(lái)變成了一個(gè)操作系統(tǒng)，它管理的內(nèi)容將越來(lái)越多，所以對(duì)于node的管理也將納入kuberntes里管理。所以延伸出了node  problem detector這個(gè)項(xiàng)目。

• Kubernetes支持兩種上報(bào)機(jī)制：

1、NodeCondition(節(jié)點(diǎn)狀況): 這是指永久性的錯(cuò)誤，它將造成pod無(wú)法在這個(gè)節(jié)點(diǎn)運(yùn)行。這個(gè)節(jié)點(diǎn)狀況只有在節(jié)點(diǎn)重啟后才會(huì)被重置

2、Event(事件):  影響節(jié)點(diǎn)的臨時(shí)性問(wèn)題，但是它是對(duì)于系統(tǒng)診斷是有意義的。NPD就是利用kubernetes的上報(bào)機(jī)制，通過(guò)檢測(cè)系統(tǒng)的日志(例如centos中journal)，把錯(cuò)誤的信息上報(bào)到kuberntes的node上。

圖片故障節(jié)點(diǎn)上的事件，會(huì)記錄在宿主機(jī)的某些日志中。這些日志(例如內(nèi)核日志)中噪音信息太多，NPD會(huì)提取其中有價(jià)值的信息，可以將這些信息報(bào)送給Prometheus，也會(huì)生成離線事件。這些信息可以推送到企業(yè)微信，人工處理。也可以對(duì)應(yīng)到自愈系統(tǒng)的方法庫(kù)，自動(dòng)恢復(fù)。在裸金屬K8S集群中，由于缺乏基礎(chǔ)設(shè)施的支撐，自動(dòng)擴(kuò)充節(jié)點(diǎn)可能無(wú)法實(shí)現(xiàn)，只能通過(guò)更加精細(xì)的自動(dòng)化運(yùn)維，治愈節(jié)點(diǎn)的異常狀態(tài)。

以CNI故障為例，可能的治愈流程如下：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 查詢運(yùn)維方法庫(kù)，如果找到匹配項(xiàng)，執(zhí)行對(duì)應(yīng)的運(yùn)維動(dòng)作

3. 如果上述步驟無(wú)效，嘗試刪除節(jié)點(diǎn)上負(fù)責(zé)CNI的Pod，以重置節(jié)點(diǎn)的路由、Iptables配置

4. 如果上述步驟無(wú)效，嘗試重啟容器運(yùn)行時(shí)

5. 告警，要求運(yùn)維人員介入

部署NPD實(shí)踐你需要有一個(gè)k8s集群，必須有1個(gè)以上的worker節(jié)點(diǎn)。大家可以參考https://github.com/kubernetes/node-problem-detector。

主要參數(shù)： --prometheus-address: 默認(rèn)綁定地址127.0.0.1，如果需要推送給promethues，需要修改。 --config.system-log-monitor: 節(jié)點(diǎn)問(wèn)題檢測(cè)器將為每個(gè)配置啟動(dòng)一個(gè)單獨(dú)的日志監(jiān)視器.案例: config/kernel-monitor.json。 --config.custom-plugin-monito: 節(jié)點(diǎn)問(wèn)題檢測(cè)器將為每個(gè)配置啟動(dòng)一個(gè)單獨(dú)的自定義插件監(jiān)視器。案例: config/custom-plugin-monitor.json

主要參數(shù)：

--prometheus-address: 默認(rèn)綁定地址127.0.0.1，如果需要推送給promethues，需要修改。

--config.system-log-monitor: 節(jié)點(diǎn)問(wèn)題檢測(cè)器將為每個(gè)配置啟動(dòng)一個(gè)單獨(dú)的日志監(jiān)視器.案例:  config/kernel-monitor.json。

--config.custom-plugin-monito: 節(jié)點(diǎn)問(wèn)題檢測(cè)器將為每個(gè)配置啟動(dòng)一個(gè)單獨(dú)的自定義插件監(jiān)視器。案例:  config/custom-plugin-monitor.json

將代碼克隆到本地，按照自己的需求更改deployment文件中的DaemonSet，執(zhí)行以下內(nèi)容：

創(chuàng)建ConfigMap： kubectl create -f node-problem-detector-config.yaml 創(chuàng)建DaemonSet: kubectl create -f node-problem-detector.yaml

如何驗(yàn)證NPD捕獲信息這部分，可以在測(cè)試集群的node幾點(diǎn)上做。

sudo sh -c "echo 'kernel: BUG: unable to handle kernel NULL pointer dereference at TESTING' >> /dev/kmsg" 可以在kubectl describe nodes x.x.x.x 中看到KernelOops事件的告警。 sudo sh -c "echo 'kernel: INFO: task docker:20744 blocked for more than 120 seconds.' >> /dev/kmsg" 可以在kubectl describe nodes x.x.x.x 中看到DockerHung事件的告警。

如果事件告警接到了promethues，可以配置策略，發(fā)送到微信。

關(guān)于k8s故障檢測(cè)與自愈的示例分析就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。