Delen via

Problemen met niet-gereed knooppunten oplossen die worden veroorzaakt door CSE-fouten

  • Artikel

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

Voorwaarden

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 hebt ontvangen van de az resource update opdracht 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 Node Not Ready.

In het algemeen identificeren afsluitcodes het specifieke probleem dat de fout veroorzaakt. U ziet bijvoorbeeld berichten zoals '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 een vervanging nodig heeft.

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

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

  • Als u aangepaste DNS-servers gebruikt, moet u ervoor zorgen dat de servers in orde en bereikbaar zijn via het netwerk.

  • Zorg ervoor dat aangepaste DNS-servers over de vereiste voorwaardelijke doorstuurservers beschikken 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 niet aanbevolen.

  • 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 in een virtuele-machineschaalset of beschikbaarheidsset.

    • Voor virtuele-machineschaalsetknooppunten gebruikt u 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>"

    • Voor VM-beschikbaarheidssetknooppunten gebruikt u 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 voor API-netwerk oplossen

Zorg ervoor dat de API-server kan worden bereikt en met vertragingen heeft te maken. Hiervoor volgt u deze stappen:

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

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

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

  • Als de DNS namen omzet en de API bereikbaar is, maar de node CSE is mislukt vanwege een time-out van de API, 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 op.
    Schaalset voor virtuele machines Maak een nieuwe installatiekopie van het knooppunt vanuit Azure Portal of verwijder het knooppunt en schaal het cluster vervolgens opnieuw op. Als u het specifieke knooppunt wilt verwijderen, gebruikt u de opdracht az aks nodepool delete-machines . Het zal eerst cordon & leegmaken en vervolgens het knooppunt verwijderen.

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

Meer informatie