集群故障处理之处理思路以及健康状态检查（三十三）
前言? ? ? ? ? ? ? ?
按照筆者的教程，大家應該都能夠比較順暢的完成k8s集群的部署，不過由于環境、配置以及對Linux、k8s的不了解會導致很多問題、異常和故障，這里筆者分享一些處理技巧和思路，以及部分常見的問題，以供大家參考和學習。
總之，出現問題不要慌，先根據異常、故障癥狀初步推敲問題的所在，然后結合相關命令、工具、日志推敲出具體問題。其中，具體的日志內容是關鍵，請務必獲得相關異常的詳細日志進行診斷，而不是被表象所迷惑，或者根據表象問題（比如“XXXX”pod崩潰了）去猜、搜索或者請教他人。總體上，思路如下圖所示：
如果問題實在無法解決或者無法確定是哪里的配置以及操作不當引起的，可以試著重置節點以及重置集群。
如果出現問題，我們應該怎么去分析和解決問題呢？下面，筆者將分享一些思路和經驗：
目錄
健康狀態檢查——初診
組件、插件健康狀態檢查
Kubernetes 組件異常分析
節點健康狀態檢查
Pod健康狀態檢查
健康狀態檢查——初診
首先，我們需要根據表象進行初步診斷，以便沿著線索按圖索驥。
組件、插件健康狀態檢查
使用命令：
kubectl get componentstatus
或
kubectl get cs
健康情況下如下圖所示：
Kubernetes組件（插件）部分默認基于systemd運行，比如kubelet、docker等，我們需要使用以下命令確保其處于活動（active）狀態：
systemctl status kubelet docker
而大部分的Kubernetes的組件則運行在命名空間為“kube-system”的靜態Pod 之中（參見“kubeadm init”一節），我們可以使用以下命令來查看這些Pod 的狀態：
kubectl get pods -o wide -n kube-system
Kubernetes 組件異常分析
k8s組件主要分為Master組件和節點組件，Master組件對集群做出全局性決策（比如調度）， 以及檢測和響應集群事件。如果Master組件出現問題，可能會導致集群不可訪問，Kubernetes API 訪問出錯，各種控制器無法工作等等。而節點組件在每個節點上運行，維護運行的Pod并提供 Kubernetes運行時環境。如果節點組件出現問題，可能會導致該節點異常并且該節點Pod無法正常運行和結束。
因此，根據不同的組件，可能會出現不同的異常。
kube-apiserver對外暴露了Kubernetes API，如果kube-apiserver出現異常可能會導致：
集群無法訪問，無法注冊新的節點
資源（Deployment、Service等）無法創建、更新和刪除
現有的不依賴Kubernetes API的pods和services可以繼續正常工作
etcd用于Kubernetes的后端存儲，所有的集群數據都存在這里。保持穩定的etcd集群對于Kubernetes集群的穩定性至關重要。因此，我們需要在專用計算機或隔離環境上運行etcd集群以確保資源需求。當etcd出現異常時可能會導致：
kube-apiserver無法讀寫集群狀態，apiserver無法啟動
Kubernetes API訪問出錯
kubectl操作異常
kubelet無法訪問apiserver，僅能繼續運行已有的Pod
kube-controller-manager和kube-scheduler分別用于控制器管理和Pod 的調度，如果他們出現問題，則可能導致：
相關控制器無法工作
資源（Deployment、Service等）無法正常工作
無法注冊新的節點
Pod無法調度，一直處于Pending狀態
kubelet是主要的節點代理，如果節點宕機（VM關機）或者kubelet出現異常（比如無法啟動），那么可能會導致：
該節點上的Pod無法正常運行，如果節點關機，則當前節點上所有Pod都將停止運行
已運行的Pod無法伸縮，也無法正常終止
無法啟動新的Pod
節點會標識為不健康狀態
副本控制器會在其它的節點上啟動新的Pod
Kubelet有可能會刪掉當前運行的Pod
CoreDNS（在1.11以及以上版本的Kubernetes中，CoreDNS是默認的DNS服務器）是k8s集群默認的DNS服務器，如果其出現問題則可能導致：
無法注冊新的節點
集群網絡出現問題
Pod無法解析域名
kube-proxy是Kubernetes在每個節點上運行網絡代理。如果它出現了異常，則可能導致：
該節點Pod通信異常
節點健康狀態檢查
我們可以使用以下命令來檢查節點狀態：
kubectl get nodes
其中，“Ready”表示節點已就緒，為正常狀態，反之則該節點出現異常。節點出現問題，則Pod無法無法調度到該節點。
Pod健康狀態檢查
如果是集群應用出現異常，我們需要檢查相關Pod是否運行正常，可以使用以下命令：
kubectl get pods -o wide
如果存在命名空間，需要使用-n參數指定命名空間。如上圖所示，Pod為“Running”狀態才是正常。
如果Pod運行正常，但是又無法訪問（集群內部、外部），這時，我們需要檢查Service是否正常，可使用以下命令：
kubectl get svc -o wide
往期內容
Docker+ Kubernetes已成為云計算的主流（二十六）
容器化之后如何節省云端成本？（二十七）
了解Kubernetes主體架構（二十八）
使用Minikube部署本地Kubernetes集群（二十九）
使用kubectl管理k8s集群（三十）
使用Kubeadm創建k8s集群之部署規劃（三十一）
使用Kubeadm創建k8s集群之節點部署（三十二）
總結
以上是生活随笔為你收集整理的集群故障处理之处理思路以及健康状态检查（三十三）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： .NET加水印/验证码的NuGet包
- 下一篇： 使用Kubeadm创建k8s集群之节点部