本文目錄

診斷流程

1. 查看Pod是否處于異常狀態，具體操作，請參見檢查Pod的狀態。

   1. 如果Pod狀態異常，可通過查看Pod的事件、Pod的日志、Pod的配置等信息確定異常原因。具體操作，請參見常見排查方法。關于Pod異常狀態及處理方式，請參見常見的Pod異常狀態及處理方式。

   2. 如果Pod狀態為Running但未正常工作，請參見Pod狀態為Running但沒正常工作。

2. 若確認是Pod OOM異常問題，請參見Pod OOM異常問題處理。

3. 如果問題仍未解決，請提交工單。

常見的Pod異常狀態及處理方式

常見排查方法

檢查Pod的狀態

1. 登錄容器計算服務控制臺，在左側導航欄選擇集群。

2. 在集群頁面，單擊目標集群ID，然后在左側導航欄，選擇工作負載 > 容器組。

3. 在容器組頁面左上角選擇Pod所在的命名空間，查看Pod狀態。

   • 若狀態為Running，說明Pod運行正常。

   • 若狀態不為Running，說明Pod狀態異常，請參見常見的Pod異常狀態及處理方式進行處理。

檢查Pod的詳情

檢查Pod的配置

檢查Pod的事件

1. 登錄容器計算服務控制臺，在左側導航欄選擇集群。

2. 在集群頁面，單擊目標集群ID，然后在左側導航欄，選擇工作負載 > 容器組。

3. 在容器組頁面左上角選擇Pod所在的命名空間，然后單擊目標Pod名稱或者目標Pod右側操作列下的詳情。

4. 在Pod詳情頁面右上角單擊編輯，查看Pod的YAML文件和詳細配置。

5. 在Pod詳情頁面下方單擊事件頁簽，查看Pod的事件。

   說明

   Kubernetes默認保留最近1小時的事件，若需保存更長時間的事件，請參見創建并使用K8s事件中心。

檢查Pod的日志

1. 登錄容器計算服務控制臺，在左側導航欄選擇集群。

2. 在集群頁面，單擊目標集群ID，然后在左側導航欄，選擇工作負載 > 容器組。

3. 在容器組頁面左上角選擇Pod所在的命名空間，然后單擊目標Pod名稱或者目標Pod右側操作列下的詳情。

4. 在Pod詳情頁面下方單擊日志頁簽，查看Pod的日志。

   說明

   阿里云容器計算服務ACS集群集成了日志服務，您可以在創建集群時啟用日志服務，快速采集集群的容器日志，包括容器的標準輸出及容器內的文本文件。更多信息，請參見通過Pod環境變量配置應用日志采集。

檢查Pod的監控

1. 登錄容器計算服務控制臺，在左側導航欄選擇集群。

2. 在集群頁面，單擊目標集群ID，然后在左側導航欄，選擇工作負載 > Prometheus 監控。

3. 在Prometheus監控頁面，單擊集群監控概覽頁簽，選擇查看Pod的CPU、內存、網絡I/O等監控大盤。

使用終端進入容器

1. 登錄容器計算服務控制臺，在左側導航欄選擇集群。

2. 在集群頁面，單擊目標集群ID，然后在左側導航欄，選擇工作負載 > 容器組。

3. 在容器組頁面，單擊目標容器組右側操作列下的終端。

   說明

   可通過終端進入容器，在容器內查看本地文件等信息。

Pod故障診斷

1. 登錄容器計算服務控制臺，在左側導航欄選擇集群。

2. 在集群頁面，單擊目標集群ID，然后在左側導航欄，選擇工作負載 > 容器組。

3. 在容器組頁面左上角選擇Pod所在的命名空間，然后單擊目標Pod名稱或者目標Pod右側操作列下的詳情，查看Pod的名稱、鏡像、Pod IP等詳細信息。

4. 在容器組頁面，單擊目標容器組右側操作列下的診斷。

   說明

   對該容器組進行故障診斷，根據診斷結果解決問題。更多信息，請參見使用集群診斷。

Pod狀態為Pending

問題原因

若Pod停留在Pending狀態，說明該Pod不能被調度。通常是由于資源依賴、quota不合理等原因導致集群中缺乏需要的資源。

問題現象

Pod的狀態為Pending。

解決方案

查看Pod的事件，根據事件描述，定位Pod不能被調度的原因。主要原因有以下幾類：

• 資源依賴

  創建Pod時，需要依賴于集群中ConfigMap、PVC等資源。例如，Pod添加存儲卷聲明前，存儲卷聲明需要先與存儲卷綁定。

• quota不合理

  在事件和審計日志查看。

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。

解決方案

1. 查看Pod的事件，確認當前Pod中未啟動的Init容器是否存在異常。具體操作，請參見檢查Pod的事件。

2. 查看Pod中未啟動的Init容器的日志，通過日志內容排查問題。具體操作，請參見檢查Pod的日志。

3. 查看Pod的配置，確認未啟動的Init容器配置是否正常。具體操作，請參見檢查Pod的配置。關于Init容器的更多信息，請參見調試Init容器。

Pod狀態為ImagePullBackOff

問題原因

若Pod停留在ImagePullBackOff狀態，說明此Pod已被后臺調度，但拉取鏡像失敗。

問題現象

Pod的狀態為ImagePullBackOff。

解決方案

通過查看該Pod的事件描述，查看具體拉取失敗的鏡像名稱。

1. 確認容器鏡像名稱是否正確。

2. 如果您使用的是私有鏡像倉庫，請參見使用在鏡像倉庫中存放的鏡像來創建ACS工作負載解決。

Pod狀態為CrashLoopBackOff

問題原因

若Pod停留在CrashLoopBackOff狀態，說明容器中應用程序有問題。

問題現象

Pod的狀態為CrashLoopBackOff。

解決方案

1. 查看Pod的事件，確認當前Pod是否存在異常。具體操作，請參見檢查Pod的事件。

2. 查看Pod的日志，通過日志內容排查問題。具體操作，請參見檢查Pod的日志。

3. 查看Pod的配置，確認容器中的健康檢查配置是否正常。具體操作，請參見檢查Pod的配置。關于Pod健康檢查的更多信息，請參見配置存活、就緒和啟動探測器。

Pod狀態為Completed

問題原因

若Pod出現Completed狀態，說明容器中的啟動命令已執行完畢，容器中的所有進程都已退出。

問題現象

Pod的狀態為Completed。

解決方案

1. 查看Pod的配置，確定Pod中容器的啟動命令。具體操作，請參見檢查Pod的配置。

2. 查看Pod的日志，通過日志內容排查問題。具體操作，請參見檢查Pod的日志。

Pod狀態為Running但沒正常工作

問題原因

部署使用的YAML文件有問題。

問題現象

Pod狀態為Running但沒正常工作。

解決方案

1. 查看Pod的配置，確定Pod中容器的配置是否符合預期。具體操作，請參見檢查Pod的配置。

2. 使用以下方法，排查環境變量中的某一個Key是否存在拼寫錯誤。

   以command拼寫成commnd為例，說明拼寫問題排查方法。

   說明

   創建Pod時，環境變量中的某一個Key拼寫錯誤的問題會被集群忽略，如Command拼寫為Commnd，您仍能夠使用該YAML文件創建資源。但容器運行時，不會執行有拼寫問題的YAML文件，而是執行鏡像中的默認命令。

   1. 在執行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。

   2. 執行以下命令，將輸出結果的pod.yaml文件與您創建Pod使用的文件進行對比。

        kubectl get pods [$Pod] -o yaml > pod.yaml

      說明

      [$Pod]為異常Pod的名稱，您可以通過kubectl get pods命令查看。

      • pod.yaml文件比您創建Pod所使用的文件多幾行，說明已創建的Pod符合預期。

      • 如果您創建Pod所使用文件里的代碼行在pod.yaml文件中沒有，說明您創建Pod使用的文件存在拼寫問題。

3. 查看Pod的日志，通過日志內容排查問題。具體操作，請參見檢查Pod的日志。

4. 可通過終端進入容器查看容器內的本地文件是否符合預期。具體操作，請參見使用終端進入容器。

Pod狀態為Terminating

問題原因

若Pod的狀態為Terminating，則說明此Pod正處于關閉狀態。

問題現象

Pod狀態為Terminating。

解決方案

Pod停留在Terminating狀態一段時間后會被自動刪除。若Pod一直停留在Terminating狀態，可執行如下命令強制刪除：

kubectl delete pod [$Pod] -n [$namespace] --grace-period=0 --force

Pod OOM異常問題處理

問題原因

當集群中的容器使用超過其限制的內存，容器可能會被終止，觸發OOM（Out Of Memory）事件，導致容器異常退出。關于OOM事件，請參見為容器和Pod分配內存資源。

問題現象

• 若被終止的進程為容器的阻塞進程，可能會導致容器異常重啟。

• 若出現OOM異常問題，在控制臺的Pod詳情頁面單擊事件頁簽將展示OOM事件pod was OOM killed。

解決方案

1. 通過Pod內存監控查看內存增長曲線，確定異常出現時間。具體操作，請參見檢查Pod的監控。

2. 根據監控、內存增長時間點、日志、進程名等信息，排查Pod內對應進程是否存在內存泄漏。

   • 若OOM是進程內存泄漏導致，請您自行排查泄露原因。

   • 若進程運行狀態正常，則根據實際運行需要，適當增大Pod的內存限制，建議Pod的內存實際使用量不超過內存限制值的80%。具體操作，請參見管理容器組。