日本熟妇hd丰满老熟妇,中文字幕一区二区三区在线不卡 ,亚洲成片在线观看,免费女同在线一区二区

AI 助理
備案控制臺
文檔
輸入文檔關鍵字查找
首頁 容器服務 Kubernetes 版 ACK ACK托管與專有集群 操作指南 應用管理 Pod異常問題排查

Pod異常問題排查

更新時間：
產品詳情
我的收藏

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

說明

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

診斷流程

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

image

階段一：調度問題

Pod未調度到節點

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

報錯信息

說明

推薦的解決方案

no nodes available to schedule pods.

當前集群中無可用節點可供調度。

  1. 查看集群節點狀態是否為NotReady。如果存在節點處于NotReady狀態，則對問題節點進行檢查和修復。

  2. 檢查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或內存已經耗盡，可參考如下方法處理。

  • x node(s) didn't match node selector.

  • x node(s) didn't match pod affinity/anti-affinity.

集群現有節點沒有匹配Pod聲明的節點親和性（nodeSelector）要求或Pod親和性（podAffinity和podAnitiAffinity）要求。

  1. 檢查并調整Pod的節點親和性策略，包括節點標簽、nodeSelector、nodeAffinity、污點和容忍等。

  2. 檢查并調整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.

節點臨時存儲容量不足。

  1. 檢查Pod是否配置了臨時存儲卷的限制，即Pod YAML中spec.containers.resources.request.ephemeral-storage的取值。如果取值過高，超出了節點的實際可用容量，Pod會調度失敗。

  2. 執行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狀態，請參見下文解決。

  1. 判斷Pod是否配置了hostPort：如果Pod配置了hostPort，那么每個節點上只能運行一個使用該hostPort的Pod實例。因此，Deployment或ReplicationController中Replicas值不能超過集群中的節點數。如果該端口被其他應用占用，將導致Pod調度失敗。

    hostPort會帶來一些管理和調度上的復雜性，推薦您使用Service來訪問Pod，請參見服務（Service）。

  2. 如果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協議從指定的鏡像倉庫地址拉取鏡像時，鏡像地址解析失敗。

  1. 檢查Pod YAML中spec.containers.image配置的鏡像倉庫地址是否正確。如有誤，需修改為正確地址。

  2. 如地址無誤，進一步驗證從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簽署的證書。

  1. 建議三方倉庫更改使用CA簽發的證書。

  2. 如果您使用的是私有鏡像倉庫，請參見使用私有鏡像倉庫創建應用。

  3. 如果無法更改，可酌情參考下面流程，配置允許節點從使用非安全證書的倉庫中拉取和推送鏡像。建議僅在測試環境中使用，可能會對節點其他Pod的運行產生影響。

展開查看詳細步驟

  1. 為containerd創建證書目錄，用于存放與特定鏡像倉庫相關的證書配置文件。

       $ mkdir -p /etc/containerd/cert.d/xxxxx

  2. 配置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

  3. 修改Docker Daemon配置以添加非安全倉庫。

       vi /etc/docker/daemon.json

    添加以下內容。其中需替換your-insecure-registry為目標私有倉庫地址。

       {
     "insecure-registries": ["your-insecure-registry"]
   }

  4. 重啟相關服務，使更新的配置生效。

       systemctl restart systemd
   systemctl restart docker

Failed to pull image "XXX": rpc error: code = Unknown desc = context canceled

操作取消，可能是由于鏡像文件過大。Kubernetes默認存在拉取鏡像超時時間，如果一定時間內鏡像下載沒有任何進度更新，Kubernetes會認為此操作異?；蛱幱跓o響應狀態，主動取消該任務。

  1. 檢查Pod YAML中配置的imagePullPolicy是否為IfNotPresent。

  2. 參見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)

無法連接鏡像倉庫，網絡不通。

  1. 參見ECS遠程連接方式概述登錄到Pod所在節點，運行cmd命令curl https://xxxxxx/xxxxx/判斷地址是否可以訪問。如有報錯，進一步判斷是否存在網絡配置、防火墻規則、DNS解析等網絡訪問問題。

  2. 判斷節點的公網策略是否正常，例如SNAT條目、綁定的彈性公網IP等配置。

Too Many Requests.

DockerHub對用戶拉取容器鏡像的請求設定了上限。

將鏡像上傳至容器鏡像服務ACR，從ACR鏡像倉庫中拉取鏡像。

一直顯示Pulling image

可能觸發了kubelet的鏡像拉取限流機制。

通過自定義節點池kubelet配置功能調整registryPullQPS（鏡像倉庫的QPS上限）和registryBurst（突發性鏡像拉取的個數上限）。

階段三：啟動問題

Pod處于init狀態

錯誤信息

說明

推薦的解決方案

停留在Init:N/M狀態

該Pod包含M個Init容器，其中N個已經啟動完成，但仍有M-N個Init容器未啟動成功。

  1. 通過kubectl describe pod -n <ns> <pod name>命令查看Pod的事件，確認當前Pod中未啟動的Init容器是否存在異常。

  2. 通過kubectl logs -n <ns> <pod name> -c <container name>命令查看Pod中未啟動的Init容器的日志，通過日志內容排查問題。

  3. 查看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分配失敗。

  1. 網卡在系統中加載是異步的。在CNI配置過程中，網卡可能仍在加載中，可能導致CNI自動重試。這種情況不會影響ENI最終的分配，請通過Pod最終狀態判斷操作是否成功。

  2. 如果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時失敗。

  1. 查看Pod所在節點中Terway組件Pod的Terway容器日志，查看ENI分配過程。

  2. 執行kubectl logs -n kube-system  <terwayPodName > -c terway | grep <podName>命令，查看Terway Pod中Terway網卡的ENI情況，獲取到申請IP操作的Request ID以及OpenAPI的報錯信息。

  3. 根據Request ID和報錯信息進一步排查失敗的原因。

Pod啟動失?。–rashLoopBackOff）

錯誤信息

說明

推薦的解決方案

日志中存在exit(0)。

  1. 登錄異常工作負載所在的節點。

  2. 執行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端口存在沖突。

  1. 檢查Pod是否配置了hostNetwork: true，這意味著Pod內的容器會直接與宿主機共享網絡接口和端口空間。如果無需使用，請改為hostNetwork: false。

  2. 如果Pod需要使用hostNetwork: true，請配置Pod的反親和性，確保同一副本集中的Pod被調度到不通節點。

  3. 檢查并確保不存在也不會有兩個或多個具有相同端口需求的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事件出現時會收到相關報警信息，請參見容器服務報警管理。

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狀態。

  1. 使用kubectl delete pod <pod-name> --grace-period=0 --force強制刪除，釋放Pod資源。

  2. 檢查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的節點被手動打上了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狀態但沒有正常工作。您可以參見以下流程解決。

  1. 查看Pod的配置，確定Pod中容器的配置是否符合預期。

  2. 使用以下方法，排查環境變量中的某一個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中存在拼寫問題。

  3. 查看Pod的日志，通過日志內容排查問題。

  4. 通過終端進入容器，查看容器內的本地文件是否符合預期。

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 來抓包并分析網絡流量，以幫助定位問題的原因。

  1. 使用以下命令確定數據庫連接斷開問題發生在哪個Pod和哪個節點上。

    kubectl  get pod -n [namespace] -o wide

  2. 登錄到目標節點，請參見ECS遠程連接方式概述。

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

    containerd（1.22以上集群）

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

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

      預期輸出：

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

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

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

      預期輸出：

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

    Docker（1.22及以下集群）

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

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

      預期輸出：

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

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

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

      預期輸出：

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

  3. 執行抓包命令。

    使用獲取到的容器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、優化業務應用程序

  • 在業務應用程序中實現數據庫連接的自動重連機制，確保數據庫發生切換或遷移時，應用程序能夠自動恢復連接，無需人工干預。

  • 使用持久化的長連接而非短連接來與數據庫通信。長連接能顯著降低性能損耗和資源消耗，提高系統整體效率。

常用排查界面

您可以登錄容器服務管理控制臺，進入集群的詳情頁面，排查Pod可能存在的問題。

操作

控制臺界面

檢查Pod的狀態

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

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

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

    • 若狀態不為Running，表明Pod狀態異常，請參見本文處理。

檢查Pod的基礎信息

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

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

檢查Pod的配置

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

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

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

檢查Pod的事件

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

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

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

    說明

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

查看Pod的日志

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

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

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

說明

ACK集群集成了日志服務SLS。您可在集群中啟用SLS，快速采集集群的容器日志，請參見通過DaemonSet采集Kubernetes容器文本日志。

檢查Pod的監控

  1. 在集群列表頁面，單擊目標集群名稱，然后在左側導航欄，選擇運維管理 > Prometheus 監控。

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

說明

ACK集群集成了阿里云Prometheus。您可以在集群中快速啟用阿里云Prometheus，以實時監控集群和容器的健康狀況，并查看可視化的Grafana監控數據大盤，請參見使用阿里云Prometheus監控。

使用終端進入容器，進入容器內部查看本地文件等信息

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

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

啟用Pod故障診斷

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

  2. 在容器組頁面，單擊目標容器組右側操作列下的診斷，對該容器組進行故障診斷，根據診斷結果解決問題。

說明

容器智能運維平臺提供了一鍵故障診斷能力，輔助您定位集群中出現的問題，請參見使用集群診斷。