Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
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.