Felsöka Azure Kubernetes Service kluster eller noder i ett feltillstånd

Artikel
04/12/2024

Den här artikeln beskriver hur du felsöker ett Microsoft Azure Kubernetes Service-kluster (AKS) eller en nod som går in i ett feltillstånd.

Vanliga orsaker

Här är de vanligaste orsakerna till ett misslyckat kluster eller en nodpool:

Orsak	Referens
Etableringsfel för tillägg för anpassade skript (CSE) för virtuella datorer (VM)	Felsöka nodfel som inte är klara på grund av CSE-fel
Viktiga Azure-resurser är inte tillgängliga	Felet "Det går inte att hämta information om Log Analytics-arbetsytan" Fel i kluster Load Balancer InvalidResourceReference SubnetFull-fel Privat DNS Zone InternalOperationError
Vm-allokeringsfel på grund av ingen zonindelad/regional kapacitet	AllocationFailed- eller ZonalAllocationFailed-fel Associera kapacitetsreservationsgrupper med nodpooler
Vm-allokeringsfel på grund av överskriden kärnkvot	Kvotexceeded-fel
Kunden införde begränsningar	RequestDisallowedByPolicy-fel Om du anger resurslås förhindrar du att nodpoolen skalas ned
Problem med arbetsbelastningar	En PodDisruptionBudget (PDB) kunde inte tömma poddar Kube-system-poddarna körs inte

Grundläggande felsökning av vanliga fel som gör att ett kluster/en nod misslyckas

I följande tabell beskrivs några vanliga fel som kan orsaka att ett kluster eller en nod anger ett feltillstånd, deras beskrivningar och grundläggande felsökningsmetoder för att lösa dessa fel.

Fel	Beskrivning	Felsökningsmetod
OutboundConnFailVMExtensionError	Det här felet indikerar att VM-tillägget inte kan installeras eller uppdateras på grund av brist på utgående anslutning.	Kontrollera reglerna för nätverkssäkerhetsgruppen (NSG) och brandväggsinställningarna för vm- eller VM-skalningsuppsättningen. Kontrollera att vm- eller VM-skalningsuppsättningen kan komma åt dessa slutpunkter: `https://aka.ms/aks/outbound`, `https://aka.ms/aks/ssh`, `https://aka.ms/aks/agent`och `https://aka.ms/aks/containerinsights`.
Tömningsfel	Det här felet anger att noden inte kan tömmas före uppgraderingen.	Kontrollera poddstatusen och händelserna på noden med hjälp av kubectl-kommandona: `kubectl get pods --all-namespaces -o wide` och `kubectl describe pod <pod-name> -n <namespace>`. Leta efter poddar som har fastnat i ett avslutat eller okänt tillstånd eller med fel eller varningar i händelserna. Du kan behöva tvinga bort poddarna eller starta om kubelet-tjänsten på noden.
SubscriptionNotRegistered-fel	Det här felet anger att prenumerationen inte är registrerad för att använda AKS-resursprovidern.	Registrera prenumerationen `az provider register --namespace Microsoft.ContainerService` med kommandot .
RequestDisallowedByPolicy-fel	Det här felet anger att åtgärden blockeras av en princip som tillämpas på prenumerationen eller resursgruppen.	Granska principinformationen och principtilldelningsomfången. Om du vill tillåta åtgärden kan du behöva ändra eller exkludera principen.
QuotaExceeded-fel	Det här felet anger att åtgärden överskrider kvotgränsen för en resurstyp eller region.	Kontrollera den aktuella kvotanvändningen och kvotgränsen för resurstypen eller regionen med hjälp av Azure Portal, Azure CLI eller Azure PowerShell. Du kan behöva ta bort vissa oanvända resurser eller begära en kvotökning.
PublicIPCountLimitReached-fel	Det här felet anger att åtgärden når det maximala antalet offentliga IP-adresser som kan skapas i en prenumeration eller region.	Kontrollera den aktuella offentliga IP-adressanvändningen och gränsen för prenumerationen eller regionen med hjälp av Azure Portal, Azure CLI eller Azure PowerShell. Du kan behöva ta bort vissa oanvända offentliga IP-adresser eller begära en ökning av gränsen för offentlig IP-adress.
OverconstrainedAllocationRequest-fel	Det här felet anger att åtgärden inte kan allokera den begärda VM-storleken i en region.	Kontrollera tillgängligheten för vm-storleken i regionen med hjälp av Azure Portal, Azure CLI eller Azure PowerShell. Du kan behöva välja en annan vm-storlek eller en annan region.
ReadOnlyDisabledSubscription-fel	Det här felet anger att prenumerationen för närvarande är inaktiverad och inställd på skrivskyddad.	Granska och justera prenumerationsbehörigheterna eftersom prenumerationen kan ha inaktiverats på grund av faktureringsproblem, förfallen kredit eller principöverträdelser.

Grundläggande felsökning av andra möjliga problem som gör att ett kluster/en nod misslyckas

Den här tabellen beskriver andra möjliga problem som kan orsaka att ett kluster eller en nod hamnar i ett feltillstånd, deras beskrivningar och lösningar för att åtgärda dessa problem.

Fråga	Beskrivning	Lösning
Undernätets storlek är för liten	Åtgärden kan inte skapa eller uppdatera klustret eftersom undernätet inte har tillräckligt med utrymme för det antal noder som krävs.	Ta bort nodpoolen och skapa en ny med en större undernätsstorlek med hjälp av Azure Portal, Azure CLI eller Azure PowerShell.
Det virtuella nätverket är blockerat	Åtgärden kan inte kommunicera med kluster-API-servern eller Kubernetes-kontrollplanet eftersom brandväggen eller en anpassad DNS-inställning (Domain Name System) blockerar de utgående anslutningarna från noderna.	Tillåt nodens trafik i brandväggen och konfigurera DNS-matchningen till Azure med hjälp av Azure Portal, Azure CLI eller Azure PowerShell.
PDB-problem	Åtgärden kan inte uppdatera klustret eftersom en PDB stoppade borttagningen av en eller flera poddar. Ett PDB är en resurs som begränsar hur många poddar som kan avslutas frivilligt under en viss period.	Ta tillfälligt bort PDB, stämma av klustret och lägg sedan till PDB igen med kommandoradsverktyget kubectl.
Infrastrukturproblem	Åtgärden kan inte uppdatera klustret på grund av ett internt problem med tjänsten Azure Resource Manager (ARM) som hanterar resurser i Azure.	Gör en agentpoolsavstämning för varje nodpool och en avstämning för det hanterade klustret med hjälp av Azure CLI eller Azure PowerShell.
API-serverfel	Åtgärden kan inte nå kluster-API-servern eller Kubernetes-kontrollplanet på grund av ett avbrott eller ett fel.	Rapportera det till AKS-supportteamet och ange relevanta loggar och diagnostikinformation. Du kan hämta loggarna och diagnostikinformationen med hjälp av Azure Portal, Azure CLI eller Azure PowerShell.

Obs!

Åtgärden som nämns i föregående tabell refererar till alla uppdateringar (PUT) som utlöses från kundsidan.
I Kubernetes finns det en komponent i en kontrollant. Det säkerställer det faktiska tillståndet i världen, inklusive klustertillståndet och potentiellt externa tillstånd som att köra containrar för Kubelet eller lastbalanserare för en molnleverantör. Den överensstämmer med önskat tillstånd som anges i ett objekt. Den här justeringsprocessen är en nyckelfunktion för kontrollanten. För AKS säkerställer den här komponenten att tillståndet för AKS-klustret överensstämmer med önskad konfiguration. Om du vill utlösa den manuellt kör du az resource update --ids <AKS cluster id>. Du kan hämta AKS-kluster-ID:t genom att köra az aks show -n <cluster name> -g <cluster resource group> -o json --query id. Om det finns några skillnader mellan de faktiska och önskade tillstånden vidtar du nödvändiga åtgärder för att korrigera dessa avvikelser.

Kontroll av etableringstillstånd

Om du vill kontrollera klusterstatusen väljer du Etableringstillståndskontroll. Sedan visas etableringstillståndet för klustret och agentpoolen.

Skärmbild som visar alternativet Etableringstillståndskontroll.

Scenario 1: Klustret är i ett feltillstånd

Lös problemet genom att hämta den åtgärd som orsakar felet och ta reda på felet. Här är två vanliga åtgärdsfel som kan resultera i ett misslyckat kluster:

Det gick inte att skapa klustret
Klusteruppgradering misslyckades

Om ett nyligen skapat eller uppgraderat kluster är i ett feltillstånd använder du följande metoder för att felsöka felet:

Granska aktivitetsloggen för att identifiera rotorsaken till felet.

Du kan visa aktivitetsloggen med hjälp av Azure Portal, Azure CLI eller Azure PowerShell.

Aktivitetsloggen kan visa felkoden och meddelandet som är associerat med felet. Mer information om specifika fel finns i avsnittet Grundläggande felsökning av vanliga fel som gör att ett kluster/en nod misslyckas .
Använd funktionen AKS Diagnostisera och lösa problem för att felsöka och lösa vanliga problem.

Obs!

Den här funktionen är endast tillgänglig i Azure Portal och Azure CLI.

Visa aktivitetsloggen för ett misslyckat kluster med hjälp av Azure Portal

Följ dessa steg om du vill visa aktivitetsloggarna för ett misslyckat kluster från Azure Portal:

I Azure Portal går du till sidan Resursgrupper och väljer den resursgrupp som innehåller klustret.
På sidan Översikt väljer du klusternamnet i resurslistan.
På klustersidan väljer du Aktivitetslogg på den vänstra menyn.
På sidan Aktivitetslogg kan du filtrera händelser efter Status, Tidsintervall, Händelse initierad av och Händelsekategori. Du kan till exempel välja Misslyckades i listrutan Status om du bara vill se misslyckade händelser.
Om du vill kontrollera information om en händelse väljer du händelsenamnet i listan. Ett nytt fönster öppnas med händelsesammanfattningen, egenskaperna och JSON-data. Du kan också ladda ned JSON-data som en fil.
Om du vill kontrollera felkoden och meddelandet som är associerat med händelsen rullar du ned till avsnittet Status i händelsesammanfattningen. Du kan också hitta felinformationen i avsnitten egenskaper och JSON-data.

Visa aktivitetsloggen för ett misslyckat kluster med hjälp av Azure CLI

Om du föredrar att använda Azure CLI för att visa aktivitetsloggen för ett misslyckat kluster följer du dessa steg:

Installera Azure CLI på datorn och logga in med ditt Azure-konto.
Visa en lista över resursgrupperna i prenumerationen az group list med hjälp av kommandot och leta reda på namnet på den resursgrupp som innehåller klustret.
Visa en lista över resurserna i resursgruppen med kommandot az resource list med parametern --resource-group och leta reda på namnet på klustret.
Visa en lista över klustrets aktivitetslogg med az monitor activity-log list kommandot och --resource parametrarna --resource-group . Du kan också använda parametrarna --status, --start-time, --end-time, --calleroch --filter för att filtrera händelser efter olika villkor. Du kan till exempel använda --status Failed för att endast se misslyckade händelser.
Visa information om en specifik händelse med hjälp av az monitor activity-log show kommandot med parametrarna --resource-group, --resourceoch --event-id . Du hittar händelse-ID:t från utdata från föregående kommando. Utdata innehåller händelsesammanfattningen, egenskaperna och JSON-data. Du kan också använda parametern --output för att ändra utdataformatet.
Om du vill se felkoden och meddelandet som är associerat med händelsen letar du upp statusMessage fältet i kommandoutdata. Du kan också hitta felinformationen i avsnitten egenskaper och JSON-data.

Använda funktionen AKS Diagnostisera och lösa problem för ett misslyckat kluster

I Azure Portal navigerar du till aks-klusterresursen och väljer Diagnostisera och lösa problem på den vänstra menyn. Du ser en lista över kategorier och scenarier som du kan välja för att köra diagnostikkontroller och få rekommenderade lösningar.

I Azure CLI använder du az aks collect kommandot med parametrarna --name och --resource-group för att samla in diagnostikdata från dina klusternoder. Du kan också använda parametrarna --storage-account och --sas-token för att ange ett Azure Storage-konto där data ska laddas upp. Utdata innehåller en länk till bladet Diagnostisera och lösa problem där du kan visa resultaten och föreslagna åtgärder.

På bladet Diagnostisera och lösa problem kan du välja Klusterproblem som kategori. Om några problem identifieras visas en lista över möjliga lösningar som du kan följa för att åtgärda dem.

Scenario 2: Noden är i ett feltillstånd

I sällsynta fall kan en åtgärd för att koppla från Azure Disk delvis misslyckas, vilket gör att den virtuella nodddatorn är i ett feltillstånd.

Lös problemet genom att uppdatera vm-statusen manuellt med någon av följande metoder:

Kör följande az vm update-kommando för ett kluster som baseras på en tillgänglighetsuppsättning:
```
az vm update --resource-group <resource-group-name> --name <vm-name>
```

För ett kluster som baseras på en VM-skalningsuppsättning kör du följande kommando az vmss update-instances :

az vmss update-instances --resource-group <resource-group-name> --name <scale-set-name> --instance-id <vm-or-scale-set-id>

Scenario 3: Nodpoolen är i ett feltillstånd

Det här problemet kan inträffa när vm-skalningsuppsättningen eller tillgänglighetsuppsättningen som säkerhetskopierar nodpoolen stöter på ett fel under etablering, skalning eller uppdatering. Det här problemet kan bero på otillräcklig kapacitet, kvotgränser, nätverksproblem, principöverträdelser, resurslås eller andra faktorer som förhindrar att den virtuella datorn allokeras eller konfigureras korrekt.

Följ dessa steg för att felsöka det här problemet:

Kontrollera statusen för nodpoolen az aks nodepool show med hjälp av kommandot . Om etableringstillståndet är Failedkan du se felmeddelandet och koden i utdata.
Kontrollera statusen för VM-skalningsuppsättningen eller tillgänglighetsuppsättningen az vmss show med hjälp av kommandot eller az vm availability-set show . Om etableringstillståndet är Failedkan du se felmeddelandet och koden i utdata.
Kontrollera statusen för den enskilda virtuella datorn i nodpoolen az vmss list-instances med hjälp av kommandot eller az vm list . Om en virtuell dator är i ett Failed eller-tillstånd Unhealthy kan du se felmeddelandet och koden i utdata.
Kontrollera aktivitetsloggen och diagnostikinställningen för VM-skalningsuppsättningen eller tillgänglighetsuppsättningen för att se om det finns händelser eller aviseringar som anger orsaken till felet. Du kan använda api:et Azure Portal, Azure CLI eller Azure Monitor för att komma åt aktivitetsloggen och diagnostikinställningen.
Kontrollera kvoten och kapaciteten för den region och prenumeration där nodpoolen distribueras. Du kan använda az vm list-usage kommandot eller Azure Portal för att kontrollera kvoten och kapaciteten. Om kvoten eller kapacitetsgränsen har nåtts kan du begära en ökning eller ta bort några oanvända resurser.
Kontrollera nodpoolens princip- och rolltilldelningar. Du kan använda az policy kommandona och az role eller Azure Portal för att kontrollera principdefinitioner, tilldelningar, efterlevnad och undantag. Du kan också kontrollera rolltilldelningarna och behörigheterna för nodpoolen az role assignment med hjälp av kommandot eller Azure Portal.
Kontrollera resurslåsen för nodpoolen. Du kan använda az lock kommandot eller Azure Portal för att kontrollera låsnivå, omfång och anteckningar. Du kan också ta bort eller uppdatera låset om det behövs.

Andra loggnings- och diagnostikverktyg

Om de tidigare felsökningsmetoderna inte löser problemet kan du använda följande loggnings- och diagnostikverktyg för att samla in mer information och identifiera rotorsaken:

Azure Monitor för containrar:

Den här tjänsten samlar in och analyserar mått och loggar från AKS-kluster och noderna. Azure Monitor för containrar kan övervaka kluster- och nodhälsa, prestanda och tillgänglighet. Du kan också använda den för att visa containerloggar, kubelet-loggar och diagnostikloggar för nodstart.
AKS Periscope

Det här verktyget samlar in nod- och poddloggar, nätverksinformation och klusterkonfiguration från ett AKS-kluster och laddar upp dem till ett Azure Storage-konto. Det här verktyget kan hjälpa dig att felsöka vanliga klusterproblem, till exempel DNS-matchning, nätverksanslutning och nodstatus. Du kan också använda den för att generera en supportbegäran med de insamlade loggarna kopplade.
AKS-diagnostik

Det här verktyget kör en serie kontroller på AKS-kluster och noderna och ger rekommendationer och reparationssteg för vanliga problem. Det här verktyget kan hjälpa dig att felsöka problem som rör klusterskapande, uppgradering, skalning, nätverk, lagring och säkerhet. Du kan också använda den för att generera en supportbegäran med de bifogade diagnostikresultaten.

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.

Dela via