本文介紹關于Pod異常問題的診斷流程、排查方法、常見問題及解決方案。
本文目錄
類別 | 內容 |
診斷流程 | |
常見排查方法 | |
常見問題及解決方案 |
診斷流程
查看Pod是否處于異常狀態,具體操作,請參見檢查Pod的狀態。
如果Pod狀態異常,可通過查看Pod的事件、Pod的日志、Pod的配置等信息確定異常原因。具體操作,請參見常見排查方法。關于Pod異常狀態及處理方式,請參見常見的Pod異常狀態及處理方式。
如果Pod狀態為Running但未正常工作,請參見Pod狀態為Running但沒正常工作。
若確認是Pod OOM異常問題,請參見Pod OOM異常問題處理。
如果問題仍未解決,請提交工單。
常見的Pod異常狀態及處理方式
Pod狀態 | Pod含義 | 解決方案 |
Pending | Pod未被調度到節點上。 | |
Init:N/M | Pod包含M個Init容器,其中N個已經啟動完成。 | |
Init:Error | Init容器已啟動失敗。 | |
Init:CrashLoopBackOff | Init容器啟動失敗,反復重啟。 | |
Completed | Pod的啟動命令已執行完畢。 | |
CrashLoopBackOff | Pod啟動失敗,反復重啟。 | |
ImagePullBackOff | Pod鏡像拉取失敗。 | |
Running |
| |
Terminating | Pod正在關閉中。 | |
Evicted | Pod被驅逐。 |
常見排查方法
檢查Pod的狀態
登錄容器服務管理控制臺。
在控制臺左側導航欄,單擊集群。
在集群列表頁面,單擊目標集群名稱或者目標集群右側操作列下的詳情。
在集群管理頁左側導航欄,選擇 。
在容器組頁面左上角選擇Pod所在的命名空間,查看Pod狀態。
若狀態為Running,說明Pod運行正常。
若狀態不為Running,說明Pod狀態異常,請參見常見的Pod異常狀態及處理方式進行處理。
檢查Pod的詳情
登錄容器服務管理控制臺。
在控制臺左側導航欄,單擊集群。
在集群列表頁面中,單擊目標集群名稱或者目標集群右側操作列下的詳情。
在集群管理頁左側導航欄,選擇 。
在容器組頁面左上角選擇Pod所在的命名空間,然后單擊目標Pod名稱或者目標Pod右側操作列下的詳情,查看Pod的名稱、鏡像、Pod IP、所在節點等詳細信息。
檢查Pod的配置
登錄容器服務管理控制臺。
在控制臺左側導航欄,單擊集群。
在集群列表頁面,單擊目標集群名稱或者目標集群右側操作列下的詳情。
在集群管理頁左側導航欄,選擇 。
在容器組頁面左上角選擇Pod所在的命名空間,然后單擊目標Pod名稱或者目標Pod右側操作列下的詳情。
在Pod詳情頁面右上角單擊編輯,查看Pod的YAML文件和詳細配置。
檢查Pod的事件
登錄容器服務管理控制臺。
在控制臺左側導航欄,單擊集群。
在集群列表頁面,單擊目標集群名稱或者目標集群右側操作列下的詳情。
在集群管理頁左側導航欄,選擇 。
在容器組頁面左上角選擇Pod所在的命名空間,然后單擊目標Pod名稱或者目標Pod右側操作列下的詳情。
在Pod詳情頁面下方單擊事件頁簽,查看Pod的事件。
說明Kubernetes默認保留最近1小時的事件,若需保存更長時間的事件,請參見創建并使用K8s事件中心。
檢查Pod的日志
登錄容器服務管理控制臺。
在控制臺左側導航欄,單擊集群。
在集群列表頁面,單擊目標集群名稱或者目標集群右側操作列下的詳情。
在集群管理頁左側導航欄,選擇 。
在容器組頁面左上角選擇Pod所在的命名空間,然后單擊目標Pod名稱或者目標Pod右側操作列下的詳情。
在Pod詳情頁面下方單擊日志頁簽,查看Pod的日志。
說明阿里云ACK集群集成了日志服務,您可在創建集群時啟用日志服務,快速采集集群的容器日志,包括容器的標準輸出及容器內的文本文件。更多信息,請參見通過日志服務采集Kubernetes容器日志。
檢查Pod的監控
登錄容器服務管理控制臺。
在控制臺左側導航欄,單擊集群。
在集群列表頁面,單擊目標集群名稱或者目標集群右側操作列下的詳情。
在集群管理頁左側導航欄中,選擇 。
在Prometheus監控頁面,單擊集群監控概覽頁簽,選擇查看Pod的CPU、內存、網絡I/O等監控大盤。
使用終端進入容器
登錄容器服務管理控制臺。
在控制臺左側導航欄,單擊集群。
在集群列表頁面,單擊目標集群名稱或者目標集群右側操作列下的詳情。
在集群管理頁左側導航欄,選擇 。
在容器組頁面,單擊目標容器組右側操作列下的終端。
可通過終端進入容器,在容器內查看本地文件等信息。
Pod故障診斷
Pod狀態為Pending
問題原因
若Pod停留在Pending狀態,說明該Pod不能被調度到某一個節點上。通常是由于資源依賴、資源不足、該Pod使用了hostPort、污點和容忍等原因導致集群中缺乏需要的資源。
問題現象
Pod的狀態為Pending。
解決方案
查看Pod的事件,根據事件描述,定位Pod不能被調度到節點的原因。主要原因有以下幾類:
資源依賴
創建Pod時,需要依賴于集群中ConfigMap、PVC等資源。例如,Pod添加存儲卷聲明前,存儲卷聲明需要先與存儲卷綁定。
資源不足
在集群信息頁面,選擇
,查看容器組、CPU、內存的使用情況,確定集群的資源使用率。說明某個節點實際使用的CPU、內存資源非常低,新加入一個Pod時,如果會導致實際使用的資源超過該節點最大可供使用的資源,則調度程序不會將該Pod分配到該節點。這樣可避免在日常的流量高峰時段,節點上出現資源短缺的情況。
若集群中的CPU或內存都已經耗盡,可參考如下方法處理。
刪除或減少不必要的Pod。具體操作,請參見管理容器組(Pod)。
根據自身業務情況,調整Pod的資源配置。具體操作,請參見設置容器的CPU和內存資源上下限。
在集群中添加新的節點。具體操作,請參見創建節點池。
為節點進行升配。具體操作,請參見升配Worker節點的資源。
該Pod使用了hostPort
如果您使用了hostPort,那么Deployment或ReplicationController中
Replicas
值不能超過集群中的節點數,因為每個實例的任意端口只有一個。如果該端口被其他應用占用,將導致Pod調度失敗。因此建議您不要使用hostPort,您可以使用Service訪問Pod,更多信息,請參見Service。污點和容忍
當您在Pod的事件中看到Taints或Tolerations時,說明是由于污點導致,您可以刪除污點或者給Pod設置容忍。更多信息,請參見管理節點污點、創建無狀態工作負載Deployment和污點和容忍。
Pod狀態為Init:N/M(Init:Error和Init:CrashLoopBackOff)
問題原因
若Pod停留在Init:N/M狀態,說明該Pod包含M個Init容器,其中N個已經啟動完成,但仍有M-N個Init容器未啟動成功。
若Pod停留在Init:Error狀態,說明Pod中的Init容器啟動失敗。
若Pod停留在Init:CrashLoopBackOff狀態,說明Pod中的Init容器啟動失敗并處于反復重啟狀態。
問題現象
Pod的狀態為Init:N/M。
Pod的狀態為Init:Error。
Pod的狀態為Init:CrashLoopBackOff。
解決方案
Pod狀態為ImagePullBackOff
問題原因
若Pod停留在ImagePullBackOff狀態,說明此Pod已被調度到某個節點,但拉取鏡像失敗。
問題現象
Pod的狀態為ImagePullBackOff。
解決方案
通過查看該Pod的事件描述,查看具體拉取失敗的鏡像名稱。
確認容器鏡像名稱是否正確。
登錄到Pod所在的節點,執行
docker pull [$Image]
命令,查看是否能正常抓取容器鏡像。說明[$Image]
為容器鏡像的名稱。若鏡像拉取失敗,請參見docker pull失敗解決。
如果您使用的是私有鏡像倉庫,請參見使用私有鏡像倉庫創建應用解決。
Pod狀態為CrashLoopBackOff
問題原因
若Pod停留在CrashLoopBackOff狀態,說明容器中應用程序有問題。
問題現象
Pod的狀態為CrashLoopBackOff。
解決方案
查看Pod的事件,確認當前Pod是否存在異常。具體操作,請參見檢查Pod的事件。
查看Pod的日志,通過日志內容排查問題。具體操作,請參見檢查Pod的日志。
查看Pod的配置,確認容器中的健康檢查配置是否正常。具體操作,請參見檢查Pod的配置。關于Pod健康檢查的更多信息,請參見配置存活、就緒和啟動探測器。
Pod狀態為Completed
問題原因
若Pod出現Completed狀態,說明容器中的啟動命令已執行完畢,容器中的所有進程都已退出。
問題現象
Pod的狀態為Completed。
解決方案
Pod狀態為Running但沒正常工作
問題原因
部署使用的YAML文件有問題。
問題現象
Pod狀態為Running但沒正常工作。
解決方案
查看Pod的配置,確定Pod中容器的配置是否符合預期。具體操作,請參見檢查Pod的配置。
使用以下方法,排查環境變量中的某一個Key是否存在拼寫錯誤。
以command拼寫成commnd為例,說明拼寫問題排查方法。
說明創建Pod時,環境變量中的某一個Key拼寫錯誤的問題會被集群忽略,如Command拼寫為Commnd,您仍能夠使用該YAML文件創建資源。但容器運行時,不會執行有拼寫問題的YAML文件,而是執行鏡像中的默認命令。
在執行
kubectl apply -f
命令前為其添加--validate
,然后執行kubectl apply --validate -f XXX.yaml
命令。如果您將command拼寫成commnd,將看到錯誤信息
XXX] unknown field: commnd XXX] this may be a false alarm, see https://gXXXb.XXX/6842pods/test
。執行以下命令,將輸出結果的pod.yaml文件與您創建Pod使用的文件進行對比。
kubectl get pods [$Pod] -o yaml > pod.yaml
說明[$Pod]
為異常Pod的名稱,您可以通過kubectl get pods
命令查看。pod.yaml文件比您創建Pod所使用的文件多幾行,說明已創建的Pod符合預期。
如果您創建Pod所使用文件里的代碼行在pod.yaml文件中沒有,說明您創建Pod使用的文件存在拼寫問題。
查看Pod的日志,通過日志內容排查問題。具體操作,請參見檢查Pod的日志。
可通過終端進入容器查看容器內的本地文件是否符合預期。具體操作,請參見使用終端進入容器。
Pod狀態為Terminating
問題原因
若Pod的狀態為Terminating,說明此Pod正處于關閉狀態。
問題現象
Pod狀態為Terminating。
解決方案
Pod停留在Terminating狀態一段時間后會被自動刪除。若Pod一直停留在Terminating狀態,可執行如下命令強制刪除:
kubectl delete pod [$Pod] -n [$namespace] --grace-period=0 --force
Pod狀態為Evicted
問題原因
當節點的內存、磁盤空間、文件系統的inode和操作系統可分配的PID等資源中的一個或者多個達到特定的消耗水平,就會引發kubelet主動地驅逐節點上一個或者多個Pod,以回收節點資源。
問題現象
Pod的狀態為Evicted。
解決方案
執行以下命令,查看Pod的
status.message
字段,來確定Pod被驅逐的原因。kubectl get pod [$Pod] -o yaml -n [$namespace]
預期輸出:
status: message: 'Pod the node had condition: [DiskPressure].' phase: Failed reason: Evicted
通過上述
status.message
字段,可以判斷當前Pod是因為節點磁盤壓力 (DiskPressure) 被驅逐。說明注意這里僅以磁盤壓力驅逐為例,其它例如內存壓力(MemoryPressure)和PID壓力(PIDPressure)等也會以類似的方式展示。
執行以下命令,刪除被驅逐的Pod。
kubectl get pods -n [$namespace]| grep Evicted | awk '{print $1}' | xargs kubectl delete pod -n [$namespace]
以下匯總如何避免Pod被驅逐的方法:
內存壓力:
根據自身業務情況,調整Pod的資源配置。具體操作,請參見設置容器的CPU和內存資源上下限。
為節點進行升配。具體操作,請參見升配Worker節點的資源。
磁盤壓力:
定時清理節點上的業務Pod日志,避免磁盤被日志打滿。
為節點進行磁盤擴容。具體操作,請參見步驟一:擴容云盤容量。
PID壓力:根據自身業務情況,調整Pod的資源配置,具體操作,請參見進程ID約束與預留。
Pod OOM異常問題處理
問題原因
當集群中的容器使用超過其限制的內存,容器可能會被終止,觸發OOM(Out Of Memory)事件,導致容器異常退出。關于OOM事件,請參見為容器和Pod分配內存資源。
問題現象
若被終止的進程為容器的阻塞進程,可能導致容器異常重啟。
若出現OOM異常問題,登錄容器服務管理控制臺,在Pod詳情頁面單擊事件頁簽可看到OOM事件pod was OOM killed。具體操作,請參見檢查Pod的事件。
若集群配置了集群容器副本異常報警,則OOM事件出現時可收到相關報警。關于配置報警,請參見容器服務報警管理。
解決方案
查看發生OOM異常的Pod所在的節點。
命令行方式查看:執行以下命令,查看容器信息。
kubectl get pod [$Pod] -o wide -n [$namespace]
預期輸出:
NAME READY STATUS RESTARTS AGE IP NODE pod_name 1/1 Running 0 25h 172.20.6.53 cn-hangzhou.192.168.0.198
控制臺方式查看:查看Pod詳情下的節點信息,請參見檢查Pod的詳情。
登錄Pod所在的Node,查看內核日志
/var/log/message
。在日志中查詢關鍵字out of memory
,確認具體被OOM終止的進程。如果該進程是容器的阻塞進程,OOM終止后容器會重啟。通過Pod內存監控查看內存增長曲線,確定異常出現時間。具體操作,請參見檢查Pod的監控。
根據監控、內存增長時間點、日志、進程名等信息,排查Pod內對應進程是否存在內存泄漏。
若OOM是進程內存泄漏導致,請您自行排查泄露原因。
若進程運行狀態正常,則根據實際運行需要,適當增大Pod的內存限制,建議Pod的內存實際使用量不超過內存限制值的80%。具體操作,請參見設置容器的CPU和內存資源上下限。