Pod異常問題排查SOP -

本文介紹關於Pod異常問題排查的診斷流程、排查方法、常見問題及對應的解決方案。

說明

如果您需要瞭解排查Pod問題常用的控制台介面，例如如何查看Pod狀態、基礎資訊、配置、事件和日誌，使用終端進入容器，啟用Pod故障診斷等，可跳轉至常用排查介面瞭解。

診斷流程

如果Pod狀態異常，可通過查看Pod的事件、Pod的日誌、Pod的配置等資訊確定異常原因。大體排查流程如下。

階段一：調度問題

Pod未調度到節點

如果Pod長時間處於“未調度到節點”（Pending）狀態，沒有被安排到任何節點上運行，可能是出於以下原因。

報錯資訊	說明	推薦的解決方案
`no nodes available to schedule pods.`	當前叢集中無可用節點可供調度。	查看叢集節點狀態是否為NotReady。如果存在節點處於NotReady狀態，則對問題節點進行檢查和修複。檢查Pod中是否聲明了nodeSelector、nodeAffinity或汙點容忍。若不存在親和性策略，可以增加節點池中的節點數量。
`0/x nodes are available: x Insufficient cpu.` `0/x nodes are available: x Insufficient memory.`	叢集中沒有可用節點能夠滿足Pod所需的CPU或記憶體資源。	在節點頁面查看容器組、CPU、記憶體的使用方式，確定叢集的資源使用率。說明當某個節點的CPU和記憶體利用率維持在較低水平時，即便引入一個新Pod不會立即達到資源使用的上限，調度器也會謹慎考慮，以防該Pod的加入導致未來高峰時段節點資源緊張，避免因資源分派不當而引發的節點資源短缺問題。若叢集中的CPU或記憶體已經耗盡，可參考如下方法處理。刪除或減少不必要的Pod，請參見管理容器組（Pod）。根據自身業務情況，調整Pod的資源配置，請參見設定容器的CPU和記憶體資源上下限。您可以啟用資源畫像，獲得容器Request和Limit的推薦配置。根據Pod聲明的親和性策略在叢集中添加新的節點，請參見建立節點池。升配節點，請參見升配Worker節點的資源。
`x node(s) didn't match node selector.` `x node(s) didn't match pod affinity/anti-affinity.`	叢集現有節點沒有匹配Pod聲明的節點親和性（nodeSelector）要求或Pod親和性（podAffinity和podAnitiAffinity）要求。	檢查並調整Pod的節點親和性策略，包括節點標籤、nodeSelector、nodeAffinity、汙點和容忍等。檢查並調整Pod的Pod親和性策略，評估節點是否滿足Pod的親和性要求：如果Pod配置了podAffinity，則需要檢查目標節點上是否有匹配的Pod存在；如果配置了podAntiAffinity，則需確認目標節點上沒有不應共存的Pod。
`0/x nodes are available: x node(s) had volume node affinity conflict.`	Pod所使用的儲存卷與待調度的節點之間存在親和性衝突，雲端硬碟無法跨可用性區域掛載，導致調度失敗。	若為靜態PVC，希望Pod能夠調度到與PV所在相同可用性區域的節點，需配置Pod的節點親和性。若為動態PVC，需設定StorageClass的雲端硬碟的繫結模式為WaitForFirstConsumer，以便PV等到Pod已調度到節點後再建立，確保雲端硬碟被建立在Pod實際啟動並執行節點所在的可用性區域。
`InvalidInstanceType.NotSupportDiskCategory`	ECS執行個體不支援掛載的雲端硬碟類型。	請參見執行個體規格類型系列確認當前ECS支援的雲端硬碟類型。掛載時，將雲端硬碟類型更新為ECS執行個體當前支援的類型。
`0/x nodes are available: x node(s) had taints that the pod didn't tolerate.`	需要調度的節點打上了汙點，不允許Pod調度到該節點上。	如果汙點是由您手動添加，您可以刪除非預期的汙點。如果無法刪除汙點，可以為Pod配置相應的容忍，請參見汙點和容忍、管理節點汙點。如果汙點為系統自動添加，您可以參見下文解決對應的問題，並等待Pod重新調度。展開查看系統自行添加的汙點 `node.kubernetes.io/not-ready`：節點未準備好，處於NotReady狀態。 `node.kubernetes.io/unreachable`：節點控制器訪問不到節點，相當於節點狀況`Ready` 的值為`Unknown`。 `node.kubernetes.io/memory-pressure`：節點存在記憶體壓力。 `node.kubernetes.io/disk-pressure`：節點存在磁碟壓力。 `node.kubernetes.io/pid-pressure`：節點存在PID壓力。 `node.kubernetes.io/network-unavailable`：節點網路不可用。 `node.kubernetes.io/unschedulable`：節點不可調度。
`0/x nodes are available: x Insufficient ephemeral-storage.`	節點臨時儲存容量不足。	檢查Pod是否配置了臨時儲存卷的限制，即Pod YAML中`spec.containers.resources.request.ephemeral-storage`的取值。如果取值過高，超出了節點的實際可用容量，Pod會調度失敗。執行`kubectl describe node \| grep -A10 Capacity`命令，查看各個節點上可用於臨時儲存的總容量。如果容量不足，可擴容節點磁碟或增加節點數量。
`0/x nodes are available: pod has unbound immediate PersistentVolumeClaims.`	Pod綁定PVC失敗。	檢查Pod所指定的PVC或PV是否已經建立，通過`kubectl describe pvc <pvc-name>` 或 `kubectl describe pv <pv-name>`命令查看PVC、PV的Event資訊，進一步進行判斷。更多資訊，請參見Pod的Event提示0/x nodes are available: x pod has unbound immediate PersistentVolumeClaims。

Pod已調度到節點

如果Pod已經被調度到某個節點上但仍處於Pending狀態，請參見下文解決。

判斷Pod是否配置了hostPort：如果Pod配置了hostPort，那麼每個節點上只能運行一個使用該hostPort的Pod執行個體。因此，Deployment或ReplicationController中Replicas值不能超過叢集中的節點數。如果該連接埠被其他應用佔用，將導致Pod調度失敗。
hostPort會帶來一些管理和調度上的複雜性，推薦您使用Service來訪問Pod，請參見服務（Service）。
如果Pod沒有配置hostPort，請參見下方步驟排查。
1. 通過kubectl describe pod <pod-name>命令查看Pod的Event資訊，並解決對應的問題。Event可能會解釋Pod啟動失敗的原因，例如鏡像拉取失敗、資源不足、安全性原則限制、配置錯誤等。
2. Event中沒有有效資訊時，進一步查看該節點kubelet的日誌，進一步排查Pod啟動過程中存在的問題。您可以通過grep -i <pod name> /var/log/messages* | less命令搜尋系統記錄檔（/var/log/messages*）中包含指定Pod名稱的日誌條目。

階段二：鏡像拉取問題

報錯資訊	說明	推薦的解決方案
`Failed to pull image "xxx": rpc error: code = Unknown desc = Error response from daemon: Get xxx: denied:`	請求訪問鏡像倉庫時被拒絕，建立Pod時未指定`imagePullSecret`。	檢查Pod YAML中`spec.template.imagePullSecrets`指定的Secret是否存在。使用ACR時，可以使用免密外掛程式拉取鏡像，請參見使用免密組件拉取容器鏡像。
`Failed to pull image "xxxx:xxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxx/xxxxx/: dial tcp: lookup xxxxxxx.xxxxx: no such host`	通過HTTPS協議從指定的鏡像倉庫地址拉取鏡像時，鏡像位址解析失敗。	檢查Pod YAML中`spec.containers.image`配置的鏡像倉庫地址是否正確。如有誤，需修改為正確地址。如地址無誤，進一步驗證從Pod所在節點到鏡像倉庫的網路連接是否通暢。參見ECS遠端連線方式概述登入到Pod所在節點，運行cmd命令`curl -kv https://xxxxxx/xxxxx/` 判斷地址是否可以訪問。如有報錯，進一步判斷是否存在網路設定、防火牆規則、DNS解析等網路訪問問題。
`Failed create pod sandbox: rpc error: code = Unknown desc = failed to create a sandbox for pod "xxxxxxxxx": Error response from daemon: mkdir xxxxx: no space left on device`	節點磁碟空間不足。	參見ECS遠端連線方式概述登入到Pod所在節點，運行`df -h`查看磁碟空間狀態。如磁碟已滿，請擴容磁碟，請參見步驟一：擴容雲端硬碟容量。
`Failed to pull image "xxx": rpc error: code = Unknown desc = error pulling image configuration: xxx x509: certificate signed by unknown authority`	第三方倉庫使用了非知名或不安全的CA簽署的認證。	建議三方倉庫更改使用CA簽發的認證。如果您使用的是私人鏡像倉庫，請參見使用私人鏡像倉庫建立應用。如果無法更改，可酌情參考下面流程，配置允許節點從使用非安全性憑證的倉庫中拉取和推送鏡像。建議僅在測試環境中使用，可能會對節點其他Pod的運行產生影響。展開查看詳細步驟為containerd建立認證目錄，用於存放與特定鏡像倉庫相關的認證設定檔。 `$ mkdir -p /etc/containerd/cert.d/xxxxx` 配置containerd信任特定的非安全鏡像倉庫。 `$ cat << EOF > /etc/containerd/cert.d/xxxxx/hosts.toml server = "https://harbor.test-cri.com" [host."https://harbor.test-cri.com"] capabilities = ["pull", "resolve", "push"] skip_verify = true # ca = "/opt/ssl/ca.crt" # 或者上傳ca認證 EOF` 修改Docker Daemon配置以添加非安全倉庫。 `vi /etc/docker/daemon.json` 添加以下內容。其中需替換`your-insecure-registry`為目標私人倉庫地址。 `{ "insecure-registries": ["your-insecure-registry"] }` 重啟相關服務，使更新的配置生效。 `systemctl restart systemd systemctl restart docker`
`Failed to pull image "XXX": rpc error: code = Unknown desc = context canceled`	操作取消，可能是由於鏡像檔案過大。Kubernetes預設存在拉取鏡像逾時時間，如果一定時間內鏡像下載沒有任何進度更新，Kubernetes會認為此操作異常或處於無響應狀態，主動取消該任務。	檢查Pod YAML中配置的`imagePullPolicy`是否為`IfNotPresent`。參見ECS遠端連線方式概述登入到Pod所在節點，運行cmd命令`docker pull`或`ctr images pull`判斷鏡像是否可以被拉取。
`Failed to pull image "xxxxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxxx: xxxxx/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)`	無法串連鏡像倉庫，網路不通。	參見ECS遠端連線方式概述登入到Pod所在節點，運行cmd命令`curl https://xxxxxx/xxxxx/`判斷地址是否可以訪問。如有報錯，進一步判斷是否存在網路設定、防火牆規則、DNS解析等網路訪問問題。判斷節點的公網策略是否正常，例如SNAT條目、綁定的Elastic IP Address等配置。
`Too Many Requests.`	DockerHub對使用者拉取容器鏡像的請求設定了上限。	將鏡像上傳至Container RegistryACR，從ACR鏡像倉庫中拉取鏡像。
一直顯示`Pulling image`	可能觸發了kubelet的鏡像拉取限流機制。	通過自訂節點池kubelet配置功能調整registryPullQPS（鏡像倉庫的QPS上限）和registryBurst（突發性鏡像拉取的個數上限）。

階段三：啟動問題

Pod處於init狀態

錯誤資訊	說明	推薦的解決方案
停留在`Init:N/M`狀態	該Pod包含M個Init容器，其中N個已經啟動完成，但仍有M-N個Init容器未啟動成功。	通過`kubectl describe pod -n <ns> <pod name>`命令查看Pod的事件，確認當前Pod中未啟動的Init容器是否存在異常。通過`kubectl logs -n <ns> <pod name> -c <container name>`命令查看Pod中未啟動的Init容器的日誌，通過日誌內容排查問題。查看Pod的配置，例如檢查健全狀態檢查配置，進一步確認未啟動的Init容器配置是否正常。關於Init容器的更多資訊，請參見調試Init容器。
停留在`Init:Error`狀態	Pod中的Init容器啟動失敗。
停留在`Init:CrashLoopBackOff`狀態	Pod中的Init容器啟動失敗並處於反覆重啟狀態。

Pod建立中（Creating）

錯誤資訊	說明	推薦的解決方案
`failed to allocate for range 0: no IP addresses available in range set: xx.xxx.xx.xx-xx.xx.xx.xx`	Flannel網路外掛程式設計原因，是預期內現象。	升級Flannel組件版本至v0.15.1.11-7e95fe23-aliyun及以上版本，請參見Flannel。
	叢集低於1.20版本時，如果發生Pod反覆重啟、CronJob中的Pod在短時間內完成任務並退出等事件，可能會導致IP地址泄漏。	升級叢集版本至1.20及以上，推薦使用最新版本的叢集，請參見手動升級叢集。
	containerd、runC存在的缺陷。	參見為什麼Pod無法正常啟動，且報錯no IP addresses available in range？進行臨時緊急處理。
`error parse config, can't found dev by mac 00:16:3e:01:c2:e8: not found`	Pod所在的節點中，Terway網路外掛程式維護的用於追蹤和管理網路介面ENI的內部資料庫狀態與實際的網路裝置配置之間存在資料不一致，造成ENI分配失敗。	網卡在系統中載入是非同步。在CNI配置過程中，網卡可能仍在載入中，可能導致CNI自動重試。這種情況不會影響ENI最終的分配，請通過Pod最終狀態判斷操作是否成功。如果Pod長時間沒有建立成功，仍然提示上述錯誤，通常是由於ENI掛載時高階記憶體不足導致驅動載入失敗。請通過重啟ECS執行個體來解決，請參見重啟執行個體。
`cmdAdd: error alloc ip rpc error: code = DeadlineExceeded desc = context deadline exceeded` `cmdAdd: error alloc ip rpc error: code = Unknown desc = error wait pod eni info, timed out waiting for the condition`	可能是Terway向vSwitch申請IP時失敗。	查看Pod所在節點中Terway組件Pod的Terway容器日誌，查看ENI分配過程。執行`kubectl logs -n kube-system <terwayPodName > -c terway \| grep <podName>`命令，查看Terway Pod中Terway網卡的ENI情況，擷取到申請IP操作的Request ID以及OpenAPI的報錯資訊。根據Request ID和報錯資訊進一步排查失敗的原因。

Pod啟動失敗（CrashLoopBackOff）

錯誤資訊	說明	推薦的解決方案
日誌中存在`exit(0)`。		登入異常工作負載所在的節點。執行`docker ps -a \| grep $podName`命令，如果容器中無持續進程，會出現`exit (0)`。
Event資訊中存在`Liveness probe failed: Get http…`。	健全狀態檢查失敗。	核查Pod中所配置的容器健全狀態檢查（Liveness Probe）策略是否符合預期，能有效地反映出容器內應用程式的實際健全狀態。
Pod日誌中存在`no left space`。	磁碟空間不足。	參見步驟一：擴容雲端硬碟容量擴容磁碟。清理不必要的鏡像，釋放磁碟空間，並按需配置imageGCHighThresholdPercent，控制節點上觸發鏡像記憶體回收（Image GC）的閾值。
啟動失敗，無Event資訊。	Pod中聲明的Limit資源少於實際所需資源時，會導致啟動容器失敗。	檢查Pod的資源配置是否正確。您可以啟用資源畫像，獲得容器Request和Limit的推薦配置。
Pod日誌中出現`Address already in use`。	同一Pod中的Container連接埠存在衝突。	檢查Pod是否配置了`hostNetwork: true`，這意味著Pod內的容器會直接與宿主機共用網路介面和連接埠空間。如果無需使用，請改為`hostNetwork: false`。如果Pod需要使用`hostNetwork: true`，請配置Pod的反親和性，確保同一複本集中的Pod被調度到不通節點。檢查並確保不存在也不會有兩個或多個具有相同連接埠需求的Pod運行在同一台節點上。
Pod日誌中出現`container init caused \"setenv: invalid argument\"": unknown`。	工作負載中掛載了Secret，但Secret對應的值沒有進行Base64加密。	通過控制台建立Secret，Secret對應的值會自動進行Base64加密。具體操作，請參見管理保密字典。通過YAML建立Secret，並執行`echo -n "xxxxx" \| base64`命令手動對密鑰值進行Base64加密。
自身業務問題。		查看Pod日誌，通過日誌內容排查問題。

階段四：Pod運行問題

OOM

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

若被終止的進程為容器的阻塞進程，可能會導致容器異常重啟。
若出現OOM異常問題，在控制台的Pod詳情頁面單擊事件頁簽將展示OOM事件pod was OOM killed。
若叢集配置了叢集容器副本異常警示，OOM事件出現時會收到相關警示資訊，請參見Container Service警示管理。

OOM層級	說明	推薦的解決方案
OS層級	查看Pod所在節點的核心日誌`/var/log/messages`，日誌中存在Killed Process，但不存在cgroup日誌，表明OOM為OS層級。	可能是系統全域記憶體不足、記憶體節點的記憶體不足或記憶體片段化時夥伴系統記憶體不足。關於不同現象可能出現的原因，請參見可能原因；關於問題對應的解決方案，請參見解決方案。
cgroup層級	查看Pod所在節點的核心日誌`/var/log/messages`，日誌中存在類似`Task in /kubepods.slice/xxxxx killed as a result of limit of /kubepods.slice/xxxx`的報錯資訊，表明OOM為cgroup層級。	若進程運行狀態正常，則根據實際運行需要，適當增大Pod的記憶體Limit，建議Pod的記憶體實際使用量不超過記憶體Limit取值的80%。具體操作，請參見設定容器的CPU和記憶體資源上下限。您可以啟用資源畫像，獲得容器Request和Limit的推薦配置。

Terminating

可能原因	說明	推薦的解決方案
節點存在異常，處於NotReady狀態。		處於NotReady狀態的節點恢複正常後會被自動刪除。
Pod配置了Finalizers。	如果Pod配置了Finalizers，Kubernetes會在刪除Pod之前執行Finalizers指定的清理操作。如果相關的清理操作沒有正常響應，Pod將保持在Terminating狀態。	通過`kubectl get pod -n <ns> <pod name> -o yaml`查看Pod的Finalizers配置，進一步排查異常原因。
Pod的preStop配置異常。	如果Pod配置了preStop，Kubernetes會在容器被終止之前執行preStop指定的操作。Pod正處於終止流程的preStop階段時，Pod將處於Terminating狀態。	通過`kubectl get pod -n <ns> <pod name> -o yaml`查看Pod的preStop配置，進一步排查異常原因。
Pod配置了優雅退出時間。	如果Pod配置了優雅退出時間（`terminationGracePeriodSeconds`），Pod收到終止命令後（例如`kubectl delete pod <pod_name>`命令）會進入Terminating狀態。等待`terminationGracePeriodSeconds`設定的時間後，或容器提前退出後，Kubernetes才認為Pod已經成功關閉。	等待容器優雅退出後，Kubernetes將自動刪除Pod。
容器無響應。	發起停止或刪除Pod的請求後，Kubernetes會向Pod內的容器發送`SIGTERM`訊號。如果容器在終止過程中沒有正確響應`SIGTERM`訊號，Pod可能會停留在Terminating狀態。	使用`kubectl delete pod <pod-name> --grace-period=0 --force`強制移除，釋放Pod資源。檢查Pod所在節點的containerd或Docker日誌，進一步進行排查。

Evicted

可能原因	說明	推薦的解決方案
節點存在資源壓力，包括記憶體不足、磁碟空間不足等，引發kubelet主動驅逐節點上的一個或者多個Pod，以回收節點資源。	可能存在記憶體壓力、磁碟壓力、Pid壓力等。可以通過`kubectl describe node <node name> \| grep Taints`命令查詢。記憶體壓力：帶有汙點`node.kubernetes.io/memory-pressure`。磁碟壓力：帶有汙點`node.kubernetes.io/disk-pressure`。 Pid壓力：帶有汙點`node.kubernetes.io/pid-pressure`。	記憶體壓力：根據自身業務情況，調整Pod的資源配置，管理容器組（Pod）。升配節點，請參見升配Worker節點的資源。磁碟壓力：定時清理節點上的業務Pod日誌，防止磁碟空間被耗盡。為節點進行磁碟擴容，請參見步驟一：擴容雲端硬碟容量。 Pid壓力：根據自身業務情況，調整Pod的資源配置，請參見進程ID約束與預留。
發生了非預期的驅逐行為。	待運行Pod的節點被手動打上了NoExecute的汙點，導致出現非預期的驅逐行為。	通過`kubectl describe node <node name> \| grep Taints`命令檢查節點是否被打上了NoExecute汙點。如是，請刪除。
未按照預期流程執行驅逐。	`--pod-eviction-timeout`：當節點宕機時間超過設定時間後，開始驅逐宕機節點上的Pod，預設為5min。 `--node-eviction-rate`：每秒從節點上驅逐的Pod數量。預設為0.1，即每10s至多從一個節點上驅逐Pod。 `--secondary-node-eviction-rate`：第二檔的節點驅逐速率。當叢集中宕機節點過多時，節點驅逐速率會降低至第二檔，預設值為0.01。 `--unhealthy-zone-threshold`：可用性區域的不健康閾值，預設為0.55，即當宕機的節點數量超過總節點數的55%時，該可用性區域被判定為不健康。 `--large-cluster-size-threshold`：叢集的大規模閾值，預設為50，即當叢集節點數量超過50時判定叢集為大規模叢集。	在小規格的叢集（叢集節點數小於等於50個節點）中，如果故障的節點大於總節點數的55%，執行個體的驅逐會被停止，更多資訊請參見節點驅逐速率限制。
未按照預期流程執行驅逐。		在大規模叢集中（叢集節點數大於50），如果叢集中不健康的節點數量佔總節點數的比例超過了預設的閾值`--unhealthy-zone-threshold`（預設為0.55），驅逐速率由`--secondary-node-eviction-rate`控制（代表每分鐘驅逐節點上Pod的最大比例），預設值為0.01。更多資訊，請參見節點驅逐速率限制。
容器被驅逐後仍然頻繁調度到原節點。	節點驅逐容器時會根據節點的資源使用率進行判斷，而容器的調度規則是根據節點上的“資源分派量”進行判斷，被驅逐的Pod有可能被再次調度到這個節點，從而出現頻繁調度到原節點的現象。	根據叢集節點的可分配資源檢查Pod的資源Request請求配置是否合理。如需調整，請參見設定容器的CPU和記憶體資源上下限。您可以啟用資源畫像，獲得容器Request和Limit的推薦配置。

Completed

Completed狀態下，Pod中容器的啟動命令已執行完畢，容器中的所有進程均已成功退出。Completed狀態通常適用於Job、Init容器等。

其他常見問題

Pod狀態為Running但沒正常工作

如果您的業務YAML存在問題，Pod可能會處於Running狀態但沒有正常工作。您可以參見以下流程解決。

查看Pod的配置，確定Pod中容器的配置是否符合預期。
使用以下方法，排查環境變數中的某一個Key是否存在拼字錯誤。
建立Pod時，如果環境變數中的某個Key拼字錯誤（例如將command拼字為commnd），叢集會忽略該錯誤並使用該YAML成功建立資源。但在容器運行過程中，系統無法執行YAML檔案中指定的命令。
下文以command拼字成commnd為例，介紹拼字問題的排查方法。
1. 在執行kubectl apply -f命令前為其添加--validate，然後執行kubectl apply --validate -f XXX.yaml 命令。
  如拼字存在錯誤，會提示報錯XXX] unknown field: commnd XXX] this may be a false alarm, see https://gXXXb.XXX/6842pods/test。
2. 執行以下命令，將輸出結果的pod.yaml與您建立Pod使用的YAML進行對比。
  說明
  [$Pod]為異常Pod的名稱，您可以通過kubectl get pods命令查看。
```
  kubectl get pods [$Pod] -o yaml > pod.yaml
```
  - pod.yaml檔案比您建立Pod所使用的檔案行數更多，表明已建立的Pod符合預期。
  - 如果您建立Pod的YAML程式碼不存在於pod.yaml檔案中，表明YAML中存在拼字問題。
查看Pod的日誌，通過日誌內容排查問題。
通過終端進入容器，查看容器內的本地檔案是否符合預期。

Pod訪問資料庫機率性網路斷聯

針對ACK叢集中Pod訪問資料庫有機率性網路斷聯的問題，可以按照以下步驟進行排查。

1、檢查Pod

查看目的地組群中該Pod的事件記錄，檢查是否存在串連不穩定的例外狀況事件，例如網路異常、重啟事件、資源不足等。
查看Pod的日誌輸出，確定是否有與資料庫連接相關的錯誤資訊，例如逾時、認證失敗或者重連機制觸發等。
查看Pod的CPU和記憶體使用量情況，避免資源耗盡導致應用程式或資料庫驅動程式異常退出。
查看Pod的資源Request和Limit配置，確保Pod分配了足夠的CPU和記憶體資源。

2、檢查節點

查看節點的資源使用方式，確認是否有記憶體、磁碟等資源不足等情況。具體操作，請參見監控節點。
測試節點到與目標資料庫之間是否出現機率性網路斷聯。

3、檢查資料庫

檢查資料庫的狀態和效能指標，是否出現重啟或效能瓶頸。
查看異常串連數和連線逾時設定，並根據業務需求進行調整。
檢查日誌資料庫是否有相關中斷連線的日誌。

4、檢查叢集組件狀態

叢集組件異常會影響Pod與叢集內其他組件的通訊。使用如下命令，檢查ACK叢集組件狀態。

kubectl get pod -n kube-system  # 查看組件Pod狀態。

同時檢查網路組件：

CoreDNS組件：檢查組件狀態和日誌，確保Pod能正常解析資料庫服務的地址。
Flannel外掛程式：查看kube-flannel組件的狀態和日誌。
Terway外掛程式：查看terway-eniip組件的狀態和日誌。

5、分析網路流量

您可以使用 tcpdump 來抓包並分析網路流量，以協助定位問題的原因。

使用以下命令確定資料庫連接斷開問題發生在哪個Pod和哪個節點上。
```
kubectl  get pod -n [namespace] -o wide 
```

登入到目標節點，請參見ECS遠端連線方式概述。

使用以下命令，分別擷取不同版本的容器進程PID。

containerd（1.22以上叢集）

執行以下命令查看容器CONTAINER。

crictl ps |grep <Pod名稱關鍵字>

預期輸出：

CONTAINER           IMAGE               CREATED             STATE                      
a1a214d2*****       35d28df4*****       2 days ago          Running

使用CONTAINER ID參數，執行以下命令查看容器PID

crictl inspect  a1a214d2***** |grep -i PID

預期輸出：

    "pid": 2309838,    # 目標容器的PID進程號。
            "pid": 1
            "type": "pid"

Docker（1.22及以下叢集）

執行以下命令查看容器CONTAINER ID。

docker ps |grep <pod名稱關鍵字>

預期輸出：

CONTAINER ID        IMAGE                  COMMAND     
a1a214d2*****       35d28df4*****          "/nginx

使用CONTAINER ID參數，執行以下命令查看容器PID。

docker inspect  a1a214d2***** |grep -i PID

預期輸出：

            "Pid": 2309838,  # 目標容器的PID進程號。
            "PidMode": "",
            "PidsLimit": null,

執行抓包命令。
使用擷取到的容器PID，執行以下命令，捕獲Pod與目標資料庫之間的網路通訊資料包。
```
nsenter -t <容器PID> tcpdump -i any -n -s 0 tcp and host <資料庫IP地址> 
```
使用擷取到的容器PID，執行以下命令，捕獲Pod與宿主機之間的網路通訊資料包。
```
nsenter -t <容器PID> tcpdump -i any -n -s 0 tcp and host <節點IP地址>
```
執行以下命令，捕獲宿主機與資料庫之間的網路通訊資料包。
```
tcpdump -i any -n -s 0 tcp and host <資料庫IP地址> 
```

6、最佳化商務應用程式

在商務應用程式中實現資料庫連接的自動重連機制，確保資料庫發生切換或遷移時，應用程式能夠自動回復串連，無需人工幹預。
使用持久化的長串連而非短串連來與資料庫通訊。長串連能顯著降低效能損耗和資源消耗，提高系統整體效率。

常用排查介面

您可以登入Container Service管理主控台，進入叢集的詳情頁面，排查Pod可能存在的問題。

操作	控制台介面
檢查Pod的狀態	在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇工作負載 > 容器組。在容器組頁面左上方選擇Pod所在的命名空間，查看Pod狀態。若狀態為Running，表明Pod運行正常。若狀態不為Running，表明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叢集整合了Log ServiceSLS。您可在叢集中啟用SLS，快速採集叢集的容器日誌，請參見通過DaemonSet採集Kubernetes容器文本日誌。
檢查Pod的監控	在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇營運管理 > Prometheus 監控。在Prometheus監控頁面，單擊叢集監控概覽頁簽，選擇查看Pod的CPU、記憶體、網路I/O等監控大盤。說明 ACK叢集整合了阿里雲Prometheus。您可以在叢集中快速啟用阿里雲Prometheus，以即時監控叢集和容器的健康情況，並查看可視化的Grafana監控資料大盤，請參見使用阿里雲Prometheus監控。
使用終端進入容器，進入容器內部查看本地檔案等資訊	在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇工作負載 > 容器組。在容器組頁面，單擊目標容器組右側操作列下的終端。
啟用Pod故障診斷	在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇工作負載 > 容器組。在容器組頁面，單擊目標容器組右側操作列下的診斷，對該容器組進行故障診斷，根據診斷結果解決問題。說明容器智能營運平台提供了一鍵故障診斷能力，輔助您定位叢集中出現的問題，請參見使用叢集診斷。