Sicheres Aktualisieren von Kubernetes und Knotenimages über mehrere Cluster

Gilt für: ✔️ Flottenmanager ✔️ Flottenmanager mit Hubcluster

Plattformadministratoren, die eine große Anzahl von Clustern verwalten, haben häufig Probleme beim Staging von Updates für mehrere Cluster (z. B. upgraden von Knotenbetriebssystemimages oder Kubernetes-Versionen) auf sichere und vorhersehbare Weise. Um diese Herausforderung zu bewältigen, können Sie Azure Kubernetes Fleet Manager Updates über mehrere Cluster hinweg mithilfe von Updateläufen koordinieren.

Aktualisierungsläufe bestehen aus Phasen, Gruppen und Strategien. Sie können Updateausführungen für einmalige Updates manuell oder mithilfe von Auto-Upgrade-Profilen für fortlaufende regelmäßige Updates automatisch ausführen. Alle Update-Ausführungen, sowohl manuelle als auch automatisierte, halten die Wartungsfenster des Clusters ein.

Grundlegendes zu Updateausführungen

Eine Aktualisierungsausführung stellt ein Update dar, das auf eine Auflistung von AKS-Clustern angewendet wird. Es besteht aus dem Updateziel und der Sequenz. Das Updateziel beschreibt die gewünschten Updates. Beispielsweise ein Upgrade auf eine bestimmte Kubernetes-Version oder das Anwenden eines konsistenten Knotenimages auf alle Cluster.

Um optimale Ergebnisse bei der Verwendung von Updateausführungen zu erzielen, ist es wichtig, die folgenden Konzepte zu verstehen.

• Updatestrategie: Beschreibt eine wiederverwendbare Updatesequenz, die aus Phasen und Gruppen von Clustern besteht. Ein Cluster wird je nach den Updategruppen oder Mitgliederbezeichnungen, die ihm zugewiesen sind, in einer Gruppe in einer Phase angezeigt. Weitere Informationen finden Sie unter Grundlegendes zu Updatestrategien.

  • Updatephase: Eine Updatestrategie ist in Updatephasen unterteilt, die sequenziell angewendet werden. Beispielsweise befinden sich Testumgebungscluster in der ersten Updatephase, während Produktionsumgebungscluster in eine zweite Updatephase wechseln. Eine Aktualisierungsphase enthält eine oder mehrere Updategruppen. Sie können zusätzliche Steuerelemente wie maximale Parallelität, Wartezeiten und Genehmigungsgates verwenden, um die Ausführung der Updatephase besser zu kontrollieren.

  • Updategruppe: Jede Updatephase enthält eine oder mehrere Updategruppen, die Cluster auswählen, die aktualisiert werden sollen. Weisen Sie Mitgliedercluster Aktualisierungsgruppen zu, indem Sie entweder die Eigenschaft „Aktualisierungsgruppe“ des Clusters verwenden oder die derzeit in der Vorschau verfügbare, auf Labels basierende Zuordnung mithilfe von Mitglieder-Labels nutzen. Update-Gruppen in einer Update-Phase werden parallel aktualisiert.

  Hinweis

  Die maximale Anzahl von Updategruppen in jeder Updatephase beträgt 50.

  • Weitere Ablaufsteuerungen: Es stehen weitere Steuerungsmöglichkeiten zur Verfügung, um mehr Flexibilität dabei zu bieten, wie schnell eine Cluster-Flotte aktualisiert werden kann:

    • Maximale Parallelität (Vorschau):Verwenden Sie die Konfiguration für maximale Parallelität , um zu ändern, wie viele Cluster parallel aktualisiert werden. Sie können dieses Verhalten sowohl auf Stufe- als auch auf Gruppenebene konfigurieren.

    • Maximal zulässige Anzahl von Fehlern (Vorschau): Verwenden Sie die Konfiguration Maximal zulässige Anzahl von Fehlern, um zu steuern, wie viele Fehler bei Upgrades von Memberclustern toleriert werden, bevor der Updatevorgang beendet wird. Sie können dieses Verhalten sowohl auf Stufe- als auch auf Gruppenebene konfigurieren.

    • Gates: Pausieren Sie den Updatevorgang, bis deren Bedingung erfüllt ist.

      • Genehmigungsgates (Vorschau): Können vor oder nach jeder Phase oder Gruppe konfiguriert werden. Genehmigungen unterbrechen die Ausführung des Updates, sodass Sie oder Automatisierungen, die Sie eingerichtet haben, überprüfen können, ob der Vorgang fortgesetzt werden kann. Nachdem Sie oder Ihre Automatisierung die Genehmigung erteilt haben, wird die Updateausführung fortgesetzt.

      • Geplante Startgates (Vorschau): Können vor jeder Phase oder Gruppe konfiguriert werden. Geplante Startgates halten die Updateausführung bis zu einem bestimmten Tag und einer bestimmten Uhrzeit an. Das Gate wird automatisch abgeschlossen, wenn die geplante Zeit erreicht wird, oder Sie können es manuell abschließen, um jederzeit fortzufahren.

• Profil für automatisches Upgrade: Automatisches Erstellen und Starten eines Updates, wenn neue Kubernetes- oder Knotenimageversionen von AKS zur Verfügung gestellt werden. Weitere Informationen finden Sie unter "Grundlegendes zu Profilen für automatische Upgrades".

Optionen für die Updateausführung

Updateausführungen können drei Arten von Upgrades anwenden:

• Aktualisieren Sie Kubernetes-Versionen für die Steuerebene und die Knoten. Dieses Upgrade umfasst die Aktualisierung der Node-Images.
• Aktualisieren von Kubernetes-Versionen nur für die Steuerungsebene der Cluster.
• Aktualisieren Sie nur die Knotenimages.

Sie können die Kubernetes-Zielversion angeben, auf die ein Upgrade durchgeführt werden soll, aber Sie können die Zielknotenimageversionen nicht auswählen. Das System wählt automatisch die Zielknotenbildversionen basierend auf Ihren Einstellungen aus:

• Neuestes: Verwenden Sie die neuesten Knotenimages, die im Azure Bereich jedes Clusters verfügbar sind, wenn das Upgrade dieses Clusters gestartet wird. Daher können unterschiedliche Imageversionen in der gesamten Flotte verwendet werden, je nachdem, in welcher Azure region sich ein Cluster befindet und wann das Upgrade tatsächlich gestartet wird.
• Konsistent: Wenn die Updateausführung gestartet wird, wählen Sie Bildversionen aus, die derzeit in allen Azure Regionen verfügbar sind, in denen sich die Cluster in dieser Ausführung befinden. Daher werden konsistente Bildversionen in allen Clustern verwendet.

Wählen Sie "Neueste " aus, um aktuellere Imageversionen zu verwenden und Sicherheitsrisiken zu minimieren. Wählen Sie "Konsistent " aus, um die Zuverlässigkeit zu verbessern, indem Sie diese Bilder in früheren Phasen verwenden und überprüfen, bevor Sie sie in späteren Clustern verwenden.

Run-Status aktualisieren

Um den Lebenszyklus einer Aktualisierungsausführung zu verstehen, müssen Sie jeden Status, die Aktionen, die Sie ausführen können, und die Berechnung des Status kennen.

Ausstehender Status

• Aktualisierungslauf: wenn sich die aktuelle Stufe im Status Pending befindet.
• Updatephase: wenn sich alle Updategruppen in dieser Phase im Status Pending befinden oder nicht gestartet wurden oder wenn sie über ein Pending Gate verfügt.
• Update-Gruppe: wenn sich alle Cluster in der Gruppe im Zustand Pending befinden oder nicht gestartet sind oder wenn die Gruppe über ein Pending-Gate verfügt. Wenn ein Cluster in Pending wechselt, versucht der Updatevorgang, den nächsten Cluster in der Gruppe zu aktualisieren. Wenn alle Mitglieder sind Pending, wechselt die Gruppe zu Pending. Die Aktualisierungsausführung wartet, bis alle Gruppen in einer Phase abgeschlossen sind, bevor sie mit der nächsten Phase fortfährt.
• Membercluster: Aus einem der folgenden Gründe, die Sie im Nachrichtenfeld anzeigen können.
  • Wartungsfenster ist nicht geöffnet. Meldung gibt die nächste Öffnungszeit an.
  • Die Zielversion von Kubernetes oder des Knotenimages ist in der Azure-Region des Clusters noch nicht verfügbar. Die Meldung enthält einen Link zum AKS-Release-Tracker, um den Releasestatus zu überprüfen.

Übersprungener Status

• Update-Lauf: Das System hat festgestellt, dass alle Phasen Skipped waren.
• Updatephase: Ein Benutzer hat die Phase oder alle Gruppen in der Phase als Skippedmarkiert.
• Gruppe aktualisieren: Ein Benutzer hat die Gruppe oder alle Cluster in der Gruppe als Skippedgekennzeichnet.
• Membercluster: Aus einem der folgenden Gründe, die Sie im Nachrichtenfeld anzeigen können.
  • Der Benutzer hat den Cluster, die Gruppe oder die Phase explizit übersprungen.
  • Das Cluster ist bereits auf der Kubernetes-Zielversion (wenn der Updateausführungsmodus Full oder ControlPlaneOnly ist), und alle Knotenpools verwenden bereits die Zielversion des Knoten-Images.
  • Wenn ein konsistentes Knotenimage ausgewählt ist und es nicht möglich ist, die Zielimageversion für einen der Knotenpools zu finden. Diese Situation kann auftreten, wenn ein neuer Knotenpool mit einer neuen VM-SKU hinzugefügt wird, nachdem eine Updateausführung gestartet wurde.

Fehlerstatus

Die fehlgeschlagenen Statuskaskaden von Clustern werden wie dargestellt angezeigt. Eine Zusammenfassungsfehlermeldung zeigt die Ursache des fehlgeschlagenen Clusterupgrades an.

• Updateausführung: Mindestens ein Cluster in der aktuellen Gruppe ist fehlgeschlagen.
• Aktualisierungsphase: Mindestens ein Cluster in einer Gruppe in der Phase ist fehlgeschlagen.
• Gruppe aktualisieren: Mindestens ein Cluster in der Gruppe ist fehlgeschlagen.
• Membercluster: Fehler beim Upgrade, und der Clusterstatus wird als Failedfestgelegt.

Wenn Sie maximal zulässige Fehler konfigurieren, wirkt sich der Fehlerschwellenwert auf den Status der Updategruppe, der Updatephase und der Updateausführung aus. Dies wirkt sich nicht auf den Status eines einzelnen Mitgliedsclusters aus. Wenn das Upgrade eines Memberclusters fehlschlägt, wird sein Status weiterhin auf Failed gesetzt.

• Wenn die Fehleranzahl für die Gruppe oder Phase den konfigurierten maxAllowedFailures Schwellenwert überschreitet, wird die Gruppe oder Stufe als Failed Zusammenfassungsfehlermeldung markiert, und die Aktualisierungsausführung beendet den Fortschritt. Wenn kein maxAllowedFailures konfiguriert ist (oder wenn es auf 0 gesetzt ist), stoppt ein einzelner Fehler den gesamten Durchlauf.
• Wenn die Anzahl der Fehler unterhalb des Schwellenwerts maxAllowedFailures liegt, setzt der Aktualisierungslauf das Upgrade der nachfolgenden Mitglieder fort. Weitere Informationen finden Sie unter "Maximal zulässige Fehler".

Abgeschlossener Status

Ein Completed Status bedeutet, dass die Aktualisierungsausführung einen Terminallebenszyklusstatus erreicht hat. Wenn Sie maximal zulässige Fehler verwenden, bedeutet dies, dass der konfigurierte Fehlerschwellenwert nicht überschritten wurde, wenn Flottenmanager entschieden hat, Completed ob die Planung der Arbeit fortgesetzt werden soll. Es garantiert keine minimale Erfolgsquote oder gesunde Ergebnisse. Überprüfen Sie immer FailureCount, Mitgliedstaaten und Fehlermeldungen.

Geplante Wartungsfenster

Updateausführungen berücksichtigen geplante Wartungsfenster, die Sie auf AKS-Clusterebene festgelegt haben.

AKS-Cluster unterstützen zwei unterschiedliche Wartungsfenster – eine für Kubernetes -Upgrades (Steuerebene) und eine für Knotenimageupgrades. Wartungsfenster definieren Zeiträume, in denen Updates auf einen Cluster angewendet werden können, aber kein Updatetrigger sind.

Der Fleet Manager-Update respektiert die AKS-Wartungsfenster wie folgt:

Die Aktualisierungsausführung priorisiert das Upgrade von Clustern basierend auf geplanter Wartung in der folgenden Reihenfolge:

1. Cluster mit geöffneten laufenden Wartungsfenstern.
2. Cluster mit Wartungsfenstern, die in den nächsten vier Stunden geöffnet werden.
3. Cluster ohne Wartungsfenster.
4. Cluster mit einem geschlossenen Wartungsfenster.

Übersicht über Profile für automatische Upgrades

Verwenden Sie Autoupgradeprofile, um Updateausführungen automatisch auszulösen, wenn neue Kubernetes- oder Knotenimageversionen für AKS verfügbar sind.

In einem Automatischen Upgradeprofil konfigurieren Sie Folgendes:

• Ein Kanal (Rapid, Stable, TargetKubernetesVersion, NodeImage, SecurityPatch (Vorschau)), der den Typ des Updates bestimmt, der auf die Cluster angewendet wird.
• eine UpdateStrategy , die die Sequenz konfiguriert, in der die Cluster aktualisiert werden. Wenn Sie keine Strategie angeben, werden Cluster nacheinander aktualisiert.
• nodeImageSelectionType (Latest, Consistent), um anzugeben, wie das Knotenimage beim Upgrade der Kubernetes-Version ausgewählt wird.

Rapid-Kanal

Der Rapid-Kanal ist immer die neueste AKS-unterstützte Kubernetes-Nebenversion. Cluster-Nebenversionen werden automatisch geändert, wenn AKS eine neue Kubernetes-Nebenversion veröffentlicht.

Beispiele:

• Die neueste unterstützte Nebenversion ist 1.30. Jede Patchversion im 1.30-Minor-Versionsbereich wird für Updates des Rapid-Kanals in Betracht gezogen.
• Eine neue Kubernetes-Nebenversion von 1.31 wird veröffentlicht. 1.30 wechselt zum Stable-Kanal. Alle Cluster, die zuvor Updates von 1.30 erhalten, werden auf den neuesten Patch für 1.31 aktualisiert, der jetzt der Rapid-Kanal ist.

Stabiler Kanal

Der Stable-Kanal ist immer die Nebenversion vor dem Rapid-Kanal . Manchmal beziehen sich die Benutzer auf Stable als "N-1", wobei "N" die neueste (Rapid-Kanal) unterstützte Kubernetes-Nebenversion ist. Cluster-Nebenversionen werden automatisch geändert, wenn AKS eine neue Kubernetes-Nebenversion veröffentlicht.

Beispiele:

• Die neueste unterstützte Kubernetes-Nebenversion ist 1.30. Alle Patchversionen im Bereich der Nebenversion 1.29 werden für Updates im Kanal „Stable“ berücksichtigt.
• Eine neue Kubernetes-Nebenversion von 1.31 wird veröffentlicht. Der Stable-Kanal zieht alle Patchversionen im 1.30-Minor-Versionsbereich für Updates in Betracht. Alle Cluster, die zuvor Updates von 1.29 erhalten, werden auf den neuesten Patch für 1.30 aktualisiert.

TargetKubernetesVersion-Kanal

Mit dem TargetKubernetesVersion-Kanal können Sie steuern, wann Sie Ihre Cluster in die nächste Kubernetes-Nebenversion verschieben. Sie müssen die Kubernetes-Zielversion im Format "{major}.{minor}" angeben (z. B. "1.33"). Fleet Manager aktualisiert Cluster automatisch auf die neueste Patch-Version der angegebenen Kubernetes-Version, wenn der Patch verfügbar ist. Der Flottenmanager aktualisiert erst dann auf die nächste Nebenversion, wenn die Kubernetes-Zielversion des Auto-Upgrade-Profils aktualisiert wird.

Beispiele:

• Sie erstellen ein Profil für automatische Upgrades mithilfe des TargetKubernetesVersion-Kanals und geben eine Kubernetes-Zielversion von "1.30" an. Eine neue Patchversion 1.30.5 wird veröffentlicht. Ein Update-Lauf wird automatisch mit der Zielversion 1.30.5 erstellt.
• Sie erstellen ein Profil für das automatische Upgrade mithilfe des TargetKubernetesVersion-Kanals, geben eine Kubernetes-Zielversion von "1.29" an, und aktivieren LongTermSupport (LTS) im Profil für automatische Upgrades. Die neueste von der Community unterstützte Nebenversion ist "1.33". Eine neue Patchversion 1.29.5 wird veröffentlicht. Ein Update-Lauf wird automatisch für die Zielversion 1.29.5 erstellt. Wenn die generierte Updateausführung Cluster ohne LTS enthält, schlägt sie fehl.

Verhalten beim Überspringen von Nebenversionen

Bei der automatischen Aktualisierung werden Cluster nicht zwischen kleineren Kubernetes-Versionen verschoben, wenn mehrere kleinere Kubernetes-Versionsunterschiede auftreten (z. B. 1.28 bis 1.30). Wenn Administratoren über eine Vielzahl von Kubernetes-Versionen verfügen, verwenden Sie zuerst eine oder mehrere Updateausführungen , um Cluster in eine Reihe konsistent versionsständiger Versionen zu integrieren, sodass konfigurierte Stable oder Rapid Kanalupdates sicherstellen, dass die Konsistenz in Zukunft beibehalten wird.

NodeImage-Kanal

Mitgliedsclusterknoten werden wöchentlich mit einer neu gepatchten VHD aktualisiert, die Sicherheitsupdates und Fehlerbehebungen enthält. Das Update auf die neue VHD führt zu Unterbrechungen und wird gemäß den Einstellungen für Wartungsfenster und Anstieg durchgeführt. Bei der Auswahl dieser Option fallen keine zusätzlichen VHD-Kosten an. Bei Upgrades von Knotenimages werden veraltete Patchversionen unterstützt, solange die Nebenversion von Kubernetes weiterhin unterstützt wird. Die Knotenimages werden mit AKS getestet und sind vollständig verwaltet. Sie werden mit sicheren Bereitstellungsmethoden angewendet.

Knoten auf verschiedenen Betriebssystemen werden entsprechend den Knotenimageversionen aktualisiert, die an diese Betriebssysteme ausgerichtet sind.

Beispiel:

• Ein Cluster verfügt über Knoten mit einem NodeImage von AKSWindows-2022-containerd der Version 20348.2582.240716. Eine neue NodeImage-Version 20348.2582.240916 wird veröffentlicht, und die Clusterknoten werden automatisch auf Version 20348.2582.240916 aktualisiert.

Grundlegendes zu Knotenimageupgrades und Momentaufnahmen

Wenn ein Cluster über Agentpools verfügt, die aus einer Momentaufnahme eines Knotenpools erstellt wurden, hängt das Ergebnis des Upgrades des Knotenimages von der Auswahl des Knotenimages im Fleet Manager Update Run ab.

SecurityPatch-Kanal (Vorschau)

Aktualisieren Sie die Knoten des Mitglieder-Clusters Linux wöchentlich mit ausschließlich Sicherheitskorrekturen. Kanonische Ubuntu und Azure Linux stellen Betriebssystemsicherheitspatches einmal täglich zur Verfügung. Microsoft testet diese Patches und bündelt sie in wöchentliche Updates für Knotenimages.

Der SecurityPatch-Kanal für das automatische Upgrade ist weniger störend, da es nach Möglichkeit das Livepatching des Betriebssystems verwendet, wodurch Knotenunterbrechungen minimiert werden, während Knoten vor bekannten Sicherheitsrisiken geschützt bleiben. Wenn Livepatching nicht möglich ist, wird stattdessen ein vorab gepatchtes Knotenimage bereitgestellt.

Nur linuxbasierte Knoten werden bei Verwendung SecurityPatchaktualisiert, und Windows-basierten Knoten werden automatisch übersprungen.

Wenn Sie Fehlerbehebungen benötigen, die mit neuen Knotenimages (VHD) bereitgestellt werden, oder ein einheitliches Verhalten mit Windows-Knoten wünschen, wählen Sie stattdessen den Kanal NodeImage.

Update-Strategien verstehen

Administratoren können die Reihenfolge steuern, in der Cluster aktualisiert werden, indem sie wiederverwendbare Updatestrategien mithilfe einer Reihe von Updatephasen und Gruppen erstellen. Sie können konfigurieren, wann Genehmigungen und Pausen innerhalb dieser Phasen und Gruppen auftreten sollen. Die gesamte Konfiguration kann als Updatestrategie gespeichert werden, die unabhängig von Updateausführungen oder Automatisch-Upgradeprofilen verwaltet werden kann, sodass Strategien nach Bedarf wiederverwendet werden können.

Gruppieren von Clustern mithilfe von Mitgliedsbezeichnungen (Vorschau)

Mitgliederlabels können verwendet werden, um Cluster zu gruppieren und Ihre Updatesequenz mit Kubernetes-Label-Selektoren zu konfigurieren. Auf diese Weise können Sie Mitgliedsclustern mehrere Bezeichnungen zuweisen und sie für verschiedene Strategien verwenden, anstatt auf nur eine einzige Updategruppe pro Cluster beschränkt zu sein. Sie können Cluster in Ihrer Strategie mit ihren Mitgliedsbezeichnungen gruppieren, indem Sie Ihre Strategie auf zwei Ebenen mit memberSelector konfigurieren.

• Stufenebene: Wählt Cluster für die gesamte Phase aus. Wenn keine Gruppen definiert sind, bilden alle übereinstimmenden Cluster eine einzelne implizite Gruppe. Wenn Gruppen auch definiert sind, fungiert der stufenweise Selektor als Vorabfilter, bevor der Abgleich auf Gruppenebene angewendet wird.
• Gruppenebene: Wählt Cluster für eine bestimmte Gruppe innerhalb einer Phase aus, wodurch parallele Teilmengen mit unterschiedlichen Parallelitätsgrenzwerten aktiviert werden.

memberSelector verwendet einen zeichenfolgenbasierten Bezeichnungsmarkierer, der mithilfe der standardmäßigen Kubernetes-Bezeichnungsmarkierersyntax analysiert wird. Unterstützte Operatoren sind: =, , ==, !=, in, notin, und exists!exists.

Anweisungen zum Zuweisen von Mitgliedsetiketten und zur Verwendung von memberSelector in einer Strategie finden Sie unter Erstellen einer Update-Strategie mit Hilfe von Mitgliedsauswahlen.

Maximale Gleichzeitigkeit (Vorschau)

Maximum concurrency ist eine optionale Einstellung für Ihre Updatestrategie, die steuert, wie viele Cluster gleichzeitig aktualisiert werden können. Sie können Maximum concurrency auf zwei Ebenen festlegen:

• Stufenebene: Definiert die maximale Anzahl von Clustern, die gleichzeitig für alle Gruppen in einer Phase aktualisiert werden können. Dient als globale Obergrenze für die Bühne.
• Gruppenebene: Definiert die maximale Anzahl von Clustern, die gleichzeitig innerhalb einer bestimmten Gruppe aktualisiert werden können.

Maximum Concurrency unterstützt zwei Wertformate:

• Feste ganze Zahl: Beschränkt beispielsweise "3" die Parallelität auf genau drei Cluster.
• Prozentsatz: Schränkt beispielsweise "25%" die Parallelität auf einen Prozentsatz von Clustern ein. Bei Einstellungen auf Stufenebene wird der Prozentsatz aus allen Clustern in der Phase berechnet. Für Einstellungen auf Gruppenebene wird der Prozentsatz aus den Clustern in dieser Gruppe berechnet. Die Prozentsätze werden zur Laufzeit berechnet, abgerundet und mit einem Mindestwert von 1 behoben.

Nebenläufigkeitskontrollvorschläge

Wenn Sie ein Upgrade mit Sicherheit durchführen möchten (weniger Geschwindigkeit, aber weniger wahrscheinlich mit mehreren fehlerhaften Clustern): legen Sie die maximale Parallelität auf einen kleineren Wert fest. Wenn Sie ein Upgrade mit Geschwindigkeit durchführen möchten (mehr Geschwindigkeit, aber wahrscheinlicher mit mehreren fehlerhaften Clustern enden): Legen Sie die maximale Parallelität auf einen größeren Wert fest.

Interaktion von Phasen- und Gruppengrenzwerten

Die maximale Parallelität auf Stage-Ebene gilt immer als Obergrenze. Auch wenn einzelne Gruppen eine höhere Parallelität zulassen, hat das Stufenlimit Vorrang. Die Parallelität auf Gruppenebene kann aufgrund des Limits auf Stage-Ebene, der Gruppengröße oder mitgliedsspezifischer Bedingungen niedriger sein als konfiguriert.

Beispiel 1: Feste Grenzwerte

Ergebnis: Bis zu vier Cluster gesamt, mit maximal zwei pro Gruppe.

Beispiel 2: Stufenlimits drosseln Gruppen

Ergebnis: Nur zwei Cluster haben gleichzeitig ein Gesamtupgrade, da das Stufenlimit Vorrang hat.

Beispiel 3: Prozentsatzbasiertes Rollout

Eine Phase umfasst 20 Cluster in zwei Gruppen: Gruppe A (acht Cluster) und Gruppe B (12 Cluster).

Ergebnis: Bis zu fünf gleichzeitige Upgrades insgesamt, verteilt auf Gruppen nach ihren individuellen Grenzwerten.

Maximal zulässige Fehler (Vorschau)

Maximum allowed failures ist eine optionale Updatestrategieeinstellung, die steuert, wie Fleet Manager auf Fehler während Multiclusterupdates reagiert.

Standardmäßig folgen Updates einem Fail-Fast-Modell – ein einzelner Clusterfehler stoppt alle weiteren Updates. Wenn Sie konfigurieren maximum allowed failures, wird die Updateausführung fehlertolerant, und Updates werden über Cluster hinweg fortgesetzt, bis der angegebene Fehlerschwellenwert erreicht ist.

Diese Einstellung bietet ein bewusstes Gleichgewicht zwischen der Erkennung von frühzeitigen Fehlern und der Aufrechterhaltung der Bereitstellungsdynamik. Legen Sie maximum allowed failures auf zwei Ebenen fest:

• Phasenebene: Definiert die maximale Anzahl von Fehlern bei Mitglieder-Upgrades, die über alle Gruppen in einer Phase hinweg toleriert werden, bevor die Phase als fehlgeschlagen gilt.
• Gruppenebene: Definiert die maximale Anzahl von Fehlschlägen bei Mitglieder-Upgrades, die innerhalb einer bestimmten Gruppe toleriert werden, bevor die Gruppe als fehlgeschlagen gekennzeichnet wird.

Maximum allowed failures akzeptiert zwei Wertformen:

• Feste Ganzzahl: Beispielsweise lässt "3" bis zu drei Fehler bei Member-Clustern zu, bevor die Gruppe oder Phase als fehlerhaft markiert wird.
• Prozentsatz: Zum Beispiel sind "25%" Ausfälle von bis zu 25 % der Mitgliedscluster zulässig. Bei Einstellungen auf Stufenebene wird der Prozentsatz aus allen Clustern in der Phase berechnet. Für Einstellungen auf Gruppenebene wird der Prozentsatz aus den Clustern in dieser Gruppe berechnet. Prozentsätze werden bei der Erstellung der Updateausführung unter Verwendung der Aufrundung aufgelöst. Beispielsweise werden 25 % von 5 Clustern zu 2 aufgelöst.

Fleet Manager bewertet maxAllowedFailures ausschließlich anhand der Anzahl fehlgeschlagener Aktualisierungen von Mitgliedern. Die Erfolgsquote wird nicht ausgewertet, und es ist keine Mindestanzahl erfolgreicher Mitglieder erforderlich. Wenn diese Einstellung vorhanden ist, bedeutet dies, Completed dass der konfigurierte Fehlerschwellenwert zum Zeitpunkt, zu dem Fleet Manager seine Planungsentscheidungen getroffen hat, nicht überschritten wurde. Completed bedeutet nicht, dass der Rollout reibungslos oder erfolgreich war.

Beispiel: Abgeschlossen mit 0% Erfolg

Angenommen, eine Gruppe hat vier Mitglieder und group.maxAllowedFailures ist auf "4" festgelegt. Wenn alle vier Mitgliederaktualisierungen fehlschlagen, kann die Gruppe weiterhin markiert Completedwerden. Dieses Ergebnis wird erwartet und beabsichtigt, kein Fehler, da vier Fehler der konfigurierten Toleranz entsprechen und daher den Schwellenwert nicht überschreiten. Mit anderen Worten, eine Gruppe kann sogar dann sein Completed , wenn 100% ihrer Mitglieder fehlgeschlagen sind.

Verwenden Sie einen solchen Schwellenwert nur, wenn dieses Verhalten Ihren Erwartungen an das Rollout entspricht.

Wählen Sie Schwellenwerte sorgfältig aus.

• Absolute Werte sind leicht zu verstehen, aber sie können kontraintuitive Ergebnisse in kleinen Gruppen erzeugen. Wenn Sie beispielsweise "2" Fehler in einer Gruppe mit zwei Membern zulassen, bedeutet dies, dass die Gruppe Completed beenden kann, selbst wenn kein Member erfolgreich war.
• Prozentwerte lassen sich über verschiedene Gruppengrößen hinweg besser skalieren und werden daher den meisten Nutzern empfohlen.
• Vermeiden Sie es, maxAllowedFailures auf die Gesamtzahl der Member festzulegen, es sei denn, Sie möchten absichtlich das Verhalten „Niemals aufgrund von Member-Fehlern fehlschlagen“ erzielen. Wenn dieses Verhalten beabsichtigt ist, 100% wird in der Regel deutlicher skaliert als eine feste Zahl.
• Achten Sie bei kleinen Gruppen besonders darauf, dass ein einzelner Fehler einen großen Prozentsatz des Rollouts darstellen kann.
• Bewerten Sie den Grenzwert neu, wenn Ihre Flotte wächst. Ein Wert, der für fünf Cluster sicher ist, kann für 500 Cluster zu streng oder zu eingeschränkt sein.

Grundlegendes zu FailureCount

Die FailureCount Felder sind Berichtsmetriken. Sie zählen fehlgeschlagene Aktualisierungen von Mitgliedern. Sie sind keine Verhältnisse oder Prozentsätze, und sie sind nicht identisch mit dem konfigurierten Erzwingungsschwellenwert.

• UpdateRun.FailureCount: Gesamtzahl der fehlgeschlagenen Member-Updates über alle Phasen und alle Gruppen in der Ausführung hinweg.
• Stage.FailureCount: Gesamtzahl fehlgeschlagener Mitgliederaktualisierungen für alle Gruppen innerhalb dieser Phase.
• Group.FailureCount: Gesamtzahl fehlgeschlagener Mitgliederaktualisierungen in dieser Gruppe.

Überprüfen Sie diese Werte immer zusammen mit den Statuswerten, Bedingungen und Fehlermeldungen auf Mitgliedsebene, bevor Sie beurteilen, ob das Rolloutergebnis akzeptabel ist.

Warum FailureCount die maxAllowedFailures überschreiten kann

maxAllowedFailures steuert die Entscheidung des Flottenmanagers, ob die Planung neuer Arbeiten fortgesetzt werden soll. Es handelt sich nicht um eine harte obere Grenze für die endgültige gemeldete Anzahl von Fehlern.

Wenn Sie parallele Member-Updates mithilfe von maxConcurrency zulassen, können mehrere Member fast gleichzeitig fehlschlagen, bevor Fleet Manager feststellt, dass der Schwellenwert überschritten wurde, und die Planung weiterer Aufgaben stoppt. Daher ist es möglich und zu erwarten, dass FailureCount größer als der konfigurierte maxAllowedFailures-Wert ist.

Wie Stufen- und Gruppenausfallgrenzen zusammenspielen

Gruppenebene und Stufenebene maxAllowedFailures werden unabhängig voneinander ausgewertet:

• Jede Gruppe verfolgt ihre eigene Fehleranzahl anhand ihres eigenen Schwellenwerts.
• Dieselben Gruppenfehler werden auch in FailureCount der Phase zusammengefasst.
• Wenn eine der Schwellenwerte überschritten wird, stoppt Fleet Manager die Planung neuer Arbeiten für dieses Segment.
• Bereits gestartete Member-Updates können noch abgeschlossen werden, was den endgültig gemeldeten Wert für FailureCount erhöhen kann, nachdem die Stoppentscheidung getroffen wurde.

Die Stufenebene maxAllowedFailures fungiert als gesamter Obergrenze für Fehlertoleranz in einer Stufe. Auch wenn einzelne Gruppen eine höhere Fehleranzahl zulassen, hat das Stufenlimit Vorrang. Wenn die Fehleranzahl einer Gruppe ihre eigene maxAllowedFailures überschreitet, wird diese Gruppe unabhängig von der Einstellung auf Phasenebene als fehlgeschlagen markiert.

Beispiel 1: Feste Fehlerbeschränkungen

Ergebnis: Gruppe A toleriert bis zu zwei Fehler und Gruppe B toleriert bis zu drei. Wenn die Gesamtfehler in der Phase fünf überschreiten, schlägt die Phase fehl.

Beispiel 2: Prozentbasierte Toleranz

Eine Phase verfügt über 19 Cluster in zwei Gruppen: Gruppe A mit 7 Clustern und Gruppe B mit 12 Clustern.

Empfohlene und nichtcommendierte Verwendungen

Verwenden Sie höhere oder prozentbasierte Schwellenwerte, wenn Sie große Flotten aktualisieren, mit vorübergehenden Fehlern rechnen oder der Fortschritt des Rollouts wichtiger ist als ein striktes Fail-Fast-Verhalten.

Verwenden Sie 0 oder sehr kleine Werte für sicherheitskritische Rollouts, streng kontrollierte Produktionsphasen oder situationen, in denen Sie nach dem ersten Fehler anhalten und prüfen müssen.

Nächste Schritte

• Anleitung: Upgrade mehrerer Cluster mit Azure Kubernetes Fleet Manager-Update-Läufen.
• How-to: Automatisches Upgrade mehrerer Cluster mithilfe von Azure Kubernetes Fleet Manager.
• Anleitung: Überwachen der Update-Durchläufe für den Azure Kubernetes Fleet Manager.
• Häufig gestellte Fragen zu Multi-Cluster-Updates