怎么排查Kubernetes故障

這篇文章主要介紹“怎么排查Kubernetes故障”，在日常操作中，相信很多人在怎么排查Kubernetes故障問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么排查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--previous

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| grep Endpoints

端點是一對，并且在服務(至少)以Pod為目標時，應該至少有一個。

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

沒有運行帶有正確標簽的Pod，應檢查是否在正確的命名空間。

服務的選擇器標簽中有錯字;

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

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

kubectl port-forward service/3000:80

入口故障排查

如果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故障”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！