Kubernetes 系列（三十一）POD 排障，解決你 99% 異常問題
您應該從底層開始對部署進行故障排除。
首先，檢查 POD 是否處于運作狀态。
如果“Pods”已經準備好，您應該調查服務是否可以将流量配置設定到“Pods”。
最後，您應該檢查 Ingress 和 服務之間的連接配接。
大多數情況下，問題出現在Pods本身。你應該確定 Pods 處于運作和就緒狀态。
你可以檢視Pods的狀态如下所示，
在輸出中，最後一個Pod既不是Running也不是Ready。
您可以使用以下四個指令來調查出錯的地方。
- 1. kubectl logs <pod name> :用于檢視pod容器的日志
- 2. kubectl describe pod <pod name> :用于檢索與pod相關的事件清單
3.kubectl get pod <pod name> -o yaml:用于提取存儲在Kubernetes中的pod的yaml定義。
- 4. kubectl exec -it <pod name> bash:用于在pod的一個容器中運作互動式指令。
常見Pods錯誤
錯誤有兩種類型，
- 1. 啟動錯誤
- 2. 運作時錯誤
啟動錯誤包括以下幾種:
- • ImagePullBackoff
- • ImageInspectError
- • ErrImagePull
- • ErrImageNeverPull
- • RegistryUnavailable
- • InvalidImageName
運作時錯誤包括:
- • CrashLoopBackOff
- • RunContainerError
- • KillContainerError
- • VerifyNonRootError
- • RunInitContainerError
- • CreatePodSandboxError
- • ConfigPodSandboxError
- • KillPodSandboxError
- • SetupNetworkError
- • TeardownNetworkError
最常見的錯誤和如何修複它們
ImagePullBackOff :
這個錯誤意味着 K8s 無法為Pod中的一個容器拉取鏡像。
常見的錯誤原因可能是以下之一，
- 1. 鏡像名稱無效
- 2. 您為鏡像指定了不存在的标記
- 3. 您試圖拉取的鏡像屬于私有注冊中心，k8s沒有通路它的憑據。
前兩種情況可以通過糾正鏡像名稱和标記來解決。
最後，您應該在Secret中将憑證添加到您的私有系統資料庫中，并在您的Pods中引用它。
CrossLoopBackOff:
如果容器不能啟動，那麼K8s将顯示 CrashLoopBackOff 消息作為狀态。
通常，容器在以下情況下不能啟動:
- 1. 應用程式中有一個錯誤，阻止它啟動。
- 2. 您錯誤地配置了容器。
- 3. alive探測失敗了太多次。
您應該嘗試從該容器檢索日志，以調查它失敗的原因。
如果因為容器重新開機太快而看不到日志，可以使用以下指令:
它列印來自前一次容器的錯誤資訊。
RunContainerError:
當容器無法啟動時出現該錯誤。
這甚至是在容器内的應用程式啟動之前。
該問題通常是由錯誤配置造成的，例如:
- • 挂載不存在的卷，如ConfigMap、Secrets等。
- • 将隻讀卷挂載為可讀寫。
你應該使用 kubectl describe pod <pod-name> 來檢查和分析錯誤。
pod 處于挂起(Pending)狀态:
當你建立一個Pod時，Pod保持在Pending狀态。
為什麼?
假設您的排程程式元件運作良好，以下是可能原因:
- 1. 叢集沒有足夠的資源(如CPU和記憶體)來運作Pod。
- 2. 目前的命名空間有一個ResourceQuota對象，建立Pod将使命名空間超過配額。
- 3. Pod被綁定到Pending PersistentVolumeClaim。
你最好的選擇是檢查 kubectl description 指令中的Events部分:
對于由于 ResourceQuotas 而産生的錯誤，您可以使用以下方法檢查叢集的日志:
Pods 處于未就緒(not Ready)狀态:
如果一個Pod是Running 但不是 Ready(Deployment 等控制類型狀态)，這意味着 Readiness探測失敗。
當Readiness探測失敗時，Pod不會附加到Service，并且沒有流量被轉發到該執行個體。
Readiness 探測失敗是應用程式特有的錯誤，是以您應該檢查 kubectl describe 中的Events部分來識别錯誤。