Condividi tramite

Risolvere i problemi relativi a nodi non pronti causati da errori CSE

  • Articolo

Questo articolo consente di risolvere i problemi relativi agli scenari in cui un cluster Microsoft servizio Azure Kubernetes (AKS) non è nello Succeeded stato e un nodo del servizio Azure Kubernetes non è pronto all'interno di un pool di nodi a causa di errori dell'estensione dello script personalizzato.

Prerequisiti

Sintomi

A causa di errori cse, un nodo del cluster del servizio Azure Kubernetes non è pronto all'interno di un pool di nodi e il cluster del servizio Azure Kubernetes non è nello Succeeded stato.

Causa

La distribuzione dell'estensione del nodo non riesce e restituisce più di un codice di errore quando si effettua il provisioning di kubelet e di altri componenti. Questa è la causa più comune di errori. Per verificare che la distribuzione dell'estensione del nodo abbia esito negativo quando si effettua il provisioning di kubelet, seguire questa procedura:

  1. Per comprendere meglio l'errore corrente nel cluster, eseguire i comandi az aks show e az resource update per configurare il debug:

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

  2. Controllare l'output di debug e i messaggi di errore ricevuti dal comando rispetto az resource update all'elenco degli errori nel file eseguibile dell'helper CSE in GitHub.

Se uno degli errori implica la distribuzione CSE di kubelet, è stato verificato che lo scenario descritto di seguito è la causa dell'errore Node Not Ready.

In generale, i codici di uscita identificano il problema specifico che causa l'errore. Ad esempio, vengono visualizzati messaggi come "Impossibile comunicare con il server API" o "Impossibile connettersi a Internet". In alternativa, i codici di uscita potrebbero avvisare l'utente dei timeout di rete dell'API o un errore del nodo che richiede una sostituzione.

Soluzione 1: Assicurarsi che il server DNS personalizzato sia configurato correttamente

Configurare il server DNS (Domain Name System) personalizzato in modo che possa eseguire correttamente la risoluzione dei nomi. È necessario configurare il server in modo che soddisfi i seguenti requisiti:

  • Se si usano server DNS personalizzati, assicurarsi che i server siano integri e raggiungibili in rete.

  • Assicurarsi che i server DNS personalizzati dispongano dei server d'inoltro condizionale necessari all'indirizzo IP DNS di Azure (o al server d'inoltro a tale indirizzo).

  • Assicurarsi che la zona DNS privato del servizio Azure Kubernetes sia collegata alle reti virtuali DNS personalizzate, se ospitate in Azure.

  • Non usare l'indirizzo IP DNS di Azure con gli indirizzi IP del server DNS personalizzato. Questa configurazione non è consigliata.

  • Evitare di usare indirizzi IP al posto del server DNS, nelle impostazioni DNS. È possibile usare i comandi dell'interfaccia della riga di comando di Azure per verificare questa situazione in un set di scalabilità di macchine virtuali o in un set di disponibilità.

    • Per i nodi del set di scalabilità di macchine virtuali, usare il 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>"

    • Per i nodi del set di disponibilità della macchina virtuale, usare il 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>"

Per altre informazioni, vedere Risoluzione dei nomi per le risorse nelle reti virtuali di Azure e hub e spoke con DNS personalizzato.

Soluzione 2: Correggere i timeout di rete dell'API

Assicurarsi che il server API sia raggiungibile e non sia soggetto a ritardi. A tale scopo, effettuare i seguenti passaggi:

  • Controllare la subnet del servizio Azure Kubernetes per verificare se il gruppo di sicurezza di rete assegnato blocca la porta 443 del traffico in uscita al server API.

  • Controllare il nodo per verificare se ha un altro gruppo di sicurezza di rete che blocca il traffico.

  • Controllare se sono presenti tabelle di route assegnate nella subnet AKS. Se una tabella di route ha un'appliance virtuale di rete (NVA) o un firewall, assicurarsi che la porta 443 sia disponibile per il traffico in uscita. Per altre informazioni, vedere Controllare il traffico in uscita per i nodi del cluster del servizio Azure Kubernetes.

  • Se il DNS risolve correttamente i nomi e l'API è raggiungibile, ma il nodo CSE non funziona a causa di un timeout dell'API, eseguire l'azione appropriata, come illustrato nella tabella seguente.

    Tipo di set Azione
    Set di disponibilità della macchina virtuale Eliminare il nodo dal portale di Azure e dall'API del servizio Azure Kubernetes usando il comando kubectl delete node e quindi aumentare nuovamente il cluster.
    Set di scalabilità della macchina virtuale Ricreazione dell'immagine del nodo dal portale di Azure o eliminazione del nodo e quindi aumento del numero di istanze del cluster. Per eliminare il nodo specifico, usare il comando az aks nodepool delete-machines . Verrà prima di tutto delimitato e svuotato e quindi eliminato il nodo.

  • Se le richieste vengono limitate dal server API del servizio Azure Kubernetes, eseguire l'upgrade a un livello di servizio superiore. Per altre informazioni, vedere Piani tariffari per il servizio Azure Kubernetes.

Ulteriori informazioni