Problembehandlung bei Fehlern bei Knoten, die nicht bereit sind, die durch CSE-Fehler verursacht werden

  • Artikel
  • 3 Minuten Lesedauer

Dieser Artikel hilft Ihnen bei der Problembehandlung bei Szenarien, in denen sich ein Microsoft Azure Kubernetes Service (AKS)-Cluster nicht im Succeeded Status befindet und ein AKS-Knoten aufgrund von CSE-Fehlern (Custom Script Extension) nicht in einem Knotenpool bereit ist.

Voraussetzungen

Problembeschreibung

Aufgrund von CSE-Fehlern ist ein AKS-Clusterknoten in einem Knotenpool nicht bereit, und der AKS-Cluster befindet sich nicht im Succeeded Status.

Ursache

Die Bereitstellung der Knotenerweiterung schlägt fehl und gibt mehr als einen Fehlercode zurück, wenn Sie das Kubelet und andere Komponenten bereitstellen. Dies ist die häufigste Fehlerursache. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob die Bereitstellung der Knotenerweiterung fehlschlägt, wenn Sie das Kubelet bereitstellen:

  1. Um den aktuellen Fehler im Cluster besser zu verstehen, führen Sie die Befehle az aks show und az resource update aus, um das Debuggen einzurichten:

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

  2. Überprüfen Sie die Debugausgabe und die Fehlermeldungen, die az resource update Sie vom Befehl erhalten haben, anhand der Fehlerliste in der ausführbaren Datei des CSE-Hilfsprogramms auf GitHub.

Wenn einer der Fehler die CSE-Bereitstellung des Kubelets betrifft, haben Sie überprüft, ob das hier beschriebene Szenario die Ursache des Node Not Ready-Fehlers ist.

Im Allgemeinen identifizieren Exitcodes das spezifische Problem, das den Fehler verursacht. Es werden beispielsweise Meldungen wie "Mit API-Server kann nicht kommuniziert werden" oder "Verbindung zum Internet kann nicht hergestellt werden" angezeigt. Oder die Beendigungscodes benachrichtigen Sie möglicherweise über Timeouts im API-Netzwerk oder einen Knotenfehler, der einen Ersatz benötigt.

Lösung 1: Stellen Sie sicher, dass Ihr benutzerdefinierter DNS-Server ordnungsgemäß konfiguriert ist

Richten Sie Ihren benutzerdefinierten DNS-Server (Domain Name System) ein, damit er die Namensauflösung ordnungsgemäß ausführen kann. Konfigurieren Sie den Server so, dass er die folgenden Anforderungen erfüllt:

  • Wenn Sie benutzerdefinierte DNS-Server verwenden, stellen Sie sicher, dass die Server fehlerfrei und über das Netzwerk erreichbar sind.

  • Stellen Sie sicher, dass benutzerdefinierte DNS-Server über die erforderlichen bedingten Weiterleitungen an die Azure DNS-IP-Adresse (oder die Weiterleitung an diese Adresse) verfügen.

  • Stellen Sie sicher, dass Ihre private AKS-DNS-Zone mit Ihren benutzerdefinierten virtuellen DNS-Netzwerken verknüpft ist, wenn sie in Azure gehostet werden.

  • Verwenden Sie nicht die Azure DNS-IP-Adresse mit den IP-Adressen Ihres benutzerdefinierten DNS-Servers. Dies wird nicht empfohlen.

  • Vermeiden Sie die Verwendung von IP-Adressen anstelle des DNS-Servers in den DNS-Einstellungen. Sie können Azure CLI-Befehle verwenden, um diese Situation auf einem Vm-Skalierungssatz oder verfügbarkeitssatz zu überprüfen.

    • Verwenden Sie für VM-Skalierungsgruppenknoten den Befehl "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>"

    • Verwenden Sie für VM-Verfügbarkeitssatzknoten den Befehl "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>"

Weitere Informationen finden Sie unter Namensauflösung für Ressourcen in virtuellen Azure-Netzwerken und Hub und sprach mit benutzerdefiniertem DNS.

Lösung 2: Beheben von TIMEOUTS im API-Netzwerk

Stellen Sie sicher, dass der API-Server erreicht werden kann und keine Verzögerungen auftreten. Gehen Sie dazu wie folgt vor:

  • Überprüfen Sie das AKS-Subnetz, um festzustellen, ob die zugewiesene Netzwerksicherheitsgruppe (NSG) den Ausgehenden Datenverkehrsport 443 an den API-Server blockiert.

  • Überprüfen Sie den Knoten selbst, um festzustellen, ob der Knoten über eine andere NSG verfügt, die den Datenverkehr blockiert.

  • Überprüfen Sie das AKS-Subnetz auf eine zugewiesene Routentabelle. Wenn eine Routentabelle über eine virtuelle Netzwerkanwendung (Network Virtual Appliance, NVA) oder Firewall verfügt, stellen Sie sicher, dass Port 443 für ausgehenden Datenverkehr verfügbar ist. Weitere Informationen finden Sie unter Steuern des Ausgangsdatenverkehrs für Clusterknoten in AKS.

  • Wenn der DNS-Name erfolgreich aufgelöst wird und die API erreichbar ist, der Knoten-CSE jedoch aufgrund eines API-Timeouts fehlgeschlagen ist, führen Sie die entsprechende Aktion aus, wie in der folgenden Tabelle dargestellt.

    Set type Aktion
    VM-Verfügbarkeitssatz Löschen Sie den Knoten aus dem Azure-Portal und der AKS-API mithilfe des Befehls "kubectl delete node", und skalieren Sie dann den Cluster erneut.
    VM-Skalierungssatz Erstellen Sie entweder ein Reimage des Knotens, oder löschen Sie den Knoten, und skalieren Sie den Cluster erneut.

  • Wenn die Anforderungen vom AKS-API-Server gedrosselt werden, führen Sie ein Upgrade auf eine höhere Dienstebene durch. Weitere Informationen finden Sie unter AKS Uptime SLA.

Weitere Informationen