Container Service for Kubernetes:Troubleshoot node exceptions

Diagnóstico de falha de nó

Se um nó falhar, use o recurso Exception Diagnosis no ACK para diagnosticar o nó com um clique.

1. Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.

2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Nodes > Nodes.

3. Na página Nodes, localize o nó a ser diagnosticado e escolha More > Exception Diagnosis na coluna Actions.

4. No painel exibido, clique em Start Diagnosis. Em seguida, visualize os resultados do diagnóstico e as soluções recomendadas no console.

Detalhes do nó

1. Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.

2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Nodes > Nodes.

3. Na página Nodes, clique no nome do nó desejado ou clique em Details na coluna Actions para visualizar seus detalhes.

Status do nó

1. Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.

2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Nodes > Nodes.

3. Na página Nodes, visualize o status dos nós.

   • Se um nó estiver no estado Ready, ele está funcionando conforme o esperado.

   • Se um nó não estiver no estado Ready, clique em seu nome ou em Details na coluna Actions para visualizar seus detalhes.

     Nota

     Para coletar informações de status sobre condições como InodesPressure, DockerOffline e RuntimeOffline, instale o node-problem-detector e crie um centro de eventos no cluster. Por padrão, um centro de eventos é criado automaticamente para novos clusters. Para mais informações, consulte Criar e usar um centro de eventos para um cluster Kubernetes.

Eventos do nó

1. Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.

2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Nodes > Nodes.

3. Na página Nodes, clique no nome do nó desejado ou clique em Details na coluna Actions para visualizar seus detalhes.

   Os eventos do nó estão listados na parte inferior da página de detalhes.

Logs de diagnóstico do nó

• Use o recurso de diagnóstico de nó fornecido pelo Container Intelligence Service no console para coletar logs de diagnóstico. Para mais informações, consulte Diagnóstico de nó.

• Use um script para coletar logs de diagnóstico. Para mais informações, consulte Como coletar informações de diagnóstico sobre um cluster Kubernetes?.

Componentes principais do nó

• kubelet

  • Verificar o status do kubelet

    Faça login no nó e execute o seguinte comando:

    systemctl status kubelet

    Saída esperada:

    

  • Verificar os logs do kubelet

    Faça login no nó e execute o seguinte comando para visualizar os logs do kubelet. Para mais informações sobre como visualizar logs do kubelet, consulte Coletar logs de diagnóstico do nó.

    journalctl -u kubelet

  • Verificar a configuração do kubelet

    Faça login no nó e execute o seguinte comando:

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

• Runtime

  • Verificar o dockerd

    • Verificar o status do dockerd

      Faça login no nó e execute o seguinte comando:

      systemctl status docker

      Saída esperada:

      

    • Verificar os logs do dockerd

      Faça login no nó e execute o seguinte comando para visualizar os logs do dockerd. Para mais informações sobre como visualizar logs do dockerd, consulte Coletar logs de diagnóstico do nó.

      journalctl -u docker

    • Verificar a configuração do dockerd

      Faça login no nó e execute o seguinte comando:

      cat /etc/docker/daemon.json

  • Verificar o containerd

    • Verificar o status do containerd

      Faça login no nó e execute o seguinte comando:

      systemctl status containerd

      Saída esperada:

      

    • Verificar os logs do containerd

      Faça login no nó e execute o seguinte comando para visualizar os logs do containerd. Para mais informações sobre como visualizar logs do containerd, consulte Coletar logs de diagnóstico do nó.

      journalctl -u containerd

• NTP

  • Verificar o status do serviço NTP

    Faça login no nó e execute o seguinte comando:

    systemctl status chronyd

    Saída esperada:

    

  • Verificar os logs do serviço NTP

    Faça login no nó e execute o seguinte comando:

    journalctl -u chronyd

Monitoramento de nó

• Cloud Monitor

  Os clusters ACK são integrados ao CloudMonitor. Faça login no console do CloudMonitor para visualizar informações básicas de monitoramento da instância ECS correspondente. Para mais informações sobre como monitorar nós, consulte Monitorar nós.

• Managed Service for Prometheus

  1. Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.

  2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Operations > Prometheus Monitoring.

  3. Na página Prometheus Monitoring, clique na aba Node Monitoring e, em seguida, clique na aba Nodes.

  4. Na página Nodes, selecione o nó que deseja visualizar. Esta página exibe informações de monitoramento do nó, como uso de CPU, memória e disco.

Grupos de segurança do nó

Para mais informações sobre como verificar os grupos de segurança de um nó, consulte Visão geral de grupo de segurança e Configure grupos de segurança do cluster.

Causa

Problemas no processo do kubelet, no runtime de contêiner ou configurações inválidas do kubelet geralmente causam exceções do kubelet.

Sintomas

O status do kubelet é inactive.

Solução

1. Execute o seguinte comando para reiniciar o kubelet. Reiniciar o kubelet não afeta os contêineres em execução.

   systemctl restart kubelet

2. Após a reinicialização do kubelet, faça login no nó e execute o seguinte comando para verificar o status do kubelet.

   systemctl status kubelet

3. Se o status do kubelet ainda estiver anormal, faça login no nó e execute o seguinte comando para visualizar os logs do kubelet.

   journalctl -u kubelet

   • Se o log contiver mensagens de erro específicas, use palavras-chave das mensagens para solucionar o problema.

   • Se você determinar que a configuração do kubelet é inválida, execute os seguintes comandos para modificá-la.

     vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf   # Modify the kubelet configuration.
     systemctl daemon-reload;systemctl restart kubelet         # Reload the configuration and restart kubelet.

Causa

Esse problema é frequentemente causado por uma configuração inválida do dockerd, alta carga de processos ou alta carga do nó.

Sintomas

• O status do dockerd é inactive.

• O status do dockerd é active (running), mas o serviço não responde, causando exceções no nó. Por exemplo, comandos como docker ps e docker exec falham.

• A condição RuntimeOffline no nó é True.

• Se você configurou alertas para exceções de nó no cluster, receberá um alerta quando ocorrer uma exceção do dockerd. Para mais informações sobre como configurar alertas, consulte Gerenciamento de alertas.

Solução

1. Execute o seguinte comando para reiniciar o dockerd.

   systemctl restart docker

2. Após a reinicialização do dockerd, faça login no nó e execute o seguinte comando para verificar o status do dockerd.

   systemctl status docker

3. Se o status permanecer anormal, faça login no nó e execute o seguinte comando para verificar os logs do dockerd.

   journalctl -u docker

Causa

Esse problema é tipicamente causado por uma configuração inválida do containerd, alta carga de processos ou alta carga do nó.

• O status do containerd é inactive.

• A condição RuntimeOffline no nó é True.

• Se você configurou alertas para exceções de nó no cluster, receberá um alerta quando ocorrer uma exceção do containerd. Para mais informações, consulte Gerenciamento de alertas do ACK.

Solução

1. Execute o seguinte comando para reiniciar o containerd:

   systemctl restart containerd

2. Faça login no nó e execute o seguinte comando para verificar o status do containerd:

   systemctl status containerd

3. Se o status ainda estiver anormal, faça login no nó e execute o seguinte comando para visualizar os logs do containerd:

   journalctl -u containerd

Causa

Esse problema é tipicamente causado por um estado anormal do processo NTP.

Sintomas

• O status do chronyd é inactive.

• A condição NTPProblem no nó é True.

• Se você configurou alertas para exceções de nó no cluster, receberá um alerta quando o serviço de tempo de um nó apresentar mau funcionamento. Para mais informações sobre como configurar alertas, consulte Gerenciamento de alertas do ACK.

Solução

1. Execute o seguinte comando para reiniciar o chronyd:

   systemctl restart chronyd

2. Após a reinicialização do chronyd, faça login no nó e execute o seguinte comando para verificar o status do chronyd:

   systemctl status chronyd

3. Se o status do chronyd ainda estiver anormal após a reinicialização, faça login no nó e execute o seguinte comando para verificar os logs do chronyd:

   journalctl -u chronyd

Causa

O Pod Lifecycle Event Generator (PLEG) registra eventos durante todo o ciclo de vida de um pod, como inícios e encerramentos de contêineres. O erro PLEG is not healthy geralmente indica que o runtime de contêiner no nó não está respondendo ou que há um problema conhecido com a versão do systemd do nó.

Sintomas

• O status do nó é NotReady.

• Os logs do kubelet contêm a seguinte mensagem:

  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.

• Se você configurou alertas para exceções de nó no cluster, receberá um alerta para exceções de PLEG. Para mais informações sobre como configurar alertas, consulte Gerenciamento de alertas do ACK.

Solução

1. Reinicie os componentes principais no nó na seguinte ordem: dockerd ou containerd e, em seguida, kubelet. Após reiniciar os componentes, verifique se o status do nó retorna ao normal.

2. Se reiniciar os componentes não resolver o problema, reinicie a instância do nó afetado. Para mais informações, consulte Reiniciar uma instância.

   Aviso

   Reiniciar um nó pode interromper suas cargas de trabalho. Prossiga com cautela.

3. Se o nó afetado executar CentOS 7.6, consulte Solucionar o erro 'PLEG is not healthy' no CentOS 7.6.

Causa

Esse problema ocorre tipicamente quando os nós no cluster têm recursos insuficientes.

Sintomas

Se a solicitação de recursos de um Pod exceder os recursos disponíveis de um nó (Alocável menos alocado), o Pod não será agendado nesse nó.

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%)

Soluções

Para resolver a insuficiência de recursos para agendamento, reduza a carga em seus nós:

• Exclua ou reduza o número de Pods desnecessários para diminuir a carga do nó. Para mais informações, consulte Gerencie Pods.

• Ajuste as solicitações e limites de recursos dos Pods com base em suas cargas de trabalho. Para mais informações, consulte Defina limites de recursos de CPU e memória para contêineres.

• Adicione novos nós ao cluster. Para mais informações, consulte Crie e gerencie pools de nós.

• Atualize as especificações dos nós. Para mais informações, consulte Redimensionar recursos do nó.

Para mais informações, consulte Recursos de CPU insuficientes, Recursos de memória insuficientes - MemoryPressure e Espaço em disco insuficiente - DiskPressure.

Causa

Esse problema ocorre tipicamente quando contêineres em um nó consomem CPU excessiva.

Sintomas

• A insuficiência de CPU no nó pode causar instabilidade no nó.

• Se você configurar alertas para exceções de nó no cluster, receberá um alerta quando o uso de CPU do nó atingir ou exceder 85%. Para mais informações sobre como configurar alertas, consulte Gerenciamento de alertas do ACK.

Solução

• Analise a tendência de uso de CPU nos dados de monitoramento do nó para identificar quando a exceção ocorreu e verifique se algum processo no nó está consumindo CPU excessiva. Para mais informações, consulte Verificar os dados de monitoramento dos nós.

• Reduza a carga no nó. Para mais informações, consulte Recursos insuficientes no nó para agendamento.

• Se necessário, reinicie o nó afetado. Para mais informações, consulte Reiniciar uma instância.

  Aviso

  Reiniciar um nó pode interromper seus serviços. Prossiga com cautela.

Causa

Esse problema ocorre tipicamente quando contêineres em um nó usam muita memória.

Sintomas

• Se a memória disponível de um nó cair abaixo do limiar memory.available, sua condição MemoryPressure será definida como True, e o sistema expulsará contêineres do nó. Para mais informações sobre esse processo, consulte Evicção por pressão no nó.

• Quando um nó está com pouca memória, você pode observar o seguinte:

  • A condição MemoryPressure do nó é True.

  • Quando contêineres no nó são expulsos:

    • Eventos para os contêineres expulsos mostram a mensagem: The node was low on resource: memory.

    • Eventos do nó mostram a mensagem: attempting to reclaim memory.

  • O nó pode sofrer um evento System OOM. Nesse caso, os eventos do nó conterão a mensagem System OOM.

• Se você configurou alertas para o seu cluster, receberá um alerta quando o uso de memória de um nó atingir ou exceder 85%. Para mais informações sobre como configurar alertas, consulte Gerenciamento de alertas do ACK.

Solução

• Analise a tendência de uso de memória nos dados de monitoramento do nó para identificar exatamente quando o problema ocorreu. Verifique se há vazamentos de memória em qualquer processo no nó. Para mais informações, consulte Verificar os dados de monitoramento dos nós.

• Reduza a carga no nó. Para mais informações, consulte Recursos insuficientes no nó para agendamento.

• Se necessário, reinicie o nó afetado. Para mais informações, consulte Reiniciar uma instância.

  Aviso

  Reiniciar um nó pode interromper suas cargas de trabalho. Prossiga com cautela.

Causa

Esse problema ocorre tipicamente quando contêineres em um nó consomem um número excessivo de inodes.

Sintomas

• Quando o número de inodes disponíveis em um nó cai abaixo do valor do parâmetro inodesFree, a condição de nó InodesPressure torna-se True, e o nó expulsa os contêineres. Para mais informações, consulte Evicção por pressão no nó.

• Quando um nó está com poucos inodes, você pode observar o seguinte:

  • A condição de nó InodesPressure é True.

  • Quando o nó expulsa contêineres:

    • Eventos para contêineres expulsos mostram a mensagem: The node was low on resource: inodes.

    • Eventos do nó mostram a mensagem: attempting to reclaim inodes.

• Se você configurou alertas para o seu cluster, receberá um alerta quando um nó estiver com poucos inodes. Para saber como configurar alertas, consulte Gerenciar alertas.

Solução

• Analise a tendência de uso de inodes nos dados de monitoramento do nó para identificar quando o problema começou. Verifique se algum processo no nó está consumindo um número excessivo de inodes. Para mais informações, consulte Verificar os dados de monitoramento de um nó.

• Para solução de problemas adicional, consulte Solucionar problemas de espaço em disco cheio em uma instância Linux.

Causa

Esse problema ocorre tipicamente quando contêineres em um nó consomem muitos PIDs.

Sintomas

• Quando o número de PIDs disponíveis em um nó cai abaixo do limiar pid.available, sua condição NodePIDPressure é definida como True, e o kubelet expulsa contêineres do nó. Para mais informações sobre evicção de nó, consulte Evicção por pressão no nó.

• Se você configurou alertas para exceções de nó do cluster, receberá um alerta quando um nó entrar na condição NodePIDPressure. Para mais informações sobre como configurar alertas, consulte Gerenciamento de alertas do ACK.

Solução

1. Execute os seguintes comandos para verificar o limite máximo de PID e o PID mais alto em uso no nó.

   sysctl kernel.pid_max  # Check the maximum PID limit.
   ps -eLf|awk '{print $2}' | sort -rn| head -n 1   # Check the highest PID in use.

2. Execute o seguinte comando para identificar os cinco principais processos com mais threads.

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

   Saída esperada:

   # The first column shows the thread count, and the second column shows the process ID.
   73 9743
   75 9316
   76 2812
   77 5726
   93 5691

3. Use os IDs de processo para identificar os processos e seus pods correspondentes. Analise por que esses processos estão usando muitos PIDs e otimize sua aplicação.

4. Reduza a carga no nó. Para mais informações, consulte Recursos insuficientes no nó para agendamento.

5. Se necessário, reinicie o nó afetado. Para mais informações, consulte Reiniciar uma instância.

   Aviso

   Reiniciar um nó pode interromper seus serviços. Prossiga com cautela.

Causa

Esse problema ocorre tipicamente quando contêineres ou imagens grandes em um nó consomem espaço em disco excessivo.

Sintomas

• Quando o espaço em disco disponível de um nó cai abaixo do limiar imagefs.available, sua condição DiskPressure é definida como True.

• Quando o espaço em disco disponível no sistema de arquivos raiz do nó cai abaixo do limiar nodefs.available, os pods no nó são expulsos. Para mais informações sobre evicção por pressão no nó, consulte Evicção por pressão no nó.

• Quando um nó está com pouco espaço em disco, você pode observar o seguinte:

  • A condição DiskPressure do nó é True.

  • Depois que a política de recuperação de imagem é acionada, se o espaço em disco disponível ainda não atender ao limiar de integridade (80% por padrão), os eventos do nó incluirão a mensagem failed to garbage collect required amount of images.

  • Quando pods no nó são expulsos:

    • Eventos para os pods expulsos contêm a mensagem The node was low on resource: [DiskPressure].

    • Eventos do nó incluem mensagens como attempting to reclaim ephemeral-storage ou attempting to reclaim nodefs.

• Se você configurou alertas para o seu cluster, receberá um alerta quando o uso de disco de um nó atingir ou exceder 85%. Para mais informações sobre como configurar alertas, consulte Gerenciamento de alertas do ACK.

Soluções

• Analise a tendência de uso de disco nos dados de monitoramento do nó para identificar quando a exceção ocorreu e verifique se algum processo no nó está consumindo espaço em disco excessivo. Para mais informações, consulte Verificar os dados de monitoramento dos nós.

• Exclua arquivos desnecessários do disco. Para mais informações, consulte Resolver problemas de "no space left" no Linux.

• Limite os recursos ephemeral-storage dos pods com base em suas cargas de trabalho. Para mais informações, consulte Defina limites de CPU e memória para contêineres.

• Use produtos de armazenamento da Alibaba Cloud e evite usar volumes hostPath sempre que possível. Para mais informações, consulte Armazenamento.

• Aumente o tamanho do disco do nó.

• Reduza a carga no nó. Para mais informações, consulte Recursos insuficientes no nó para agendamento.

Causa

Esse problema ocorre quando muitos contêineres em um nó usam todos os endereços IP disponíveis.

Sintomas

• Os Pods falham ao iniciar e permanecem no estado ContainerCreating. Os logs do Pod mostram uma mensagem de erro que contém a palavra-chave InvalidVSwitchId.IpNotEnough. Para verificar os logs do Pod, consulte Solução de problemas de 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"

• Se você ativou alertas para nós do cluster, receberá um alerta quando um nó tiver endereços IP insuficientes. Para configurar alertas, consulte Gerenciamento de alertas do ACK.

Solução

Reduza o número de contêineres no nó. Para obter instruções, consulte Recursos insuficientes no nó para agendamento. Para mais informações, consulte O que posso fazer se houver endereços IP insuficientes fornecidos por um vSwitch em um cluster que usa Terway? e Falha na atribuição de IP do Pod no modo de rede Terway.

Causa

As causas comuns incluem status anormal do nó, grupos de segurança mal configurados ou alta carga de rede.

Sintomas

• Impossibilidade de fazer login no nó.

• A condição do nó é Unknown.

• Se você configurou alertas para exceções de nó, um alerta será acionado quando o uso de largura de banda de internet de saída do nó atingir ou exceder 85%. Para mais informações sobre como configurar alertas, consulte Gerenciamento de alertas do ACK.

Solução

• Se você não conseguir fazer login no nó, solucione o problema da seguinte forma:

  • Verifique se a instância do nó está Running.

  • Verifique a configuração do grupo de segurança do nó. Para mais informações, consulte Verificar os grupos de segurança dos nós.

• Se o nó estiver enfrentando alta carga de rede, solucione o problema da seguinte forma:

  • Analise as tendências de uso de rede do nó nos dados de monitoramento para identificar pods que consomem largura de banda excessiva. Para mais informações, consulte Verificar os dados de monitoramento dos nós.

  • Use políticas de rede para controlar o tráfego dos pods. Para mais informações, consulte Usar políticas de rede em clusters ACK.

Causa

Esse problema ocorre tipicamente quando um nó está sobrecarregado.

Sintomas

• Durante a reinicialização, o status do nó é NotReady.

• Se você configurou alertas para exceções de nó no cluster, receberá um alerta quando um nó for reiniciado inesperadamente. Para mais informações, consulte Gerenciamento de alertas do ACK.

Solução

1. Execute o seguinte comando para verificar quando o nó foi reiniciado.

   last reboot

   Saída esperada:

2. Analise os dados de monitoramento do nó e solucione anomalias de recursos com base no horário da reinicialização. Para mais informações, consulte Verificar os dados de monitoramento dos nós.

3. Verifique os logs do kernel do nó e solucione quaisquer exceções registradas próximo ao horário da reinicialização. Para mais informações, consulte Coletar os logs de diagnóstico dos nós.

Causa

Por padrão, alguns nós existentes em um cluster são configurados com regras do auditd para Docker. Quando esses nós usam o runtime de contêiner Docker, essas regras fazem com que o sistema registre logs de auditoria para operações do Docker. Em casos raros, como reinicializações em massa de contêineres, E/S intensiva de arquivos dentro de contêineres ou bugs de kernel, o sistema pode gerar um alto volume de logs de auditoria. Isso pode levar a alta E/S de disco pelo processo auditd ou a erros audit: backlog limit exceeded no log do sistema.

Sintomas

Esse problema afeta apenas nós que usam o runtime de contêiner Docker. Você pode observar os seguintes sintomas em um nó afetado:

• Ao executar o comando iotop -o -d 1, a saída mostra que o valor DISK WRITE para o processo auditd é consistentemente 1 MB/s ou superior.

• Ao executar o comando dmesg -d, a saída contém logs com a palavra-chave audit_printk_skb, como audit_printk_skb: 100 callbacks suppressed.

• Ao executar o comando dmesg -d, a saída contém a mensagem audit: backlog limit exceeded.

Solução

Siga estas etapas para verificar se a configuração do auditd está causando o problema no seu nó:

1. Faça login no nó afetado.

2. Execute o seguinte comando para verificar as regras do auditd.

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

   Se a saída incluir a seguinte linha, a configuração do auditd está causando o problema.

   -w /var/lib/docker -k docker

Se a verificação confirmar a causa, escolha uma das seguintes soluções.

• Atualizar a versão do cluster

  Atualizar o cluster resolve esse problema. Para mais informações, consulte Atualize manualmente um cluster.

• Usar o runtime de contêiner containerd

  Para clusters que você não pode atualizar, é possível contornar esse problema usando containerd em vez de Docker como runtime de contêiner. Execute as seguintes etapas para cada pool de nós que usa o runtime de contêiner Docker:

  1. Clone o pool de nós de origem para criar um novo pool de nós que use containerd como runtime de contêiner. Certifique-se de que todas as outras configurações do novo pool de nós sejam idênticas às do pool de origem.

  2. Durante horários de baixa demanda, drene os nós no pool de nós de origem um por um. Certifique-se de que nenhum pod de aplicação esteja implantado no pool de nós.

• Atualizar a configuração do auditd no nó

  Se você não puder atualizar o cluster ou mudar para o runtime de contêiner containerd, é possível contornar esse problema atualizando manualmente a configuração do auditd. Execute as seguintes etapas em cada nó que usa o runtime de contêiner Docker.

  1. Faça login no nó afetado.

  2. Execute o seguinte comando para excluir as regras do auditd relacionadas ao Docker.

     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. Execute o seguinte comando para aplicar as novas regras do 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