Felsöka nodfel som inte är klara på grund av CSE-fel

Artikel
11/19/2024

Den här artikeln hjälper dig att felsöka scenarier där ett AKS-kluster (Microsoft Azure Kubernetes Service) inte är i Succeeded tillståndet och en AKS-nod inte är redo i en nodpool på grund av cse-fel (custom script extension).

Förutsättningar

Azure CLI

Symptom

På grund av CSE-fel är en AKS-klusternod inte redo i en nodpool och AKS-klustret är inte i tillståndet Succeeded .

Orsak

Distributionen av nodtillägget misslyckas och returnerar mer än en felkod när du etablerar kubelet och andra komponenter. Det här är den vanligaste orsaken till fel. Så här kontrollerar du att distributionen av nodtillägget misslyckas när du etablerar kubelet:

För att bättre förstå det aktuella felet i klustret kör du kommandona az aks show och az resource update för att konfigurera felsökning:

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

Kontrollera felsökningsutdata och de felmeddelanden som du fick från az resource update kommandot mot fellistan i cse-hjälpfilen på GitHub.

Om något av felen gäller CSE-distributionen av kubelet har du kontrollerat att scenariot som beskrivs här är orsaken till felet Nod är inte klar.

I allmänhet identifierar slutkoder det specifika problem som orsakar felet. Du kan till exempel se meddelanden som "Det går inte att kommunicera med API-servern" eller "Det går inte att ansluta till Internet". Eller så kan slutkoderna varna dig för api-nätverkstidsutgångar eller ett nodfel som behöver ersättas.

Lösning 1: Kontrollera att din anpassade DNS-server är korrekt konfigurerad

Konfigurera din anpassade DNS-server (Domain Name System) så att den kan matcha namn korrekt. Konfigurera servrarna för att uppfylla följande krav:

Om du använder anpassade DNS-servrar kontrollerar du att servrarna är felfria och kan nås via nätverket.
Kontrollera att anpassade DNS-servrar har de villkorsstyrda vidarebefordrare som krävs till Azure DNS IP-adressen (eller vidarebefordraren till den adressen).
Kontrollera att din privata AKS DNS-zon är länkad till dina anpassade virtuella DNS-nätverk om de finns i Azure.
Använd inte Azure DNS-IP-adressen med IP-adresserna för din anpassade DNS-server. Att göra det här rekommenderas inte.

Undvik att använda IP-adresser i stället för DNS-servern i DNS-inställningar. Du kan använda Azure CLI-kommandon för att söka efter den här situationen på en VM-skalningsuppsättning eller tillgänglighetsuppsättning.

För vm-skalningsuppsättningsnoder använder du kommandot 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>"

För noder för VM-tillgänglighetsuppsättningar använder du kommandot 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>"

Mer information finns i Namnmatchning för resurser i virtuella Azure-nätverk och Hub and spoke med anpassad DNS.

Lösning 2: Åtgärda tidsgränser för API-nätverk

Kontrollera att API-servern kan nås och inte blir fördröjd. För att göra detta följer du stegen nedan:

Kontrollera AKS-undernätet för att se om den tilldelade nätverkssäkerhetsgruppen (NSG) blockerar utgående trafikport 443 till API-servern.
Kontrollera själva noden för att se om noden har en annan NSG som blockerar trafiken.
Kontrollera AKS-undernätet om det finns en tilldelad routningstabell. Om en routningstabell har en virtuell nätverksinstallation (NVA) eller brandvägg kontrollerar du att port 443 är tillgänglig för utgående trafik. Mer information finns i Kontrollera utgående trafik för klusternoder i AKS.

Om DNS löser namn och API:et kan nås, men nodens CSE misslyckades på grund av en API-tidsgräns, vidtar du lämplig åtgärd enligt följande tabell.

Ange typ	Åtgärd
Vm-tillgänglighetsuppsättning	Ta bort noden från Azure Portal och AKS-API:et med kommandot kubectl delete node och skala sedan upp klustret igen.
Skaluppsättning för virtuella datorer	Återskapa noden från Azure Portal eller ta bort noden och skala sedan upp klustret igen. Om du vill ta bort den specifika noden använder du kommandot az aks nodepool delete-machines . Den avspärrar och tömmer först och tar sedan bort noden.

Om begäranden begränsas av AKS API-servern uppgraderar du till en högre tjänstnivå. Mer information finns i Prisnivåer för AKS.

Mer information

Allmänna felsökningssteg finns i Grundläggande felsökning av nodfel som inte är klara.

Dela via