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:
- O AKS reinicia o nó.
- Se o nó permanecer não íntegro após a reinicialização, o AKS recria a imagem do nó.
- 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.
Azure Kubernetes Service