Compartilhar via

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

  • Artigo

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

Pré-requisitos

Sintomas

Devido a erros do CSE, um nó de cluster do AKS não está pronto dentro de 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. Essa é a causa mais comum de erros. Para verificar se a implantação da extensão do nó está falhando ao provisionar 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 az resource update comando na 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ê verá mensagens como "Não é possível se comunicar com o servidor de API" ou "Não é possível se conectar à Internet". Ou os códigos de saída podem alertá-lo para tempo limite de rede de 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 o 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 são saudáveis 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).

  • Verifique se sua zona DNS do AKS privada está vinculada às redes virtuais DNS personalizadas se elas estiverem hospedadas no Azure.

  • Não use o endereço IP DNS do Azure com os endereços IP do servidor DNS personalizado. Não é recomendável fazer isso.

  • Evite usar endereços IP em vez do servidor DNS em configurações DNS. Você pode usar comandos da CLI do Azure para marcar para essa situação em um conjunto de dimensionamento ou conjunto de disponibilidade de máquina virtual (VM).

    • Para nós de conjunto de dimensionamento de VM, 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 de conjunto de disponibilidade de 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, confira Resolução de nomes para recursos em redes virtuais do Azure e hub e conversão com DNS personalizado.

Solução 2: corrigir tempo limite de rede de API

Verifique se o servidor de API pode ser atingido e não está 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 nó em si para ver se o nó 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 NVA (dispositivo virtual de rede) ou firewall, verifique se a porta 443 está disponível para tráfego de saída. Para obter mais informações, consulte Controlar o tráfego de saída para nós de cluster no AKS.

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

    Definir tipo Ação
    Conjunto de disponibilidade de VM Exclua o nó do portal do Azure e da API do AKS usando o comando de nó de exclusão kubectl e, em seguida, dimensione o cluster novamente.
    Conjunto de dimensionamento de VM Reimage o nó ou exclua o nó e, em seguida, dimensione o cluster novamente.

  • 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 SLA de tempo de atividade do AKS.

Mais informações