Condividi tramite

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

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:

    Impostare le variabili di ambiente ed eseguire i comandi per visualizzare lo stato del cluster e le informazioni di debug.

    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

    Risultati:

    {
  "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. 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 :

      Importante: È necessario specificare il parametro --instance-id del set di scalabilità di macchine virtuali. Qui, dimostriamo l'esecuzione di query per un ID istanza valido (ad esempio 0) e un probabile VMSS in un gruppo di risorse del nodo AKS. Aggiornare i valori in modo appropriato in base all'ambiente in uso.

      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"

    • Per i nodi del set di disponibilità della macchina virtuale, usare il comando az vm run-command invoke :

      Importante: È necessario specificare il parametro --name di una VM valida in un set di disponibilità nel gruppo di risorse. Ecco un modello per l'esecuzione dei controlli di rete.

      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"

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

  • Last updated on