Pod異常問題排查
本文介紹關于Pod異常問題的診斷流程、排查方法、常見問題及解決方案。
排查流程
1、首先需查看Pod是否處于異常狀態，具體操作請參見下文【 檢查Pod的狀態 】相關章節
2、如果Pod狀態異常，可通過在容器服務控制臺查看Pod事件、Pod日志、Pod配置等信息確定異常原因
3、如果Pod狀態為Running但并未正常工作，請參見下文【 Pod狀態為Running但沒正常工作 】章節
4、若確認Pod狀態異常是由Pod OOM所致，請參見【 Pod OOM異常問題處理 】章節
5、如果根據本文的操作說明問題仍未解決，請提交工單申請售后服務
常規排查方法
檢查Pod的狀態
1、登錄控制臺
2、在控制臺左側導航欄，單擊集群
3、在集群列表頁面，單擊目標集群名稱
4、在集群管理頁左側導航欄，選擇工作負載 > 容器組
5、在容器組頁面頂部選擇Pod所在的 命名空間 ，查看Pod狀態。若狀態為Running，說明Pod運行正常。若狀態不為Running，說明Pod狀態異常
檢查Pod的詳情
1、登錄控制臺
2、在控制臺左側導航欄，單擊集群
3、在集群列表頁面，單擊目標集群名稱
4、在集群管理頁左側導航欄，選擇工作負載 > 容器組
5、在容器組頁面頂部選擇Pod所在的命名空間，然后單擊目標Pod名稱，查看Pod的名稱、鏡像、Pod IP、所在節點等詳細信息
檢查Pod的配置
1、登錄控制臺
2、在控制臺左側導航欄，單擊集群
3、在集群列表頁面，單擊目標集群名稱或者目標集群右側操作列下的詳情
4、在集群管理頁左側導航欄，選擇工作負載 > 容器組
5、在容器組頁面左上角選擇Pod所在的命名空間，然后單擊目標Pod名稱或者目標Pod右側操作列下的詳情
6、在Pod詳情頁面右上角單擊編輯，查看Pod的YAML文件和詳細配置
檢查Pod的事件
1、登錄控制臺
2、在控制臺左側導航欄，單擊集群-運維管理-事件中心
3、在時間列表頁面選擇查詢選項，類型選擇為pod，選擇命名空間和名稱選項
4、點擊查詢按鈕查看pod事件
檢查Pod的日志
1、登錄控制臺
2、在控制臺左側導航欄，單擊集群-運維管理-日志中心
3、日志中心需要使用ctg-log-operator插件支持，若未安裝插件，根據頁面提示安裝ctg-log-operator插件
4、在日志中心頁面，切換到應用日志標簽頁，依次選擇命名空間、負載類型、負載名稱、開始結束時間，然后點擊搜索按鈕查看Pod的日志
檢查Pod的監控
1、登錄控制臺
2、在控制臺左側導航欄，單擊集群-運維管理-監控
3、監控功能需要使用ccse-monitor插件支持，若未安裝插件，根據頁面提示安裝ccse-monitor插件
4、在集群健康頁面，選擇查看Pod的CPU、內存、網絡I/O等監控大盤
使用終端進入容器
1、登錄控制臺
2、在控制臺左側導航欄，單擊集群
3、在集群列表頁面，單擊目標集群名稱或者目標集群右側操作列下的詳情
4、在集群管理頁左側導航欄，選擇工作負載> 容器組
5、在容器組頁面，單擊目標容器組右側遠程登陸
6、可通過終端進入容器，在容器內查看本地文件等信息
Pod狀態為Pending
問題現象：Pod長期處于Pending狀態。
問題原因：Pod長期處于Pending狀態是因為Pod不能被調度到某一個節點上。通常是由于資源依賴、資源不足、該Pod使用了hostPort、污點和容忍等原因導致集群中缺乏需要的資源。
解決方案：通過查看Pod的事件定位Pod不能被調度到節點的原因，常見的原因有以下幾類：
1、存在資源依賴。創建Pod時，需要依賴于集群中ConfigMap、PVC等資源。例如，Pod添加存儲卷聲明前，存儲卷聲明需要先與存儲卷綁定。
2、資源不足。在集群信息頁面，查看節點CPU、內存的使用情況，確定集群的資源使用率。若集群中的CPU或內存都已經耗盡，可參考如下方法處理：
- 調整deployment資源類型副本數量
- 調整Pod的資源配置
- 為集群添加新的節點
- 為節點進行升配
3、使用了hostPort，使用hostPort會導致因端口新占用導致Pod新副本無法調度到節點，改為通過Service訪問Pod。
4、污點和容忍。當在Pod的事件中看到Taints或Tolerations時，說明是由于污點導致，可以刪除污點或者給Pod設置容忍。
Pod狀態為ImagePullBackOff
問題現象: Pod的狀態為ImagePullBackOff。
問題原因: Pod使用的鏡像拉取失敗，可能因鏡像地址錯誤，或者遇到網絡問題，導致鏡像無法拉取。
解決方案: 查看Pod的事件描述，找到無法拉取的鏡像地址，確認容器鏡像地址是否正確。若地址無誤，登錄到Pod所在的節點，手動執行docker pull 命令看鏡像是否能正常拉取。
Pod狀態為CrashLoopBackOff
問題現象: Pod的狀態為CrashLoopBackOff。
問題原因: Pod中的應用負載啟動失敗所致。
解決方案: 1、查看Pod的日志，定問題原因。2、查看Pod的存活探針和就緒探針配置是否正確。
Pod狀態為Completed
問題現象: Pod的狀態為Completed。
問題原因: Pod中的應用程序正常執行后退出，若應用行為不符合預期則需要排查。
解決方案: 1、查看Pod配置，檢查Pod中容器的啟動命令是否正確。2、通過Pod日志定位問題。
Pod狀態為Running但沒正常工作
問題原因: 部署使用的YAML文件有問題。
問題現象: Pod狀態為Running但沒正常工作。
解決方案: 1、查看Pod的配置，確定應用的啟動參數是否存在問題。2、檢查Pod的環境變量配置是否存在問題。3、查看Pod的日志，通過日志內容排查問題。4、通過控制臺提供的遠程登陸功能進入到容器內部排查
Pod狀態為Terminating
問題現象：Pod狀態為Terminating。
問題原因：Pod正處于關閉狀態。
解決方案：若Pod一直停留在Terminating狀態，可執行如下命令強制刪除：
kubectl delete pod -n --grace-period=0 --force
Pod狀態為Evicted
問題現象：Pod的狀態為Evicted。
問題原因：當節點的內存、磁盤空間、文件系統的inode和操作系統可分配的PID等資源中的一個或者多個達到特定的消耗水平，節點的kubelet進程就會主動地驅逐一到多個Pod，以回收節點資源。
解決方案：
1、執行以下命令，查看Pod的status.message字段，來確定Pod被驅逐的原因。
kubectl get pod -o yaml -n
2、執行以下命令，刪除被驅逐的Pod。
kubectl get pods -n | grep Evicted | awk '{print $1}' | xargs kubectl delete pod -n
Pod OOM異常問題處理
問題現象：容器異常重啟，并重啟次數較多
問題原因：Pod使用超過其限制的內存
解決方案：
1、確定發生OOM異常的Pod所在的節點
2、登錄Pod所在的Node，查看系統日志文件/var/log/message，搜索out of memory關鍵字，確認具體被OOM終止時間點和進程名稱
3、根據Pod的內存監控數據，排查Pod內應用進程否存在內存泄漏。若應用進程存在內存泄漏導致需客戶自行修正程序漏洞。若進程運行狀態正常，則根據實際運行需要，適當增大Pod的內存限制
