Solução de problemas básicas de falhas não prontas do nó

Este artigo fornece etapas de solução de problemas para recuperar nós de cluster do AKS (Microsoft Serviço de Kubernetes do Azure) após uma falha. Este artigo aborda especificamente as mensagens de erro mais comuns geradas quando ocorre uma falha de Nó Não Pronto e explica como a funcionalidade de reparo de nó pode ser feita para nós Windows e Linux.

Antes de começar

Leia o guia oficial para solucionar problemas de clusters do Kubernetes. Além disso, leia o guia do engenheiro da Microsoft para a solução de problemas do Kubernetes. Este guia contém comandos para solucionar problemas de pods, nós, clusters e outros recursos.

Pré-requisitos

  • CLI do Azure, versão 2.31 ou uma versão posterior. Se a CLI do Azure já estiver instalada, você poderá encontrar o número da versão executando az --version.

Solução de problemas básica

O AKS monitora continuamente o estado de integridade dos nós de trabalho e repara automaticamente os nós se eles se tornarem não saudáveis. A plataforma VM (Máquina Virtual) do Azure mantém VMs que enfrentam problemas. As VMs do AKS e do Azure trabalham juntas para reduzir as interrupções de serviço para clusters.

Para nós, há duas formas de pulsação:

Comparado às atualizações com o arquivo .status de um Node, um é um Lease recurso leve. O uso Lease de objetos para pulsações reduz o impacto de desempenho dessas atualizações para clusters grandes.

O kubelet é responsável por criar e atualizar o arquivo .status para Node objetos. Ele também é responsável por atualizar os Lease objetos relacionados aos Node objetos.

O kubelet atualizará o Node arquivo .status se uma das seguintes condições for verdadeira:

  • Ocorre uma alteração no status.

  • Nenhuma atualização ocorre após um intervalo de tempo configurado.

O intervalo padrão para status atualizações para um Node é de cinco minutos. Esse intervalo é muito maior do que o tempo limite padrão de 40 segundos para nós inacessíveis. O kubelet cria e atualiza seu Lease objeto uma vez a cada dez segundos (o intervalo de atualização padrão). Atualizações ocorrer Lease independentemente das atualizações para o Node status. Se a Lease atualização falhar, o kubelet repetirá, usando um backoff exponencial que começa em 200 milissegundos e é limitado a um máximo de sete segundos.

Você não pode agendar um Pod em um Node que tenha uma status de NotReady ou Unknown. Você pode agendar um Pod somente em nós que estão no Ready estado.

Se o MemoryPressurenó estiver no estado , ou , DiskPressurePIDPressure você deverá gerenciar seus recursos para agendar pods extras no nó. Se o nó estiver no NetworkUnavailable modo, você deverá configurar a rede no nó corretamente. Verifique se as seguintes condições são atendidas:

Aviso de isenção de responsabilidade para contatos de terceiros

A Microsoft fornece informações de contato de terceiros para ajudá-lo a encontrar informações adicionais sobre esse tópico. Essas informações de contato podem ser alteradas sem aviso prévio. A Microsoft não garante a precisão das informações de contato de terceiros.