Condividi tramite


Risolvere gli errori del nodo non pronti causati da errori cse

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

Prerequisiti

Sintomi

A causa di errori dell'ambiente del servizio Azure Kubernetes, 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 ha esito negativo e restituisce più di un codice di errore quando si esegue il provisioning del kubelet e di altri componenti. Questa è la causa più comune di errori. Per verificare che la distribuzione dell'estensione del nodo non riesca durante il provisioning del 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 az resource update comando rispetto all'elenco degli errori nel file eseguibile dell'helper CSE in GitHub.

Se uno degli errori riguarda la distribuzione CSE del kubelet, si è verificato che lo scenario descritto qui è la causa dell'errore Node Not Ready.

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

Soluzione 1: verificare 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. Configurare il server per soddisfare i requisiti seguenti:

  • 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 condizionali necessari per l'indirizzo IP DNS di Azure (o il server d'inoltro per tale indirizzo).

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

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

  • Evitare di usare gli indirizzi IP anziché il server DNS nelle impostazioni DNS. È possibile usare i comandi dell'interfaccia della riga di comando di Azure per verificare la presenza di 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 e nell'hub di Azuree spoke con DNS personalizzato.

Soluzione 2: Correggere i timeout di rete dell'API

Assicurarsi che il server API sia raggiungibile e che non sia soggetto a ritardi. A tal fine, attenersi alla seguente procedura:

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

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

  • Controllare la subnet del servizio Azure Kubernetes per qualsiasi tabella di route assegnata. 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 nel servizio Azure Kubernetes.

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

    Imposta tipo Azione
    Set di disponibilità di macchine virtuali Eliminare il nodo dalla portale di Azure e dall'API del servizio Azure Kubernetes usando il comando kubectl delete node e quindi aumentare di nuovo il cluster.
    Set di scalabilità di macchine virtuali Ricreare l'immagine del nodo o eliminare il nodo e quindi aumentare di nuovo il cluster.
  • Se le richieste vengono limitate dal server API del servizio Azure Kubernetes, eseguire l'aggiornamento a un livello di servizio superiore. Per altre informazioni, vedere Contratto di servizio Tempo di attività del servizio Azure Kubernetes.

Ulteriori informazioni