針對越來多的Kubernetes容器云，對Kubernetes集群的故障排查卻成了一個棘手問題。本文給大家以直觀圖示方式介紹如何排查Kubernetes的故障。該篇是系列文章續(xù)——故障排查篇。關(guān)于圖解部署配置請參考上一篇文章：圖解Kubernetes應(yīng)用部署

 

 

概述

上一篇，我們介紹了Kubernetes三個關(guān)鍵組件入口、服務(wù)和Pods之間如何連接，以及相關(guān)配置關(guān)鍵點。知道如何正確配置YAML只是開始，最重要最實用的是要知道出問題了如何排查。

在深入研究排查部署之前，我們必須先給出排查Kubernetes故障的思維模型。由于每個部署中都存在三個組件，因此需要從底部開始依次調(diào)試所有組件。

關(guān)鍵點

排查Kubernetes部署故障的3個步驟：

• 應(yīng)確保Pods正常運行;
• 確保于服務(wù)可以將流量調(diào)度到Pod;
• 檢查是否正確配置了入口。

直觀圖示

首先，檢查Pod已經(jīng)創(chuàng)建，并且正常。

 

 

其次，如果Pod正常，則應(yīng)檢查服務(wù)是否可以將流量分配給Pod。

 

 

最后，檢查服務(wù)與入口之間的連接。

 

 

Pod故障排查

在大多數(shù)情況下，問題出在Pod本身。應(yīng)該確保Pod正在運行并準(zhǔn)備就緒(READY為1)。

檢查方法：

kubectl get pods

 

 

如上述會話，最后一個Pod處于"Running"和"就緒"狀態(tài)，前兩個Pod都沒有處于Running狀，狀態(tài)也未"就緒"。

關(guān)鍵點

可以用下面幾個命令用來排查Pod故障：

• kubectl logs ：用來查看Pod容器日志。
• kubectl describe pod ：用于查看與Pod相關(guān)的事件列表。
• kubectl get pod ：用于獲取Pod的YAML定義。
• kubectl exec -ti bash：對進入Pod容器進行交互式終端。

常見Pod錯誤列表

Pod可能會出現(xiàn)各種啟動和運行時錯誤。

啟動錯誤：

ImagePullBackoff，ImageInspectError，ErrImagePull，ErrImageNeverPull，RegistryUnavailable，InvalidImageName

運行時錯誤：

CrashLoopBackOff，RunContainerError，KillContainerError，VerifyNonRootError，RunInitContainerError，CreatePodSandboxError，ConfigPodSandboxError，KillPodSandboxError，SetupNetworkError，TeardownNetworkError

關(guān)鍵錯誤代碼及其修復(fù)方法

ImagePullBackOff

當(dāng)Kubernetes無法檢索Pod容器之一的圖像時，將出現(xiàn)此錯誤。

主要三個原因：

• 鏡像名稱無效。例如，輸錯名字，或者鏡像不存在。
• 為鏡像指定了一個不存在的標(biāo)簽。
• 嘗試檢索的鏡像屬于一個私有注冊表，但是Kubernetes沒有設(shè)置權(quán)限訪問。

解決方法：

前兩種情況可以通過修改鏡像名和標(biāo)簽來解決。

第三個問題，需要在注冊表中添加憑據(jù)，并在Pod中引用。

官方文檔中有一個有關(guān)如何實現(xiàn)此目標(biāo)的示例。

CrashLoopBackOff

如果容器無法啟動，則Kubernetes status會顯示CrashLoopBackOff錯誤。

通常，Pod在以下情況下容器無法啟動：

• 應(yīng)用程序中出現(xiàn)錯誤，阻止其啟動;
• 未正確配置容器;
• Liveness探針失敗太多次;

解決方法：

應(yīng)該查看容器中日志，了解詳細(xì)失敗的原因。

kubectl logs --previous

RunContainerError

當(dāng)容器無法啟動時出現(xiàn)錯誤，直至在容器內(nèi)的應(yīng)用程序啟動之前。

該問題通常是由于配置錯誤，例如：

掛載不存在的卷，例如ConfigMap或Secrets

將只讀卷安裝為可讀寫

解決方法：

對該錯誤應(yīng)該使用kubectl describe pod 來收集和分析錯誤。

Pod處于待處理狀態(tài)

當(dāng)創(chuàng)建Pod時，該Pod保持在待處理狀態(tài)。主要可能原因：

• 群集沒有足夠的資源(例如CPU和內(nèi)存)來運行Pod;
• 當(dāng)前的命名空間具有ResourceQuota對象，創(chuàng)建Pod將使命名空間超過配額;
• Pod綁定到一個待處理的PersistentVolumeClaim;

解決方法：

檢查kubectl describe命令的事件部分：

kubectl describe pod

對于因ResourceQuotas而導(dǎo)致的錯誤，可以使用以下方法檢查群集的日志：

kubectl get events --sort-by=.metadata.creationTimestamp

Pod處于未就緒狀態(tài)

如果Pod正在運行但未就緒，則表示"就緒"探針失敗。

當(dāng)就緒探針失敗時，Pod未連接到服務(wù)，并且不會有流量轉(zhuǎn)發(fā)到該實例。

解決方法

準(zhǔn)備就緒探針失敗是特定于應(yīng)用程序的錯誤，因此應(yīng)該檢查kubectl描述中的"事件"部分以識別錯誤。

服務(wù)故障排查

如果的Pod正在運行且已就緒，但仍無法收到應(yīng)用程序的響應(yīng)，則應(yīng)檢查服務(wù)的配置是否正確。

關(guān)鍵點

服務(wù)的主要功能是根據(jù)流量的標(biāo)簽將流量路由到Pod。所以，先應(yīng)該檢查服務(wù)定位了多少個Pod，可以通過檢查服務(wù)中的端點來查看：

kubectl describe service | grep Endpoints

端點是一對，并且在服務(wù)(至少)以Pod為目標(biāo)時，應(yīng)該至少有一個。

如果"端點"部分為空，則有兩種原因：

沒有運行帶有正確標(biāo)簽的Pod，應(yīng)檢查是否在正確的命名空間。

服務(wù)的選擇器標(biāo)簽中有錯字;

如果可以看到端點列表，但仍然無法訪問應(yīng)用程序，則很大原因是服務(wù)中的targetPort配置有誤。

可以通過使用kubectl port-forward連接到服務(wù)具體排查：

kubectl port-forward service/ 3000:80

入口故障排查

如果Pod運行正常，服務(wù)可以分配流量到Pod，則可能原因是入口配置有誤：

根據(jù)入口可能使用不同控制器類型，需要按具體對應(yīng)方法進行調(diào)試。

關(guān)鍵點

檢查入口配置參數(shù)serviceName和servicePort配置是否正確?？梢允褂孟旅婷顧z查：

kubectl describe ingress

如果"后端"列為空，則配置中肯定有一個錯誤。

如果可以在"后端"列中看到端口，但是仍然無法訪問該應(yīng)用程序，則可能是以下問題：

沒有如何將入口發(fā)布到公網(wǎng);沒有如何將群集發(fā)布到公網(wǎng);

可以通過直接連接到Ingress Pod來將基礎(chǔ)結(jié)構(gòu)問題與入口隔離開。

首先，查看入口控制器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時，請求都會轉(zhuǎn)發(fā)到Pod上的端口80?，F(xiàn)在應(yīng)用可以用嗎?

如果可行，則問題出在基礎(chǔ)架構(gòu)中。應(yīng)該檢查如何將流量調(diào)度到群集。

如果還不行，則問題出在入口控制器中。應(yīng)該調(diào)試入口控制器。常見的入口控制包括Nginx，HAProxy，Traefik等，可以查看具體控制器相關(guān)文檔進行問題排查。此處我們以Nginx為例：

排查Nginx控制器

Ingress-nginx項目是Kubectl官方插件?？梢允褂胟ubectl ingress-nginx執(zhí)行以下操作：

• 查看日志，后端，證書等;
• 連接到入口;
• 檢查當(dāng)前配置。

對應(yīng)的命令有：

• kubectl ingress-nginx lint：用于檢查nginx.conf
• kubectl ingress-nginx backend：用于檢查后端(類似于kubectl describe ingress )
• kubectl ingress-nginx logs：查看控制器日志。

總結(jié)

對一個諸如Kubernetes之類復(fù)雜架構(gòu)的集群，進行故障排除是一項艱巨的任務(wù)。有句俗語"老虎吃天，無處下爪"。面對艱巨的任務(wù)，首要任務(wù)是找到故障排查的思路，對Kubernetes集群的故障排查應(yīng)該遵循從下至上排查方法：先從Pod開始，然后是服務(wù)和入口，依次按順序排查。