Aktualisieren Sie Kubernetes- und Knoten-Images über mehrere Cluster hinweg

Artikel
10/20/2024

Plattformadministratoren, die eine große Anzahl von Clustern verwalten, haben oft Probleme, die Updates mehrerer Cluster (z. B. das Upgrade von Knotenbetriebssystemimages oder Kubernetes-Versionen) auf sichere und vorhersehbare Weise durchzuführen. Um diese Herausforderung zu bewältigen, ermöglicht Ihnen Azure Kubernetes Fleet Manager (Fleet) die Orchestrierung von Updates über mehrere Cluster hinweg mithilfe von Updateausführungen.

Updateausführungen bestehen aus Phasen, Gruppen und Strategien und können entweder manuell für einmalige Updates oder automatisch für fortlaufende regelmäßige Updates unter Verwendung von Auto-Upgrade-Profilen angewendet werden. Bei allen Updateausführungen (manuell oder automatisch) werden die Wartungsfenster für Mitgliedercluster berücksichtigt.

Grundlegendes zu Updateausführungen

Die folgende Abbildung veranschaulicht eine Upgradeausführung, die zwei Updatephasen mit jeweils zwei Updategruppen und zwei Mitgliederclustern umfasst. Eine Wartezeit wird zwischen der ersten und der zweiten Phase konfiguriert.

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 Updatesequenz beschreibt die genaue Reihenfolge, um das Update 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 und ermöglicht es Ihnen, eine Updateausführungskonfiguration wiederzuverwenden, anstatt die Sequenz in jeder Ausführung wiederholt zu definieren. Eine Updatestrategie enthält keine gewünschten Kubernetes- oder Knotenimageversionen.

Derzeit sind die unterstützten Updatevorgänge im Membercluster Upgrades. 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 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 nicht die genaue Zielknotenimageversion angeben. Dies liegt daran, dass die neueste verfügbare Knotenimageversion je nach Azure-Region des Clusters variieren kann (überprüfen Sie die AKS-Release-Tracker, 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 Azure-Region eines Clusters verfügbar sind, wenn das Upgrade des Clusters gestartet wird. Daher können unterschiedliche Imageversionen verwendet werden, je nachdem, in welcher Azure-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 Azure-Regionen der Mitgliedcluster 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:

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

Status der Updateausführung

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

NotStarted: Die Updateausführung wurde nicht gestartet.
Running: Das Upgrade wird für mindestens einen der Mitgliedcluster in der Updateausführung ausgeführt.
Pending:
- Mitgliedscluster: Ein Mitgliedscluster kann aus folgenden Gründen im ausstehenden Status sein, der im Nachrichtenfeld angezeigt werden kann.
  - Wartungsfenster ist nicht geöffnet. Meldung gibt die nächste Öffnungszeit an.
  - Die Ziel-Kubernetes-Version ist in der Azure-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 Azure-Region des Mitglieds noch nicht verfügbar. Nachrichtenlinks zum Release-Tracker, sodass Sie den Status der Freigabe über Regionen hinweg überprüfen können.
- Gruppe: Eine Gruppe befindet sich im Pending Zustand, wenn sich alle Mitglieder in der Gruppe 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 alle Mitglieder Pending, wird die Gruppe in den Pending Status verschoben. Wenn sich eine Gruppe im Pending Zustand befindet, wartet die Updateausführung, bis die Gruppe dies abgeschlossen hat, bevor sie zur nächsten Phase für die Ausführung wechselt.
- Stage: Eine Stage ist im Pending-Zustand, 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.
Übersprungen: Alle Ebenen einer Updateausführung können übersprungen werden. Das Überspringen kann vom System oder vom Benutzer initiiert werden.
- Member:
  - Sie haben das Upgrade für ein Mitglied, eine Gruppe oder eine Stage ü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. Dies kann beispielsweise auftreten, 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. Vorgänge werden für nachfolgende Cluster in der Updateausführung nicht versucht.
Ausgefallen: 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.

Hinweis

Sie können ein Update jederzeit erneut ausführen, um Upgrades erneut anzuwenden, die möglicherweise übersprungen oder fehlgeschlagen sind.

Grundlegendes zu Profilen für automatische Upgrades (Vorschau)

Automatische Aktualisierungsprofile werden verwendet, um Updateausführungen automatisch auszulösen, wenn neue Kubernetes- oder Knotenimageversionen für AKS verfügbar gemacht werden.

Wichtig

Previewfunktionen von Azure Kubernetes Fleet Manager sind auf Self-Service-Basis per Aktivierung verfügbar. Vorschauversionen werden „wie besehen“ und „wie verfügbar“ bereitgestellt und sind von den Vereinbarungen zum Service Level und der eingeschränkten Garantie ausgeschlossen. Vorschauversionen von Azure Kubernetes Fleet Manager sind auf Best-Effort-Basis teilweise durch den Kundensupport abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen.

In einem automatischen Upgradeprofil können Sie Folgendes konfigurieren:

ein Channel (Stable, Rapid, NodeImage), der den Typ des automatischen Upgrades bestimmt, der auf die Cluster angewendet wird.
ein UpdateStrategy, mit dem die Sequenz konfiguriert wird, in der die Cluster aktualisiert werden. Wenn keine Strategie bereitgestellt wird, werden Cluster nacheinander aktualisiert.
die NodeImageSelectionType (Neueste, konsistent), um anzugeben, wie das Knotenimage beim Upgrade der Kubernetes-Version ausgewählt wird.

Stabiler Kanal

Der Stable-Kanal ist immer die neueste AKS-unterstützte Kubernetes-Patchversion auf Nebenversion N-1, wobei N die neueste unterstützte Nebenversion ist.

Beispiele:

Die neueste unterstützte Kubernetes-Nebenversion ist 1.30. Alle Patchversionen im 1.29 Nebenbereich werden für Stable-Kanalupdates berücksichtigt.
Eine neue Kubernetes-Nebenversion von 1.31 wird veröffentlicht. Alle Patchversionen im 1.30 Nebenbereich werden für Stable-Kanalupdates berücksichtigt. Alle Cluster, die zuvor Updates von 1.29 erhalten, werden auf den neuesten Patch für 1.30 aktualisiert.

Rapid-Kanal

Der Rapid-Kanal ist immer die neueste AKS-unterstützte Kubernetes-Nebenversion.

Beispiele:

Die neueste unterstützte Nebenversion ist 1.30. Alle Patchversionen im 1.30 Nebenbereich werden für Rapid-Kanalupdates berücksichtigt.
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.

NodeImage-Kanal

Mitgliedclusterknoten werden mit einer neu gepatchten VHD aktualisiert, die Sicherheitsupdates und Fehlerbehebungen in wöchentlicher Zeit enthält. Das Update auf die neue VHD ist nach Wartungsfenstern und Überspannungseinstellungen störend. Bei der Auswahl dieser Option fallen keine zusätzlichen VHD-Kosten an.

Wenn Sie diesen Kanal verwenden, sind unbeaufsichtigte Upgrades für Linux standardmäßig deaktiviert. Knotenimage-Upgrades unterstützen veraltete Patchversionen, solange die Nebenversion von Kubernetes weiterhin unterstützt wird. Node-Images werden AKS-getestet, vollständig verwaltet und 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.

Verhalten beim Überspringen von Nebenversionen

Bei der automatischen Aktualisierung werden keine Cluster 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, wird empfohlen, zunächst einen oder mehrere Aktualisierungsausführungen durchzuführen, um die Mitgliedcluster in eine Reihe konsistenter Versionen zu bringen, damit konfigurierte Stable oder Rapid Kanalaktualisierungen sicherstellen, dass die Konsistenz in Zukunft erhalten bleibt.