Container Service for Kubernetes：節點異常問題排查

節點故障診斷

當節點出現故障時，您可以使用Container ServiceACK提供的故障診斷功能，一鍵診斷節點異常。

1. 登入Container Service管理主控台，在左側導覽列選擇叢集列表。

2. 在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇節點管理 > 節點。

3. 在節點頁面，單擊目標診斷節點右側操作列下的更多 > 故障診斷。

4. 在彈出的面板單擊發起診斷，然後在控制台頁面查看診斷結果以及對應的修複建議。

檢查節點的詳情

1. 登入Container Service管理主控台，在左側導覽列選擇叢集列表。

2. 在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇節點管理 > 節點。

3. 在節點頁面，單擊目標節點名稱或者目標節點右側操作列下詳情，查看節點的詳情。

檢查節點的狀態

1. 登入Container Service管理主控台，在左側導覽列選擇叢集列表。

2. 在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇節點管理 > 節點。

3. 在節點頁面，可查看對應節點的狀態。

   • 若節點狀態為就緒，說明節點運行正常。

   • 若節點狀態不是就緒，可單擊目標節點名稱或者目標節點右側操作列下的詳情，查看異常狀態節點的詳情。

     說明

     若您要收集InodesPressure、DockerOffline、RuntimeOffline等類型的狀態資訊，需要在叢集中安裝node-problem-detector並建立事件中心，該功能在建立叢集時預設選中。更多資訊，請參見建立並使用K8s事件中心。

檢查節點的事件

1. 登入Container Service管理主控台，在左側導覽列選擇叢集列表。

2. 在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇節點管理 > 節點。

3. 在節點頁面，單擊目標節點名稱或者目標節點右側操作列下的詳情，查看節點的詳情。

   在節點詳情頁面的最下方，可查看節時間點事件資訊。

採集節點的診斷記錄

• 通過控制台，使用容器智能營運平台提供的節點診斷功能收集診斷記錄，請參見節點診斷。

• 使用指令碼收集診斷記錄，請參見如何收集Kubernetes叢集診斷資訊？。

檢查節點的關鍵組件

• Kubelet：

  • 查看Kubelet狀態

    登入對應節點，在節點上執行如下命令，查看Kubelet進程狀態。

    systemctl status kubelet

    預期輸出：

    [root@iZm5eali3mx0qwqo68eobrZ ~]# systemctl status kubelet
    ● kubelet.service - kubelet: The Kubernetes Node Agent
       Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
      Drop-In: /etc/systemd/system/kubelet.service.d
               └─10-kubeadm.conf
       Active: active (running) since Thu 2025-06-12 13:18:45 CST; 28min ago
         Docs: http://kubernetes.io/docs/
     Main PID: 6171 (kubelet)
        Tasks: 12 (limit: 98626)
       Memory: 88.2M
       CGroup: /system.slice/kubelet.service
               └─6171 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --pod-manifest-path=/etc/kubernetes/manifests --v=3 --authorization
    Jun 12 13:47:12                kubelet[6171]: I0612 13:47:12.250117    6171 prober.go:116] "Probe succeeded" probeType="Liveness" pod="kube-system/coredns-5b97654649-jkbtq" podUID="0530c82c-a012-4f
    Jun 12 13:47:12                kubelet[6171]: I0612 13:47:12.250144    6171 prober.go:116] "Probe succeeded" probeType="Readiness" pod="kube-system/coredns-5b97654649-jkbtq" podUID="0530c82c-a012-4
    Jun 12 13:47:12                kubelet[6171]: I0612 13:47:12.716032    6171 prober.go:116] "Probe succeeded" probeType="Liveness" pod="kube-system/csi-plugin-bqdjr" podUID="33fd9325-c75d-458d-adc3-
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.574947    6171 kubelet_pods.go:1151] "Clean up pod workers for terminated pods"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575713    6171 kubelet_pods.go:1201] "Clean up probes for terminated pods"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575724    6171 kubelet_pods.go:1205] "Clean up orphaned pod statuses"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575731    6171 kubelet_pods.go:1209] "Clean up orphaned pod user namespace allocations"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575736    6171 kubelet_pods.go:1221] "Clean up orphaned pod directories"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575775    6171 kubelet_pods.go:1232] "Clean up mirror pods"
    Jun 12 13:47:13                kubelet[6171]: I0612 13:47:13.575807    6171 kubelet_pods.go:1374] "Clean up orphaned pod cgroups"
    lines 1-22/22 (END)

  • 查看Kubelet日誌

    登入對應節點，在節點上執行如下命令，可查看Kubelet日誌資訊。關於更多查看Kubelet日誌的方式，請參見採集節點的診斷記錄。

    journalctl -u kubelet

  • 查看Kubelet配置

    登入對應節點，在節點上執行如下命令，可查看Kubelet配置資訊。

    cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

• 運行時：

  • 檢查Dockerd

    • 查看Dockerd狀態

      登入對應節點，在節點上執行如下命令，查看Dockerd進程狀態。

      systemctl status docker

      預期輸出：

      #systemctl status docker
      ● docker.service - Docker Application Container Engine
         Loaded: loaded (/etc/systemd/system/docker.service; enabled; vendor preset: disabled)
         Active: active (running) since Wed 2022-03-02 15:11:46 CST; 5 days ago
           Docs: https://docs.docker.com
       Main PID: 4330 (dockerd)
          Tasks: 75
         Memory: 8.3G
         CGroup: /system.slice/docker.service
                 └─4330 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
      Mar 02 15:19:29 xxx                    dockerd[4330]: time="2022-03-02T15:19:29.418689546+08:00" level=info msg="Attempting next endpoint for pull a...eaders
      Mar 02 15:22:20 xxx                    dockerd[4330]: time="2022-03-02T15:22:20.888769038+08:00" level=warning msg="Error getting v2 registry: Get h...eaders
      Mar 02 15:22:20 xxx                    dockerd[4330]: time="2022-03-02T15:22:20.888912991+08:00" level=info msg="Attempting next endpoint for pull a...eaders
      Mar 02 15:23:25 xxx                    dockerd[4330]: time="2022-03-02T15:23:25.487947465+08:00" level=warning msg="Seccomp is not enabled in your k...rofile

    • 查看Dockerd日誌

      登入對應節點，在節點上執行如下命令，可查看Dockerd的日誌資訊。關於更多查看Dockerd日誌的方式，請參見採集節點的診斷記錄。

      journalctl -u docker

    • 查看Dockerd配置

      登入對應節點，在節點上執行如下命令，可查看Dockerd配置資訊。

      cat /etc/docker/daemon.json

  • 檢查containerd

    • 查看containerd狀態

      登入對應節點，在節點上執行如下命令，查看containerd進程狀態。

      systemctl status containerd

      預期輸出：

      [root@iZm5eali3mx0qwqo68eobrZ ~]# systemctl status containerd
      ● containerd.service - containerd container runtime
         Loaded: loaded (/etc/systemd/system/containerd.service; enabled; vendor preset: disabled)
         Active: active (running) since Thu 2025-06-12 13:18:44 CST; 29min ago
           Docs: https://containerd.io
       Main PID: 5994 (containerd)
          Tasks: 153
         Memory: 3.5G
         CGroup: /system.slice/containerd.service
                 ├─ 5994 /usr/bin/containerd
                 ├─ 6589 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id b4ad8b28c61fa573e04bc641901bd64b15adb1d4a... xxx -address /run/containerd/containerd.sock
                 ├─ 6592 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id eb828cfb114bd404d7781f72b55ed4ee1e9743b7d... xxx -address /run/containerd/containerd.sock
                 ├─ 6666 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 92bf24db851fcaf65ed9c3ddc9210b61169623158... xxx -address /run/containerd/containerd.sock
                 ├─ 6726 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 96d44ff7503b876227e7d287a730cac5b50b5183f1... xxx -address /run/containerd/containerd.sock
                 ├─ 6727 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 3707c088fec2d14f9ec2c78beccf5f3e1f0a18a6b... xxx -address /run/containerd/containerd.sock
                 ├─ 6766 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id b390b71290b772958626a0cc943fb678c7fec4ef5... xxx -address /run/containerd/containerd.sock
                 ├─ 9501 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 40c0f850c4c003144bbc5a17bcb5b7f15ad121862... xxx -address /run/containerd/containerd.sock
                 ├─ 9567 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 3b07c32bf4fe84fde20177efdcffabd2cd93ac02a... xxx -address /run/containerd/containerd.sock
                 ├─ 9633 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id d181fcabeebca990b1298072f91da4fbb251b666c... xxx -address /run/containerd/containerd.sock
                 └─11643 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id f3744bcb95b522bc64a5a88dd4c49a231c082f5d79... xxx -address /run/containerd/containerd.sock
      Jun 12 13:19:53  containerd[5994]: time="2025-06-12T13:19:53.013508035+08:00" level=error msg="ContainerStatus for \"f3744bcb95b522bc64a5a88dd4c49a231c082f5d790e64e6f835760b83e7b280\""
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.708151565+08:00" level=info msg="ImageCreate event &ImageCreate{Name:registry-cn-qingdao-vpc.ack.aliyuncs.com/acs/loongcol..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.710172874+08:00" level=info msg="ImageCreate event &ImageCreate{Name:sha256:e705a85d376f9fdecd0f1b2ebce63d85f8392de70a9636..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.713591809+08:00" level=info msg="PullImage \"registry-cn-qingdao-vpc.ack.aliyuncs.com/acs/loongcollector:v3.0.11.0-915c655..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.713969883+08:00" level=info msg="ImageCreate event &ImageCreate{Name:registry-cn-qingdao-vpc.ack.aliyuncs.com/acs/loongcol..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.717628440+08:00" level=info msg="CreateContainer within sandbox \"f3744bcb95b522bc64a5a88dd4c49a231c082f5d790e64e6f835760b..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.732237135+08:00" level=info msg="CreateContainer within sandbox \"f3744bcb95b522bc64a5a88dd4c49a231c082f5d790e64e6f835760b..."
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.735512597+08:00" level=info msg="StartContainer for \"e7c6a20368f9c20900848fbcec81d5145d73caa8c4decaae660e0ea89dd64c28\""
      Jun 12 13:19:54  containerd[5994]: time="2025-06-12T13:19:54.771464238+08:00" level=info msg="StartContainer for \"e7c6a20368f9c20900848fbcec81d5145d73caa8c4decaae660e0ea89dd64c28\"..."
      Jun 12 13:20:47  containerd[5994]: time="2025-06-12T13:20:47.246563467+08:00" level=error msg="ContainerStatus for \"f3744bcb95b522bc64a5a88dd4c49a231c082f5d790e64e6f835760b83e7b280\""
      lines 1-30/30 (END)

    • 查看containerd日誌

      登入對應節點，在節點上執行如下命令，可查看containerd日誌資訊。關於更多查看containerd日誌的方式，請參見採集節點的診斷記錄。

      journalctl -u containerd

• 檢查NTP：

  • 查看NTP服務狀態

    登入對應節點，在節點上執行如下命令，查看Chronyd進程的狀態。

    systemctl status chronyd

    預期輸出：

    [root@iZm5eali3mx0qwqo68eobrZ ~]# systemctl status chronyd
    ● chronyd.service - NTP client/server
       Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
       Active: active (running) since Thu 2025-06-12 13:18:22 CST; 20min ago
         Docs: man:chronyd(8)
               man:chrony.conf(5)
     Main PID: 1603 (chronyd)
        Tasks: 1 (limit: 98626)
       Memory: 732.0K
       CGroup: /system.slice/chronyd.service
               └─1603 /usr/sbin/chronyd
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ systemd[1]: chronyd.service: Succeeded.
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ systemd[1]: Stopped NTP client/server.
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ systemd[1]: Starting NTP client/server...
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: chronyd version 4.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: Frequency -35.639 +/- 2.058 ppm read from /var/lib/chrony/drift
    Jun 12 13:18:22 iZm5eali3mx0qwqo68eobrZ systemd[1]: Started NTP client/server.
    Jun 12 13:18:23 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: System clock was stepped by 0.000000 seconds
    Jun 12 13:18:27 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: Selected source 100.100.61.88 (ntp.cloud.aliyuncs.com)
    Jun 12 13:18:27 iZm5eali3mx0qwqo68eobrZ chronyd[1603]: System clock wrong by 1.476188 seconds
    xxx

  • 查看NTP服務日誌

    登入對應節點，在節點上執行如下命令，可查看NTP日誌資訊。

    journalctl -u chronyd

檢查節點的監控

• Cloud Monitor

  阿里雲Container ServiceACK叢集整合了監控服務，可登入CloudMonitor制台查看對應ECS執行個體的基本監控資訊，關於CloudMonitor節點的使用方式，請參見監控節點。

• Prometheus監控

  1. 登入Container Service管理主控台，在左側導覽列選擇叢集列表。

  2. 在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇營運管理 > Prometheus 監控。

  3. 在Prometheus 監控頁面，單擊節點監控頁簽，然後再單擊叢集節點監控詳情頁簽。

  4. 在叢集節點監控詳情頁面選擇待查看的節點，可查看對應節點的CPU、記憶體、磁碟等監控資訊。

檢查節點的安全性群組

關於如何檢查節點的安全性群組，請參見安全性群組概述和配置叢集安全性群組。

問題原因

通常是Kubelet進程異常、運行時異常、Kubelet配置有誤等原因導致。

問題現象

Kubelet狀態為inactive。

解決方案

1. 執行如下命令重啟Kubelet。重啟Kubelet不會影響運行中的容器。

   systemctl restart kubelet

2. Kubelet重啟後，登入節點執行以下命令，再次查看kubelet狀態是否恢複正常。

   systemctl status kubelet

3. 若Kubelet重啟後狀態仍異常，請登入節點執行以下命令查看Kubelet日誌。

   journalctl -u kubelet

   • 若日誌中有明確的異常資訊，請根據異常關鍵字進行排查。

   • 若確認是Kubelet配置異常，請執行如下命令修改Kubelet配置。

     vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf   #修改Kubelet配置。
     systemctl daemon-reload;systemctl restart kubelet         #重新載入配置並重啟Kubelet。

問題原因

通常是Dockerd配置異常、進程負載異常、節點負載異常等原因導致。

問題現象

• Dockerd狀態為inactive。

• Dockerd狀態為active (running)，但未正常工作，導致節點異常。通常有docker ps、docker exec等命令執行失敗的現象。

• 節點狀態中RuntimeOffline為True。

• 若叢集配置了叢集節點異常警示，則節點Dockerd異常時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

1. 執行如下命令重啟Dockerd。

   systemctl restart docker

2. Dockerd重啟後，登入節點執行以下命令，再次查看Dockerd狀態是否恢複正常。

   systemctl status docker

3. 若Dockerd重啟後狀態仍異常，請登入節點執行以下命令查看Dockerd日誌。

   journalctl -u docker

問題原因

通常是containerd配置異常、進程負載異常、節點負載異常等原因導致。

• containerd狀態為inactive。

• 節點狀態中RuntimeOffline為True。

• 若叢集配置了叢集節點異常警示，則節點containerd異常時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

1. 執行如下命令重啟containerd。

   systemctl restart containerd

2. containerd重啟後，登入節點執行以下命令，再次查看containerd狀態是否恢複正常。

   systemctl status containerd

3. 若containerd重啟後狀態仍異常，請登入節點執行以下命令查看containerd日誌。

   journalctl -u containerd

問題原因

通常是NTP進程狀態異常導致。

問題現象

• Chronyd狀態為inactive。

• 節點狀態中NTPProblem為True。

• 若叢集配置了叢集節點異常警示，則節點時間服務異常時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

1. 執行如下命令重啟Chronyd。

   systemctl restart chronyd

2. Chronyd重啟後，登入節點執行以下命令，再次查看Chronyd狀態是否恢複正常。

   systemctl status chronyd

3. 若Chronyd重啟後狀態仍異常，請登入節點執行以下命令查看Chronyd日誌。

   journalctl -u chronyd

問題原因

Pod生命週期事件產生器PLEG（Pod Lifecycle Event Generator）會記錄Pod生命週期中的各種事件，如容器的啟動、終止等。PLEG is not healthy異常通常是由於節點上的運行時進程異常或者節點Systemd版本缺陷導致。

問題現象

• 節點狀態NotReady。

• 在Kubelet日誌中，可看到如下日誌。

  I0729 11:20:59.245243    9575 kubelet.go:1823] skipping pod synchronization - PLEG is not healthy: pleg was last seen active 3m57.138893648s ago; threshold is 3m0s.

• 若叢集配置了叢集節點異常警示，則節點PLEG異常時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

1. 依次重啟節點關鍵組件Dockerd/Containerd、Kubelet，重啟後查看節點是否恢複正常。

2. 若節點關鍵組件重啟後節點仍未恢複正常，可嘗試重啟異常節點。具體操作，請參見重啟執行個體。

   警告

   重啟節點可能會導致您的業務中斷，請謹慎操作。

3. 若異常節點系統為CentOS 7.6，參見 使用CentOS 7.6系統時kubelet日誌含有“Reason:KubeletNotReady Message:PLEG is not healthy:”資訊進行排查。

問題原因

通常是叢集中的節點資源不足導致。

問題現象

如果當前Pod請求的資源總量大於節點可分配的資源總量減去節點已指派的資源總量，Pod就不會調度到當前節點。

kubectl describe node [$nodeName]

Allocatable:
  cpu:                3900m
  ephemeral-storage:  114022843818
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             12601Mi
  pods:               60
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests    Limits
  --------           --------    ------
  cpu                725m (18%)  6600m (169%)
  memory             977Mi (7%)  16640Mi (132%)
  ephemeral-storage  0 (0%)      0 (0%)
  hugepages-1Gi      0 (0%)      0 (0%)
  hugepages-2Mi      0 (0%)      0 (0%)

解決方案

當節點調度資源不足時，需降低節點負載，方法如下：

• 刪除或減少不必要的Pod，降低節點的負載。具體操作，請參見管理容器組（Pod）。

• 根據自身業務情況，限制Pod的資源配置。具體操作，請參見設定容器的CPU和記憶體資源上下限。

  您可以使用ACK提供的資源畫像功能，基於資源使用量的歷史資料獲得容器粒度的資源規格推薦，簡化為容器配置Request和Limit的複雜度。更多資訊，請參見資源畫像。

• 在叢集中添加新的節點。具體操作，請參見建立和管理節點池。

• 為節點進行升配。具體操作，請參見升降配節點資源。

更多資訊，請參見節點CPU不足、節點記憶體不足-MemoryPressure和節點磁碟空間不足-DiskPressure。

問題原因

通常是節點上的容器佔用CPU過多導致節點的CPU不足。

問題現象

• 當節點CPU不足時，可能會導致節點狀態異常。

• 若叢集配置了叢集節點異常警示，則節點CPU使用率>=85%時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

• 通過節點的監控查看CPU增長曲線，確認異常出現時間點，檢查節點上的進程是否存在CPU佔用過高的現象。具體操作，請參見檢查節點的監控。

• 降低節點的負載，具體操作，請參見節點調度資源不足。

• 如需重啟節點，可嘗試重啟異常節點。具體操作，請參見重啟執行個體。

  警告

  重啟節點可能會導致您的業務中斷，請謹慎操作。

問題原因

通常是節點上的容器佔用記憶體過多導致節點的記憶體不足。

問題現象

• 當節點的可用記憶體低於memory.available配置項時，則節點狀態中MemoryPressure為True，同時該節點上的容器被驅逐。關於節點驅逐，請參見節點壓力驅逐。

• 當節點記憶體不足時，會有以下常見錯誤資訊：

  • 節點狀態中MemoryPressure為True。

  • 當節點上的容器被驅逐時：

    • 在被驅逐的容器事件中可看到關鍵字The node was low on resource: memory。

    • 在節時間點事件中可看到關鍵字attempting to reclaim memory。

  • 可能會導致系統OOM異常，當出現系統OOM異常時，節時間點事件中可看到關鍵字System OOM。

• 若叢集配置了叢集節點異常警示，則節點記憶體使用量率>=85%時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

• 通過節點的監控查看記憶體增長曲線，確認異常出現時間點，檢查節點上的進程是否存在記憶體泄露現象。具體操作，請參見檢查節點的監控。

• 降低節點的負載，具體操作，請參見節點調度資源不足。

• 如需重啟節點，可嘗試重啟異常節點。具體操作，請參見重啟執行個體。

  警告

  重啟節點可能會導致您的業務中斷，請謹慎操作。

問題原因

通常是節點上的容器佔用索引節點過多導致節點的索引節點不足。

問題現象

• 當節點的可用索引節點低於inodesFree配置項時，則節點狀態中InodesPressure為True，同時該節點上的容器被驅逐。關於節點驅逐，請參見節點壓力驅逐。

• 當節點索引點不足時，通常會有以下常見錯誤資訊：

  • 節點狀態中InodesPressure為True。

  • 當節點上的容器被驅逐時：

    • 被驅逐的容器事件中可看到關鍵字The node was low on resource: inodes。

    • 節時間點事件中可看到關鍵字attempting to reclaim inodes。

• 若叢集配置了叢集節點異常警示，則節點索引節點不足時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

• 通過節點的監控查看索引節點增長曲線，確認異常出現時間點，檢查節點上的進程是否存在佔用索引節點過多現象。具體操作，請參見檢查節點的監控。

• 其他問題相關操作，請參見解決Linux執行個體磁碟空間滿問題。

問題原因

通常是節點上的容器佔用PID過多導致節點的PID不足。

問題現象

• 當節點的可用PID低於pid.available配置項時，則節點狀態中NodePIDPressure為True，同時該節點上的容器被驅逐。關於節點驅逐，請參見節點壓力驅逐。

• 若叢集配置了叢集節點異常警示，則節點PID不足時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

1. 執行如下命令，查看節點的最大PID數和節點當前的最大PID。

   sysctl kernel.pid_max  #查看最大PID數。
   ps -eLf|awk '{print $2}' | sort -rn| head -n 1   #查看當前的最大PID。

2. 執行如下命令，查看佔用PID最多的前5個進程。

   ps -elT | awk '{print $4}' | sort | uniq -c | sort -k1 -g | tail -5

   預期輸出：

   #第一列為進程佔用的PID數，第二列為當前進程號。
   73 9743
   75 9316
   76 2812
   77 5726
   93 5691

3. 根據進程號找到對應進程和所屬的Pod，分析佔用PID過多的原因並最佳化對應代碼。

4. 降低節點的負載。具體操作，請參見節點調度資源不足。

5. 如需重啟節點，可嘗試重啟異常節點。具體操作，請參見重啟執行個體。

   警告

   重啟節點可能會導致您的業務中斷，請謹慎操作。

問題原因

通常是節點上的容器佔用磁碟過多、鏡像檔案過大導致節點的磁碟空間不足。

問題現象

• 當節點的可用磁碟空間低於imagefs.available配置項時，則節點狀態中DiskPressure為True。

• 當可用磁碟空間低於nodefs.available配置項時，則該節點上的容器全部被驅逐。關於節點驅逐，請參見節點壓力驅逐。

• 當磁碟空間不足時，通常會有以下常見錯誤資訊：

  • 節點狀態中DiskPressure為True。

  • 當觸發鏡像回收策略後，磁碟空間仍然不足以達到健康閾值（預設為80%），在節時間點事件中可看到關鍵字failed to garbage collect required amount of images。

  • 當節點上的容器被驅逐時：

    • 被驅逐的容器事件中可看到關鍵字The node was low on resource: [DiskPressure]。

    • 節時間點事件中可看到關鍵字attempting to reclaim ephemeral-storage或attempting to reclaim nodefs。

• 若叢集配置了叢集節點異常警示，則節點磁碟使用率>=85%時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

• 通過節點的監控查看磁碟增長曲線，確認異常出現時間點，檢查節點上的進程是否存在佔用磁碟空間過多的現象。具體操作，請參見檢查節點的監控。

• 若有大量檔案在磁碟上未清理，請清理檔案。具體操作，請參見解決Linux執行個體磁碟空間滿問題。

• 根據自身業務情況，限制Pod的ephemeral-storage資源配置。具體操作，請參見設定容器的CPU和記憶體資源上下限。

• 建議使用阿里雲儲存產品，盡量避免使用HostPath資料卷。更多資訊，請參見儲存。

• 節點磁碟擴容。

• 降低節點的負載。具體操作，請參見節點調度資源不足。

問題原因

通常是節點上的容器數過多導致IP資源不足。

問題現象

• Pod啟動失敗，狀態為ContainerCreating。檢查Pod的日誌有類似如下報錯，包含錯誤資訊關鍵字InvalidVSwitchId.IpNotEnough。關於查看Pod日誌的具體操作，請參見Pod異常問題排查。

  time="2020-03-17T07:03:40Z" level=warning msg="Assign private ip address failed: Aliyun API Error: RequestId: 2095E971-E473-4BA0-853F-0C41CF52651D Status Code: 403 Code: InvalidVSwitchId.IpNotEnough Message: The specified VSwitch \"vsw-AAA\" has not enough IpAddress., retrying"

• 若叢集配置了叢集節點異常警示，則節點IP資源不足時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

降低節點上的容器數量。具體操作，請參見節點調度資源不足。其他相關操作，請參見Terway網路情境中交換器的IP資源不足和Terway網路模式擴容vSwitch後，依然無法分配Pod IP怎麼辦？。

問題原因

通常是節點運行狀態異常、安全性群組配置有誤或網路負載過高導致。

問題現象

• 節點無法登入。

• 節點狀態Unknown。

• 若叢集配置了叢集節點異常警示，則節點公網流出頻寬使用率 >=85%時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

• 若節點無法登入，請參考以下步驟進行排查：

  • 檢查節點執行個體狀態是否為運行中。

  • 檢查節點的安全性群組配置。具體操作，請參見檢查節點的安全性群組。

• 若節點的網路負載過高，請參考以下步驟進行排查：

  • 通過節點的監控查看節點網路增長曲線，檢查節點上的Pod是否存在佔用網路頻寬過多的現象。具體操作，請參見檢查節點的監控。

  • 使用網路原則控制Pod的網路流量。具體操作，請參見在ACK叢集使用網路原則。

問題原因

通常是節點負載異常等原因導致。

問題現象

• 在節點重啟的過程中，節點狀態為NotReady。

• 若叢集配置了叢集節點異常警示，則節點異常重啟時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

1. 執行以下命令，查看節點重啟時間。

   last reboot

   預期輸出：

   [root@iZoj203tgmxxx /root]
   #last reboot
   reboot   system boot  xxx  Tue Mar 22 06:26 - 11:49 (1+05:22)
   reboot   system boot  xxx  Fri Oct 15 05:27 - 11:49 (159+06:22)
   wtmp begins Fri Oct 15 05:27:03 2021

2. 查看節點的監控，根據重啟時間排查出現異常的資源，請參見檢查節點的監控。

3. 查看節點的核心日誌，根據重啟時間排查異常日誌，請參見採集節點的診斷記錄。

問題原因

部分叢集的存量節點上預設配置了Docker相關的auditd審計規則，當節點使用了Docker容器運行時，這些審計規則會觸發系統記錄Docker操作相關的審計日誌。在某些情況下（節點上大量容器集中反覆重啟、容器內應用短時間內寫入海量檔案、核心Bug等），會低機率出現系統大量寫入審計日誌影響節點磁碟IO，進而出現auditd進程佔用大量磁碟IO的現象或者系統日誌中出現audit: backlog limit exceeded錯誤的問題。

問題現象

該問題隻影響使用Docker容器運行時的節點。當您在節點上執行相關命令時，具體的問題現象如下：

• 執行iotop -o -d 1命令時，結果顯示auditd進程的DISK WRITE指標持續大於或等於1MB/s。

• 執行dmesg -d命令時，結果中存在包含關鍵字audit_printk_skb的日誌。比如audit_printk_skb: 100 callbacks suppressed。

• 執行dmesg -d命令時，結果中存在關鍵字 audit: backlog limit exceeded。

解決方案

您可以通過以下操作，檢查您的節點中出現的以上問題是否與節點的auditd配置有關：

1. 登入叢集節點。

2. 執行以下命令，檢查auditd規則。

   sudo auditctl -l | grep -- ' -k docker'

   如果該命令的輸出中包含如下資訊，說明該節點出現的問題與auditd配置有關。

   -w /var/lib/docker -k docker

如果通過以上檢查確認是該問題影響了叢集節點，您可以選擇以下三種解決方案的任一方案解決問題。

• 升級叢集版本

  您可以通過升級叢集版本來修複該問題。具體操作，請參見手動升級叢集。

• 使用containerd容器運行時

  對於無法升級的叢集，可以通過使用containerd代替Docker作為節點容器運行時的方法規避該問題。需要對每個使用Docker容器運行時的節點池進行如下操作：

  1. 通過複製節點池的方式建立一個以containerd為容器運行時的節點池，同時確保新節點池除容器運行時配置外的其他配置都與被複製的目標節點池保持一致。

  2. 在業務低峰期對目標節點池內的節點逐個進行排空節點操作，確保已無商務服務部署在目標節點池中。

• 更新節點上的auditd配置

  對於無法升級叢集也不能使用containerd容器運行時的情境，可以通過手動更新節點上的auditd配置的方法規避該問題。需要對每個使用Docker容器運行時的節點進行如下操作。

  1. 登入叢集節點。

  2. 執行以下命令，刪除Docker相關的auditd規則。

     sudo test -f /etc/audit/rules.d/audit.rules && sudo sed -i.bak '/ -k docker/d' /etc/audit/rules.d/audit.rules
     sudo test -f /etc/audit/audit.rules && sudo sed -i.bak '/ -k docker/d' /etc/audit/audit.rules

  3. 執行以下命令，應用新的auditd規則。

     if service auditd status |grep running || systemctl status auditd |grep running; then
         sudo service auditd restart || sudo systemctl restart auditd
         sudo service auditd status || sudo systemctl status auditd
     fi