在學習k8s過程中會發現pod會有很多狀態，今天就pod的異常狀態總結一下；
pod運行異常排錯
常用的幾種命令來進行pod狀態查看
- kubectl describe pod
-n namespaces查看 Pod 的事件 - kubectl get pod
-o yaml -n namespaces 查看 Pod 的配置是否正確 - kubectl logs
[-c ] -n namespaces 查看容器日志
通過上述事件和日志基本上能排除大部分pod的問題。
Pod 一直處於 Pending 狀態
Pending狀態的pod 還沒有被調度到某個node上，可以通過
kubectl describe pod
- 資源不足，集群內所有的 Node 都不滿足該 Pod 請求的 CPU、內存、GPU 等資源
- HostPort 已被占用，通常推薦使用 Service 對外開放服務端口
- 如果只有一個node節點或者配置中指定了node信息，還有觀察kubelet的狀態
Pod 一直處於 Waiting 或 ContainerCreating 狀態
首先還是通過 kubectl describe pod
- 鏡像拉取失敗，比如
- 配置了錯誤的鏡像
- Kubelet 無法訪問鏡像（國內環境訪問 gcr.io 需要特殊處理）
- 私有鏡像的密鑰配置錯誤
- 鏡像太大，拉取超時（可以適當調整 kubelet 的 --image-pull-progress-deadline 和 --runtime-request-timeout 選項）
- CNI 網絡錯誤，一般需要檢查 CNI 網絡插件的配置，比如
- 無法配置 Pod 網絡
- 無法分配 IP 地址
- 容器無法啟動，需要檢查是否打包了正確的鏡像或者是否配置了正確的容器參數
Pod 處於 Error 狀態
- 依賴的 ConfigMap、Secret 或者 PV 等不存在
- 請求的資源超過了管理員設置的限制，比如超過了 LimitRange 等
- 違反集群的安全策略，比如違反了 PodSecurityPolicy 等
- 容器無權操作集群內的資源，比如開啟 RBAC 后，需要為 ServiceAccount 配置角色綁定
Pod 處於 Terminating 或 Unknown 狀態
從 v1.5 開始，Kubernetes 不會因為 Node 失聯而刪除其上正在運行的 Pod，而是將其標記為 Terminating 或 Unknown 狀態。想要刪除這些狀態的 Pod 有三種方法：
- 從集群中刪除該 Node。使用公有雲時，kube-controller-manager 會在 VM 刪除后自動刪除對應的 Node。而在物理機部署的集群中，需要管理員手動刪除 Node（如 kubectl delete node
。 - Node 恢復正常。Kubelet 會重新跟 kube-apiserver 通信確認這些 Pod 的期待狀態，進而再決定刪除或者繼續運行這些 Pod。
- 用戶強制刪除。用戶可以執行 kubectl delete pods
--grace-period=0 --force 強制刪除 Pod。除非明確知道 Pod 的確處於停止狀態（比如 Node 所在 VM 或物理機已經關機），否則不建議使用該方法。特別是 StatefulSet 管理的 Pod，強制刪除容易導致腦裂或者數據丟失等問題。
Pod 行為異常
這里所說的行為異常是指 Pod 沒有按預期的行為執行，比如沒有運行 podSpec 里面設置的命令行參數。這一般是 podSpec yaml 文件內容有誤，可以嘗試使用 --validate 參數重建容器，比如
kubectl delete pod mypod
kubectl create --validate -f mypod.yaml
也可以查看創建后的 podSpec 是否是對的，比如
kubectl get pod mypod -o yaml
修改靜態 Pod 的 Manifest 后未自動重建
Kubelet 使用 inotify 機制檢測 /etc/kubernetes/manifests 目錄（可通過 Kubelet 的 --pod-manifest-path 選項指定）中靜態 Pod 的變化，並在文件發生變化后重新創建相應的 Pod。但有時也會發生修改靜態 Pod 的 Manifest 后未自動創建新 Pod 的情景，此時一個簡單的修復方法是重啟 Kubelet。