节点异常问题排查

本文目录

诊断流程

1. 查看节点是否处于异常状态。具体操作，请参见检查节点的状态。

   • 若节点处于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解决。

2. 若根据诊断流程未能排查问题，请使用容器服务ACK提供的故障诊断功能进行排查。具体操作，请参见节点故障诊断。

3. 若问题仍未解决，请提交工单排查。

常见排查方法

节点故障诊断

当节点出现故障时，您可以使用容器服务ACK提供的故障诊断功能，一键诊断节点异常。

1. 登录容器服务管理控制台，在左侧导航栏选择集群列表。

2. 在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择节点管理 > 节点。

3. 在节点页面，单击目标诊断节点右侧操作列下的故障诊断。

4. 在弹出的面板中单击发起诊断。

5. 在诊断详情页面，根据诊断后的异常信息进行排查。

检查节点的详情

1. 登录容器服务管理控制台，在左侧导航栏选择集群列表。

2. 在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择节点管理 > 节点。

3. 在节点页面，单击目标节点名称或者目标节点右侧操作列下的更多 > 详情，查看节点的详情。

检查节点的状态

1. 登录容器服务管理控制台，在左侧导航栏选择集群列表。

2. 在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择节点管理 > 节点。

3. 在节点页面，可查看对应节点的状态。

   • 若节点状态为运行中，说明节点运行正常。

   • 若节点状态不是运行中，可单击目标节点名称或者目标节点右侧操作列下的更多 > 详情，查看异常状态节点的详情。

     说明

     若您要收集InodesPressure、DockerOffline、RuntimeOffline等类型的状态信息，需要在集群中安装node-problem-detector并创建事件中心，该功能在创建集群时默认选中。更多信息，请参见创建并使用K8s事件中心。

检查节点的事件

1. 登录容器服务管理控制台，在左侧导航栏选择集群列表。

2. 在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择节点管理 > 节点。

3. 在节点页面，单击目标节点名称或者目标节点右侧操作列下的更多 > 详情，查看节点的详情。

   在节点详情页面的最下方，可查看节点事件信息。

检查节点的诊断日志

• 使用脚本收集诊断日志：具体操作，请参见如何收集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监控

  1. 登录容器服务管理控制台，在左侧导航栏选择集群列表。

  2. 在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择运维管理 > Prometheus 监控。

  3. 在Prometheus 监控页面，单击节点监控页签，然后再单击集群节点监控详情页签。

  4. 在集群节点监控详情页面选择待查看的节点，可查看对应节点的CPU、内存、磁盘等监控信息。

检查节点的安全组

关于如何检查节点的安全组，请参见安全组概述和配置集群安全组。

Kubelet异常处理

问题原因

通常是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异常处理-RuntimeOffline

问题原因

通常是Dockerd配置异常、进程负载异常、节点负载异常等原因导致。

问题现象

• Dockerd状态为inactive。

• Dockerd状态为active (running)，但未正常工作，导致节点异常。通常有docker ps、docker exec等命令执行失败的现象。

• 节点状态中RuntimeOffline为True。

• 若集群配置了集群节点异常报警，则节点Dockerd异常时可收到相关报警。关于配置报警，请参见容器服务报警管理。

解决方案

1. 执行如下命令重启Dockerd。

   systemctl restart docker

2. Dockerd重启后，登录节点执行以下命令，再次查看Dockerd状态是否恢复正常。

   systemctl status docker

3. 若Dockerd重启后状态仍异常，请登录节点执行以下命令查看Dockerd日志。

   journalctl -u docker

Containerd异常处理-RuntimeOffline

问题原因

通常是Containerd配置异常、进程负载异常、节点负载异常等原因导致。

• Containerd状态为inactive。

• 节点状态中RuntimeOffline为True。

• 若集群配置了集群节点异常报警，则节点Containerd异常时可收到相关报警。关于配置报警，请参见容器服务报警管理。

解决方案

1. 执行如下命令重启Containerd。

   systemctl restart containerd

2. Containerd重启后，登录节点执行以下命令，再次查看Containerd状态是否恢复正常。

   systemctl status containerd

3. 若Containerd重启后状态仍异常，请登录节点执行以下命令查看Containerd日志。

   journalctl -u containerd

NTP异常处理-NTPProblem

问题原因

通常是NTP进程状态异常导致。

问题现象

• Chronyd状态为inactive。

• 节点状态中NTPProblem为True。

• 若集群配置了集群节点异常报警，则节点时间服务异常时可收到相关报警。关于配置报警，请参见容器服务报警管理。

解决方案

1. 执行如下命令重启Chronyd。

   systemctl restart chronyd

2. Chronyd重启后，登录节点执行以下命令，再次查看Chronyd状态是否恢复正常。

   systemctl status chronyd

3. 若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异常时可收到相关报警。关于配置报警，请参见容器服务报警管理。

解决方案

1. 依次重启节点关键组件Dockerd、Contatinerd、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不足时，可能会导致节点状态异常。

• 若集群配置了集群节点异常报警，则节点CPU使用率>=85%时可收到相关报警。关于配置报警，请参见容器服务报警管理。

解决方案

• 通过节点的监控查看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%时可收到相关报警。关于配置报警，请参见容器服务报警管理。

解决方案

• 通过节点的监控查看内存增长曲线，确认异常出现时间点，检查节点上的进程是否存在内存泄露现象。具体操作，请参见检查节点的监控。

• 降低节点的负载，具体操作，请参见节点调度资源不足。

• 如需重启节点，可尝试重启异常节点。具体操作，请参见重启实例。

  警告

  重启节点可能会导致您的业务中断，请谨慎操作。

节点索引节点不足-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不足时可收到相关报警。关于配置报警，请参见容器服务报警管理。

解决方案

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. 如需重启节点，可尝试重启异常节点。具体操作，请参见重启实例。

   警告

   重启节点可能会导致您的业务中断，请谨慎操作。

节点磁盘空间不足-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数据卷。更多信息，请参见存储。

• 节点磁盘扩容。

• 降低节点的负载。具体操作，请参见节点调度资源不足。

节点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。

• 若集群配置了集群节点异常报警，则节点异常重启时可收到相关报警。关于配置报警，请参见容器服务报警管理。

解决方案

1. 执行以下命令，查看节点重启时间。

   last reboot

   预期输出：

2. 查看节点的监控，根据重启时间排查出现异常的资源。具体操作，请参见检查节点的监控 。

3. 查看节点的内核日志，根据重启时间排查异常日志。具体操作，请参见检查节点的诊断日志 。

如何解决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配置有关：

1. 登录集群节点。

2. 执行以下命令，检查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