圖解Kubernetes故障排查指南
針對越來多的Kubernetes容器云，對Kubernetes集群的故障排查卻成了一個棘手問題。本文給大家以直觀圖示方式介紹如何排查Kubernetes的故障。該篇是系列文章續——故障排查篇。關于圖解部署配置請參考上一篇文章：圖解Kubernetes應用部署
概述
上一篇，我們介紹了Kubernetes三個關鍵組件入口、服務和Pods之間如何連接，以及相關配置關鍵點。知道如何正確配置YAML只是開始，最重要最實用的是要知道出問題了如何排查。
在深入研究排查部署之前，我們必須先給出排查Kubernetes故障的思維模型。由于每個部署中都存在三個組件，因此需要從底部開始依次調試所有組件。
關鍵點
排查Kubernetes部署故障的3個步驟：
- 應確保Pods正常運行;
- 確保于服務可以將流量調度到Pod;
- 檢查是否正確配置了入口。
直觀圖示
首先，檢查Pod已經創建，并且正常。
其次，如果Pod正常，則應檢查服務是否可以將流量分配給Pod。
最后，檢查服務與入口之間的連接。
Pod故障排查
在大多數情況下，問題出在Pod本身。應該確保Pod正在運行并準備就緒(READY為1)。
檢查方法：
kubectl get pods
如上述會話，最后一個Pod處于"Running"和"就緒"狀態，前兩個Pod都沒有處于Running狀，狀態也未"就緒"。
關鍵點
可以用下面幾個命令用來排查Pod故障：
- kubectl logs
：用來查看Pod容器日志。 - kubectl describe pod
：用于查看與Pod相關的事件列表。 - kubectl get pod
：用于獲取Pod的YAML定義。 - kubectl exec -ti
bash：對進入Pod容器進行交互式終端。
常見Pod錯誤列表
Pod可能會出現各種啟動和運行時錯誤。
啟動錯誤：
ImagePullBackoff，ImageInspectError，ErrImagePull，ErrImageNeverPull，RegistryUnavailable，InvalidImageName
運行時錯誤：
CrashLoopBackOff，RunContainerError，KillContainerError，VerifyNonRootError，RunInitContainerError，CreatePodSandboxError，ConfigPodSandboxError，KillPodSandboxError，SetupNetworkError，TeardownNetworkError
關鍵錯誤代碼及其修復方法
ImagePullBackOff
當Kubernetes無法檢索Pod容器之一的圖像時，將出現此錯誤。
主要三個原因：
- 鏡像名稱無效。例如，輸錯名字，或者鏡像不存在。
- 為鏡像指定了一個不存在的標簽。
- 嘗試檢索的鏡像屬于一個私有注冊表，但是Kubernetes沒有設置權限訪問。
解決方法：
前兩種情況可以通過修改鏡像名和標簽來解決。
第三個問題，需要在注冊表中添加憑據，并在Pod中引用。
官方文檔中有一個有關如何實現此目標的示例。
CrashLoopBackOff
如果容器無法啟動，則Kubernetes status會顯示CrashLoopBackOff錯誤。
通常，Pod在以下情況下容器無法啟動：
- 應用程序中出現錯誤，阻止其啟動;
- 未正確配置容器;
- Liveness探針失敗太多次;
解決方法：
應該查看容器中日志，了解詳細失敗的原因。
kubectl logs
RunContainerError
當容器無法啟動時出現錯誤，直至在容器內的應用程序啟動之前。
該問題通常是由于配置錯誤，例如：
掛載不存在的卷，例如ConfigMap或Secrets
將只讀卷安裝為可讀寫
解決方法：
對該錯誤應該使用kubectl describe pod
Pod處于待處理狀態
當創建Pod時，該Pod保持在待處理狀態。主要可能原因：
- 群集沒有足夠的資源(例如CPU和內存)來運行Pod;
- 當前的命名空間具有ResourceQuota對象，創建Pod將使命名空間超過配額;
- Pod綁定到一個待處理的PersistentVolumeClaim;
解決方法：
檢查kubectl describe命令的事件部分：
kubectl describe pod
對于因ResourceQuotas而導致的錯誤，可以使用以下方法檢查群集的日志：
kubectl get events --sort-by=.metadata.creationTimestamp
Pod處于未就緒狀態
如果Pod正在運行但未就緒，則表示"就緒"探針失敗。
當就緒探針失敗時，Pod未連接到服務，并且不會有流量轉發到該實例。
解決方法
準備就緒探針失敗是特定于應用程序的錯誤，因此應該檢查kubectl描述中的"事件"部分以識別錯誤。
服務故障排查
如果的Pod正在運行且已就緒，但仍無法收到應用程序的響應，則應檢查服務的配置是否正確。
關鍵點
服務的主要功能是根據流量的標簽將流量路由到Pod。所以，先應該檢查服務定位了多少個Pod，可以通過檢查服務中的端點來查看：
kubectl describe service
端點是一對
如果"端點"部分為空，則有兩種原因：
沒有運行帶有正確標簽的Pod，應檢查是否在正確的命名空間。
服務的選擇器標簽中有錯字;
如果可以看到端點列表，但仍然無法訪問應用程序，則很大原因是服務中的targetPort配置有誤。
可以通過使用kubectl port-forward連接到服務具體排查：
kubectl port-forward service/
入口故障排查
如果Pod運行正常，服務可以分配流量到Pod，則可能原因是入口配置有誤：
根據入口可能使用不同控制器類型，需要按具體對應方法進行調試。
關鍵點
檢查入口配置參數serviceName和servicePort配置是否正確。可以使用下面命令檢查：
kubectl describe ingress
如果"后端"列為空，則配置中肯定有一個錯誤。
如果可以在"后端"列中看到端口，但是仍然無法訪問該應用程序，則可能是以下問題：
沒有如何將入口發布到公網;沒有如何將群集發布到公網;
可以通過直接連接到Ingress Pod來將基礎結構問題與入口隔離開。
首先，查看入口控制器Pod列表：
kubectl get pods --all-namespaces
其次，使用kubectl describe命令查看端口：
kubectl describe pod nginx-ingress-controller-6fc5bcc
最后，連接到Pod：
kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system
這樣，訪問計算機上的端口3000時，請求都會轉發到Pod上的端口80。現在應用可以用嗎?
如果可行，則問題出在基礎架構中。應該檢查如何將流量調度到群集。
如果還不行，則問題出在入口控制器中。應該調試入口控制器。常見的入口控制包括Nginx，HAProxy，Traefik等，可以查看具體控制器相關文檔進行問題排查。此處我們以Nginx為例：
排查Nginx控制器
Ingress-nginx項目是Kubectl官方插件。可以使用kubectl ingress-nginx執行以下操作：
- 查看日志，后端，證書等;
- 連接到入口;
- 檢查當前配置。
對應的命令有：
- kubectl ingress-nginx lint：用于檢查nginx.conf
- kubectl ingress-nginx backend：用于檢查后端(類似于kubectl describe ingress
) - kubectl ingress-nginx logs：查看控制器日志。
總結
對一個諸如Kubernetes之類復雜架構的集群，進行故障排除是一項艱巨的任務。有句俗語"老虎吃天，無處下爪"。面對艱巨的任務，首要任務是找到故障排查的思路，對Kubernetes集群的故障排查應該遵循從下至上排查方法：先從Pod開始，然后是服務和入口，依次按順序排查。
