Solução básica de problemas de falhas de nó não pronto

  • Artigo

Este artigo fornece etapas de solução de problemas para recuperar nós de cluster do AKS (Serviço de Kubernetes do Microsoft 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 solução de problemas de clusters do Kubernetes. Além disso, leia o guia do engenheiro da Microsoft para 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 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ásicos

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 íntegros. A plataforma de VM (Máquina Virtual) do Azure mantém as VMs que apresentam problemas. O AKS e as VMs do Azure trabalham em conjunto para reduzir as interrupções de serviço para os clusters.

Para os nós, há duas formas de pulsações:

  • Atualizações no arquivo .status de um Node objeto.

  • Objetos de Concessão no namespace kube-node-lease. Cada Node um tem um objeto associado Lease .

Comparado às atualizações do arquivo .status de um Node, a Lease é um recurso leve. O uso Lease de objetos para pulsações reduz o impacto no 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 atualiza o Node arquivo .status se uma das seguintes condições for verdadeira:

  • Ocorre uma mudança no status.

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

O intervalo padrão para atualizações de status para a é de Node 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). As atualizações devem Lease ocorrer independentemente das atualizações do Node status. Se a Lease atualização falhar, o kubelet tentará novamente, usando uma retirada exponencial que começa em 200 milissegundos e é limitada a um máximo de sete segundos.

Você não pode agendar um Pod em um Node que tenha um 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 , DiskPressureou PIDPressure , 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. Certifique-se de que as seguintes condições sejam atendidas:

  • Seu cluster está no estado Bem-sucedido (Em execução ). Para verificar o status do cluster no portal do Azure, pesquise e selecione Serviços do Kubernetes e selecione o nome do cluster do AKS. Em seguida, na página Visão geral do cluster, procure no Essentials para encontrar o Status. Ou insira o comando az aks show na CLI do Azure.

    Captura de tela do portal do Azure de uma página Visão geral do cluster do Serviço de Kubernetes do Azure (A K S). Na seção Essentials, o status é 'Bem-sucedido (em execução)'.

  • Seu pool de nós tem um estado de provisionamento de Êxito e um estado de Energia de Execução. Para verificar o status do pool de nós no portal do Azure, retorne à página do cluster do AKS e selecione Pools de nós. Como alternativa, insira o comando az aks nodepool show na CLI do Azure.

    Captura de tela do portal do Azure de um pool de nós de cluster do Serviço de Kubernetes do Azure (A K S). O estado de provisionamento é Bem-sucedido. O estado de energia é Em execução.

  • As portas de saída necessárias estão abertas em seus NSGs (grupos de segurança de rede) e firewall para que o endereço IP do servidor de API possa ser alcançado. Para obter mais informações, consulte Regras de rede de saída necessárias e FQDNs para clusters do AKS.

  • Seus nós implantaram as imagens de nó mais recentes.

  • Seus nós estão no Running estado em vez de Stopped ou Deallocated.

  • Seu cluster está executando uma versão do Kubernetes com suporte do AKS.

Isenção de responsabilidade de contato de terceiros

A Microsoft fornece informações de contato de terceiros para ajudá-lo a encontrar informações adicionais sobre este 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.