Share via

Problemen met knooppunten oplossen die niet gereed zijn vanwege CSE-fouten

  • Artikel

Dit artikel helpt u bij het oplossen van problemen met scenario's waarin een Microsoft Azure Kubernetes Service (AKS)-cluster zich niet in de Succeeded status bevindt en een AKS-knooppunt niet gereed is binnen een knooppuntgroep vanwege cse-fouten (Custom Script Extension).

Vereisten

Symptomen

Vanwege CSE-fouten is een AKS-clusterknooppunt niet gereed binnen een knooppuntgroep en heeft het AKS-cluster niet de Succeeded status.

Oorzaak

De implementatie van de knooppuntextensie mislukt en retourneert meer dan één foutcode wanneer u de kubelet en andere onderdelen inricht. Dit is de meest voorkomende oorzaak van fouten. Voer de volgende stappen uit om te controleren of de implementatie van de knooppuntextensie mislukt wanneer u de kubelet inricht:

  1. Als u meer inzicht wilt krijgen in de huidige fout in het cluster, voert u de opdrachten az aks show en az resource update uit om foutopsporing in te stellen:

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

  2. Controleer de uitvoer van foutopsporing en de foutberichten die u van de az resource update opdracht hebt ontvangen op basis van de foutenlijst in het uitvoerbare bestand van de CSE-helper op GitHub.

Als een van de fouten betrekking heeft op de CSE-implementatie van de kubelet, hebt u gecontroleerd of het scenario dat hier wordt beschreven, de oorzaak is van de fout Knooppunt niet gereed.

Over het algemeen identificeren afsluitcodes het specifieke probleem dat de fout veroorzaakt. U ziet bijvoorbeeld berichten als 'Kan niet communiceren met API-server' of 'Kan geen verbinding maken met internet'. Of de afsluitcodes kunnen u waarschuwen voor time-outs van API-netwerk of een knooppuntfout die moet worden vervangen.

Oplossing 1: Controleer of uw aangepaste DNS-server correct is geconfigureerd

Stel uw aangepaste DNS-server (Domain Name System) in zodat deze naamomzetting correct kan uitvoeren. Configureer de server om te voldoen aan de volgende vereisten:

  • Als u aangepaste DNS-servers gebruikt, controleert u of de servers in orde zijn en bereikbaar zijn via het netwerk.

  • Zorg ervoor dat aangepaste DNS-servers de vereiste voorwaardelijke doorstuurservers hebben naar het IP-adres van Azure DNS (of de doorstuurserver naar dat adres).

  • Zorg ervoor dat uw privé-AKS DNS-zone is gekoppeld aan uw aangepaste virtuele DNS-netwerken als deze worden gehost in Azure.

  • Gebruik het IP-adres van Azure DNS niet met de IP-adressen van uw aangepaste DNS-server. Dit wordt afgeraden.

  • Vermijd het gebruik van IP-adressen in plaats van de DNS-server in DNS-instellingen. U kunt Azure CLI-opdrachten gebruiken om te controleren op deze situatie op een virtuele machine (VM) schaalset of beschikbaarheidsset.

    • Gebruik voor VM-schaalsetknooppunten de opdracht 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>"

    • Gebruik voor VM-beschikbaarheidssetknooppunten de opdracht 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>"

Zie Naamomzetting voor resources in virtuele Azure-netwerken en Hub en spoke met aangepaste DNS voor meer informatie.

Oplossing 2: Time-outs van API-netwerk oplossen

Zorg ervoor dat de API-server kan worden bereikt en niet onderhevig is aan vertragingen. Ga hiervoor als volgt te werk:

  • Controleer het AKS-subnet om te zien of de toegewezen netwerkbeveiligingsgroep (NSG) de uitgaande verkeerspoort 443 naar de API-server blokkeert.

  • Controleer het knooppunt zelf om te zien of het knooppunt een andere NSG heeft die het verkeer blokkeert.

  • Controleer het AKS-subnet op een toegewezen routetabel. Als een routetabel een virtueel netwerkapparaat (NVA) of een firewall heeft, controleert u of poort 443 beschikbaar is voor uitgaand verkeer. Zie Uitgaand verkeer voor clusterknooppunten in AKS beheren voor meer informatie.

  • Als de DNS namen met succes omzet en de API bereikbaar is, maar het knooppunt CSE is mislukt vanwege een API-time-out, voert u de juiste actie uit, zoals wordt weergegeven in de volgende tabel.

    Type instellen Actie
    VM-beschikbaarheidsset Verwijder het knooppunt uit de Azure Portal en de AKS-API met behulp van de opdracht kubectl delete node en schaal het cluster vervolgens opnieuw omhoog.
    VM-schaalset Maak een nieuwe installatiekopie van het knooppunt of verwijder het knooppunt en schaal het cluster vervolgens opnieuw omhoog.

  • Als de aanvragen worden beperkt door de AKS API-server, voert u een upgrade uit naar een hogere servicelaag. Zie AKS Uptime SLA voor meer informatie.

Meer informatie