Compartilhar via

Solucionar problemas de falhas não prontas de nó causadas por erros de CSE

  • Artigo

Este artigo ajuda você a solucionar problemas de cenários em que um cluster do AKS (Serviço de Kubernetes do Microsoft Azure) não está no Succeeded estado e um nó do AKS não está pronto em um pool de nós devido a erros de CSE (extensão de script personalizado).

Pré-requisitos

Sintomas

Devido a erros de CSE, um nó de cluster do AKS não está pronto em um pool de nós e o cluster do AKS não está no Succeeded estado.

Motivo

A implantação da extensão do nó falha e retorna mais de um código de erro quando você provisiona o kubelet e outros componentes. Esta é a causa mais comum de erros. Para verificar se a implantação da extensão do nó está falhando quando você provisiona o kubelet, siga estas etapas:

  1. Para entender melhor a falha atual no cluster, execute os comandos az aks show e az resource update para configurar a depuração:

    clusterResourceId=$(az aks show \
    --resource-group <resource-group-name> --name <cluster-name> --output tsv --query id)
az resource update --debug --verbose --ids $clusterResourceId

  2. Verifique a saída de depuração e as mensagens de erro recebidas do comando em relação à az resource update lista de erros no arquivo executável auxiliar do CSE no GitHub.

Se algum dos erros envolver a implantação do CSE do kubelet, você verificou que o cenário descrito aqui é a causa da falha do nó não pronto.

Em geral, os códigos de saída identificam o problema específico que está causando a falha. Por exemplo, você vê mensagens como "Não é possível se comunicar com o servidor de API" ou "Não é possível conectar-se à Internet". Ou os códigos de saída podem alertá-lo sobre tempos limite de rede da API ou uma falha de nó que precisa de uma substituição.

Solução 1: verifique se o servidor DNS personalizado está configurado corretamente

Configure seu servidor DNS (Sistema de Nomes de Domínio) personalizado para que ele possa fazer a resolução de nomes corretamente. Configure o servidor para atender aos seguintes requisitos:

  • Se você estiver usando servidores DNS personalizados, verifique se os servidores estão íntegros e acessíveis pela rede.

  • Verifique se os servidores DNS personalizados têm os encaminhadores condicionais necessários para o endereço IP DNS do Azure (ou o encaminhador para esse endereço).

  • Certifique-se de que a sua zona DNS privada do AKS esteja vinculada às suas redes virtuais de DNS personalizadas se estiverem hospedadas no Azure.

  • Não use o endereço IP do DNS do Azure com os endereços IP do seu servidor DNS personalizado. Não é recomendado fazer isso.

  • Evite usar endereços IP em vez do servidor DNS nas configurações de DNS. Você pode usar comandos da CLI do Azure para verificar essa situação em um Conjunto de Dimensionamento de Máquinas Virtuais ou conjunto de disponibilidade.

    • Para nós do Conjunto de Dimensionamento de Máquinas Virtuais, use o comando az vmss run-command invoke :

      az vmss run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-scale-set-name> \
    --command-id RunShellScript \
    --instance-id 0 \
    --output tsv \
    --query "value[0].message" \
    --scripts "telnet <dns-ip-address> 53"
az vmss run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-scale-set-name> \
    --instance-id 0 \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "nslookup <api-fqdn> <dns-ip-address>"

    • Para nós do conjunto de disponibilidade da VM, use o comando az vm run-command invoke :

      az vm run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-availability-set-name> \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "telnet <dns-ip-address> 53"
az vm run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-availability-set-name> \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "nslookup <api-fqdn> <dns-ip-address>"

Para obter mais informações, consulte Resolução de nomes para recursos em redes virtuais do Azure e Hub e spoke com DNS personalizado.

Solução 2: Corrigir tempos limite de rede de API

Certifique-se de que o servidor de API possa ser acessado e de que não esteja sujeito a atrasos. Para fazer isso, siga estas etapas:

  • Verifique a sub-rede do AKS para ver se o NSG (grupo de segurança de rede) atribuído está bloqueando a porta de tráfego de saída 443 para o servidor de API.

  • Verifique o próprio nó para ver se ele tem outro NSG que está bloqueando o tráfego.

  • Verifique a sub-rede do AKS em busca de qualquer tabela de rotas atribuída. Se uma tabela de rotas tiver uma solução de virtualização de rede (NVA) ou firewall, verifique se a porta 443 está disponível para tráfego de saída. Para obter mais informações, confira Controlar o tráfego de saída para nós de cluster no AKS.

  • Se o DNS resolver nomes com êxito e a API estiver acessível, mas o CSE do nó falhar devido a um tempo limite da API, execute a ação apropriada, conforme mostrado na tabela a seguir.

    Tipo de conjunto Action
    Conjunto de disponibilidade de VMs Exclua o nó do portal do Azure e da API do AKS usando o comando kubectl delete node e, em seguida, escale verticalmente o cluster novamente.
    Conjunto de Dimensionamento de Máquinas Virtuais Recrie a imagem do nó do portal do Azure ou exclua o nó e, em seguida, escale verticalmente o cluster novamente. Para excluir o nó específico, use o comando az aks nodepool delete-machines . Ele irá isolar e drenar primeiro e depois excluir o nó.

  • Se as solicitações estiverem sendo limitadas pelo servidor de API do AKS, atualize para uma camada de serviço mais alta. Para obter mais informações, consulte Tipos de preço para AKS.

Mais informações