本文中含有需要您注意的重要提示信息，忽略該信息可能對您的業務造成影響，請務必仔細閱讀。
本文介紹關于節點異常問題的診斷流程、排查思路、常見問題及解決方案。
本文目錄
類別 | 內容 |
診斷流程 | |
常見排查方法 | |
常見問題及解決方案 |
|
診斷流程
查看節點是否處于異常狀態。具體操作，請參見檢查節點的狀態。
若節點處于NotReady狀態，可參考如下步驟進行排查：
檢查節點狀態信息，查看PIDPressure、DiskPressure、MemoryPressure等節點類型的狀態是否為True。若某一節點類型的狀態為True，則根據相應異常狀態關鍵字進行排查。具體操作，請參見Dockerd異常處理-RuntimeOffline、節點內存不足-MemoryPressure和節點索引節點不足-InodesPressure等進行解決。
檢查節點的關鍵組件和日志。
Kubelet
檢查Kubelet的狀態、日志、配置等是否存在異常。具體操作，請參見檢查節點的關鍵組件。
若Kubelet存在異常，請參見Kubelet異常處理操作。
Dockerd
檢查Dockerd的狀態、日志、配置等是否存在異常。具體操作，請參見檢查節點的關鍵組件。
若Dockerd存在異常，請參見Dockerd異常處理-RuntimeOffline操作。
Containerd
檢查Containerd的狀態、日志、配置等是否存在異常。具體操作，請參見檢查節點的關鍵組件。
若Containerd存在異常，請參見Containerd異常處理-RuntimeOffline操作。
NTP
檢查NTP服務的狀態、日志、配置等是否存在異常。具體操作，請參見檢查節點的關鍵組件。
若NTP服務存在異常，請參見NTP異常處理-NTPProblem操作。
檢查節點的診斷日志。具體操作，請參見檢查節點的診斷日志。
檢查節點的監控，查看節點CPU、內存、網絡等資源負載情況是否存在異常。具體操作，請參見檢查節點的監控。若節點負載異常，請參見節點CPU不足和節點內存不足-MemoryPressure等解決。
若節點處于Unknown狀態，可參考如下步驟進行排查。
檢查節點ECS實例狀態是否為運行中。
檢查節點的關鍵組件。
Kubelet
檢查Kubelet的狀態、日志、配置等是否存在異常。具體操作，請參見檢查節點的關鍵組件。
若Kubelet存在異常，請參見Kubelet異常處理操作。
Dockerd
檢查Dockerd的狀態、日志、配置等是否存在異常。具體操作，請參見檢查節點的關鍵組件。
若Dockerd存在異常，請參見Dockerd異常處理-RuntimeOffline操作。
Containerd
檢查Containerd的狀態、日志、配置等是否存在異常。具體操作，請參見檢查節點的關鍵組件。
若Containerd存在異常，請參見Containerd異常處理-RuntimeOffline操作。
NTP
檢查NTP服務的狀態、日志、配置等是否存在異常。具體操作，請參見檢查節點的關鍵組件。
若NTP服務存在異常，請參見NTP異常處理-NTPProblem操作。
檢查節點的診斷日志。具體操作，請參見檢查節點的診斷日志。
檢查節點的監控，查看節點CPU、內存、網絡等資源負載情況是否存在異常。具體操作，請參見檢查節點的監控。若節點負載異常，請參見節點CPU不足和節點內存不足-MemoryPressure解決。
若根據診斷流程未能排查問題，請使用容器服務ACK提供的故障診斷功能進行排查。具體操作，請參見節點故障診斷。
若問題仍未解決，請提交工單排查。
常見排查方法
節點故障診斷
當節點出現故障時，您可以使用容器服務ACK提供的故障診斷功能，一鍵診斷節點異常。
登錄容器服務管理控制臺。
在控制臺左側導航欄，單擊集群。
在集群列表頁面，單擊目標集群名稱或者目標集群右側操作列下的詳情。
在集群管理頁左側導航欄，選擇。
在節點管理頁面，單擊目標診斷節點右側操作列下的。
在診斷詳情頁面，根據診斷后的異常信息進行排查。
檢查節點的詳情
登錄容器服務管理控制臺。
在控制臺左側導航欄，單擊集群。
在集群列表頁面，單擊目標集群名稱或者目標集群右側操作列下的詳情。
在集群管理頁左側導航欄，選擇。
在節點頁面，單擊目標節點名稱或者目標節點右側操作列下的，查看節點的詳情。
檢查節點的狀態
登錄容器服務管理控制臺。
在控制臺左側導航欄，單擊集群。
在集群列表頁面，單擊目標集群名稱或者目標集群右側操作列下的詳情。
在集群管理頁左側導航欄，選擇。
在節點頁面，可查看對應節點的狀態。
若節點狀態為運行中，說明節點運行正常。
若節點狀態不是運行中，可單擊目標節點名稱或者目標節點右側操作列下的，查看異常狀態節點的詳情。
說明若您要收集InodesPressure、DockerOffline、RuntimeOffline等類型的狀態信息，需要在集群中安裝node-problem-detector并創建事件中心，該功能在創建集群時默認選中。更多信息，請參見創建并使用K8s事件中心。
檢查節點的事件
登錄容器服務管理控制臺。
在控制臺左側導航欄，單擊集群。
在集群列表頁面，單擊目標集群名稱或者目標集群右側操作列下的詳情。
在集群管理頁左側導航欄，選擇。
在節點頁面，單擊目標節點名稱或者目標節點右側操作列下的，查看節點的詳情。
在節點詳情頁面的最下方，可查看節點事件信息。
檢查節點的診斷日志
使用腳本收集診斷日志：具體操作，請參見如何收集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
檢查節點的監控
云監控
阿里云容器服務ACK集群集成了監控服務，可登錄云監控制臺查看對應ECS實例的基本監控信息，關于云監控節點的使用方式，請參見監控節點。
Prometheus監控
登錄容器服務管理控制臺。
在控制臺左側導航欄中，單擊集群。
在集群列表頁面中，單擊目標集群名稱或者目標集群右側操作列下的詳情。
在集群管理頁左側導航欄中，選擇。
在Prometheus監控頁面，單擊節點監控頁簽，在集群節點監控詳情頁面選擇待查看的節點，可查看對應節點的CPU、內存、磁盤等監控信息。
檢查節點的安全組
Kubelet異常處理
問題原因
通常是Kubelet進程異常、運行時異常、Kubelet配置有誤等原因導致。
問題現象
Kubelet狀態為inactive。
解決方案
執行如下命令重啟Kubelet。重啟Kubelet不會影響運行中的容器。
systemctl restart kubeletKubelet重啟后，登錄節點執行以下命令，再次查看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異常時可收到相關報警。關于配置報警，請參見容器服務報警管理。
解決方案
執行如下命令重啟Dockerd。
systemctl restart dockerDockerd重啟后，登錄節點執行以下命令，再次查看Dockerd狀態是否恢復正常。
systemctl status docker若Dockerd重啟后狀態仍異常，請登錄節點執行以下命令查看Dockerd日志。
journalctl -u docker
Containerd異常處理-RuntimeOffline
問題原因
通常是Containerd配置異常、進程負載異常、節點負載異常等原因導致。
Containerd狀態為inactive。
節點狀態中RuntimeOffline為True。
若集群配置了集群節點異常報警，則節點Containerd異常時可收到相關報警。關于配置報警，請參見容器服務報警管理。
解決方案
執行如下命令重啟Containerd。
systemctl restart containerdContainerd重啟后，登錄節點執行以下命令，再次查看Containerd狀態是否恢復正常。
systemctl status containerd若Containerd重啟后狀態仍異常，請登錄節點執行以下命令查看Containerd日志。
journalctl -u containerd
NTP異常處理-NTPProblem
問題原因
通常是NTP進程狀態異常導致。
問題現象
Chronyd狀態為inactive。
節點狀態中NTPProblem為True。
若集群配置了集群節點異常報警，則節點時間服務異常時可收到相關報警。關于配置報警，請參見容器服務報警管理。
解決方案
執行如下命令重啟Chronyd。
systemctl restart chronydChronyd重啟后，登錄節點執行以下命令，再次查看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異常時可收到相關報警。關于配置報警，請參見容器服務報警管理。
解決方案
依次重啟節點關鍵組件Dockerd、Contatinerd、Kubelet，重啟后查看節點是否恢復正常。
若節點關鍵組件重啟后節點仍未恢復正常，可嘗試重啟異常節點。具體操作，請參見重啟實例。
警告重啟節點可能會導致您的業務中斷，請謹慎操作。
若異常節點系統為CentOS 7.6，參見 使用CentOS 7.6系統時kubelet日志含有“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不足、節點內存不足-MemoryPressure和節點磁盤空間不足-DiskPressure。
節點CPU不足
問題原因
通常是節點上的容器占用CPU過多導致節點的CPU不足。
問題現象
當節點CPU不足時，可能會導致節點狀態異常。
若集群配置了集群節點異常報警，則節點CPU使用率>=85%時可收到相關報警。關于配置報警，請參見容器服務報警管理。
解決方案
節點內存不足-MemoryPressure
問題原因
通常是節點上的容器占用內存過多導致節點的內存不足。
問題現象
當節點的可用內存低于
memory.available配置項時，則節點狀態中MemoryPressure為True，同時該節點上的容器被驅逐。關于節點驅逐，請參見節點壓力驅逐。當節點內存不足時，會有以下常見錯誤信息：
節點狀態中MemoryPressure為True。
當節點上的容器被驅逐時：
在被驅逐的容器事件中可看到關鍵字The node was low on resource: memory。
在節點事件中可看到關鍵字attempting to reclaim memory。
可能會導致系統OOM異常，當出現系統OOM異常時，節點事件中可看到關鍵字System OOM。
若集群配置了集群節點異常報警，則節點內存使用率>=85%時可收到相關報警。關于配置報警，請參見容器服務報警管理。
解決方案
節點索引節點不足-InodesPressure
問題原因
通常是節點上的容器占用索引節點過多導致節點的索引節點不足。
問題現象
當節點的可用索引節點低于
inodesFree配置項時，則節點狀態中InodesPressure為True，同時該節點上的容器被驅逐。關于節點驅逐，請參見節點壓力驅逐。當節點索引點不足時，通常會有以下常見錯誤信息：
節點狀態中InodesPressure為True。
當節點上的容器被驅逐時：
被驅逐的容器事件中可看到關鍵字The node was low on resource: inodes。
節點事件中可看到關鍵字attempting to reclaim inodes。
若集群配置了集群節點異常報警，則節點索引節點不足時可收到相關報警。關于配置報警，請參見容器服務報警管理。
解決方案
通過節點的監控查看索引節點增長曲線，確認異常出現時間點，檢查節點上的進程是否存在占用索引節點過多現象。具體操作，請參見檢查節點的監控。
其他問題相關操作，請參見解決Linux實例磁盤空間滿問題。
節點PID不足-NodePIDPressure
問題原因
通常是節點上的容器占用PID過多導致節點的PID不足。
問題現象
當節點的可用PID低于
pid.available配置項時，則節點狀態中NodePIDPressure為True，同時該節點上的容器被驅逐。關于節點驅逐，請參見節點壓力驅逐。若集群配置了集群節點異常報警，則節點PID不足時可收到相關報警。關于配置報警，請參見容器服務報警管理。
解決方案
執行如下命令，查看節點的最大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%時可收到相關報警。關于配置報警，請參見容器服務報警管理。
解決方案
通過節點的監控查看磁盤增長曲線，確認異常出現時間點，檢查節點上的進程是否存在占用磁盤空間過多的現象。具體操作，請參見檢查節點的監控。
若有大量文件在磁盤上未清理，請清理文件。具體操作，請參見解決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資源不足時可收到相關報警。關于配置報警，請參見容器服務報警管理。
解決方案
降低節點上的容器數量。具體操作，請參見節點調度資源不足。其他相關操作，請參見Terway網絡場景中交換機的IP資源不足和Terway網絡模式擴容vSwitch后，依然無法分配Pod IP怎么辦？。
節點網絡異常
問題原因
通常是節點運行狀態異常、安全組配置有誤或網絡負載過高導致。
問題現象
節點無法登錄。
節點狀態Unknown。
若集群配置了集群節點異常報警，則節點公網流出帶寬使用率 >=85%時可收到相關報警。關于配置報警，請參見容器服務報警管理。
解決方案
若節點無法登錄，請參考以下步驟進行排查：
檢查節點實例狀態是否為運行中。
檢查節點的安全組配置。具體操作，請參見檢查節點的安全組。
若節點的網絡負載過高，請參考以下步驟進行排查：
通過節點的監控查節點網絡增長曲線，檢查節點上的Pod是否存在占用網絡帶寬過多的現象。具體操作，請參見檢查節點的監控。
使用網絡策略控制Pod的網絡流量。具體操作，請參見在ACK集群使用網絡策略。
節點異常重啟
問題原因
通常是節點負載異常等原因導致。
問題現象
在節點重啟的過程中，節點狀態為NotReady。
若集群配置了集群節點異常報警，則節點異常重啟時可收到相關報警。關于配置報警，請參見容器服務報警管理。
解決方案
如何解決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容器運行時的節點池進行如下操作：
通過克隆節點池的方式新建一個以Containerd為容器運行時的節點池，同時確保新節點池除容器運行時配置外的其他配置都與被克隆的目標節點池保持一致。
在業務低峰期對目標節點池內的節點逐個進行排空節點操作，確保已無業務服務部署在目標節點池中。
更新節點上的auditd配置
對于無法升級集群也不能使用Containerd容器運行時的場景，可以通過手動更新節點上的auditd配置的方法規避該問題。需要對每個使用Docker容器運行時的節點進行如下操作：
說明您可以對節點進行批量操作，具體操作，請參見批量運維節點。
登錄集群節點。
執行以下命令，刪除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執行以下命令，應用新的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