Partilhar via


Reparo automático do nó do Serviço Kubernetes do Azure (AKS)

O Azure Kubernetes Service (AKS) monitoriza continuamente o estado de funcionamento dos nós de trabalho e realiza uma reparação automática dos nós se ficarem em mau estado de funcionamento. A plataforma de máquina virtual (VM) do Azure executa manutenção em VMs com problemas. O AKS e as VMs do Azure trabalham em conjunto para minimizar as interrupções do serviço para os clusters.

Neste artigo, você aprenderá como a funcionalidade de reparo automático de nó se comporta para nós Windows e Linux.

Como o AKS verifica os nós NotReady

O AKS usa as seguintes regras para determinar se um nó não está íntegro e precisa de reparo:

  • O nó relata o status NotReady em verificações consecutivas dentro de um período de tempo de 10 minutos.
  • O nó não relata nenhum status em 10 minutos.

Você pode verificar manualmente o estado de integridade de seus nós com o kubectl get nodes comando.

Como funciona a reparação automática

Nota

O AKS inicia operações de reparo com a conta de usuário aks-remediator.

Se o AKS identificar um nó não íntegro que permanece não íntegro por pelo menos cinco minutos, o AKS executa as seguintes ações:

  1. O AKS reinicia o nó.
  2. Se o nó permanecer não íntegro após a reinicialização, o AKS recria a imagem do nó.
  3. Se o nó permanecer não íntegro após a reimagem e for um nó Linux, o AKS reimplantará o nó.

O AKS tenta reiniciar, recriar a imagem e reimplantar a sequência até três vezes se o nó permanecer não íntegro. O processo geral de reparo automático pode levar até uma hora para ser concluído.

Limitações

A reparação automática do nó AKS é um serviço de melhor esforço e não garantimos que o nó seja restaurado de volta ao estado saudável. Se o nó persistir em um estado não íntegro, recomendamos que você realize uma investigação manual do nó. Saiba mais sobre como solucionar problemas do status NotReady do nó.

Há casos em que o AKS não realiza reparos automáticos. A falha ao reparar automaticamente o nó pode ocorrer por design ou se o Azure não puder detetar a existência de um problema. Exemplos de quando o reparo automático não é realizado incluem:

  • O status de um nó não está sendo relatado devido a um erro na configuração da rede.
  • Um nó falhou ao se registrar inicialmente como um nó íntegro.
  • Se uma das seguintes manchas estiver presente no nó: node.cloudprovider.kubernetes.io/shutdown, ToBeDeletedByClusterAutoscaler.

Monitorar o reparo automático do nó usando eventos do Kubernetes

Quando o AKS executa o reparo automático do nó em seu cluster, o AKS emite eventos do Kubernetes da fonte aks-auto-repair para visibilidade. Os eventos a seguir aparecem em um objeto de nó quando o reparo automático acontece.

Para saber mais sobre como acessar, armazenar e configurar alertas em eventos do Kubernetes, consulte Usar eventos do Kubernetes para solução de problemas no Serviço Kubernetes do Azure.

Razão Mensagem do Evento Description
NodeRebootStart O reparo automático do nó está iniciando uma ação de reinicialização devido ao status NotReady persistir por mais de 5 minutos. Esse evento é emitido para notificá-lo quando a reinicialização está prestes a ser executada no seu nó. Esta ação é a primeira na sequência geral de reparo automático do nó.
NodeRebootEnd A ação de reinicialização do reparo automático do nó foi concluída. Emitido assim que a reinicialização é concluída no nó. Esse evento não indica o status de integridade (íntegro ou não íntegro) do nó após a reinicialização ser executada.
NodeReimageStart O reparo automático do nó está iniciando uma ação de recriação de imagem devido ao status NotReady persistir por mais de 5 minutos. Este evento é emitido para notificá-lo quando a reimagem está prestes a ser executada no seu nó.
NodeReimageEnd A ação de recriação de imagem do reparo automático do nó foi concluída. Emitido assim que a reimagem estiver completa no nó. Esse evento não indica o estado de integridade (íntegro ou não íntegro) do nó após a reimagem ser executada.
NodeRedeployStart O reparo automático do nó está iniciando uma ação de reimplantação devido ao status NotReady persistir por mais de 5 minutos. Esse evento é emitido para notificá-lo quando a reimplantação estiver prestes a ser executada no nó. Reimplantar é a última ação na sequência de reparo automático do nó.
NodeRedeployEnd A ação de reimplantação do reparo automático do nó foi concluída. Emitido assim que a reimplantação for concluída no nó. Esse evento não indica o status de integridade (íntegro ou não íntegro) do nó após a reimplantação ser executada.

Se ocorrer algum erro durante o processo de reparo automático do nó, os seguintes eventos serão emitidos com a mensagem de erro literal. Saiba mais sobre como solucionar erros comuns de reparo automático de nós.

Nota

O código de erro nas seguintes mensagens de evento varia dependendo do erro relatado.

Razão Mensagem do Evento Description
NodeRebootError A ação de reinicialização de reparo automático do nó falhou devido a uma falha de operação. Veja os detalhes do erro aqui: Código de erro Emitido quando há um erro com a ação de reinicialização.
NodeReimageError A ação de reimagem de reparo automático do nó falhou devido a uma falha de operação. Veja os detalhes do erro aqui: Código de erro Emitido quando há um erro com a ação de reimagem.
NodeRedeployError A ação de reimplantação de reparo automático do nó falhou devido a uma falha de operação. Veja os detalhes do erro aqui: Código de erro Emitido quando há um erro com a ação de reimplantação.

Próximos passos

Por padrão, você pode acessar eventos e logs do Kubernetes em seu cluster AKS da última 1 hora. Para armazenar e consultar eventos e logs dos últimos 90 dias, habilite o Container Insights para uma solução de problemas mais profunda em seu cluster AKS.