Freigeben über

Problembehandlung von Knotenfehlern, die durch CSE-Fehler verursacht werden

  • Artikel

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

Voraussetzungen

Problembeschreibung

Aufgrund von CSE-Fehlern ist ein AKS-Clusterknoten innerhalb eines Knotenpools nicht bereit, und der AKS-Cluster befindet sich nicht im Succeeded Zustand.

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 bei der Bereitstellung der Knotenerweiterung ein Fehler auftritt, 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 CSE-Hilfsdatei auf GitHub.

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

Im Allgemeinen identifizieren Exitcodes das spezifische Problem, das den Fehler verursacht. Beispielsweise werden Meldungen wie "Kommunikation mit API-Server nicht möglich" oder "Verbindung mit dem Internet nicht möglich" angezeigt. Oder die Exitcodes benachrichtigen Sie möglicherweise über API-Netzwerktimeouts oder einen Knotenfehler, der ersetzt werden muss.

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

Richten Sie Ihren benutzerdefinierten DNS-Server (Domain Name System) so ein, dass 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 diese in Azure gehostet werden.

  • Verwenden Sie die Azure DNS-IP-Adresse nicht 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 in einer VM-Skalierungsgruppe oder Verfügbarkeitsgruppe 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ügbarkeitsgruppenknoten 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-and-Spoke mit benutzerdefiniertem DNS.

Lösung 2: Beheben von API-Netzwerktimeouts

Stellen Sie sicher, dass der API-Server erreicht werden kann und keine Verzögerungen unterliegt. 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 weitere NSG verfügt, die den Datenverkehr blockiert.

  • Überprüfen Sie das AKS-Subnetz auf eine zugewiesene Routingtabelle. Wenn eine Routingtabelle über ein virtuelles Netzwerk-Anwendung (NVA) oder eine Firewall verfügt, stellen Sie sicher, dass Port 443 für ausgehenden Datenverkehr verfügbar ist. Weitere Informationen finden Sie unter Steuern des ausgehenden Datenverkehrs für Clusterknoten in AKS.

  • Wenn das DNS Namen erfolgreich auflöst und die API erreichbar ist, der CsE-Knoten jedoch aufgrund eines API-Timeouts fehlgeschlagen ist, führen Sie die entsprechende Aktion aus, wie in der folgenden Tabelle gezeigt.

    Festlegen des Typs Aktion
    VM-Verfügbarkeitsgruppe Löschen Sie den Knoten aus dem Azure-Portal und der AKS-API, indem Sie den Befehl kubectl delete node verwenden, und skalieren Sie den Cluster dann erneut hoch.
    VM-Skalierungsgruppe Erstellen Sie entweder ein Reimaging für den Knoten, oder löschen Sie den Knoten, und skalieren Sie den Cluster dann erneut hoch.

  • 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-Betriebszeit-SLA.

Weitere Informationen