Kubernetes- en knooppuntinstallatiekopieën veilig bijwerken in meerdere clusters

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

Platformbeheerders die grote aantallen clusters beheren, hebben vaak problemen met het faseren van updates voor meerdere clusters (bijvoorbeeld het upgraden van de installatiekopie van het knooppuntbesturingssysteem of kubernetes-versies) op een veilige en voorspelbare manier. Om deze uitdaging aan te pakken, kunt u met Azure Kubernetes Fleet Manager updates in meerdere clusters organiseren met behulp van updateuitvoeringen.

Updateuitvoeringen bestaan uit fasen, groepen en strategieën. U kunt updateuitvoeringen handmatig toepassen voor eenmalige updates of automatisch voor doorlopende reguliere updates met behulp van profielen voor automatische upgrade. Alle updateuitvoeringen, zowel handmatig als geautomatiseerd, houden rekening met onderhoudsvensters voor clusters.

Inzicht in updateruns

Een updateuitvoering vertegenwoordigt een update die wordt toegepast op een verzameling AKS-clusters. Het bestaat uit het doel van de update en de volgorde. Het doel van de update beschrijft de gewenste wijzigingen. Bijvoorbeeld upgraden naar een specifieke Kubernetes-versie of dezelfde node-image gebruiken voor alle clusters.

Om de beste resultaten te behalen bij het gebruik van updateuitvoeringen, is het belangrijk dat u de volgende concepten begrijpt.

• Updatestrategie: beschrijft een herbruikbare updatereeks die bestaat uit fasen en groepen clusters. Een cluster wordt weergegeven in een groep in een fase op basis van de updategroep of lidlabels waaraan het is toegewezen. Zie update-strategieën begrijpen voor meer informatie.

  • Updatefase: een updatestrategie is onderverdeeld in updatefasen, die opeenvolgend worden toegepast. Testomgevingsclusters bevinden zich bijvoorbeeld in de eerste updatefase, terwijl productieomgevingsclusters in een tweede updatefase gaan. Een updatefase bevat een of meer updategroepen. U kunt aanvullende besturingselementen gebruiken, zoals maximale gelijktijdigheid, wachttijden en goedkeuringspoorten voor meer controle over de uitvoering van updatefasen.

  • Updategroep: Elke updatefase bevat een of meer updategroepen, die clusters selecteren die moeten worden bijgewerkt. Wijs memberclusters toe aan Updategroepen met behulp van de eigenschap Updategroep van het cluster of via de previewfunctie voor labelgebaseerde overeenstemming met behulp van memberlabels. Updategroepen in een update van een updatefase worden parallel bijgewerkt.

  Notitie

  Het maximum aantal updategroepen in elke updatefase is 50.

  • Verdere besturingselementen voor stromen: er zijn meer besturingselementen beschikbaar om flexibiliteit te bieden over hoe snel een vloot clusters kan worden bijgewerkt:

    • Maximale gelijktijdigheid (preview): gebruik de configuratie voor maximale gelijktijdigheid om te wijzigen hoeveel clusters parallel worden bijgewerkt. U kunt dit gedrag configureren op zowel fase- als groepsniveau.

    • Maximaal toegestane fouten (preview): gebruik de configuratie voor maximaal toegestane fouten om te bepalen hoeveel mislukte upgraden van lidclusters worden getolereerd voordat de updateuitvoering wordt gestopt. U kunt dit gedrag configureren op zowel fase- als groepsniveau.

    • Gates: Onderbreek de update totdat aan de voorwaarden is voldaan.

      • Goedkeuringspoorten (preview): kan worden geconfigureerd voor of na elke fase of groep. Goedkeuringen pauzeren de update, zodat jij of de automatiseringen die je hebt ingesteld kunnen controleren of het goed is om door te gaan. Nadat u of uw automatisering goedkeuring heeft verleend, wordt de updateuitvoering voortgezet.

      • Geplande beginpoorten (preview): kan worden geconfigureerd voor elke fase of groep. Geplande startpoorten onderbreken de updateuitvoering tot een opgegeven dag en tijd. De poort wordt automatisch voltooid wanneer de geplande tijd is bereikt of u kunt deze handmatig voltooien om door te gaan op elk gewenst moment.

• Profiel voor automatische upgrade: automatisch een updateuitvoering maken en starten wanneer nieuwe versies van Kubernetes of knooppuntinstallatiekopieën beschikbaar worden gesteld door AKS. Zie voor meer informatie over profielen voor automatische upgrade.

Opties voor uitvoeren bijwerken

Bijwerkuitvoeringen kunnen drie typen upgrades toepassen:

• Kubernetes-versies upgraden voor het besturingsvlak en de knooppunten. Deze upgrade omvat ook een upgrade van de node-image.
• Voer een upgrade uit van Kubernetes-versies voor alleen het besturingsvlak van de clusters.
• Alleen de knooppuntafbeeldingen bijwerken.

U kunt de Kubernetes-doelversie opgeven waarnaar u wilt upgraden, maar u kunt de versies van de doelknooppuntinstallatiekopieën niet selecteren. Het systeem selecteert automatisch de versies van de installatiekopieën voor het doelknooppunt op basis van uw voorkeuren:

• Meest recente: Gebruik de nieuwste knooppuntinstallatiekopieën die beschikbaar zijn in de Azure regio van elk cluster wanneer de upgrade van dat cluster wordt gestart. Als gevolg hiervan kunnen verschillende installatiekopieën in de hele vloot worden gebruikt, afhankelijk van de Azure regio waarin een cluster zich bevindt en wanneer de upgrade daadwerkelijk wordt gestart.
• Consistent: Wanneer de updateuitvoering wordt gestart, kiest u installatiekopieversies die momenteel beschikbaar zijn in alle Azure regio's waar de clusters in deze uitvoering zich bevinden. Daarom worden in alle clusters dezelfde imageversies gebruikt.

Kies Nieuwste om nieuwere versies van installatiekopieën te gebruiken en beveiligingsrisico's te minimaliseren. Kies Consistent om de betrouwbaarheid te verbeteren door deze installatiekopieën in clusters in eerdere fasen te gebruiken en te verifiëren voordat u ze in latere clusters gebruikt.

Statussen van runs bijwerken

Als u de levenscyclus van een updateuitvoering wilt begrijpen, moet u elke status, de acties die u kunt ondernemen en hoe de status wordt berekend, weten.

Status in behandeling

• Update uitvoeren: als de huidige fase de status Pending heeft.
• Updatefase: als alle Update Groups in de fase Pending of niet gestart zijn, of als de fase een Pending gate heeft.
• Updategroep: als alle clusters in de groep Pending zijn of niet zijn gestart, of als de groep een Pending blokkade heeft. Wanneer een cluster naartoe Pendingwordt verplaatst, probeert de updateuitvoering het volgende cluster in de groep bij te werken. Als alle leden zijn Pending, wordt de groep verplaatst naar Pending. De updatebewerking wacht totdat alle groepen in een fase zijn afgerond voordat wordt doorgegaan naar de volgende fase.
• Lidcluster: om een van de volgende redenen, die u in het berichtveld kunt bekijken.
  • Het onderhoudsvenster is niet geopend. Bericht geeft de volgende openingstijd aan.
  • De beoogde versie van Kubernetes of de node-installatiekopie is nog niet beschikbaar in de Azure-regio van het cluster. Het bericht bevat koppelingen naar de AKS-releasetracker om de releasestatus te controleren.

Overgeslagen status

• Update-run: het systeem heeft vastgesteld dat alle fasen Skipped waren.
• Updatefase: een gebruiker heeft de fase gemarkeerd of alle groepen in de fase als Skipped.
• Groep bijwerken: een gebruiker heeft de groep of alle clusters in de groep gemarkeerd als Skipped.
• Lidcluster: om een van de volgende redenen, die u in het berichtveld kunt bekijken.
  • De gebruiker heeft het cluster, de groep of de fase uitdrukkelijk overgeslagen.
  • Het cluster heeft al de doelversie van Kubernetes (als de uitvoeringsmodus van de update Full of ControlPlaneOnly is) en alle nodepools hebben al de doelversie van de node-installatiekopie.
  • Wanneer een consistente node-installatiekopie is geselecteerd en het niet mogelijk is om voor een van de nodepools de doelversie van de installatiekopie te vinden. Deze situatie kan optreden wanneer een nieuwe knooppuntgroep met een nieuwe VM-SKU (virtuele machine) wordt toegevoegd nadat een update-uitvoering is gestart.

Status mislukt

De status Mislukt wordt vanuit clusters doorgegeven, zoals weergegeven. Een samenvattend foutbericht geeft de oorzaak van de mislukte upgrade van het cluster weer.

• Updateuitvoering: ten minste één cluster in de huidige groep is mislukt.
• Updatefase: ten minste één cluster in een groep in de fase is mislukt.
• Updategroep: ten minste één cluster in de groep is mislukt.
• Lidcluster: de upgrade is mislukt en de clusterstatus is ingesteld als Failed.

Wanneer u maximaal toegestane fouten configureert, heeft de drempelwaarde voor fouten invloed op de status van de updategroep, de updatefase en de updateuitvoering. Dit heeft geen invloed op de status van een afzonderlijk lidcluster. Als een upgrade van een lidcluster mislukt, is de status ervan nog steeds ingesteld op Failed.

• Als het aantal fouten voor de groep of fase de geconfigureerde maxAllowedFailures drempelwaarde overschrijdt, wordt de groep of fase gemarkeerd als Failed een samenvattingsfoutbericht en wordt de updateuitvoering gestopt. Als er geen maxAllowedFailures is geconfigureerd (of is ingesteld op 0), stopt één fout de hele uitvoering.
• Als het aantal fouten binnen de maxAllowedFailures drempelwaarde valt, wordt de updateuitvoering voortgezet met het upgraden van volgende leden. Zie Maximaal toegestane fouten voor meer informatie.

Status voltooid

Een Completed status betekent dat de updateuitvoering de status van de levenscyclus van de terminal heeft bereikt. Wanneer u maximaal toegestane fouten gebruikt, Completed betekent dit dat de geconfigureerde drempelwaarde voor fouten niet is overschreden wanneer Fleet Manager heeft besloten of de planning van het werk moet worden voortgezet. Het garandeert geen minimum slagingspercentage of gezonde resultaten. Controleer altijd FailureCount, lidstaten en foutmeldingen.

Geplande onderhoudsvensters

Update wordt uitgevoerd op geplande onderhoudsvensters die u hebt ingesteld op het niveau van het AKS-cluster.

AKS-clusters ondersteunen twee afzonderlijke onderhoudsvensters: één voor Kubernetes-upgrades (besturingsvlak) en één voor upgrades van knooppuntinstallatiekopieën. Onderhoudsvensters definiëren perioden waarin updates kunnen worden toegepast op een cluster, maar geen updatetrigger zijn.

Fleet Manager-updates respecteren de AKS-onderhoudsvensters als volgt:

De update geeft prioriteit aan het upgraden van clusters op basis van gepland onderhoud in de volgende volgorde:

1. Cluster met een geopend onderhoudsvenster.
2. Cluster met een onderhoudsvenster dat in de komende vier uur begint.
3. Cluster zonder onderhoudsvenster.
4. Cluster met een gesloten onderhoudsvenster.

Overzicht van profielen voor automatische upgrade

Gebruik profielen voor automatische upgrades om updateruns automatisch te starten wanneer er voor AKS nieuwe versies van Kubernetes of knooppuntafbeeldingen beschikbaar zijn.

In een profiel voor automatische upgrade configureert u het volgende:

• een kanaal (Rapid, Stable, TargetKubernetesVersion, NodeImage, SecurityPatch (preview)) dat bepaalt welk type update op de clusters wordt toegepast.
• een UpdateStrategy waarmee de volgorde wordt geconfigureerd waarin de clusters worden bijgewerkt. Als u geen strategie opgeeft, worden clusters één voor één opeenvolgend bijgewerkt.
• de NodeImageSelectionType (Latest, Consistent) om op te geven hoe de knooppuntimage wordt geselecteerd bij het upgraden van de Kubernetes-versie.

Snel kanaal

Het Rapid-kanaal is altijd de meest recente door AKS ondersteunde Kubernetes-secundaire release. Secundaire clusterversies worden automatisch gewijzigd wanneer AKS een nieuwe secundaire Kubernetes-versie publiceert.

Voorbeelden:

• De meest recente ondersteunde secundaire versie is 1.30. Elke patchversie in de minorreeks 1.30 komt in aanmerking voor updates voor het Rapid-kanaal.
• Er wordt een nieuwe secundaire Kubernetes-versie van 1.31 gepubliceerd. 1.30 schakelt naar het Stabiele kanaal. Elk cluster dat eerder updates van 1.30 ontvangt, wordt bijgewerkt naar de meest recente patch voor 1.31 dat nu het Rapid-kanaal is.

Stabiel kanaal

Het Stabiele kanaal is altijd de secundaire versie vóór het Rapid-kanaal . Soms verwijzen mensen naar Stable als 'N-1', waarbij 'N' de meest recente (Rapid-kanaal) ondersteunde Kubernetes-secundaire versie is. Secundaire clusterversies worden automatisch gewijzigd wanneer AKS een nieuwe secundaire Kubernetes-versie publiceert.

Voorbeelden:

• De meest recente ondersteunde secundaire Kubernetes-versie is 1.30. Eventuele patchreleases in de minorreeks van 1.29 worden in aanmerking genomen voor updates voor het stabiele kanaal.
• Er wordt een nieuwe secundaire Kubernetes-versie van 1.31 gepubliceerd. Het Stable-kanaal beschouwt elke patchrelease in het secundaire bereik van 1.30 voor updates. Elk cluster dat eerder updates van 1.29 ontvangt, wordt bijgewerkt naar de meest recente patch voor 1.30.

TargetKubernetesVersion-kanaal

Het TargetKubernetesVersion-kanaal geeft u controle over wanneer u uw clusters naar de volgende secundaire Kubernetes-versie verplaatst. U moet de kubernetes-doelversie opgeven in de indeling {major}. {minor}" (bijvoorbeeld '1,33'). Fleet Manager werkt clusters automatisch bij naar de nieuwste patchversie van de opgegeven Kubernetes-doelversie wanneer de patch beschikbaar is. Fleet Manager wordt pas geüpgraded naar de volgende minor-versie wanneer de Kubernetes-doelversie van het auto-upgradeprofiel is bijgewerkt.

Voorbeelden:

• U maakt een profiel voor automatische upgrade met behulp van het TargetKubernetesVersion-kanaal en geeft een Kubernetes-doelversie van '1.30' op. Er wordt een nieuwe patchversie 1.30.5 gepubliceerd. Er wordt automatisch een updaterun gemaakt met als doelversie 1.30.5.
• U maakt een profiel voor automatische upgrade met behulp van het TargetKubernetesVersion-kanaal, geeft een Kubernetes-doelversie van '1.29' op en schakelt LongTermSupport (LTS) in het profiel voor automatische upgrade in. De meest recente ondersteunde secundaire versie van de community is 1.33. Er wordt een nieuwe patchversie 1.29.5 gepubliceerd. Er wordt automatisch een update-uitvoering gemaakt met als doelversie 1.29.5. Als de gegenereerde updateuitvoering clusters bevat zonder LTS ingeschakeld, mislukt deze.

Gedrag bij het overslaan van secundaire versies

Met automatische upgrade worden clusters niet verplaatst tussen secundaire Kubernetes-versies wanneer er meer dan één secundair Kubernetes-versieverschil is (bijvoorbeeld: 1.28 tot 1.30). Wanneer beheerders een diverse set Kubernetes-versies hebben, moet u eerst een of meer updateruns gebruiken om clusters in een set consistente versies te brengen, zodat geconfigureerde Stable of Rapid kanaalupdates ervoor zorgen dat consistentie in de toekomst behouden blijft.

NodeImage-kanaal

Lidclusterknooppunten worden bijgewerkt met een nieuw gepatchte VHD met beveiligingsoplossingen en bugfixes op een wekelijkse frequentie. De update naar de nieuwe VHD is disruptief, volgend op onderhoudsvensters en piekinstellingen. Er worden geen extra VHD-kosten gemaakt bij het kiezen van deze optie. Upgrades van knooppuntinstallatiekopieën ondersteunen patchversies die zijn afgeschaft, zolang de secundaire Kubernetes-versie nog steeds wordt ondersteund. Node-afbeeldingen worden door AKS getest, zijn volledig beheerd en worden toegepast met veilige implementatiepraktijken.

Knooppunten op verschillende besturingssystemen worden bijgewerkt in overeenstemming met de node-afbeeldingsversies die zijn afgestemd op die besturingssystemen.

Voorbeeld:

• Een cluster heeft knooppunten met een NodeImage van AKSWindows-2022-containerd van versie 20348.2582.240716. Er wordt een nieuwe NodeImage-versie 20348.2582.240916 uitgebracht en de clusterknooppunten worden automatisch bijgewerkt naar versie 20348.2582.240916.

Inzicht in upgrades en momentopnamen van knooppunt-afbeeldingen

Wanneer een cluster agentpools bevat die zijn gemaakt vanuit een snapshot van een nodepool, hangt het resultaat van de upgrade van de node-installatiekopie af van de selectie van de node-installatiekopie in Fleet Manager Update Run.

SecurityPatch-kanaal (previewversie)

Werk knooppunten van lidclusters met Linux wekelijks bij met uitsluitend beveiligingsupdates. Canonical Ubuntu en Azure Linux maken besturingssysteembeveiligingspatches eenmaal per dag beschikbaar. Microsoft test deze patches en bundelt ze in wekelijkse updates van node-images.

Het SecurityPatch Auto Upgrade-kanaal is minder verstorend omdat het live patchen van het besturingssysteem indien mogelijk gebruikt, waardoor knooppuntonderbreking wordt geminimaliseerd terwijl knooppunten worden beschermd tegen bekende beveiligingsproblemen. Wanneer live patching niet mogelijk is, wordt in plaats daarvan een installatiekopie van een vooraf gepatcht knooppunt geïmplementeerd.

Alleen Linux-knooppunten worden bijgewerkt bij het gebruik van SecurityPatch, en Windows-knooppunten worden automatisch overgeslagen.

Als u bugfixes nodig hebt die met nieuwe node-installatiekopieën (VHD) worden geleverd, of een consistente ervaring met Windows-knooppunten, kies dan in plaats daarvan het NodeImage-kanaal.

Inzicht in updatestrategieën

Beheerders kunnen de volgorde bepalen waarin clusters worden bijgewerkt door herbruikbare updatestrategieën te bouwen met behulp van een reeks updatefasen en groepen. Ze kunnen configureren wanneer goedkeuringen en pauzes moeten plaatsvinden binnen die fasen en groepen. De volledige configuratie kan worden opgeslagen als een updatestrategie die onafhankelijk van updateuitvoeringen of profielen voor automatische upgrades kan worden beheerd, zodat strategieën naar behoefte opnieuw kunnen worden gebruikt.

Clusters groeperen met lidlabels (preview)

Lidlabels kunnen worden gebruikt om clusters te groeperen en uw updatevolgorde te configureren met Kubernetes-labelkiezers. Op deze manier kunt u meerdere labels toewijzen aan lidclusters en deze gebruiken voor verschillende strategieën in plaats van te worden beperkt tot één updategroep per cluster. U kunt clusters in uw strategie groeperen met hun lidlabels door deze memberSelector op twee niveaus te configureren voor uw strategie:

• Faseniveau: Hiermee selecteert u clusters voor de hele fase. Wanneer er geen groepen zijn gedefinieerd, vormen alle overeenkomende clusters één impliciete groep. Wanneer groepen ook worden gedefinieerd, fungeert de fase-niveau selector als een prefilter voordat de overeenkomst op groepsniveau wordt toegepast.
• Groepeerniveau: Selecteert clusters voor een specifieke groep binnen een fase, waardoor parallelle subsets met verschillende gelijktijdigheidslimieten worden ingeschakeld.

memberSelector maakt gebruik van een labelkiezer op basis van tekenreeksen die wordt geparseerd met behulp van de standaard-Kubernetes-labelkiezersyntaxis. Ondersteunde operators zijn: =, ==, !=, in, notin, , , existsen !exists.

Zie memberSelector voor instructies over het toewijzen van lidlabels en het gebruik ervan in een strategie.

Maximale gelijktijdigheid (voorvertoning)

Maximum concurrency is een optionele instelling voor uw updatestrategie waarmee wordt bepaald hoeveel clusters gelijktijdig kunnen worden bijgewerkt. U kunt Maximum concurrency op twee niveaus instellen.

• Faseniveau: Definieert het maximum aantal clusters dat tegelijkertijd kan worden bijgewerkt voor alle groepen in een fase. Fungeert als een globaal plafond voor het podium.
• Groepeerniveau: Definieert het maximum aantal clusters dat gelijktijdig kan worden bijgewerkt binnen een specifieke groep.

Maximale gelijktijdigheid accepteert twee waardeformulieren:

• Vast geheel getal: beperkt bijvoorbeeld "3" gelijktijdigheid tot precies drie clusters.
• Percentage: begrenst bijvoorbeeld "25%" gelijktijdigheid tot een percentage clusters. Voor instellingen op faseniveau wordt het percentage berekend op basis van alle clusters in de fase. Voor instellingen op groepsniveau wordt het percentage berekend op basis van de clusters in die groep. Percentages worden tijdens runtime berekend, naar beneden afgerond en afgedwongen met een minimaal opgeloste waarde van 1.

Suggesties voor gelijktijdigheidsbeheer

Als u wilt upgraden met veiligheid (minder snelheid, maar minder waarschijnlijk eindigt op meerdere verbroken clusters): stel maximale gelijktijdigheid in op een kleinere waarde. Als u wilt upgraden met snelheid (meer snelheid, maar waarschijnlijker eindigt op meerdere verbroken clusters): stel maximale gelijktijdigheid in op een grotere waarde.

De interactie tussen fase- en groepslimieten

De maximale gelijktijdigheid op faseniveau fungeert altijd als het totale plafond. Zelfs als afzonderlijke groepen hogere gelijktijdigheid toestaan, heeft de faselimiet voorrang. Gelijktijdigheid op groepsniveau kan lager zijn dan geconfigureerd vanwege de limiet op faseniveau, groepsgrootte of lidspecifieke voorwaarden.

Voorbeeld 1: Vaste limieten

Resultaat: Maximaal vier clusters in totaal, met een maximum van twee per groep.

Voorbeeld 2: Faselimiet dempt groepen

Resultaat: Kunnen slechts twee clusters totaal tegelijk upgraden doordat de faselimiet prioriteit heeft.

Voorbeeld 3: Implementatie op basis van percentage

Een fase heeft 20 clusters in twee groepen: Groep A (acht clusters) en Groep B (12 clusters).

Resultaat: Maximaal vijf gelijktijdige upgrades, verdeeld over groepen op basis van hun afzonderlijke limieten.

Maximaal toegestane fouten (preview)

Maximum allowed failures is een optionele updatestrategieinstelling waarmee wordt bepaald hoe Fleet Manager reageert op fouten tijdens updates voor meerdere clusters.

Updates volgen standaard een fail-fast model: één clusterfout stopt verdere updates. Wanneer u configureert maximum allowed failures, wordt de updateuitvoering fouttolerant en worden updates voortgezet in clusters totdat de opgegeven drempelwaarde voor fouten is bereikt.

Deze instelling biedt een weloverwogen balans tussen het vroegtijdig opsporen van fouten en het behouden van vaart in de uitrol. Stel maximum allowed failures in op twee niveaus:

• Faseniveau: Definieert het maximum aantal mislukte ledenupgrades dat voor alle groepen in een fase wordt getolereerd voordat de fase is gemarkeerd als mislukt.
• Groepeerniveau: Definieert het maximum aantal mislukte ledenupgrades dat binnen een specifieke groep wordt getolereerd voordat de groep wordt gemarkeerd als mislukt.

Maximum allowed failures accepteert twee waardeformulieren:

• Vast geheel getal: staat bijvoorbeeld "3" maximaal drie clusterfouten toe voordat de groep of fase is gemarkeerd als mislukt.
• Percentage: "25%" staat bijvoorbeeld uitval toe tot maximaal 25% van de lidclusters. Voor instellingen op faseniveau wordt het percentage berekend op basis van alle clusters in de fase. Voor instellingen op groepsniveau wordt het percentage berekend op basis van de clusters in die groep. Percentages worden berekend wanneer de updaterun wordt gemaakt, waarbij naar boven wordt afgerond; bijvoorbeeld 25% van 5 clusters komt uit op 2.

Fleet Manager beoordeelt maxAllowedFailures alleen op basis van het aantal mislukte updates van leden. Het evalueert geen slagingspercentage en vereist geen minimumaantal geslaagde leden. Wanneer deze instelling aanwezig is, Completed betekent dit dat de geconfigureerde drempelwaarde voor fouten niet is overschreden op het moment dat Fleet Manager de planningsbeslissingen heeft genomen. Completed betekent niet dat de implementatie in orde of geslaagd is.

Voorbeeld: Voltooid met 0% succes

Stel dat een groep vier leden heeft en group.maxAllowedFailures is ingesteld op "4". Als alle vier de updates van leden mislukken, kan de groep nog steeds worden gemarkeerd Completed. Dit resultaat is verwacht en opzettelijk, geen fout, omdat vier fouten gelijk zijn aan de geconfigureerde tolerantie en daarom niet de drempelwaarde overschrijdt. Met andere woorden, een groep kan Completed zijn, zelfs wanneer 100% van de leden heeft gefaald.

Gebruik een dergelijke drempelwaarde alleen wanneer dat gedrag overeenkomt met de verwachtingen van uw implementatie.

Kies zorgvuldig drempelwaarden

• Absolute waarden zijn gemakkelijk te begrijpen, maar ze kunnen contraintieve resultaten produceren in kleine groepen. Als u bijvoorbeeld "2" mislukkingen toestaat in een groep met twee leden, betekent dit dat de groep Completed kan voltooien, zelfs als geen van beide leden is geslaagd.
• Percentagewaarden worden beter geschaald in verschillende groepsgrootten, zodat ze voor de meeste gebruikers worden aanbevolen.
• Vermijd om maxAllowedFailures in te stellen op hetzelfde aantal als het totale aantal members, tenzij het uw bedoeling is dat het systeem in feite nooit faalt door uitval van members. Als dat gedrag opzettelijk is, 100% wordt meestal duidelijker geschaald dan een vast getal.
• Wees extra voorzichtig met kleine groepen, waarbij één fout een groot percentage van de implementatie kan vertegenwoordigen.
• Evalueer de drempelwaarde opnieuw naarmate uw vloot groeit. Een waarde die veilig is voor vijf clusters, is mogelijk te strikt of te permissief voor 500 clusters.

Meer informatie over FailureCount

De FailureCount velden rapporteren metrische gegevens. Ze tellen mislukte updates van leden. Ze zijn geen verhoudingen of percentages en zijn niet hetzelfde als de geconfigureerde afdwingingsdrempel.

• UpdateRun.FailureCount: Totaal aantal mislukte updates van leden in alle fasen en alle groepen tijdens de uitvoering.
• Stage.FailureCount: Totaal aantal mislukte lidupdates voor alle groepen in die fase.
• Group.FailureCount: Totaal aantal mislukte lidupdates binnen die groep.

Controleer deze aantallen altijd samen met statussen, voorwaarden en foutberichten op lidniveau voordat u besluit of het implementatieresultaat acceptabel is.

Waarom FailureCount maxAllowedFailures kan overschrijden

maxAllowedFailures stuurt de beslissing van Fleet Manager om al dan niet door te gaan met het plannen van nieuw werk. Het is geen harde bovengrens voor het uiteindelijke gerapporteerde aantal fouten.

Als u parallelle updates van leden toestaat met maxConcurrency, kunnen updates voor meerdere leden vrijwel tegelijkertijd mislukken voordat Fleet Manager constateert dat de drempelwaarde is overschreden en stopt met het plannen van meer werk. Daarom is het mogelijk en te verwachten dat FailureCount groter is dan de geconfigureerde waarde maxAllowedFailures.

Hoe limieten voor fase- en groepsstoringen op elkaar inwerken

Op groepsniveau en faseniveau worden maxAllowedFailures onafhankelijk geëvalueerd:

• Elke groep houdt het eigen aantal fouten bij op basis van een eigen drempelwaarde.
• Dezelfde groepsfouten worden ook samengeteld in de fase.FailureCount
• Als een van beide drempelwaarden wordt overschreden, stopt Fleet Manager met het plannen van nieuw werk voor dat segment.
• Al gestarte ledenupdates kunnen nog worden voltooid, waardoor de uiteindelijke gerapporteerde FailureCount nog kan toenemen nadat het besluit om te stoppen is genomen.

Het faseniveau maxAllowedFailures fungeert als het algemene plafond voor fouttolerantie in een fase. Zelfs als afzonderlijke groepen hogere foutenaantallen toestaan, heeft de faselimiet voorrang. Als het aantal mislukte pogingen van een groep de eigen maxAllowedFailureswaarde overschrijdt, wordt die groep gemarkeerd als mislukt, ongeacht de instelling op faseniveau.

Voorbeeld 1: Vaste foutlimieten

Resultaat: Groep A tolereert maximaal twee fouten en Groep B tolereert maximaal drie. Als het totaal aantal fouten in de fase groter is dan vijf, mislukt de fase.

Voorbeeld 2: Tolerantie op basis van percentage

Een fase heeft 19 clusters in twee groepen: Groep A met 7 clusters en groep B met 12 clusters.

Aanbevolen en niet-aanbevolen toepassingen

Gebruik hogere drempelwaarden of drempelwaarden op basis van percentages wanneer u grote vloten upgradet, u rekening houdt met enkele tijdelijke fouten, of de voortgang van de uitrol belangrijker is dan strikt fail-fast-gedrag.

Gebruik 0 of zeer kleine waarden voor veiligheidskritieke implementaties, nauw gecontroleerde productiefasen of situaties waarin u na de eerste storing moet stoppen en inspecteren.

Volgende stappen

• Handleiding: Meerdere clusters bijwerken met update-uitvoeringen van Azure Kubernetes Fleet Manager
• Hoe-to: Meerdere clusters automatisch upgraden met Azure Kubernetes Fleet Manager.
• Hoe-to: Bewaak updateuitvoeringen voor Azure Kubernetes Fleet Manager.
• Veelgestelde vragen over updates voor meerdere clusters.