前言? ? ? ? ? ? ? ?

按照筆者的教程，大家應(yīng)該都能夠比較順暢的完成k8s集群的部署，不過由于環(huán)境、配置以及對(duì)Linux、k8s的不了解會(huì)導(dǎo)致很多問題、異常和故障，這里筆者分享一些處理技巧和思路，以及部分常見的問題，以供大家參考和學(xué)習(xí)。

總之，出現(xiàn)問題不要慌，先根據(jù)異常、故障癥狀初步推敲問題的所在，然后結(jié)合相關(guān)命令、工具、日志推敲出具體問題。其中，具體的日志內(nèi)容是關(guān)鍵，請(qǐng)務(wù)必獲得相關(guān)異常的詳細(xì)日志進(jìn)行診斷，而不是被表象所迷惑，或者根據(jù)表象問題（比如“XXXX”pod崩潰了）去猜、搜索或者請(qǐng)教他人。總體上，思路如下圖所示：

如果問題實(shí)在無(wú)法解決或者無(wú)法確定是哪里的配置以及操作不當(dāng)引起的，可以試著重置節(jié)點(diǎn)以及重置集群。

如果出現(xiàn)問題，我們應(yīng)該怎么去分析和解決問題呢？下面，筆者將分享一些思路和經(jīng)驗(yàn)：

目錄

健康狀態(tài)檢查——初診

• 組件、插件健康狀態(tài)檢查

• Kubernetes 組件異常分析

• 節(jié)點(diǎn)健康狀態(tài)檢查

• Pod健康狀態(tài)檢查

健康狀態(tài)檢查——初診

首先，我們需要根據(jù)表象進(jìn)行初步診斷，以便沿著線索按圖索驥。

組件、插件健康狀態(tài)檢查

使用命令：

kubectl get componentstatus

或

kubectl get cs

健康情況下如下圖所示：

Kubernetes組件（插件）部分默認(rèn)基于systemd運(yùn)行，比如kubelet、docker等，我們需要使用以下命令確保其處于活動(dòng)（active）狀態(tài)：

systemctl status kubelet docker

而大部分的Kubernetes的組件則運(yùn)行在命名空間為“kube-system”的靜態(tài)Pod 之中（參見“kubeadm init”一節(jié)），我們可以使用以下命令來(lái)查看這些Pod 的狀態(tài)：

kubectl get pods -o wide -n kube-system

Kubernetes 組件異常分析

k8s組件主要分為Master組件和節(jié)點(diǎn)組件，Master組件對(duì)集群做出全局性決策（比如調(diào)度）， 以及檢測(cè)和響應(yīng)集群事件。如果Master組件出現(xiàn)問題，可能會(huì)導(dǎo)致集群不可訪問，Kubernetes API 訪問出錯(cuò)，各種控制器無(wú)法工作等等。而節(jié)點(diǎn)組件在每個(gè)節(jié)點(diǎn)上運(yùn)行，維護(hù)運(yùn)行的Pod并提供 Kubernetes運(yùn)行時(shí)環(huán)境。如果節(jié)點(diǎn)組件出現(xiàn)問題，可能會(huì)導(dǎo)致該節(jié)點(diǎn)異常并且該節(jié)點(diǎn)Pod無(wú)法正常運(yùn)行和結(jié)束。

因此，根據(jù)不同的組件，可能會(huì)出現(xiàn)不同的異常。

kube-apiserver對(duì)外暴露了Kubernetes API，如果kube-apiserver出現(xiàn)異常可能會(huì)導(dǎo)致：

• 集群無(wú)法訪問，無(wú)法注冊(cè)新的節(jié)點(diǎn)

• 資源（Deployment、Service等）無(wú)法創(chuàng)建、更新和刪除

• 現(xiàn)有的不依賴Kubernetes API的pods和services可以繼續(xù)正常工作

etcd用于Kubernetes的后端存儲(chǔ)，所有的集群數(shù)據(jù)都存在這里。保持穩(wěn)定的etcd集群對(duì)于Kubernetes集群的穩(wěn)定性至關(guān)重要。因此，我們需要在專用計(jì)算機(jī)或隔離環(huán)境上運(yùn)行etcd集群以確保資源需求。當(dāng)etcd出現(xiàn)異常時(shí)可能會(huì)導(dǎo)致：

• kube-apiserver無(wú)法讀寫集群狀態(tài)，apiserver無(wú)法啟動(dòng)

• Kubernetes API訪問出錯(cuò)

• kubectl操作異常

• kubelet無(wú)法訪問apiserver，僅能繼續(xù)運(yùn)行已有的Pod

kube-controller-manager和kube-scheduler分別用于控制器管理和Pod 的調(diào)度，如果他們出現(xiàn)問題，則可能導(dǎo)致：

• 相關(guān)控制器無(wú)法工作

• 資源（Deployment、Service等）無(wú)法正常工作

• 無(wú)法注冊(cè)新的節(jié)點(diǎn)

• Pod無(wú)法調(diào)度，一直處于Pending狀態(tài)

kubelet是主要的節(jié)點(diǎn)代理，如果節(jié)點(diǎn)宕機(jī)（VM關(guān)機(jī)）或者kubelet出現(xiàn)異常（比如無(wú)法啟動(dòng)），那么可能會(huì)導(dǎo)致：

• 該節(jié)點(diǎn)上的Pod無(wú)法正常運(yùn)行，如果節(jié)點(diǎn)關(guān)機(jī)，則當(dāng)前節(jié)點(diǎn)上所有Pod都將停止運(yùn)行

• 已運(yùn)行的Pod無(wú)法伸縮，也無(wú)法正常終止

• 無(wú)法啟動(dòng)新的Pod

• 節(jié)點(diǎn)會(huì)標(biāo)識(shí)為不健康狀態(tài)

• 副本控制器會(huì)在其它的節(jié)點(diǎn)上啟動(dòng)新的Pod

• Kubelet有可能會(huì)刪掉當(dāng)前運(yùn)行的Pod

CoreDNS（在1.11以及以上版本的Kubernetes中，CoreDNS是默認(rèn)的DNS服務(wù)器）是k8s集群默認(rèn)的DNS服務(wù)器，如果其出現(xiàn)問題則可能導(dǎo)致：

• 無(wú)法注冊(cè)新的節(jié)點(diǎn)

• 集群網(wǎng)絡(luò)出現(xiàn)問題

• Pod無(wú)法解析域名

kube-proxy是Kubernetes在每個(gè)節(jié)點(diǎn)上運(yùn)行網(wǎng)絡(luò)代理。如果它出現(xiàn)了異常，則可能導(dǎo)致：

• 該節(jié)點(diǎn)Pod通信異常

節(jié)點(diǎn)健康狀態(tài)檢查

我們可以使用以下命令來(lái)檢查節(jié)點(diǎn)狀態(tài)：

kubectl get nodes

其中，“Ready”表示節(jié)點(diǎn)已就緒，為正常狀態(tài)，反之則該節(jié)點(diǎn)出現(xiàn)異常。節(jié)點(diǎn)出現(xiàn)問題，則Pod無(wú)法無(wú)法調(diào)度到該節(jié)點(diǎn)。

Pod健康狀態(tài)檢查

如果是集群應(yīng)用出現(xiàn)異常，我們需要檢查相關(guān)Pod是否運(yùn)行正常，可以使用以下命令：

kubectl get pods -o wide

如果存在命名空間，需要使用-n參數(shù)指定命名空間。如上圖所示，Pod為“Running”狀態(tài)才是正常。

如果Pod運(yùn)行正常，但是又無(wú)法訪問（集群內(nèi)部、外部），這時(shí)，我們需要檢查Service是否正常，可使用以下命令：

kubectl get svc -o wide

往期內(nèi)容

Docker+ Kubernetes已成為云計(jì)算的主流（二十六）

容器化之后如何節(jié)省云端成本？（二十七）

了解Kubernetes主體架構(gòu)（二十八）

使用Minikube部署本地Kubernetes集群（二十九）

使用kubectl管理k8s集群（三十）

使用Kubeadm創(chuàng)建k8s集群之部署規(guī)劃（三十一）

使用Kubeadm創(chuàng)建k8s集群之節(jié)點(diǎn)部署（三十二）

總結(jié)

以上是生活随笔為你收集整理的集群故障处理之处理思路以及健康状态检查（三十三）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。