建站
咨詢
售后
建站咨詢
新聞中心
針對越來多的Kubernetes容器云，對Kubernetes集群的故障排查卻成了一個棘手問題。本文給大家以直觀圖示方式介紹如何排查Kubernetes的故障。該篇是系列文章續(xù)——故障排查篇。關(guān)于圖解部署配置請參考上一篇文章：圖解Kubernetes應(yīng)用部署
創(chuàng)新互聯(lián)建站-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比林芝網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式林芝網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋林芝地區(qū)。費用合理售后完善，十年實體公司更值得信賴。
概述
上一篇，我們介紹了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正在運行并準備就緒(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)此錯誤。
主要三個原因：
- 鏡像名稱無效。例如，輸錯名字，或者鏡像不存在。
- 為鏡像指定了一個不存在的標簽。
- 嘗試檢索的鏡像屬于一個私有注冊表，但是Kubernetes沒有設(shè)置權(quán)限訪問。
解決方法：
前兩種情況可以通過修改鏡像名和標簽來解決。
第三個問題，需要在注冊表中添加憑據(jù)，并在Pod中引用。
官方文檔中有一個有關(guān)如何實現(xiàn)此目標的示例。
CrashLoopBackOff
如果容器無法啟動，則Kubernetes status會顯示CrashLoopBackOff錯誤。
通常，Pod在以下情況下容器無法啟動：
- 應(yīng)用程序中出現(xiàn)錯誤，阻止其啟動;
- 未正確配置容器;
- Liveness探針失敗太多次;
解決方法：
應(yīng)該查看容器中日志，了解詳細失敗的原因。
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ā)到該實例。
解決方法
準備就緒探針失敗是特定于應(yīng)用程序的錯誤，因此應(yīng)該檢查kubectl描述中的"事件"部分以識別錯誤。
服務(wù)故障排查
如果的Pod正在運行且已就緒，但仍無法收到應(yīng)用程序的響應(yīng)，則應(yīng)檢查服務(wù)的配置是否正確。
關(guān)鍵點
服務(wù)的主要功能是根據(jù)流量的標簽將流量路由到Pod。所以，先應(yīng)該檢查服務(wù)定位了多少個Pod，可以通過檢查服務(wù)中的端點來查看：
kubectl describe service | grep Endpoints
端點是一對 ，并且在服務(wù)(至少)以Pod為目標時，應(yīng)該至少有一個。
如果"端點"部分為空，則有兩種原因：
沒有運行帶有正確標簽的Pod，應(yīng)檢查是否在正確的命名空間。
服務(wù)的選擇器標簽中有錯字;
如果可以看到端點列表，但仍然無法訪問應(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。現(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官方插件。可以使用kubectl 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ù)和入口，依次按順序排查。
標題名稱：圖解Kubernetes故障排查指南
文章位置：http://www.dlmjj.cn/article/ccddhji.html
