Solucionar erros comuns de reparo automático de nó
Quando o AKS (Serviço de Kubernetes do Azure) detecta um nó com um NotReady status por mais de cinco minutos, ele tenta reparar automaticamente o nó. O reparo automático do nó é um serviço de melhor esforço. Isso não garante que o nó possa ser restaurado para um estado íntegro. Para obter mais informações, consulte processo de reparo automático do nó.
Durante o processo de reparo automático do nó, o AKS inicia reboot, reimagee ações redeploy no nó não íntegro. Os erros podem ocorrer devido a vários motivos e os códigos de erro são descobertos por meio de eventos do Kubernetes. Você pode usar eventos do Kubernetes para monitorar o status do nó e as ações de reparo automático.
Este artigo fornece possíveis causas e soluções para erros comuns de reparo automático de nó e descreve as práticas recomendadas para monitorar o processo de reparo automático de nó.
Pré-requisitos
Verifique os seguintes eventos do Kubernetes para identificar o tipo de erro de reparo automático do nó:
| Motivo | Mensagem de evento | Descrição |
|---|---|---|
| Erro de reinicialização do nó | A ação de reinicialização do reparo automático do nó falhou devido a uma falha de operação: [código de erro aqui] | Emitido quando há um erro com a reboot ação. |
| Erro de Nó de Imagem | A ação de recriação de imagem de reparo automático do nó falhou devido a uma falha de operação: [código de erro aqui] | Emitido quando há um erro com a reimage ação. |
| NodeRedeployError | A ação de reimplantação de reparo automático do nó falhou devido a uma falha de operação: [código de erro aqui] | Emitido quando há um erro com a redeploy ação. |
Observação
Como o nó já está em um estado não íntegro antes do processo de reparo automático, na maioria dos casos, os erros de reparo automático do nó não afetam o cluster ou os aplicativos. Quando você encontrar erros de reparo automático do nó, recomendamos que você tente reparar o nó seguindo as instruções em Solução básica de problemas de falhas de nó não pronto. Se você não conseguir restaurá-lo para um Succeeded status e vir erros persistentes relatados pelo reparo automático do nó, entre em contato com o suporte do Azure para obter assistência.
Códigos de erro comuns
| Código do erro | Causa e solução |
|---|---|
| VMExtensionProvisioningError | Uma ou mais extensões de VM (máquina virtual) não foram provisionadas na VM. Para obter mais informações sobre possíveis tipos de erro e etapas de solução de problemas, consulte Solucionar problemas do código de erro ERR_VHD_FILE_NOT_FOUND (124). Para determinar o erro exato de provisionamento de extensão de VM em seu nó, exiba os detalhes do erro no portal do Azure. |
| InvalidParameter | Esse erro ocorrerá se o processo de reparo automático do nó tentar acessar um nó que não existe mais. |
| scaleSetNameAndInstanceIDFromProviderID falhou | Esse problema ocorre quando o nó não é provisionado corretamente. |
| Falha na autenticação ManagedIdentityCredential | Esse problema ocorre quando o nó não é inicializado corretamente. |
| VMRedimploymentFailed | Esse erro ocorre quando você tenta reimplantar o nó. Nesse caso, o pool de nós pode entrar em um estado de falha. Para obter mais informações sobre possíveis causas e etapas de solução de problemas, consulte Solucionar problemas de clusters ou nós do Serviço de Kubernetes do Azure em um estado de falha. |
| TooManyVMRedeploymentRequests | Esse erro ocorre quando o cluster excede o limite de solicitações de reimplantação de VM. Redeploy é uma das ações de reparo automático do nó. Esse erro significa que a redeploy ação não pode reparar seu nó. Para solucionar o problema de nó não pronto, consulte Solução de problemas básicos de falhas de nó não pronto. |
| OutboundConnectivityNotEnabledOnVMSS | Esse erro ocorre quando o nó ou o Conjunto de Dimensionamento de Máquinas Virtuais geral não tem o acesso de saída habilitado. Para resolver esse problema, habilite o acesso de saída seguro para o conjunto de dimensionamento usando um método mais adequado para seu aplicativo. Para obter mais informações, consulte "OutboundConnectivityNotEnabledOnVM. Nenhuma conectividade de saída configurada para máquina virtual." |
Práticas recomendadas para monitorar o reparo automático do nó
O AKS armazena eventos do Kubernetes da última hora por padrão. Recomendamos habilitar o Container Insights para que você possa armazenar eventos por até 90 dias. Você também pode consultar eventos e configurar alertas para detectar rapidamente erros de reparo automático de nós.
O reparo automático do nó é um serviço de melhor esforço. Isso não garante que seu nó possa ser restaurado para um
Readystatus. Recomendamos que você monitore ativamente e defina alertas para problemas de nó não pronto e solucione e resolva esses problemas por conta própria. Para obter mais informações, consulte solução de problemas básicos de problemas de nó não pronto.
Entre em contato conosco para obter ajuda
Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.