您好,登錄后才能下訂單哦!
這篇文章主要介紹“怎么排查Kubernetes故障”,在日常操作中,相信很多人在怎么排查Kubernetes故障問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”怎么排查Kubernetes故障”的疑惑有所幫助!接下來,請跟著小編一起來學(xué)習(xí)吧!
排查Kubernetes部署故障的3個步驟:
應(yīng)確保Pods正常運行;
確保于服務(wù)可以將流量調(diào)度到Pod;
檢查是否正確配置了入口。
首先,檢查Pod已經(jīng)創(chuàng)建,并且正常。
其次,如果Pod正常,則應(yīng)檢查服務(wù)是否可以將流量分配給Pod。
最后,檢查服務(wù)與入口之間的連接。
在大多數(shù)情況下,問題出在Pod本身。應(yīng)該確保Pod正在運行并準(zhǔn)備就緒(READY為1)。
檢查方法:
kubectl get pods
如上述會話,最后一個Pod處于"Running"和"就緒"狀態(tài),前兩個Pod都沒有處于Running狀,狀態(tài)也未"就緒"。
可以用下面幾個命令用來排查Pod故障:
kubectl logs
kubectl describe pod
kubectl get pod
kubectl exec -ti
Pod可能會出現(xiàn)各種啟動和運行時錯誤。
啟動錯誤:
ImagePullBackoff,ImageInspectError,ErrImagePull,ErrImageNeverPull,RegistryUnavailable,InvalidImageName
運行時錯誤:
CrashLoopBackOff,RunContainerError,KillContainerError,VerifyNonRootError,RunInitContainerError,CreatePodSandboxError,ConfigPodSandboxError,KillPodSandboxError,SetupNetworkError,TeardownNetworkError
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
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描述中的"事件"部分以識別錯誤。
如果的Pod正在運行且已就緒,但仍無法收到應(yīng)用程序的響應(yīng),則應(yīng)檢查服務(wù)的配置是否正確。
服務(wù)的主要功能是根據(jù)流量的標(biāo)簽將流量路由到Pod。所以,先應(yīng)該檢查服務(wù)定位了多少個Pod,可以通過檢查服務(wù)中的端點來查看:
kubectl describe service
端點是一對
如果"端點"部分為空,則有兩種原因:
沒有運行帶有正確標(biāo)簽的Pod,應(yīng)檢查是否在正確的命名空間。
服務(wù)的選擇器標(biāo)簽中有錯字;
如果可以看到端點列表,但仍然無法訪問應(yīng)用程序,則很大原因是服務(wù)中的targetPort配置有誤。
可以通過使用kubectl port-forward連接到服務(wù)具體排查:
kubectl port-forward service/
如果Pod運行正常,服務(wù)可以分配流量到Pod,則可能原因是入口配置有誤:
根據(jù)入口可能使用不同控制器類型,需要按具體對應(yīng)方法進(jìn)行調(diào)試。
檢查入口配置參數(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)文檔進(jìn)行問題排查。此處我們以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:查看控制器日志。
到此,關(guān)于“怎么排查Kubernetes故障”的學(xué)習(xí)就結(jié)束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí),快去試試吧!若想繼續(xù)學(xué)習(xí)更多相關(guān)知識,請繼續(xù)關(guān)注億速云網(wǎng)站,小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。