Vanliga frågor och svar – Azure Kubernetes Fleet Manager

Gäller för: ✔️ Fleet Manager ✔️ Fleet Manager med hubbkluster

Den här artikeln beskriver vanliga frågor och svar om Azure Kubernetes Fleet Manager.

Vanliga frågor och svar om Fleet Manager-tjänsten

Är Fleet Manager en regional eller global resurs?

Fleet Manager är en regional resurs. Stöd för regionväxling för haveriberedskapsanvändningsfall finns på färdplanen.

Hur många kluster kan jag ansluta till Fleet Manager?

Fleet Manager (med eller utan hubbkluster) stöder anslutning till upp till 1 000 Kubernetes-kluster. Medlemskluster kan vara en blandning av AKS och Arc-aktiverade Kubernetes.

Om du vill att Fleet Manager ska ha stöd för fler än 1 000 kluster lägger du till feedback.

Vilka Kubernetes-kluster kan jag ansluta till som medlemmar?

Fleet Manager tillåter behöriga användare att lägga till valfritt AKS-, AKS Automatic- eller Arc-aktiverat Kubernetes-kluster i valfri Azure-prenumeration och valfri region, så länge Azure-prenumerationen är associerad med samma Microsoft Entra ID-klientorganisation som Fleet Manager.

Stöder Fleet Manager hanterade identiteter?

Ja, Fleet Manager stöder både systemtilldelade och användartilldelade hanterade identiteter. Mer information finns i dokumentationen om hur du använder hanterade identiteter med Fleet Manager.

Vad händer när jag ändrar klusteridentiteten för ett anslutet kluster?

Om du ändrar identiteten för ett medlemskluster bryts kommunikationen mellan Fleet Manager och det medlemsklustret. Medlemsagenten använder den nya identiteten för att kommunicera med Fleet Manager, men Fleet Manager måste fortfarande känna till den nya identiteten. Kör det här kommandot för att lösa problemet:

az fleet member create \
    --resource-group ${GROUP} \
    --fleet-name ${FLEET} \
    --name ${MEMBER_NAME} \
    --member-cluster-id ${MEMBER_CLUSTER_ID}

Relation till Azure Arc-aktiverade Kubernetes

Fleet Manager stöder både Azure värdbaserade AKS-kluster och Azure Arc-aktiverade Kubernetes-kluster som medlemskluster.

Förhållande till Azure Kubernetes Service-kluster

Azure Kubernetes Service (AKS) förenklar distributionen av ett hanterat Kubernetes-kluster i Azure genom att avlasta driftkostnaderna till Azure. Som värdbaserad Kubernetes-tjänst hanterar Azure viktiga uppgifter, till exempel hälsoövervakning och underhåll. Eftersom Kubernetes-kontrollplanet är Azure-hanterat underhåller du bara agentnoderna. Du kör dina verkliga arbetsbelastningar på AKS-klustren.

Azure Kubernetes Fleet Manager hjälper dig att hantera scenarier i stor skala och flera kluster för Azure Kubernetes Service-kluster. Azure Kubernetes Fleet Manager tillhandahåller en grupprepresentation för dina AKS-kluster och hjälper användare med orkestrering av klusteruppdateringar, Kubernetes-resursspridning och belastningsutjämning för flera kluster. Användararbetsbelastningar kan inte köras på Fleet Manager-hubbklustret.

Kan jag etablera nya AKS-kluster från Fleet Manager?

Skapande och livscykelhantering av nya AKS-kluster finns i vår översikt. Ge feedback om stöd för att skapa kluster är ett viktigt scenario för dig.

Behöver jag hantera uppdateringar av Fleet Manager-hubbklustret?

Nej. Fleet Managers hubbkluster är en Microsoft-hanterad resurs. Microsoft uppdaterar automatiskt hubbklustret till den senaste versionen av Kubernetes eller nodavbildningen när de blir tillgängliga.

Om du försöker uppdatera eller ändra hubbklustret (som är ett AKS-kluster med en nod med namnet hub) blockerar en uppsättning nekanderegler dina ändringar från att tillämpas.

Varför övergick mitt Fleet Manager-hubbkluster från Misslyckades till Att köra?

Fleet Manager-hubbklustret är ett Microsoft-hanterat AKS-kluster som skapats i din prenumeration. Du behöver inte vidta några åtgärder på hubbklustret.

Om det uppstår problem med etablering eller drift av hubbklustret kan det övergå till ett Failed tillstånd.

Fleet Manager synkroniserar automatiskt hubbklustret som en del av periodiska standardåtgärder för tjänsten, vilket kan föra hubbklustret till tillståndet Running.

När ett hubbkluster är Failed det genererar inte en kostnad, men när det flyttas till Running en kostnad genereras.

Uppdateringar med flera kluster – automatiserade eller manuella vanliga frågor och svar

Vilka kluster stöder uppdateringar med flera kluster?

Vilka AKS-uppdateringskanaler stöder Fleet Manager?

Fleet Manager stöder följande AKS-uppdateringskanaler:

• Snabb: Uppdateringar för den senaste AKS-stödda Kubernetes-versionen (N).
• Stabil: Uppdateringar för Kubernetes stable channel (N-1) där "N" är den senaste AKS-stödda Kubernetes-versionen.
• NodeImage: VHD för nodavbildning, patchad med bugg- och säkerhetsfixar, med veckovisa versioner.
• TargetKubernetesVersion (Kubernetes Patch): Uppgraderar kluster till den senaste korrigeringsversionen av den angivna målversionen när korrigeringen är tillgänglig. Stöder Kubernetes-delversioner som endast är tillgängliga via AKS Long-Term Support (LTS).
• SecurityPatch (Linux-nodavbildningar): Uppdateringar av nodavbildningens operativsystem som tillhandahåller AKS-hanterade säkerhetskorrigeringar som tillämpas på den befintliga virtuella hårddisken som körs på noden.

AKS-kanaler som för närvarande inte stöds:

• Ej hanterad: OS-uppdateringar för nodavbildningen tillämpas direkt via operativsystemets inbyggda korrigeringar (endast Linux-noder). Det finns för närvarande inga planer för Fleet Manager att stödja det här alternativet.

Målversionen av Kubernetes delversion i min automatiska uppgraderingsprofil har upphört att stödas av communityn. Vad kan jag göra?

Du kan:

• Tillåt Long Term Support (LTS) i profilen för automatisk uppgradering och aktivera den för alla kluster i din flotta som du vill behålla på den specifika mindre versionen. Se till att endast LTS-kluster ingår i den uppdateringsstrategi som du använder.
• Uppdatera profilen för automatisk uppgradering till en ny mindre version av Kubernetes. Kluster uppdateras till den senaste korrigeringen i den angivna Kubernetes minor-versionen när den släpps.

Information om hur du aktiverar LTS i profiler för automatisk uppgradering finns i Uppdateringar av Kubernetes-målversioner. Information om hur du aktiverar LTS på hanterade kluster finns i Långsiktig support.

Vad händer om jag låter automatiska uppgraderingar av AKS-kluster vara aktiverade?

Om du låter automatisk uppgradering för AKS-klustret vara aktiverad, utförs uppdateringen antingen av Fleet Manager eller av AKS-klustrets automatiska uppgradering, beroende på vilken som sker först.

Fleet Manager ändrar inte konfigurationen av inställningar för automatisk uppgradering av AKS-kluster.

Om du vill att Fleet Manager ska hantera automatiska uppgraderingar inaktiverar du automatisk uppgradering på varje AKS-medlemskluster.

Stöd för underhållsfönster för AKS-kluster

Ett underhållsfönster definierar när ett kluster kan uppgraderas på ett säkert sätt.

Fleet Manager följer underhållsfönsterinställningarna per kluster för varje medlemskluster.

När ett underhållsfönster inleds startar inte uppgraderingarna omedelbart. Orsaker är:

• Gränser för samtidighet: även om ett underhållsfönster infaller kanske ett kluster inte uppgraderas på grund av strategins samtidighetsinställningar.
• Regelbunden pollning: Fleet Manager kontrollerar öppna underhållsfönster var 60:e minut, så den maximala väntetiden är 60 minuter från det att fönstret öppnas.

Vad är omfånget för konsekventa nodbilduppgraderingar?

Nodkonsekvens garanteras endast för alla kluster som finns i en enda uppdateringskörning där du väljer alternativet consistent image .

Det finns ingen garanti för enhetliga nodavbildningsversioner vid separata uppdateringar.

Hur tar jag reda på vilka nodbilder som användes i en uppdateringskörning?

Uppdateringskörningen visar de valda nodbilderna som används för körningen. Du kan komma åt den här informationen även om uppdateringskörningen inte har startats.

Fler än en nodavbildning kan väljas eftersom olika nodpooler fungerar i alla kluster som valts för uppdatering.

Om du vill hitta de markerade bilderna använder du det här kommandot Azure CLI:

az fleet updaterun show \
    --resource-group ${GROUP} \
    --fleet-name ${FLEET} \
    --name ${UPDATE_RUN_NAME} \
    --query "status.nodeImageSelection.selectedNodeImageVersions"

Du kan också använda View JSON alternativet på sidan Översikt över uppdateringskörning i Azure-portalen för att visa rådata för en uppdateringskörning.

Min uppdateringskörning är i vänteläge sedan en längre tid. Vad ska jag göra?

Uppdateringskörningar för Fleet Manager kan vara i ett vänteläge av många skäl. Du kan visa status för en uppdatering som körs antingen via Azure-portalen eller genom att följa övervakningsdokumentationen.

De två vanligaste orsakerna till långa väntande tillstånd är:

• Underhållsfönster för medlemskluster: Om ett medlemsklusters underhållsfönster inte är öppet, övergår uppdateringskörningen till pausat läge. Den här pausen blockerar slutförandet av uppdateringsgruppen eller fasen tills nästa underhållsfönster öppnas. Om du vill fortsätta uppdateringskörningen hoppar du manuellt över klustret. Om du hoppar över klustret är det inte synkroniserat med resten av medlemsklustret i uppdateringskörningen.

• Kubernetes- eller nodavbildningsversion som inte finns i Azure region: Om den nya Kubernetes- eller nodavbildningsversionen inte publiceras till den Azure region där ett medlemskluster finns, går uppdateringskörningen in i ett väntande tillstånd. Du kan kontrollera AKS-versionsspåraren för att se versionens regionala status. Du kan hoppa över medlemsklustret, men om det finns andra kluster i samma Azure region kan de inte heller uppdateras.

Min automatiska uppgraderingskörning startade och gick sedan omedelbart in i ett väntande tillstånd. Varför?

Se föregående fråga.

Jag försökte skapa en uppdateringskörning från min profil för automatisk uppgradering, men jag kan inte se uppdateringskörningen.

När du manuellt genererar en uppdateringskörning från en profil för automatisk uppgradering kanske den resulterande uppdateringskörningen redan finns.

Det här scenariot kan uppstå om profilen för automatisk uppgradering automatiskt genererade uppdateringskörningen, eller om uppdateringskörningen tidigare genererades manuellt.

Namnet på den genererade uppdateringskörningen baseras på den automatiska uppgraderingsprofilens uppgraderingsspecifikation som endast ändras när egenskaper som nodavbildning eller Kubernetes-version uppdateras.

Du ser oftast det här problemet i Azure portalen där den befintliga uppdateringskörningen inte är den senaste uppdateringskörningen. Om du stöter på det här problemet och inte kan hitta uppdateringskörningen kan du använda Azure CLI:t för att generera körningen så att du kan se namnet på uppdateringskörningen. Microsoft planerar att åtgärda problemet i Azure portalen i framtiden.

Om du genererar en uppdateringskörning och den finns ändras inte den befintliga uppdateringskörningen.

Att redigera min uppdateringsstrategi ändrade inte de befintliga uppdateringsprocesser som använde den. Varför inte?

När du skapar en uppdateringskörning kopieras strategin till uppdateringskörningen så att ändringar i strategin inte påverkar körningen av uppdateringskörningar.

Hur förhindrar jag att ett enskilt klusterfel stoppar hela min uppdateringskörning?

maxAllowedFailures Använd inställningen för dina uppdateringsstrategisteg och -grupper (tillgängliga från och med API version 2026-06-02-preview). Med den här inställningen kan du ange hur många medlemsklusterfel som tolereras innan gruppen eller fasen markeras som misslyckad. Värden kan vara ett fast heltal (till exempel "3") eller en procentandel (till exempel "25%"). När den inte är inställd eller "0", stoppar ett enskilt fel hela körningen.

Mer information finns i Maximalt antal tillåtna fel (förhandsversion).

Varför visar min uppdateringskörning eller grupp Slutförd trots att medlemmar misslyckades?

När du anger maxAllowedFailuresutvärderar Fleet Manager endast antalet misslyckade medlemsuppdateringar. Den kräver ingen lägsta framgångsgrad. En uppdateringskörning, fas eller grupp kan därför sluta i Completed även om vissa eller alla medlemmar har misslyckats, så länge det konfigurerade tröskelvärdet inte överskrids när Fleet Manager fattar beslut om schemaläggning.

Det här resultatet är förväntat och avsiktligt, inte en bugg. Inspektera alltid FailureCount, status för enskilda medlemmar och felorsaker innan du betraktar utrullningen som problemfri. För de flesta uppdateringsstrategier är procentbaserade tröskelvärden lättare att resonera kring än absoluta värden.

Vilka regler och begränsningar bör jag veta när jag använder maxAllowedFailures?

Tänk på följande regler:

• Funktionen är tillgänglig från och med API version 2026-06-02-preview.
• När du tar maxAllowedFailures bort eller ställer in den på "0"använder Fleet Manager felsnabbt beteende och stoppas efter den första misslyckade medlemsuppdateringen.
• Tröskelvärdet utvärderas endast mot antalet fel. Den kräver ingen lägsta framgångsgrad.
• En körning, ett steg eller en grupp kan visa Completed även när fel uppstår, så länge det angivna tröskelvärdet inte överskrids.
• FailureCount kan vara större än maxAllowedFailures när uppdateringar körs parallellt, eftersom flera medlemsuppdateringar kan misslyckas innan Fleet Manager slutar schemalägga mer arbete.
• Tröskelvärden på stegnivå och gruppnivå utvärderas oberoende av varandra och fel på stegnivå aggregeras över alla grupper i fasen.
• För de flesta distributioner är procentbaserade tröskelvärden enklare att resonera kring och skala bättre än fasta tal, särskilt i små grupper.

Kan jag godkänna ett godkännande i förväg?

Nej. Du kan bara godkänna en uppgradering när du har kontrollerat att medlemskluster är redo för uppgradering eller att uppgraderingen har slutförts. Om du vill förgodkänna kan du överväga att inte konfigurera ett godkännande i din strategi alls.

Upphör godkännanden att gälla?

Nej, godkännanden väntar tills de har godkänts. Du kan inte konfigurera ett tidsfönster för godkännanden.

Kan jag hoppa över ett godkännande?

Om du vill hoppa över medlemsklusteruppgraderingar tillsammans med gating-godkännandet hoppar du över den omfattande gruppen eller fasen. Om du vill fortsätta med uppgraderingarna måste du bevilja godkännandet.

Hur tar jag bort ett godkännande?

Precis som i föregående fråga måste du bevilja godkännandet om du vill fortsätta med en uppgradering. Om du försöker rensa den underliggande gate-resursen måste du ta bort den associerade uppdateringskörningen, vilket tar bort alla gatear som är länkade till uppdateringskörningen.

Kan jag konfigurera ett godkännande efter ett steg tillsammans med en väntetid efter ett steg?

Ja. Väntetiden efter fasen börjar samtidigt som godkännandet. Båda måste slutföras innan uppdateringskörningen fortsätter.

Kan jag lägga till godkännanden i befintliga uppdateringsstrategier?

Ja. Du kan redigera den befintliga strategin så att den innehåller godkännanden. Befintliga uppdateringskörningar som du har skapat med strategin uppdateras dock inte.

Hur interagerar schemalagda startgrindar med AKS-klusterunderhållsfönster?

Schemalagda startgrindar och planerade underhållsfönster för AKS-kluster är oberoende kontroller. Båda villkoren måste uppfyllas innan ett kluster börjar uppgradera. Om en schemalagd startgrind till exempel slutförs kl. 02:00 men ett klusters underhållsperiod inte öppnas förrän 06:00 väntar klustret till 06:00 för att påbörja uppgraderingen.

Hur kan jag styra ordningen på klusteruppdateringar i en uppdateringskörning?

Medlemsetiketter och uppdateringsgrupper är två olika sätt att välja vilka kluster som ska ingå i varje fas och grupp i din uppdateringsstrategi. Varje medlemskluster kan tilldelas till en uppdateringsgrupp men kan ha flera etiketter. Medlemsetiketter (med ) memberSelectorger mer flexibilitet och stöd för komplexa urvalsscenarier, så de är det rekommenderade sättet att välja medlemmar i flottan för uppdateringsstrategier. Mer information finns i Gruppera kluster med medlemsetiketter.

Behöver jag ange grupper om jag ställer in en medlemsväljare på stegnivå?

Nej. När du ställer in memberSelector på en fas utan att definiera några grupper behandlas alla matchande kluster som en enda grupp. Fasen styr maxConcurrency hur många kluster som uppgraderas samtidigt. Du behöver bara definiera grupper inom en fas om du vill partitionera de matchande medlemmarna i parallella delmängder med olika samtidighetsinställningar.

Vad händer med att uppdatera grupper om jag ställer in en medlemsväljare på gruppnivå?

Om du anger ett memberSelector på gruppnivå används gruppens fält endast som visningsidentifierare name för statusrapportering och loggning. memberSelector Har företräde framför namnet på uppdateringsgruppen när du väljer kluster för gruppen.

Vanliga frågor och svar om placering av klusterresurser

Kan jag välja resurser i ett namnområde för spridning?

Ja. Fleet Manager stöder resursplacering med både klusteromfattning och namnområdesomfång:

• ClusterResourcePlacement: Sprider klusteromfattande resurser och hela namnområden (inklusive allt innehåll) till medlemskluster. Mer information finns i Använda ClusterResourcePlacement för att distribuera klusteromfångsresurser.
• ResourcePlacement: Ger detaljerad kontroll för att välja och sprida specifika namnområdesomfångsresurser (till exempel ConfigMaps, Hemligheter, Distributioner) i ett namnområde. Mer information finns i Använda ResourcePlacement för att distribuera namnområdesomfångsresurser.

Översikt

Översikten över Azure Kubernetes Fleet Manager finns på GitHub. Teamet välkomnar funktionsförfrågningar, frågor och felrapporter.

Nästa steg

• Skapa en flotta och ansluta till medlemskluster.
• Felsökningsguider för Fleet Manager.