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

  • Artikel

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

Förutsättningar

Symptom

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

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:

  1. 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

  2. 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 inte redo.

I allmänhet identifierar slutkoder det specifika problem som orsakar felet. Du ser till exempel 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ätverks timeouter, 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 utföra namnmatchning korrekt. Konfigurera servern så att den uppfyller 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. Detta rekommenderas inte.

  • Undvik att använda IP-adresser i stället för DNS-servern i DNS-inställningarna. 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 påverkas av fördröjningar. Gör så här:

  • 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 för att se om det finns någon 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-timeout, 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.
    VM-skalningsuppsättning Återskapa noden eller ta bort noden och skala sedan upp klustret igen.

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

Mer information