Wie Upgrades für Azure Kubernetes Service (AKS) Cluster funktionieren

Azure Kubernetes Service (AKS) führt Rollupgrades durch, um Unterbrechungen bei der Ausführung von Workloads zu minimieren.

Für die meisten Produktionsworkloads ist AKS Automatic gegebenenfalls die empfohlene Standardeinstellung. AKS Automatic umfasst produktionsreife Standardeinstellungen für Upgradevorgänge, z. B. automatische Kubernetes-Versionsupgrades, automatische Updates der Betriebssystemimages der Knoten, verwaltete Vorgänge für Systemknoten und integrierte Schutzmechanismen, die den manuellen Aufwand reduzieren. Weitere Informationen finden Sie in der Einführung in AKS Automatic.

In diesem Artikel werden die AKS-Upgrademechaniken erläutert und hervorgehoben, wo AKS Automatic und AKS Standard unterschiedlich sind.

Voraussetzungen

Upgrademodell: AKS Automatic und AKS Standard

Die Clustermodi „AKS Automatic“ und „AKS Standard“ verwenden dieselben grundlegenden Prinzipien für Kubernetes-Upgrades, unterscheiden sich jedoch bei den Standardeinstellungen und der operativen Verantwortung.

Upgrade-Bedenken AKS Automatik AKS Standard
Produktionspositionierung Empfohlene Standardeinstellung für die meisten Produktionsworkloads, sofern zutreffend Flexibles Modell mit standardmäßig mehr manueller Konfiguration
Aktualisierungen von Kubernetes-Minor-Versionen Vorkonfiguriertes Kanal für automatische Upgrades Standardmäßig manuell, optionaler automatischer Kanal
Node-OS-Image-Upgrades Vorkonfigurierter automatischer Kanal für Knoten-OS-Images Standardmäßig manuell, optionaler automatischer Kanal
Systemknotenpoolvorgänge Von AKS verwaltet Vom Kunden verwaltet
Geplante Wartungsfenster Standardmäßig verfügbar Optionale Konfiguration
Steuerelemente für Arbeitslastunterbrechungen Kundenseitig verwaltet, einschließlich Replikationsstrategie, Bereitschaftsverhalten und Unterbrechungsrichtlinie Kundenseitig verwaltet, einschließlich Replikationsstrategie, Bereitschaftsverhalten und Unterbrechungsrichtlinie

Note

AKS Automatic vereinfacht Plattformvorgänge, aber die gemeinsame Verantwortung gilt weiterhin. Das Verfügbarkeitskonzept auf Workload-Ebene und das Verhalten der Eviction-Richtlinie liegen weiterhin in der Verantwortung der Kunden.

Verhalten bei Rolling Upgrades in AKS

AKS aktualisiert Knotenpools mithilfe eines rollierenden Musters, das Kapazität behält, während knoten ersetzt oder umgestaltet werden. Dieses Verhalten ist für alle AKS-Clustermodi identisch.

Auf hoher Ebene: AKS

  1. Fügt anhand der Upgrade-Einstellungen temporäre Zusatzkapazität hinzu.
  2. Sperrt Knoten und entfernt Workloads von ihnen, um sie zu verschieben.
  3. Stellt Knoten mit dem Ziel-Image neu bereit oder ersetzt sie durch die Zielversion.
  4. Entfernt die temporäre Kapazitätserhöhung nach Abschluss.

Beispiel für ein fortlaufendes Upgrade

In diesem Beispiel wird das Upgrade eines Clusters mit zwei Knoten von Kubernetes 1.30 auf 1.31 veranschaulicht, wobei maxSurge auf 1 festgelegt ist.

Schritt 1: Ersteinrichtung

Der Cluster startet mit zwei Knoten, die Version 1.30 ausführen, wobei jeder Knoten Anwendungs-Pods hostet.

Diagramm, das das anfängliche Cluster-Setup mit zwei Knoten zeigt, auf denen Version 1.30 ausgeführt wird, die jeweils Anwendungs-Pods hosten, sowie einen neu erstellten Surge-Knoten.

  • Knoten 1: Pod A, Pod B
  • Knoten 2: Pod C, Pod D
  • Surge Node: Leer (mit Ausnahme von DaemonSets und neuen Pods)

Schritt 2: Absperren und Entwässerung des ersten Knotens

AKS sperrt Knoten 1 ab, um die Planung neuer Pods zu verhindern, und entleert dann bestehende Pods.

Diagramm, das zeigt, dass Node 1 gesperrt und geleert wird, wobei Pods entfernt und auf anderen verfügbaren Knoten ersetzt werden.

  • Pod A → auf dem Surge Node entfernt und ersetzt
  • Pod B → auf Knoten 2 entfernt und ersetzt

Schritt 3: Upgrade des ersten Knotens

Auf Node 1 wird ein Reimaging mit Kubernetes Version 1.31 durchgeführt, während die Pods weiterhin auf anderen Knoten ausgeführt werden.

Diagramm, in dem Node 1 in Version 1.31 umgestaltet wird, während Anwendungs pods weiterhin auf Node 2 und dem Surge Node ausgeführt werden.

  • Knoten 1: Upgrade auf v1.31
  • Knoten 2: Pod B, Pod C, Pod D
  • Überspannungsknoten: Pod A

Schritt 4: Abgrenzen und entwässern des zweiten Knotens

AKS wiederholt den Vorgang für Node 2, Pods werden entfernt, und der Scheduler verteilt sie auf geeignete verfügbare Knoten.

Diagramm, das zeigt, wie Knoten 2 gesperrt und entleert wird, wobei Pods verdrängt und auf dem aktualisierten Knoten 1 und dem Surge-Knoten ersetzt werden.

  • Pod C, B → auf Knoten 1 entfernt und ersetzt
  • Pod D → auf dem Surge Node entfernt und ersetzt
  • Node 2: Gesperrt und Reimaging auf v1.31

Schritt 5: Entfernen des Surge-Knotens

Nachdem alle dauerhaften Knoten aktualisiert wurden, wird der Surge-Knoten gesperrt, entleert und gelöscht.

Diagramm, das zeigt, dass der Surge Node entwässert und gelöscht wird, wobei Pods entfernt und auf den aktualisierten permanenten Knoten ersetzt werden.

  • Pod A wurde aus Knoten 1 ausgegliedert und ersetzt
  • Pod D → auf Node 2 entfernt und ersetzt
  • Surge Node: Gelöscht

Endzustand

Alle Knoten führen jetzt Kubernetes Version 1.31 aus, wobei die Pods über den Cluster verteilt werden.

  • Knoten 1 (v1.31): Pod A, Pod C
  • Knoten 2 (v1.31): Pod B, Pod D

Restriktives Verhalten von Pod Disruption Budgets (PDBs)

Wenn eine restriktive PDB-Sperrung blockiert, kann der Knotenabfluss verzögert oder verhindert werden. AKS kann das Cordon Verhalten eines Knotens, der nicht entleert werden kann, verwenden, um je nach konfiguriertem Verhalten andere geeignete Knoten weiter zu aktualisieren. Blockierte Knoten verbleiben möglicherweise in einer älteren Version, bis die Blockierungsbedingung aufgelöst wird.

Restriktives PDB-Beispiel

Dieses Beispiel zeigt das Upgrade eines Clusters mit zwei Knoten von Kubernetes 1.30 auf 1.31, wobei maxSurge auf 2 gesetzt ist und ein PDB den Drain-Vorgang des ersten Knotens blockiert.

Schritt 1: Anfängliches Setup mit restriktivem PDB

Der Cluster hat anfänglich zwei Knoten, auf denen Version 1.30 ausgeführt wird, mit einem PDB, das Pod A vor dem Entfernen schützt.

Diagramm, das den anfänglichen Cluster mit zwei Knoten, einem Surge Node und einem Pod Disruption Budget zeigt, das Pod A vor Eviction schützt.

  • Knoten 1: Pod A (geschützt durch PDB), Pod B
  • Knoten 2: Pod C, Pod D
  • Spitzenlastknoten: 2 neu erstellte Knoten
  • PDB: Verhindert die Entfernung von Pod A

Schritt 2: Versuch, ersten Knoten zu entwässern (blockiert)

AKS sperrt Node 1, kann Pod A jedoch aufgrund von PDB-Beschränkungen nicht evakuieren.

Diagramm, das zeigt, dass Knoten 1 abgesperrt ist, der Drain-Vorgang jedoch durch ein Pod Disruption Budget blockiert wird, wobei Pod A festhängt und Pod B auf den Surge-Knoten verdrängt wird.

  • Knoten 1: Abgesperrt und als unter Quarantäne markiert (Pod A festgefahren)
  • Pod B → auf Surge Node 1 ausgeräumt und ersetzt, während Surge Node 2 vorübergehend nicht verwendet wird
  • Status: Node 1-Upgrade blockiert

Schritt 3: Fahren Sie mit dem zweiten Knoten fort

Mit Knoten 1 unter Quarantäne stellt AKS das Upgrade von Node 2 fort.

Diagramm, das zeigt, dass Knoten 1 unter Quarantäne bleibt, während Knoten 2 abgesperrt und erfolgreich geleert wird, wobei Pods auf den Surge Node verschoben werden.

  • Knoten 1: Bleibt unter Quarantäne (v1.30)
  • Knoten 2: Abgesperrt und erfolgreich entleert
  • Pod C → Wird entfernt und auf Surge-Node 2 ersetzt
  • Pod D → Wird entfernt und auf Surge-Node 2 ersetzt

Schritt 4: Upgrade des zweiten Knotens

Node 2 wird erfolgreich auf Kubernetes Version 1.31 umgeschrieben.

Diagramm, das zeigt, dass Node 2 erfolgreich auf Version 1.31 aktualisiert wurde, während Node 1 mit Pod A isoliert bleibt.

  • Knoten 1: Immer noch unter Quarantäne (v1.30) mit Pod A
  • Knoten 2: Upgrade auf v1.31
  • Spitzknoten 1: Pod B
  • Überspannungsknoten 2: Pod C, Pod D

Schritt 5: Ein Surge-Node wird zum dauerhaften Ersatz, wenn ein anderer entfernt wird

Da Node 1 weiterhin unter Quarantäne bleibt, wird Surge Node 1 zum dauerhaften Ersatz und läuft mit v1.31, während Surge Node 2 gelöscht wird.

Diagramm, das zeigt, dass der Surge Node zu einem dauerhaften Ersatz mit Version 1.31 wird, während Node 1 unter Quarantäne bleibt.

  • Knoten 1: In Quarantäne (v1.30) – erfordert manuelle Eingriffe
  • Pod C, Pod D → von Surge Node 2 entfernt und auf Knoten 2 ersetzt
  • Surge Node 1 (v1.31): Pod B (jetzt dauerhaft)
  • Surge Node 2 (v1.31): Gelöscht

Endzustand

Das Upgrade wird mit einem isolierten Knoten abgeschlossen, der manuelle Eingriffe erfordert.

  • Knoten 1: In Quarantäne versetzt (v1.30) mit Pod A – Kunde muss das Problem manuell lösen (siehe Nicht entleerbare Knoten auflösen)
  • Node 2 (v1.31): Normal ausgeführt
  • Ehemaliger Surge Node (v1.31): Jetzt dauerhafter Ersatz

Von Bedeutung

Der unter Quarantäne gestellte Knoten (Knoten 1) liegt in der Verantwortung des Kunden, der ihn selbst verwalten muss. Sie müssen eine der folgenden Aktionen ausführen:

  • Passen Sie die PDB so an, dass die Eviction von Pod A möglich ist.
  • Manuelles Löschen von Pod A.
  • Löschen Sie den Knoten und erstellen Sie ihn neu, nachdem die blockierende Bedingung behoben wurde.

Wichtige Überlegungen für PDB-blockierte Upgrades

  • Verhalten bei nicht entleerbaren Knoten: Legen Sie für den Knotenpool Cordon fest, um dieses Quarantäneverhalten zu aktivieren.
  • Verantwortung des Kunden: Unter Quarantäne gestellte Knoten erfordern ein manuelles Eingreifen, um das Problem zu beheben.
  • Clusterkapazität: Der Spitzenlastknoten bleibt dauerhaft bestehen, was sich potenziell auf die Kapazitätsplanung des Clusters auswirkt.
  • Überwachung: Verfolgen Sie isolierte Knoten über Azure Monitor oder Kubectl, um eine zeitnahe Auflösung sicherzustellen.

Tipp

Um das Quarantäneszenario vollständig zu vermeiden, können Sie die automatische PDB-Verwaltung verwenden, um Bereitstellungsreplikate automatisch zu skalieren, damit PDB-Einschränkungen erfüllt sind, bevor der Abfluss beginnt. Auf diese Weise kann die Entfernung ohne Blockierung fortgesetzt werden, ohne die Notwendigkeit einer manuellen Quarantäneauflösung zu vermeiden.

Blue-Green-Knotenpool-Aktualisierungen (manuelle Kontrolle)

Blue-Green Upgrades bieten einen kontrollierteren Upgradeansatz, indem manuell ein vollständiger Satz neuer Knotenpools erstellt wird, bevor Workloads migriert werden. Dieser manuelle Ansatz bietet Ihnen die vollständige Kontrolle über den Upgradeprozess und dessen Zeitpunkt.

Weitere Informationen finden Sie unter Blue-Green-Knotenpoolupgrades in AKS.

Wann Blue-Green-Upgrades eingesetzt werden sollten

Manuelle Blue-Green-Upgrades von Knotenpools sind eine fortgeschrittene Strategie für spezialisierte Anforderungen, wie etwa explizite Migrationsprüfpunkte, benutzerdefinierte Validierungsschranken oder engmaschig kontrollierte Umschaltungen.

Verwenden Sie manuelles Blue-Green, wenn Sie es benötigen:

  • Operatorgesteuerte Migrationsphasen.
  • Benutzerdefinierte Überprüfungs- und Akzeptanzkriterien vor dem Commit.
  • Explizite Rollback-Choreographie, die an interne Runbooks gebunden ist.

Für die meisten Produktionsworkloads ist, sofern zutreffend, das Standardaktualisierungsverhalten von AKS Automatic der bevorzugte Ausgangspunkt, und manuelle Blue-Green-Bereitstellungen bleiben in der Regel Ausnahmefällen vorbehalten.

Wichtige Begriffe

  • Blauer Knotenpool: Ihr vorhandener Knotenpool, der die aktuelle Kubernetes-Version ausführt.
  • Grüner Knotenpool: Neuer Knotenpool, den Sie erstellen, um die Kubernetes-Zielversion auszuführen.
  • Manuelle Steuerung: Sie verwalten alle Aspekte des Migrationsprozesses.
  • Überprüfungsprüfpunkte: Sie entscheiden, wann Sie fortfahren, anhalten oder rollbacken möchten.

Vorteile von Blue-Green-Aktualisierungen

  • Vollzugriff: Sie entscheiden genau, wann jeder Schritt eintritt.
  • Benutzerdefinierte Validierung: Definieren Sie Ihre eigenen Validierungskriterien und den Zeitpunkt der Validierung.
  • Schrittweise Migration: Verschieben Sie Workloads in Ihrem bevorzugten Tempo.
  • Einfaches Rollback: Ursprüngliche Knoten bleiben verfügbar, bis Sie sie löschen.

Wichtige Aspekte für Blue-Green-Upgrades

  • Manueller Aufwand: Erfordert eine aktive Verwaltung während des gesamten Prozesses.
  • Kontingentanforderungen: Erfordert 2x die Knotenkapazität während des Upgrades.
  • Planung: Dokumentieren Sie Ihre Überprüfungskriterien und Rollbackprozeduren.

Beispiel für einen manuellen Blue-Green-Upgradeprozess

In diesem Beispiel wird das manuelle Upgrade eines Clusters mit zwei Knoten von Kubernetes 1.30 auf 1.31 mithilfe der Blau-Grün-Bereitstellung veranschaulicht.

Schritt 1: Erstellen eines grünen Knotenpools

Zunächst erstellen Sie manuell einen neuen Knotenpool mit der Kubernetes-Zielversion zusammen mit Ihrem vorhandenen Knotenpool.

Diagramm, das Blue-Green anfänglichen Setup mit dem Blauen Knotenpool mit Version 1.30 und dem neu erstellten Grünen Knotenpool mit Version 1.31 zeigt.

  • Blauer Knotenpool (v1.30): Pod A, Pod B, Pod C, Pod D (vorhanden)
  • Grüner Knotenpool (v1.31):Leer (manuell erstellt von Ihnen)
  • Ihre Aktion: az aks nodepool add mit neuer Kubernetes-Version

Schritt 2: Manuelles Abkabeln blauer Knoten

Sperren Sie die blauen Knoten für die Planung neuer Pods, während vorhandene Pods weiter ausgeführt werden.

  • Ihre Aktion: kubectl cordon auf jedem blauen Knoten
  • Blaue Knoten: Gesperrt, keine neuen Pods geplant
  • Grüne Knoten: Bereit zum Empfangen von Workloads

Schritt 3: Manuelles Entwässern blauer Knoten (kontrolliertes Tempo)

Sie steuern das Migrationstempo, indem Sie Knoten einzeln oder in Batches manuell entwässern.

Diagramm, das zeigt, wie der blaue Knoten entleert wird, wobei die Pods evakuiert und im grünen Knotenpool neu bereitgestellt werden, und wie der zweite blaue Knoten entleert wird, wobei die verbleibenden Pods in den grünen Knotenpool migriert werden.

  • Ihre Aktion: kubectl drain auf ausgewählten blauen Knoten
  • Pod-Migration: Pods werden automatisch grünen Knoten neu zugewiesen
  • Überprüfung: Überprüfen von Arbeitslasten auf grünen Knoten, bevor Sie fortfahren

Schritt 4: Überprüfen und Entscheiden

Überprüfen Sie nach der Migration von Workloads die Anwendungsleistung auf grünen Knoten.

Diagramm, das die Überprüfungsphase mit allen Workloads zeigt, die im Grünen Knotenpool ausgeführt werden, während der Blaue Knotenpool für rollbacks verfügbar bleibt.

In dieser Phase haben Sie folgende Möglichkeiten:

  • Überwachen: Überprüfen von Anwendungsmetriken und Protokollen
  • Test: Ausführen von Überprüfungstests im grünen Knotenpool
  • Entscheiden: Festlegen auf Grün oder Zurückschalten auf Blau

Schritt 5: Commit oder Rollback

Basierend auf Ihrer Überprüfung führen Sie das Upgrade manuell aus oder führen ein Rollback aus.

Option A - Commit (Erfolg):

Diagramm, das einen erfolgreichen Commit mit dem gelöschten blauen Knotenpool und dem grünen Knotenpool zeigt, der zum primären Knotenpool wird.

  • Ihre Aktion: Löschen des blauen Knotenpools mithilfe von az aks nodepool delete
  • Ergebnis: Der grüne Knotenpool wird primär

Option B - Rollback (Probleme erkannt):

Diagramm, das ein Rollback zeigt, bei dem die Arbeitslasten zum blauen Knotenpool zurückkehren und der grüne Knotenpool gelöscht wird.

  • Ihre Aktion: Heben Sie die Sperrung blauer Knoten mit kubectl uncordon auf, leeren Sie grüne Knoten mit kubectl drain und löschen Sie den grünen Knotenpool mit az aks nodepool delete
  • Ergebnis: Workloads kehren zu blauen Knoten zurück

Überlegungen zur Produktion für die Upgradeplanung

  • Surge (maxSurge) Konfiguration: Steuert die Anzahl der zusätzlichen Knoten, die bei Upgrades erstellt werden. Höhere Werte beschleunigen Upgrades, verbrauchen aber mehr Ressourcen.
  • Pod-Unterbrechungsbudgets (PDBs): Konfigurieren Sie PDBs, um die Anwendungsverfügbarkeit während des Upgradeprozesses sicherzustellen.
  • Knotenpool-Upgrades: Jeder Knotenpool wird unabhängig aktualisiert. Planen Sie ihre Upgradestrategie entsprechend.
  • Kapazität und Kontingente: Überprüfen Sie vor Upgrade-Zeitfenstern die Anforderungen an temporäre Kapazität sowie an Kapazität und Kontingente im Dauerbetrieb.
  • Überwachung und Warnungen: Richten Sie die Überwachung und Warnung ein, bevor das Upgrade gestartet wird.

In AKS Automatic sind mehrere Optionen auf Plattformebene für upgrades vorkonfiguriert für die Produktionsbereitschaft. In AKS Standard treffen Teams diese Entscheidungen in der Regel explizit.

Verwandte Inhalte

  • Last updated on