Aktualisieren der Orchestrierung über mehrere Mitgliedscluster hinweg

Plattformadministratoren, die eine große Anzahl von Clustern verwalten, haben häufig Probleme beim Staging der Updates mehrerer Cluster (z. B. das Aktualisieren von Knotenbetriebssystemimageversionen, das Upgrade von Kubernetes-Versionen) auf sichere und vorhersehbare Weise. Dieses Problem können Sie umgehen, indem Sie Updates mit Azure Kubernetes Fleet Manager (Flotte) in mehreren Clustern mithilfe von Updateausführungen, -phasen, -gruppen und -strategien orchestrieren.

• Updateausführung: Eine Updateausführung stellt ein Update dar, das auf eine Sammlung von AKS-Clustern angewendet wird, bestehend aus dem Updateziel und der Sequenz. Das Updateziel beschreibt die gewünschten Updates (z. B. ein Upgrade auf Kubernetes, Version 1.28.3). Die Aktualisierungssequenz beschreibt die genaue Reihenfolge, um die Aktualisierungen auf mehrere Membercluster anzuwenden, ausgedrückt mithilfe von Phasen und Gruppen. Wenn nicht angegeben, werden alle Membercluster nacheinander aktualisiert. Eine Updateausführung kann beendet und gestartet werden.
• Updatephase: Updateausführungen sind in Phasen unterteilt, die sequenziell angewendet werden. Beispielsweise kann eine erste Updatephase Mitgliedscluster der Testumgebung aktualisieren und eine zweite Updatestufe würde dann später Produktionsumgebung-Membercluster aktualisieren. Es kann eine Wartezeit angegeben werden, um zwischen der Durchführung der nachfolgenden Updatephasen Abstände zu haben.
• Updategruppe: Jede Updatephase enthält eine oder mehrere Updategruppen, die verwendet werden, um die zu aktualisierenden Mitgliedscluster auszuwählen. Updategruppen werden auch verwendet, um die Anwendung von Updates auf Mitgliedscluster zu ordnen. Innerhalb einer Aktualisierungsphase werden Updates parallel auf alle verschiedenen Updategruppen angewendet; innerhalb einer Updategruppe werden Mitgliedercluster sequenziell aktualisiert. Jeder Mitgliedscluster der Flotte kann nur Teil einer Updategruppe sein.
• Updatestrategie: Eine Updatestrategie beschreibt die Updatesequenz mit Phasen und Gruppen. Sie können eine Strategie in Ihren Updateausführungen wiederverwenden, anstatt die Sequenz in jeder Ausführung wiederholt zu definieren.

Derzeit werden im Cluster Upgrades unterstützt. Es gibt drei Typen von Upgrades, aus denen Sie wählen können:

• Aktualisieren Sie Kubernetes-Versionen für die Kubernetes-Steuerungsebene und die Knoten (einschließlich upgraden der Knotenimages).
• Aktualisieren von Kubernetes-Versionen nur für die Steuerungsebenen der Cluster
• Aktualisieren Sie nur die Knotenimages.

Sie können die Kubernetes-Zielversion angeben, auf die ein Upgrade durchgeführt werden soll. Sie können jedoch nicht die genauen Zielknotenimageversionen angeben, da die neuesten verfügbaren Knotenimageversionen je nach Region des Clusters variieren können (überprüfen Sie die Versionsverfolgung, um weitere Informationen zu erhalten). Die Imageversionen des Zielknotens werden basierend auf Ihren Einstellungen automatisch für Sie ausgewählt:

• Latest: Verwenden Sie die neuesten Knotenimages, die in der Region eines Clusters verfügbar sind, wenn das Upgrade des Clusters gestartet wird. Daher können unterschiedliche Imageversionen verwendet werden, je nachdem, in welcher Region sich ein Cluster befindet und wann das Upgrade tatsächlich gestartet wird.
• Consistent: Wenn die Updateausführung gestartet wird, wählt sie die neuesten allgemeinen Imageversionen in den Bereichen der Membercluster in dieser Ausführung aus, sodass die gleichen, konsistenten Imageversionen in allen Clustern verwendet werden.

Sie sollten Latest auswählen, um neuere Imageversionen zu verwenden und Sicherheitsrisiken zu minimieren, und wählen Sie Consistent aus, um die Zuverlässigkeit zu verbessern, indem Sie diese Bilder in Clustern in früheren Phasen verwenden und überprüfen, bevor Sie sie in späteren Clustern verwenden.

Geplante Wartung

Update führt geplante Wartungsfenster aus, die Sie auf der Azure Kubernetes Service (AKS)-Clusterebene festlegen.

Innerhalb eines Update-Laufs (sowohl für Update-Läufe vom Typ Eins nach dem anderen als auch für Stufen) priorisiert der Update-Lauf das Upgrade der Cluster in der folgenden Reihenfolge:

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

Status der Updateausführung

Eine Updateausführung kann in einem der folgenden Zustände auftreten:

• NotStarted: Status des Updates, bevor es gestartet wird.

• Running: Das Upgrade wird für mindestens einen der Cluster in der Updateausführung ausgeführt.

• Ausstehend:

  • Membercluster: Ein Mitgliedscluster kann aus folgenden Gründen in den ausstehenden Zustand versetzt werden und unter dem Nachrichtenfeld angezeigt werden.
    • Wartungsfenster ist nicht geöffnet. Meldung gibt die nächste Öffnungszeit an.
    • Die Ziel-Kubernetes-Version ist in der Region des Mitglieds noch nicht verfügbar. Nachrichtenlinks zum Release-Tracker, sodass Sie den Status der Freigabe über Regionen hinweg überprüfen können.
    • Die Zielknotenbildversion ist in der Region des Mitglieds noch nicht verfügbar. Nachrichtenlinks zum Release-Tracker, sodass Sie den Status der Freigabe über Regionen hinweg überprüfen können.
  • Group: Eine Gruppe befindet sich im Pending Zustand, wenn sich alle Mitglieder in den Gruppen im Pending Status befinden oder noch nicht gestartet. Wenn ein Mitglied zu Pending wechselt, versucht die Updateausführung, das nächste Mitglied in der Gruppe zu aktualisieren. Wenn sich alle Mitglieder im Pending Status befinden, wird die Gruppe in den Pending Status verschoben. Alle Gruppen müssen sich im Terminalzustand befinden, bevor Sie zur nächsten Stufe wechseln. Wenn sich eine Gruppe im Pending Zustand befindet, wartet die Updateausführung, bis sie abgeschlossen ist, bevor sie zur nächsten Phase für die Ausführung wechselt.
  • Stage: Eine Stage ist in Pending, wenn alle Gruppen, die sich in dieser Stage befinden, im Pending Zustand befindet oder nicht gestartet sind.
  • Run: Eine Ausführung befindet sich im Pending Zustand, wenn sich die aktuelle Phase, die ausgeführt werden soll, im Pending Zustand befindet.

• Skipped: Alle Ebenen einer Updateausführung können übersprungen werden, und dies kann entweder vom System erkannt oder vom Benutzer initiiert werden.

  • Member:
    • Sie haben das Upgrade für ein Mitglied oder eines seiner Eltern übersprungen.
    • Der Membercluster befindet sich bereits in der Kubernetes-Zielversion (wenn der Updateausführungsmodus Full oder ControlPlaneOnly ist).
    • Der Membercluster befindet sich bereits in der Kubernetes-Zielversion, und alle Knotenpools befinden sich in der Zielknotenimageversion.
    • Wenn ein konsistentes Knotenimage für eine Upgradeausführung ausgewählt wird, wird das Upgrade für diesen Cluster übersprungen, wenn es nicht möglich ist, die Zielimageversion für einen der Knotenpools zu finden. Eine Beispielsituation hierfür ist, wenn ein neuer Knotenpool mit einer neuen VM-SKU hinzugefügt wird, nachdem eine Updateausführung gestartet wurde.
  • Gruppe:
    • Alle Membercluster wurden vom System als Skipped erkannt.
    • Sie haben Überspringen auf Gruppenebene initiiert.
  • Stage:
    • Alle Gruppen in der Stage wurden vom System als Skipped erkannt.
    • Sie haben Überspringen auf Stage-Ebene initiiert.
  • Run:
    • Alle Stages wurden vom System als Skipped erkannt.

• Stopped: Alle Ebenen einer Updateausführung können beendet werden. Es gibt zwei Möglichkeiten für die Einreise in einen angehaltenen Zustand:

  • Sie beenden den Updatelauf, an dem die Aktualisierungsausführung beendet, um alle Vorgänge zu verfolgen. Wenn ein Vorgang bereits von der Updateausführung initiiert wurde (z. B. wird ein Clusterupgrade ausgeführt), wird dieser Vorgang für diesen einzelnen Cluster nicht abgebrochen.
  • Wenn während der Updateausführung ein Fehler aufgetreten ist (z. B. bei Upgrades auf einem der Cluster fehlgeschlagen), wechselt der gesamte Updatelauf in einen Stoppzustand und wird nicht für nachfolgende Cluster in der Updateausführung versucht.

• Failed: Ein Fehler beim Upgrade eines Clusters führt zu den folgenden Aktionen:

  • Markiert das MemberUpdateStatus als Failed auf dem Membercluster.
  • Markiert alle übergeordneten Elemente (Gruppe -> Stage -> Ausführen) als Failed mit einer Zusammenfassungsfehlermeldung.
  • Beendet die Ausführung des Updates, wenn der Vorgang fortgesetzt wird.

Nächste Schritte

• Orchestrierung von Updates über mehrere Mitgliedscluster.