Veelgestelde vragen - Azure Kubernetes Fleet Manager

Van toepassing op: ✔️ Fleet Manager ✔️ Fleet Manager met hubcluster

In dit artikel worden de veelgestelde vragen voor Azure Kubernetes Fleet Manager behandeld.

Veelgestelde vragen over Fleet Manager-service

Is Fleet Manager een regionale of wereldwijde resource?

Fleet Manager is een regionale bron. Ondersteuning voor regionale failover voor toepassingen voor noodherstel staat op de roadmap.

Hoeveel clusters kan ik toevoegen aan Fleet Manager?

Fleet Manager (met of zonder een hubcluster) ondersteunt het samenvoegen van maximaal 1000 Kubernetes-clusters. Lidclusters kunnen bestaan uit een combinatie van AKS en Arc-enabled Kubernetes.

Als u Wilt dat Fleet Manager meer dan 1000 clusters ondersteunt, voegt u feedback toe.

Welke Kubernetes-clusters kan ik deelnemen als leden?

Met Fleet Manager kunnen geautoriseerde gebruikers elk AKS-, AKS-automatisch of Arc-kubernetes-cluster toevoegen in elk Azure abonnement en regio, mits het Azure-abonnement is gekoppeld aan dezelfde Microsoft Entra ID tenant als Fleet Manager.

Ondersteunt Fleet Manager beheerde identiteiten?

Ja, Fleet Manager ondersteunt zowel door het systeem toegewezen als door de gebruiker toegewezen beheerde identiteiten. Zie de documentatie over het gebruik van beheerde identiteiten met Fleet Manager voor meer informatie.

Wat gebeurt er wanneer ik de clusteridentiteit van een gekoppeld cluster wijzig?

Als u de identiteit van een lidcluster wijzigt, wordt de communicatie tussen Fleet Manager en dat lidcluster verbroken. Hoewel de lidagent de nieuwe identiteit gebruikt om met de Fleet Manager te communiceren, moet Fleet Manager nog steeds op de hoogte worden gesteld van de nieuwe identiteit. Voer deze opdracht uit om het volgende op te lossen:

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

Relatie met Kubernetes met Azure Arc

Fleet Manager ondersteunt zowel Azure gehoste AKS-clusters als Azure Arc kubernetes-clusters als lidclusters.

Relatie met Azure Kubernetes Service-clusters

Azure Kubernetes Service (AKS) vereenvoudigt het implementeren van een beheerd Kubernetes-cluster in Azure door de operationele overhead naar Azure te offloaden. Als gehoste Kubernetes-service verwerkt Azure kritieke taken, zoals statuscontrole en onderhoud. Omdat het Kubernetes-besturingsvlak door Azure wordt beheerd, onderhoudt u alleen de agentknooppunten. U voert uw werkelijke workloads uit op de AKS-clusters.

Azure Kubernetes Fleet Manager helpt u bij het oplossen van scenario's met meerdere clusters voor Azure Kubernetes Service-clusters. Azure Kubernetes Fleet Manager biedt een groepsweergave voor uw AKS-clusters en helpt gebruikers bij het organiseren van clusterupdates, het doorgeven van Kubernetes-resources en taakverdeling met meerdere clusters. Gebruikersworkloads kunnen niet worden uitgevoerd op het Fleet Manager-hubcluster.

Kan ik nieuwe AKS-clusters inrichten vanuit Fleet Manager?

Het maken en levenscyclusbeheer van nieuwe AKS-clusters staat op onze roadmap. Geef feedback als ondersteuning voor het maken van clusters een belangrijk scenario voor u is.

Moet ik updates voor het Fleet Manager-hubcluster beheren?

Nee. Fleet Manager's hubcluster is een door Microsoft beheerde resource. Microsoft werkt het hubcluster automatisch bij naar de nieuwste versie van kubernetes of knooppuntinstallatiekopieën zodra deze beschikbaar komen.

Als u probeert het hubcluster (een AKS-cluster met één knooppunt met de naam hub) bij te werken of te wijzigen, worden uw wijzigingen niet toegepast door een set weigeringsregels.

Waarom is mijn Fleet Manager-hubcluster overgestapt van Mislukt naar Actief?

Het Fleet Manager-hubcluster is een Microsoft beheerd AKS-cluster dat in uw abonnement is gemaakt. U hoeft geen actie te ondernemen op het hubcluster.

Als er een probleem is bij het inrichten of gebruiken van het hubcluster, kan het worden verplaatst naar een Failed status.

Fleet Manager past het hubcluster automatisch af als onderdeel van periodieke standaardservicebewerkingen, waardoor het hubcluster naar een Running status kan worden verplaatst.

Wanneer een hubcluster Failed is, brengt dit geen kosten met zich mee, maar wanneer het naar Running gaat, ontstaan er kosten.

Updates voor meerdere clusters - geautomatiseerde of handmatige veelgestelde vragen

Welke clusters ondersteunen updates voor meerdere clusters?

Welke AKS-updatekanalen ondersteunt Fleet Manager?

Fleet Manager ondersteunt de volgende AKS-updatekanalen:

• Snel: Updates voor de meest recente kubernetes-release (N) die door AKS wordt ondersteund.
• Stabiel: Updates voor kubernetes stabiel kanaal (N-1) waarbij 'N' de meest recente Kubernetes-release is die door AKS wordt ondersteund.
• NodeImage: knooppuntinstallatiekopie-VHD gepatcht (bugfixes en beveiligingsupdates) volgens een wekelijks releaseschema.
• TargetKubernetesVersion (Kubernetes Patch): hiermee worden clusters bijgewerkt naar de nieuwste patchrelease van de opgegeven doelversie wanneer de patch beschikbaar is. Ondersteunt Secundaire versies van Kubernetes die alleen beschikbaar zijn via AKS Long-Term Support (LTS).
• SecurityPatch (Linux-knooppuntinstallatiekopieën): updates voor het besturingssysteem van knooppuntinstallatiekopieën waarmee door AKS beheerde beveiligingspatches worden geleverd die worden toegepast op de bestaande VHD die op het knooppunt wordt gebruikt.

Momenteel niet-ondersteunde AKS-kanalen:

• Onbeheerd: updates van het besturingssysteem van knooppuntinstallatiekopieën worden rechtstreeks toegepast via ingebouwde patches van het besturingssysteem (alleen Linux-knooppunten). Er zijn momenteel geen plannen voor Fleet Manager om deze optie te ondersteunen.

De minor versie van Kubernetes in mijn profiel voor automatische upgrade valt buiten de community-ondersteuning. Wat kan ik doen?

U kunt:

• Sta LONG Term Support (LTS) toe in het profiel voor automatische upgrade en schakel dit in voor alle clusters in uw vloot die u wilt behouden op de specifieke minor. Zorg ervoor dat alleen LTS-clusters zijn opgenomen in de updatestrategie die u gebruikt.
• Werk het profiel voor automatische upgrade bij naar een nieuwe secundaire kubernetes-doelversie. Clusters worden bijgewerkt naar de meest recente patch in de opgegeven Kubernetes-secundaire versie wanneer ze worden uitgebracht.

Zie Doel-Kubernetes-versie-updates voor informatie over het inschakelen van LTS in profielen voor automatische upgrade. Zie Langetermijnondersteuning voor informatie over het inschakelen van LTS in beheerde clusters.

Wat gebeurt er als ik automatische upgrades van AKS-clusters ingeschakeld laat?

Als u automatische upgrades van AKS-clusters ingeschakeld laat, wordt de update automatisch uitgevoerd in Fleet Manager of AKS-cluster, afhankelijk van welke eerst wordt uitgevoerd.

Fleet Manager wijzigt de configuratie van instellingen voor automatische upgrade van AKS-clusters niet.

Als u wilt dat Fleet Manager automatische upgrades beheert, schakelt u automatische upgrade uit op elk AKS-cluster van leden.

Ondersteuning voor het onderhoudsvenster voor AKS-clusters

Een onderhoudsvenster definieert wanneer een cluster veilig kan worden bijgewerkt.

Fleet Manager respecteert de onderhoudsvensterinstellingen per cluster voor elk lidcluster.

Wanneer er een onderhoudsvenster wordt geopend, worden upgrades niet onmiddellijk gestart. Redenen zijn onder andere:

• Gelijktijdigheidslimieten: zelfs als er een onderhoudsvenster wordt geopend, wordt een cluster mogelijk niet bijgewerkt vanwege de gelijktijdigheidsinstellingen voor de strategie.
• Regelmatige polling: Fleet Manager peilt elke 60 minuten naar geopende onderhoudsvensters, dus de maximale wachttijd is 60 minuten van het venster geopend.

Wat is de omvang van upgrades van consistente knooppuntafbeeldingen?

Consistentie van knooppunten is alleen gegarandeerd voor alle clusters in één updateuitvoering waarbij u de consistent image optie kiest.

Er is geen consistentiegarantie voor versies van knooppuntafbeeldingen in afzonderlijke updatecycli.

Hoe kom ik erachter welke knooppuntafbeeldingen zijn gebruikt in een updateproces?

De updatebewerking vermeldt de geselecteerde knooppuntimages die voor deze bewerking worden gebruikt. U hebt toegang tot deze informatie, zelfs als de update-uitvoering nog niet is gestart.

Er kunnen meerdere node-images worden geselecteerd, omdat verschillende knooppuntgroepen actief zijn in alle clusters die zijn geselecteerd om te worden bijgewerkt.

Als u de geselecteerde afbeeldingen wilt zoeken, gebruikt u deze Azure CLI opdracht:

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

U kunt de View JSON optie ook gebruiken op de pagina Update Run Overzicht in de Azure-portal om de onbewerkte gegevens voor een updateuitvoering weer te geven.

Mijn updateproces staat al enige tijd in de wachtstand. Wat moet ik doen?

Fleet Manager - update-uitvoeringen kunnen om verschillende redenen in afwachting zijn. U kunt de status van een updateuitvoering bekijken via de Azure-portal of door de bewakingsdocumentatie te volgen.

De twee meest voorkomende redenen voor lang wachtende statussen zijn:

• Onderhoudsvensters voor lidclusters: als het onderhoudsvenster van een lidcluster niet is geopend, wordt de updateuitvoering onderbroken. Hierdoor wordt de voltooiing van de updategroep of fase geblokkeerd totdat het volgende onderhoudsvenster wordt geopend. Als u de updateuitvoering wilt voortzetten, slaat u het cluster handmatig over. Als u het cluster overslaat, is het niet gesynchroniseerd met de rest van de lidclusters in de updateuitvoering.

• Kubernetes- of knooppuntinstallatiekopieversie niet in Azure regio: Als de nieuwe versie van de Kubernetes- of knooppuntinstallatiekopie niet wordt gepubliceerd naar de Azure regio waarin een lidcluster bestaat, wordt de updateuitvoering de status In behandeling weergegeven. U kunt de AKS-releasetracker controleren om de regionale status van de versie te bekijken. Hoewel u het lidcluster kunt overslaan, kunnen ze ook niet worden bijgewerkt als er andere clusters in dezelfde Azure regio zijn.

Mijn automatische upgrade is gestart en is vervolgens onmiddellijk in een wachttijdstatus terechtgekomen. Waarom?

Zie de vorige vraag.

Ik heb geprobeerd een updateuitvoering te genereren vanuit mijn profiel voor automatische upgrade, maar ik zie de updateuitvoering niet.

Wanneer u handmatig een updateuitvoering genereert vanuit een profiel voor automatische upgrade, bestaat de resulterende updateuitvoering mogelijk al.

Dit scenario kan zich voordoen als het profiel voor automatisch upgraden de updateuitvoering automatisch heeft gegenereerd of als de update-uitvoering eerder handmatig is gegenereerd.

De naam van de gegenereerde updaterun is gebaseerd op de upgradespecificatie van het automatisch-upgradeprofiel, die alleen verandert wanneer eigenschappen zoals de knooppuntimage of de Kubernetes-versie worden bijgewerkt.

Dit probleem wordt meestal weergegeven in de Azure-portal, waarbij de bestaande updateuitvoering niet de meest recente updateuitvoering is. Als u dit probleem ondervindt en de updateuitvoering niet kunt vinden, gebruikt u de Azure CLI om de uitvoering te genereren om de naam van de updateuitvoering weer te geven. Microsoft plannen om dit probleem in de Azure portal in de toekomst op te lossen.

Als u een updateuitvoering genereert en deze bestaat, wordt de bestaande updateuitvoering niet gewijzigd.

Het bewerken van mijn updatestrategie heeft de bestaande updateuitvoeringen die deze hebben gebruikt, niet gewijzigd. Waarom niet?

Wanneer u een updateuitvoering maakt, wordt de strategie gekopieerd naar de updateuitvoering, zodat wijzigingen in de strategie geen invloed hebben op het uitvoeren van updateuitvoeringen.

Hoe kan ik voorkomen dat één clusterfout mijn volledige updateuitvoering stopt?

Gebruik de maxAllowedFailures instelling voor de fasen en groepen van uw updatestrategie (beschikbaar vanaf API-versie 2026-06-02-preview). Met deze instelling kunt u opgeven hoeveel mislukte lidclusterfouten worden getolereerd voordat de groep of fase is gemarkeerd als mislukt. Waarden kunnen een vast geheel getal zijn (bijvoorbeeld "3") of een percentage (bijvoorbeeld "25%"). Wanneer deze niet is ingesteld of "0", stopt één fout de volledige uitvoering.

Zie Maximaal toegestane fouten (preview) voor meer informatie.

Waarom wordt de status van mijn update-uitvoering of -groep weergegeven als Voltooid, ook al zijn sommige leden mislukt?

Wanneer u instelt maxAllowedFailures, evalueert Fleet Manager alleen het aantal mislukte lidupdates. Er wordt geen minimum slagingspercentage afgedwongen. Een update-uitvoering, fase of groep kan daarom in Completed eindigen, zelfs als sommige of alle leden zijn uitgevallen, zolang de geconfigureerde drempelwaarde niet wordt overschreden wanneer Fleet Manager zijn planningsbeslissingen maakt.

Dit resultaat wordt verwacht en opzettelijk, geen bug. Controleer FailureCountaltijd statussen op lidniveau en mislukte redenen voordat u de implementatie als gezond behandelt. Voor de meeste updatestrategieën zijn drempelwaarden op basis van percentages gemakkelijker te redeneren dan absolute waarden.

Welke regels en beperkingen moet ik weten wanneer ik maxAllowedFailures gebruik?

Houd rekening met de volgende regels:

• De functie is beschikbaar vanaf API-versie 2026-06-02-preview.
• Wanneer u maxAllowedFailures uitschakelt of deze op "0" instelt, gebruikt Fleet Manager fail-fast-gedrag en stopt Fleet Manager na de eerste mislukte update van een lid.
• De drempelwaarde wordt alleen geëvalueerd op basis van het aantal fouten. Er wordt geen minimum slagingspercentage afgedwongen.
• Een run, fase of groep kan Completed weergeven, zelfs als er mislukkingen optreden, zolang de geconfigureerde drempelwaarde niet wordt overschreden.
• FailureCount kan groter zijn dan maxAllowedFailures wanneer updates parallel worden uitgevoerd, omdat meerdere lidupdates mogelijk mislukken voordat Fleet Manager stopt met het plannen van meer werk.
• Drempelwaarden op faseniveau en groepsniveau worden onafhankelijk geëvalueerd en fouten op faseniveau worden geaggregeerd voor alle groepen in de fase.
• Voor de meeste implementaties zijn drempelwaarden op basis van percentages gemakkelijker te redeneren en beter te schalen dan vaste getallen, met name in kleine groepen.

Kan ik een goedkeuring vooraf goedkeuren?

Nee. U kunt een upgrade pas goedkeuren nadat u hebt gecontroleerd of de lidclusters gereed zijn voor de upgrade of dat de upgrade is voltooid. Als u vooraf wilt goedkeuren, kunt u overwegen om helemaal geen goedkeuring in uw strategie te configureren.

Verlopen goedkeuringen?

Nee, goedkeuringen wachten totdat ze zijn goedgekeurd. U kunt geen tijdvenster voor goedkeuringen configureren.

Kan ik een goedkeuring overslaan?

Als u de upgrades van het lidcluster samen met de keuringstoestemming wilt overslaan, slaat u de gehele groep of fase over. Als u door wilt gaan met de upgrades, moet u de goedkeuring verlenen.

Hoe verwijder ik een goedkeuring?

Net als in de vorige vraag, moet u de goedkeuring verlenen als u wilt doorgaan met een upgrade. Als u de onderliggende gate-resource wilt verwijderen, moet u de bijbehorende update-uitvoering verwijderen, waarmee alle gates die aan die update-uitvoering zijn gekoppeld, worden verwijderd.

Kan ik een goedkeuring na een fase samen met een wachttijd na een fase instellen?

Ja. De wachttijd na de fase begint op hetzelfde moment als de goedkeuring. Beide moeten worden voltooid voordat de update wordt uitgevoerd.

Kan ik goedkeuringen toevoegen aan bestaande updatestrategieën?

Ja. U kunt de bestaande strategie bewerken om goedkeuringen op te nemen. Bestaande updateuitvoeringen die u hebt gemaakt met behulp van de strategie, worden echter niet bijgewerkt.

Hoe communiceren geplande startpoorten met onderhoudsvensters voor AKS-clusters?

Geplande startpoorten en geplande onderhoudsvensters van het AKS-cluster zijn onafhankelijke besturingselementen. Aan beide voorwaarden moet worden voldaan voordat een cluster wordt geupgraded. Als een geplande startpoort bijvoorbeeld om 2:00 uur is voltooid, maar het onderhoudsvenster van een cluster pas om 6:00 uur wordt geopend, wacht het cluster tot 6:00 uur om de upgrade te starten.

Hoe kan ik de volgorde van clusterupdates in een updateuitvoering beheren?

Lidlabels en updategroepen zijn twee verschillende manieren om te selecteren welke clusters zijn opgenomen in elke fase en groep van uw updatestrategie. Elk lidcluster kan worden toegewezen aan één updategroep, maar kan meerdere labels hebben. Ledenlabels (met behulp van memberSelector) bieden meer flexibiliteit en ondersteunen complexe selectiescenario's, zodat ze de aanbevolen manier zijn om vlootleden te selecteren voor updatestrategieën. Zie Groepsclusters met lidlabels voor meer informatie.

Moet ik groepen opgeven als ik een lidkiezer op faseniveau heb ingesteld?

Nee. Wanneer u een fase instelt memberSelector zonder groepen te definiëren, worden alle overeenkomende clusters behandeld als één groep. De fase maxConcurrency bepaalt hoeveel clusters gelijktijdig worden bijgewerkt. U hoeft alleen groepen in een fase te definiëren als u de overeenkomende leden wilt partitioneren in parallelle subsets met verschillende gelijktijdigheidsinstellingen.

Wat gebeurt er met het bijwerken van groepen als ik een lidkiezer op groepsniveau heb ingesteld?

Als u een memberSelector op groepsniveau instelt, wordt het veld van de groep name alleen gebruikt als display-identificator voor statusrapportage en logboeken. memberSelector heeft voorrang boven de naam van de updategroep wanneer u clusters voor de groep selecteert.

Veelgestelde vragen over plaatsing van clustermiddelen

Kan ik resources in een naamruimte selecteren voor doorgifte?

Ja. Fleet Manager ondersteunt zowel cluster- als naamruimte-gebaseerde resourceplaatsing:

• ClusterResourcePlacement: hiermee worden resources met clusterbereik en volledige naamruimten (inclusief alle inhoud) doorgegeven aan lidclusters. Zie ClusterResourcePlacement gebruiken om resources met clusterbereik te implementeren voor meer informatie.
• ResourcePlacement: biedt gedetailleerd beheer voor het selecteren en verspreiden van specifieke resources die beperkt zijn tot een naamruimte (zoals ConfigMaps, Secrets, en Deployments). Zie ResourcePlacement gebruiken om resources met naamruimtebereik te implementeren voor meer informatie.

Routekaart

De Azure Kubernetes Fleet Manager-roadmap is beschikbaar op GitHub. Het team verwelkomt functieaanvragen, vragen en bugrapporten.

Volgende stappen

• Maak een vloot en voeg lidclusters toe.
• Handleidingen voor probleemoplossing voor Fleet Manager.