ACK叢集節點異常問題排查SOP - Container Service for Kubernetes

本文介紹關於節點異常問題的診斷流程、排查思路、常見問題及解決方案。

本文目錄

類別	內容
診斷流程	診斷流程
常見排查方法	節點故障診斷檢查節點的詳情檢查節點的狀態檢查節點的事件檢查節點的診斷記錄檢查節點的關鍵組件檢查節點的監控檢查節點的安全性群組
常見問題及解決方案	節點關鍵組件異常處理 Kubelet異常處理 Dockerd異常處理-RuntimeOffline Containerd異常處理-RuntimeOffline NTP異常處理-NTPProblem 節點PLEG異常-PLEG is not healthy 節點資源異常處理節點調度資源不足節點CPU不足節點記憶體不足-MemoryPressure 節點索引節點不足-InodesPressure 節點PID不足-NodePIDPressure 節點磁碟空間不足-DiskPressure 節點IP資源不足-InvalidVSwitchId.IpNotEnough 節點網路異常處理節點網路異常節點其他異常處理節點異常重啟如何解決auditd進程佔用大量磁碟IO或者系統日誌中出現audit: backlog limit exceeded錯誤的問題

診斷流程

查看節點是否處於異常狀態。具體操作，請參見檢查節點的狀態。
- 若節點處於NotReady狀態，可參考如下步驟進行排查：
  1. 檢查節點狀態資訊，查看PIDPressure、DiskPressure、MemoryPressure等節點類型的狀態是否為True。若某一節點類型的狀態為True，則根據相應異常狀態關鍵字進行排查。具體操作，請參見Dockerd異常處理-RuntimeOffline、節點記憶體不足-MemoryPressure和節點索引節點不足-InodesPressure等進行解決。
  2. 檢查節點的關鍵組件和日誌。
    - Kubelet
      1. 檢查Kubelet的狀態、日誌、配置等是否存在異常。具體操作，請參見檢查節點的關鍵組件。
      2. 若Kubelet存在異常，請參見Kubelet異常處理操作。
    - Dockerd
      1. 檢查Dockerd的狀態、日誌、配置等是否存在異常。具體操作，請參見檢查節點的關鍵組件。
      2. 若Dockerd存在異常，請參見Dockerd異常處理-RuntimeOffline操作。
    - Containerd
      1. 檢查Containerd的狀態、日誌、配置等是否存在異常。具體操作，請參見檢查節點的關鍵組件。
      2. 若Containerd存在異常，請參見Containerd異常處理-RuntimeOffline操作。
    - NTP
      1. 檢查NTP服務的狀態、日誌、配置等是否存在異常。具體操作，請參見檢查節點的關鍵組件。
      2. 若NTP服務存在異常，請參見NTP異常處理-NTPProblem操作。
  3. 檢查節點的診斷記錄。具體操作，請參見檢查節點的診斷記錄。
  4. 檢查節點的監控，查看節點CPU、記憶體、網路等資源負載情況是否存在異常。具體操作，請參見檢查節點的監控。若節點負載異常，請參見節點CPU不足和節點記憶體不足-MemoryPressure等解決。
- 若節點處於Unknown狀態，可參考如下步驟進行排查。
  1. 檢查節點ECS執行個體狀態是否為運行中。
  2. 檢查節點的關鍵組件。
    - Kubelet
      1. 檢查Kubelet的狀態、日誌、配置等是否存在異常。具體操作，請參見檢查節點的關鍵組件。
      2. 若Kubelet存在異常，請參見Kubelet異常處理操作。
    - Dockerd
      1. 檢查Dockerd的狀態、日誌、配置等是否存在異常。具體操作，請參見檢查節點的關鍵組件。
      2. 若Dockerd存在異常，請參見Dockerd異常處理-RuntimeOffline操作。
    - Containerd
      1. 檢查Containerd的狀態、日誌、配置等是否存在異常。具體操作，請參見檢查節點的關鍵組件。
      2. 若Containerd存在異常，請參見Containerd異常處理-RuntimeOffline操作。
    - NTP
      1. 檢查NTP服務的狀態、日誌、配置等是否存在異常。具體操作，請參見檢查節點的關鍵組件。
      2. 若NTP服務存在異常，請參見NTP異常處理-NTPProblem操作。
  3. 檢查節點的網路連通性。具體操作，請參見檢查節點的安全性群組。若節點網路存在異常，請參見節點網路異常解決。
  4. 檢查節點的診斷記錄。具體操作，請參見檢查節點的診斷記錄。
  5. 檢查節點的監控，查看節點CPU、記憶體、網路等資源負載情況是否存在異常。具體操作，請參見檢查節點的監控。若節點負載異常，請參見節點CPU不足和節點記憶體不足-MemoryPressure解決。
若根據診斷流程未能排查問題，請使用Container ServiceACK提供的故障診斷功能進行排查。具體操作，請參見節點故障診斷。
若問題仍未解決，請提交工單排查。

常見排查方法

節點故障診斷

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

登入Container Service管理主控台。
在控制台左側導覽列，單擊叢集。
在叢集列表頁面，單擊目的地組群名稱或者目的地組群右側操作列下的詳情。
在叢集管理頁左側導覽列，選擇節點管理 > 節點。
在節點管理頁面，單擊目標診斷節點右側操作列下的更多 > 故障診斷。
在診斷詳情頁面，根據診斷後的異常資訊進行排查。

檢查節點的詳情

登入Container Service管理主控台。
在控制台左側導覽列，單擊叢集。
在叢集列表頁面，單擊目的地組群名稱或者目的地組群右側操作列下的詳情。
在叢集管理頁左側導覽列，選擇節點管理 > 節點。
在節點頁面，單擊目標節點名稱或者目標節點右側操作列下的更多 > 詳情，查看節點的詳情。

檢查節點的狀態

登入Container Service管理主控台。
在控制台左側導覽列，單擊叢集。
在叢集列表頁面，單擊目的地組群名稱或者目的地組群右側操作列下的詳情。
在叢集管理頁左側導覽列，選擇節點管理 > 節點。
在節點頁面，可查看對應節點的狀態。
- 若節點狀態為運行中，說明節點運行正常。
- 若節點狀態不是運行中，可單擊目標節點名稱或者目標節點右側操作列下的更多 > 詳情，查看異常狀態節點的詳情。
  說明
  若您要收集InodesPressure、DockerOffline、RuntimeOffline等類型的狀態資訊，需要在叢集中安裝node-problem-detector並建立事件中心，該功能在建立叢集時預設選中。更多資訊，請參見建立並使用K8s事件中心。

檢查節點的事件

登入Container Service管理主控台。
在控制台左側導覽列，單擊叢集。
在叢集列表頁面，單擊目的地組群名稱或者目的地組群右側操作列下的詳情。
在叢集管理頁左側導覽列，選擇節點管理 > 節點。
在節點頁面，單擊目標節點名稱或者目標節點右側操作列下的更多 > 詳情，查看節點的詳情。
在節點詳情頁面的最下方，可查看節時間點事件資訊。

檢查節點的診斷記錄

使用指令碼收集診斷記錄：具體操作，請參見如何收集Kubernetes叢集診斷資訊？。
使用控制台收集診斷記錄：具體操作，請參見一鍵採集節點的診斷記錄。

檢查節點的關鍵組件

Kubelet：
- 查看Kubelet狀態
  登入對應節點，在節點上執行如下命令，查看Kubelet進程狀態。
```
systemctl status kubelet
```
  預期輸出：
- 查看Kubelet日誌
  登入對應節點，在節點上執行如下命令，可查看Kubelet日誌資訊。關於更多查看Kubelet日誌的方式，請參見檢查節點的診斷記錄。
```
journalctl -u kubelet
```
- 查看Kubelet配置
  登入對應節點，在節點上執行如下命令，可查看Kubelet配置資訊。
```
cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
```
運行時：
- 檢查Dockerd
  - 查看Dockerd狀態
    登入對應節點，在節點上執行如下命令，查看Dockerd進程狀態。
```
systemctl status docker
```
    預期輸出：
  - 查看Dockerd日誌
    登入對應節點，在節點上執行如下命令，可查看Dockerd的日誌資訊。關於更多查看Dockerd日誌的方式，請參見檢查節點的診斷記錄。
```
journalctl -u docker
```
  - 查看Dockerd配置
    登入對應節點，在節點上執行如下命令，可查看Dockerd配置資訊。
```
cat /etc/docker/daemon.json
```
- 檢查Containerd
  - 查看Containerd狀態
    登入對應節點，在節點上執行如下命令，查看Containerd進程狀態。
```
systemctl status containerd
```
    預期輸出：
  - 查看Containerd日誌
    登入對應節點，在節點上執行如下命令，可查看Containerd日誌資訊。關於更多查看Containerd日誌的方式，請參見檢查節點的診斷記錄。
```
journalctl -u containerd
```
檢查NTP：
- 查看NTP服務狀態
  登入對應節點，在節點上執行如下命令，查看Chronyd進程的狀態。
```
systemctl status chronyd
```
  預期輸出：
- 查看NTP服務日誌
  登入對應節點，在節點上執行如下命令，可查看NTP日誌資訊。
```
journalctl -u chronyd
```

檢查節點的監控

CloudMonitor
阿里雲Container ServiceACK叢集整合了監控服務，可登入CloudMonitor制台查看對應ECS執行個體的基本監控資訊，關於CloudMonitor節點的使用方式，請參見監控節點。
Prometheus監控
1. 登入Container Service管理主控台。
2. 在控制台左側導覽列中，單擊叢集。
3. 在叢集列表頁面中，單擊目的地組群名稱或者目的地組群右側操作列下的詳情。
4. 在叢集管理頁左側導覽列中，選擇營運管理 > Prometheus監控。
5. 在Prometheus監控頁面，單擊節點監控頁簽，在叢集節點監控詳情頁面選擇待查看的節點，可查看對應節點的CPU、記憶體、磁碟等監控資訊。

檢查節點的安全性群組

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

Kubelet異常處理

問題原因

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

問題現象

Kubelet狀態為inactive。

解決方案

執行如下命令重啟Kubelet。重啟Kubelet不會影響運行中的容器。
```
systemctl restart kubelet
```
Kubelet重啟後，登入節點執行以下命令，再次查看kubelet狀態是否恢複正常。
```
systemctl status kubelet
```
若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異常處理-RuntimeOffline

問題原因

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

問題現象

Dockerd狀態為inactive。
Dockerd狀態為active (running)，但未正常工作，導致節點異常。通常有docker ps、docker exec等命令執行失敗的現象。
節點狀態中RuntimeOffline為True。
若叢集配置了叢集節點異常警示，則節點Dockerd異常時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

執行如下命令重啟Dockerd。
```
systemctl restart docker
```
Dockerd重啟後，登入節點執行以下命令，再次查看Dockerd狀態是否恢複正常。
```
systemctl status docker
```
若Dockerd重啟後狀態仍異常，請登入節點執行以下命令查看Dockerd日誌。
```
journalctl -u docker
```

Containerd異常處理-RuntimeOffline

問題原因

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

Containerd狀態為inactive。
節點狀態中RuntimeOffline為True。
若叢集配置了叢集節點異常警示，則節點Containerd異常時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

執行如下命令重啟Containerd。
```
systemctl restart containerd
```
Containerd重啟後，登入節點執行以下命令，再次查看Containerd狀態是否恢複正常。
```
systemctl status containerd
```
若Containerd重啟後狀態仍異常，請登入節點執行以下命令查看Containerd日誌。
```
journalctl -u containerd
```

NTP異常處理-NTPProblem

問題原因

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

問題現象

Chronyd狀態為inactive。
節點狀態中NTPProblem為True。
若叢集配置了叢集節點異常警示，則節點時間服務異常時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

執行如下命令重啟Chronyd。
```
systemctl restart chronyd
```
Chronyd重啟後，登入節點執行以下命令，再次查看Chronyd狀態是否恢複正常。
```
systemctl status chronyd
```
若Chronyd重啟後狀態仍異常，請登入節點執行以下命令查看Chronyd日誌。
```
journalctl -u chronyd
```

節點PLEG異常-PLEG is not healthy

問題原因

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警示管理。

解決方案

依次重啟節點關鍵組件Dockerd、Contatinerd、Kubelet，重啟後查看節點是否恢複正常。
若節點關鍵組件重啟後節點仍未恢複正常，可嘗試重啟異常節點。具體操作，請參見重啟執行個體。
警告
重啟節點可能會導致您的業務中斷，請謹慎操作。
若異常節點系統為CentOS 7.6，參見使用CentOS 7.6系統時kubelet日誌含有“Reason:KubeletNotReady Message:PLEG is not healthy:”資訊進行排查。

節點調度資源不足

問題原因

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

問題現象

當叢集中的節點調度資源不足時，會導致Pod調度失敗，出現以下常見錯誤資訊：

叢集CPU資源不足：0/2 nodes are available: 2 Insufficient cpu
叢集記憶體資源不足：0/2 nodes are available: 2 Insufficient memory
叢集臨時儲存不足：0/2 nodes are available: 2 Insufficient ephemeral-storage

其中調度器判定節點資源不足的計算方式為：

叢集節點CPU資源不足的判定方式：當前Pod請求的CPU資源總量>（節點可分配的CPU資源總量-節點已指派的CPU資源總量）
叢集節點記憶體資源不足的判定方式：當前Pod請求的記憶體資源總量>（節點可分配的記憶體資源總量-節點已指派的記憶體資源總量）
叢集節點臨時儲存不足的判定方式：當前Pod請求的臨時儲存總量>（節點可分配的臨時儲存總量-節點已指派的臨時儲存總量）

如果當前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%)

其中：

Allocatable：表示本節點可分配的（CPU/記憶體/臨時儲存）資源總量。
Allocated resources：表示本節點已經分配的（CPU/記憶體/臨時儲存）資源總量。

解決方案

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

刪除或減少不必要的Pod，降低節點的負載。具體操作，請參見管理容器組（Pod）。
根據自身業務情況，限制Pod的資源配置。具體操作，請參見設定容器的CPU和記憶體資源上下限。
您可以使用ACK提供的資源畫像功能，基於資源使用量的歷史資料獲得容器粒度的資源規格推薦，簡化為容器配置Request和Limit的複雜度。更多資訊，請參見資源畫像。
在叢集中添加新的節點。具體操作，請參見建立節點池。
為節點進行升配。具體操作，請參見升配Worker節點的資源。

節點CPU不足

問題原因

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

問題現象

當節點CPU不足時，可能會導致節點狀態異常。
若叢集配置了叢集節點異常警示，則節點CPU使用率>=85%時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

通過節點的監控查看CPU增長曲線，確認異常出現時間點，檢查節點上的進程是否存在CPU佔用過高的現象。具體操作，請參見檢查節點的監控。
降低節點的負載，具體操作，請參見節點調度資源不足。
如需重啟節點，可嘗試重啟異常節點。具體操作，請參見重啟執行個體。
警告
重啟節點可能會導致您的業務中斷，請謹慎操作。

節點記憶體不足-MemoryPressure

問題原因

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

問題現象

當節點的可用記憶體低於memory.available配置項時，則節點狀態中MemoryPressure為True，同時該節點上的容器被驅逐。關於節點驅逐，請參見節點壓力驅逐。
當節點記憶體不足時，會有以下常見錯誤資訊：
- 節點狀態中MemoryPressure為True。
- 當節點上的容器被驅逐時：
  - 在被驅逐的容器事件中可看到關鍵字The node was low on resource: memory。
  - 在節時間點事件中可看到關鍵字attempting to reclaim memory。
- 可能會導致系統OOM異常，當出現系統OOM異常時，節時間點事件中可看到關鍵字System OOM。
若叢集配置了叢集節點異常警示，則節點記憶體使用量率>=85%時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

通過節點的監控查看記憶體增長曲線，確認異常出現時間點，檢查節點上的進程是否存在記憶體泄露現象。具體操作，請參見檢查節點的監控。
降低節點的負載，具體操作，請參見節點調度資源不足。
如需重啟節點，可嘗試重啟異常節點。具體操作，請參見重啟執行個體。
警告
重啟節點可能會導致您的業務中斷，請謹慎操作。

節點索引節點不足-InodesPressure

問題原因

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

問題現象

當節點的可用索引節點低於inodesFree配置項時，則節點狀態中InodesPressure為True，同時該節點上的容器被驅逐。關於節點驅逐，請參見節點壓力驅逐。
當節點索引點不足時，通常會有以下常見錯誤資訊：
- 節點狀態中InodesPressure為True。
- 當節點上的容器被驅逐時：
  - 被驅逐的容器事件中可看到關鍵字The node was low on resource: inodes。
  - 節時間點事件中可看到關鍵字attempting to reclaim inodes。
若叢集配置了叢集節點異常警示，則節點索引節點不足時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

通過節點的監控查看索引節點增長曲線，確認異常出現時間點，檢查節點上的進程是否存在佔用索引節點過多現象。具體操作，請參見檢查節點的監控。
其他問題相關操作，請參見解決Linux執行個體磁碟空間滿問題。

節點PID不足-NodePIDPressure

問題原因

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

問題現象

當節點的可用PID低於pid.available配置項時，則節點狀態中NodePIDPressure為True，同時該節點上的容器被驅逐。關於節點驅逐，請參見節點壓力驅逐。
若叢集配置了叢集節點異常警示，則節點PID不足時可收到相關警示。關於配置警示，請參見Container Service警示管理。

解決方案

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

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

執行如下命令，查看佔用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

根據進程號找到對應進程和所屬的Pod，分析佔用PID過多的原因並最佳化對應代碼。
降低節點的負載。具體操作，請參見節點調度資源不足。
如需重啟節點，可嘗試重啟異常節點。具體操作，請參見重啟執行個體。
警告
重啟節點可能會導致您的業務中斷，請謹慎操作。

節點磁碟空間不足-DiskPressure

問題原因

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

問題現象

當節點的可用磁碟空間低於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資料卷。更多資訊，請參見儲存CSI概述。
節點磁碟擴容。
降低節點的負載。具體操作，請參見節點調度資源不足。

節點IP資源不足-InvalidVSwitchId.IpNotEnough

問題原因

通常是節點上的容器數過多導致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警示管理。

解決方案

執行以下命令，查看節點重啟時間。
```
last reboot
```
預期輸出：
查看節點的監控，根據重啟時間排查出現異常的資源。具體操作，請參見檢查節點的監控。
查看節點的核心日誌，根據重啟時間排查異常日誌。具體操作，請參見檢查節點的診斷記錄。

如何解決auditd進程佔用大量磁碟IO或者系統日誌中出現audit: backlog limit exceeded錯誤的問題

問題原因

部分叢集的存量節點上預設配置了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配置有關：

登入叢集節點。
執行以下命令，檢查auditd規則。
```
sudo auditctl -l | grep -- ' -k docker'
```
如果該命令的輸出中包含如下資訊，說明該節點出現的問題與auditd配置有關。
```
-w /var/lib/docker -k docker
```

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

升級叢集版本
您可以通過升級叢集版本來修複該問題。具體操作，請參見升級ACK叢集K8s版本。
使用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
```