Partilhar via

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

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:

    Defina as variáveis de ambiente e execute os comandos para exibir o status do cluster e as informações de depuração.

    export RG_NAME="my-aks-rg"
export CLUSTER_NAME="myakscluster"
clusterResourceId=$(az aks show \
    --resource-group $RG_NAME --name $CLUSTER_NAME --output tsv --query id)
az resource update --debug --verbose --ids $clusterResourceId

    Resultados:

    {
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-aks-rg-xxx/providers/Microsoft.ContainerService/managedClusters/myaksclusterxxx",
  "name": "myaksclusterxxx",
  "type": "Microsoft.ContainerService/managedClusters",
  "location": "eastus2",
  "tags": null,
  "properties": {
    ...
  }
}

  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 :

      Importante: Você deve especificar o --instance-id conjunto de dimensionamento da VM. Aqui, demonstramos a consulta de uma ID de instância válida (por exemplo, 0) e uma VMSS provável em um grupo de recursos de nó do AKS. Atualize os valores adequadamente para corresponder ao seu ambiente.

      export NODE_RESOURCE_GROUP=$(az aks show --resource-group $RG_NAME --name $CLUSTER_NAME --query nodeResourceGroup -o tsv)
export VMSS_NAME=$(az vmss list --resource-group $NODE_RESOURCE_GROUP --query "[0].name" -o tsv)
export DNS_IP_ADDRESS="10.0.0.10"
export INSTANCE_ID=$(az vmss list-instances --resource-group $NODE_RESOURCE_GROUP --name $VMSS_NAME --query "[0].instanceId" -o tsv)
export API_FQDN=$(az aks show --resource-group $RG_NAME --name $CLUSTER_NAME --query fqdn -o tsv)

az vmss run-command invoke \
    --resource-group $NODE_RESOURCE_GROUP \
    --name $VMSS_NAME \
    --instance-id $INSTANCE_ID \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "telnet $DNS_IP_ADDRESS 53"
az vmss run-command invoke \
    --resource-group $NODE_RESOURCE_GROUP \
    --name $VMSS_NAME \
    --instance-id $INSTANCE_ID \
    --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 :

      Importante: Você deve especificar a --name de uma VM válida em um conjunto de disponibilidade em seu grupo de recursos. Aqui está um modelo para executar verificações de rede.

      az vm run-command invoke \
    --resource-group $RG_NAME \
    --name $AVAILABILITY_SET_VM \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "telnet $DNS_IP_ADDRESS 53"
az vm run-command invoke \
    --resource-group $RG_NAME \
    --name $AVAILABILITY_SET_VM \
    --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 Ação
    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

  • Last updated on