Best Practices für GKE-Clusterupgrades

In diesem Dokument finden Sie Best Practices für Plattformadministratoren zum Verwalten von GKE-Clusterupgrades (Google Kubernetes Engine). Standardmäßig aktualisiert die GKE die Version der Steuerungsebene und der Knoten Ihres Clusters automatisch, um neue Funktionen, Fehlerkorrekturen und Sicherheitspatches bereitzustellen und so die Leistung und Sicherheit Ihrer Umgebung zu gewährleisten.

Damit diese automatischen Upgrades Ihren betrieblichen Anforderungen entsprechen und die Unterbrechung von Arbeitslasten minimiert wird, bietet die GKE Tools, mit denen Sie die maximale Kontrolle behalten. In diesem Leitfaden wird erläutert, wie Sie diese Tools effektiv einsetzen, um eine hohe Leistung und Verfügbarkeit zu gewährleisten. Grundlegende Informationen finden Sie unter GKE-Clusterupgrades.

Zusätzlich zu Clusterupgrades, bei denen nur die GKE-Version der Steuerungsebene und der Knoten aktualisiert wird, führt GKE regelmäßig zusätzliche Updates für den Cluster durch. Wenn Sie die Best Practices in diesem Dokument umsetzen, können Sie sich auf einige dieser Arten von Änderungen vorbereiten. Weitere Informationen finden Sie unter Clusterlebenszyklusänderungen verwalten, um Unterbrechungen zu minimieren.

Eine konsolidierte Übersicht aller Best Practices für GKE finden Sie unter Best Practices für GKE.

Checkliste

In der folgenden Tabelle sind die Aufgaben zusammengefasst, die in den folgenden Abschnitten ausführlich erläutert werden. Wir empfehlen, diese Aufgaben auszuführen, wenn Sie Ihre Umgebung für Clusterupgrades vorbereiten.

Best Practice Tasks
Mit Release-Versionen das gewünschte Verhältnis zwischen Funktionsgeschwindigkeit und Upgradestabilität auswählen
Zeitpunkt von Upgrades mit Wartungsrichtlinien auswählen
Roll-out von Upgrades über Cluster hinweg steuern
Steuern, wie Upgrades ausgelöst werden
Clusterupgrades überwachen
Unterbrechungen bestehender Arbeitslasten während Knotenupgrades minimieren

Mit Release-Versionen das gewünschte Verhältnis zwischen Funktionsgeschwindigkeit und Upgradestabilität auswählen

Mit Release-Versionen können Sie ein Gleichgewicht zwischen Funktionsgeschwindigkeit und Upgradestabilität wählen. GKE-Cluster sind standardmäßig in der Release-Version „Regular“ registriert. Wenn GKE die Steuerungsebene und die Knoten Ihres Clusters aktualisiert, um Sicherheitspatches bereitzustellen, bekannte Probleme zu beheben und neue Funktionen einzuführen, bestimmt die Release-Version, welche GKE-Versionen auf Ihrem Cluster ausgeführt werden. Wenn Sie beispielsweise neue Funktionen früher nutzen möchten, können Sie den Rapid Channel auswählen. Wenn Sie Versionen mit nachgewiesener Stabilität bevorzugen, wählen Sie den Stable Channel aus. Weitere Informationen zur Auswahl zwischen bestimmten Versionen finden Sie unter Welche Versionen sind verfügbar?.

Wenn Sie Ihre Cluster manuell aktualisieren möchten, können Sie trotzdem von der Auswahl Ihres Release-Channels profitieren, indem Sie die verfügbaren Versionen und automatischen Upgradeziele für den Channel prüfen, bevor Sie eine neue Version auswählen.

Wenn Sie Patchversionen in einer Release-Version so schnell wie möglich erhalten möchten, z. B. um kritische Sicherheitspatches zu erhalten, lesen Sie den Abschnitt Patchversionen früher erhalten.

Auswählen, wie viel Support Sie für eine Nebenversion benötigen

GKE bietet insgesamt bis zu 24 Monate Support für eine Nebenversion, nachdem die Version im Regular Channel verfügbar gemacht wurde. Dieser Support umfasst 14 Monate Standardsupport und etwa 10 Monate erweiterten Support, der mit dem Extended Channel verfügbar ist. Weitere Informationen dazu, wie GKE eine Nebenversion unterstützt, finden Sie unter Unterstützung von Nebenversionen.

Wenn Sie Ihren Cluster länger auf einer Nebenversion belassen und auch nach dem Ende des Standardsupports noch Sicherheitspatches erhalten möchten oder wenn Sie verhindern möchten, dass das Ende des Standardsupports erzwungen wird, können Sie auch den Extended Channel verwenden. Weitere Informationen finden Sie im Abschnitt Erweiterten Kanal für Langzeitsupport verwenden.

Wenn die Nebenversion das Ende des Supports erreicht, führt die GKE je nach Release-Version, für die der Cluster registriert ist, automatisch ein Upgrade des Clusters durch, um dafür zu sorgen, dass der Cluster leistungsfähig und sicher bleibt. Weitere Informationen finden Sie unter Automatische Clusterupgrades für Sicherheit und Kompatibilität. Wenn Sie die in diesem Dokument beschriebenen Tools verwenden, um automatische Clusterupgrades zu verhindern oder zu verzögern, empfehlen wir, Ihre Cluster manuell zu aktualisieren, bevor die Nebenversion, die sie ausführen, das Ende des Supports erreicht. Andernfalls führt GKE automatisch ein Upgrade Ihres Clusters durch.

Zeitpunkt von Upgrades mit Wartungsrichtlinien auswählen

Mit den folgenden Optionen können Sie festlegen, wann Upgrades durchgeführt werden können und wann nicht:

  • Wartungsfenster: Wählen Sie ein wiederkehrendes Zeitfenster aus, in dem GKE ein Upgrade Ihres Clusters durchführen kann, z. B. außerhalb der Öffnungszeiten. Wenn der Upgradeprozess über das Wartungsfenster hinausgeht, versucht GKE, den Vorgang zu pausieren und im nächsten Wartungsfenster fortzusetzen.
  • Wartungsausschlüsse: Wählen Sie einen bestimmten Zeitraum aus, in dem GKE Ihren Cluster nicht aktualisieren darf, z. B. während einer wichtigen Verkaufsaktion für ein Einzelhandelsunternehmen. Sie können Wartungsausschlüsse auch verwenden, um automatische Upgrades eines Clusters vorübergehend zu verschieben, wenn Sie beispielsweise ein Problem mit anderen Clustern feststellen, die auf eine neue Version aktualisiert werden.
    • Für erweiterte Anwendungsfälle müssen Sie möglicherweise bestimmte Arten von Upgrades manuell durchführen, anstatt sie von GKE durchführen zu lassen. Sie können Wartungsausschlüsse verwenden, um diese Arten von automatischen Upgrades zu deaktivieren. Sie können beispielsweise den Bereich „Keine Nebenversions- oder Knotenupgrades“ verwenden, um alle Nebenversions- und Knotenupgrades zu deaktivieren. Sie müssen diese Upgrades manuell ausführen oder GKE führt Upgrades Ihrer Cluster am Ende des Supports für die Nebenversion durch.
  • Wartungshäufigkeit: Für erweiterte Anwendungsfälle können Sie das Mindestintervall zwischen zwei aufeinanderfolgenden automatischen Upgrades mit dem Budget für Clusterunterbrechungen steuern.

Durch die Konfiguration von Wartungsrichtlinien können Sie die Vorhersehbarkeit von Upgrades verbessern und dafür sorgen, dass Upgrades dann durchgeführt werden, wenn es für Ihre Arbeitslasten am besten ist.

Roll-out von Upgrades für Cluster steuern

Wir empfehlen, mehrere Umgebungen zu verwenden, um Risiken und unerwünschte Ausfallzeiten zu minimieren. Dazu sollten Sie Software- und Infrastrukturänderungen separat von Ihrer Produktionsumgebung testen. Wir empfehlen, mindestens eine Produktionsumgebung und eine Vorproduktions- oder Testumgebung zu haben.

Folgende Umgebungen werden empfohlen:

Umgebung Beschreibung
Produktion Live-Traffic für geschäftskritische Anwendungen für Endnutzer bereitstellen
Canary Testen Sie einen kleinen Teil der Produktionsumgebung, bevor alle Cluster aktualisiert werden.
Staging Prüfen Sie, ob alle neuen Änderungen, die aus vorherigen Umgebungen bereitgestellt wurden, wie vorgesehen funktionieren, bevor die Änderungen in der Produktionsumgebung bereitgestellt werden.
Test Führen Sie Benchmarking, Tests und Qualitätssicherung (QS) für Arbeitslasten mit der GKE-Version durch, die Sie in der Produktion verwenden werden.
Entwicklung Verwenden Sie für die aktive Entwicklung dieselbe Version, die in der Produktion ausgeführt wird. In dieser Umgebung erstellen Sie Korrekturen und inkrementelle Änderungen, die in der Produktion bereitgestellt werden sollen.

GKE bietet Funktionen wie die Roll-out-Sequenzierung, mit denen Sie steuern können, wie Upgrades in diesen verschiedenen Umgebungen bereitgestellt werden, wie im folgenden Abschnitt beschrieben.

Roll-out-Sequenzierung für Roll-outs in verschiedenen Umgebungen verwenden

Wenn Sie neue GKE-Versionen schrittweise innerhalb und zwischen diesen Umgebungen bereitstellen möchten, empfehlen wir die Verwendung der Roll-out-Sequenzierung. Bei der Roll-out-Sequenzierung verwenden alle Cluster in allen Bereitstellungsphasen dieselbe Release-Version und Nebenversion. Die GKE führt neue Versionen schrittweise in der von Ihnen konfigurierten Sequenz ein. Wenn GKE die neue Version in Ihren Umgebungen einführt, können Sie prüfen, ob Ihre Clusterumgebung und Arbeitslasten mit der neuen Version wie erwartet ausgeführt werden.

Wenn Sie eine neue Umgebung konfigurieren, verwenden Sie die Sequenzierung der Einführung mit benutzerdefinierten Phasen. Mit dieser neueren Version der Roll-out-Sequenzierung können Sie den Roll-out einer neuen Version auf eine Flotte in mehrere Phasen aufteilen. Mit diesem Ansatz kann GKE beispielsweise eine Canary-Umgebung in der Produktion aktualisieren, bevor der Rest der Produktion aktualisiert wird.

Wir empfehlen es zwar nicht für neue Umgebungen, aber Sie können auch eine frühere Version des Features verwenden, die flottenbasierte Rollout-Sequenzierung. Diese Version der Funktion ist die einzige, die in derGoogle Cloud -Konsole unterstützt wird, bietet aber ansonsten einen eingeschränkten Funktionsumfang.

GKE-Patch- und Nebenupgrades testen

Die GKE aktualisiert Cluster automatisch auf einen neuen Patch, bis zu einmal pro Woche. Upgrades von Nebenversionen erfolgen jedoch nur etwa dreimal pro Jahr. Neue Kubernetes-Nebenversionen enthalten mehr Änderungen als Patches derselben Nebenversion. Wir empfehlen, bei der Einführung von Nebenversions-Upgrades in Ihren Umgebungen besonders sorgfältig vorzugehen, um sicherzustellen, dass die neue Nebenversion wie erwartet mit Ihren Clustern und Arbeitslasten funktioniert.

Prüfungen vor dem Upgrade des Clusters durchführen

Bevor automatische Cluster-Upgrades durchgeführt werden, qualifiziert GKE neue Versionen für einen Zeitraum, der von der Release-Version abhängt, und prüft die Bereitschaft des Clusters.

Vor Clusterupgrades empfehlen wir Folgendes:

  • Für alle Upgrades, einschließlich Patch- und Nebenversionsupgrades:
    • In den GKE-Versionshinweisen finden Sie Informationen zu Problemen und das Änderungslog für neue Neben- und Patchversionen.
    • Prüfen Sie die bekannten GKE-Probleme auf Probleme, die für Ihre Clusterumgebung und die neue Version relevant sind.
  • Beachten Sie bei Nebenupgrades außerdem Folgendes:
    • Prüfen Sie, ob APIs eingestellt wurden. Weitere Informationen finden Sie in den GKE-Versionshinweisen für die neue Version, im Kubernetes-Changelog und unter Einstellung von Funktionen und APIs.
    • Achten Sie darauf, dass die Versionsabweichung zwischen der Steuerungsebene und den Knoten unterstützt wird. GKE unterstützt die Ausführung von Knoten, die bis zu zwei Nebenversionen älter sind als die Steuerungsebene. Weitere Informationen finden Sie unter Richtlinie für GKE-Versionsabweichungen.
  • Für Knotenupgrades:

Steuern, wie Upgrades ausgelöst werden

Die GKE aktualisiert Cluster standardmäßig regelmäßig automatisch auf neue Versionen. Sie können jedoch auch manuelle Upgrades verwenden, um Ihren Cluster genau dann zu aktualisieren, wenn Sie möchten, und die Version zu steuern, die auf Ihrem Cluster ausgeführt wird.

In diesem Fall können Sie folgende Aktionen ausführen:

  • Cluster manuell upgraden

  • Aktionen für laufende automatische oder manuelle Knotenupgrades ausführen, einschließlich:

    • Upgrade abbrechen
    • Upgrade fortsetzen
    • Rollback eines Upgrades durchführen
    • Laufendes Upgrade abschließen

Wenn Sie mehr Kontrolle über den Upgradeprozess haben möchten, empfehlen wir, Wartungsausschlüsse zu konfigurieren und dann bei Bedarf manuelle Upgrades durchzuführen. Weitere Informationen zu manuellen Upgrades und anderen Aktionen, die Sie für laufende Upgrades ausführen können, finden Sie unter Manuelles Upgrade eines Clusters oder Knotenpools.

Clusterupgrades überwachen

Damit GKE-Upgrades wie erwartet ablaufen und Ihre Clusterumgebung leistungsfähig und verfügbar bleibt, sollten Sie die folgenden Tools verwenden, um Clusterupgrades zu überwachen. Mit Tools wie Benachrichtigungen, Statistiken und Empfehlungen sowie Protokollen können Sie den Status Ihrer Cluster im Blick behalten. Wir empfehlen Ihnen, besonders auf Benachrichtigungen zum Supportende, Benachrichtigungen zum Start von Upgrades und Benachrichtigungen zu geplanten Upgrades für Nebenversionen zu achten, für die Sie sich anmelden müssen. Richten Sie Benachrichtigungsrichtlinien ein, damit Sie diese Benachrichtigungen sehen.

In den folgenden Ressourcen finden Sie Details zu aktuellen Upgrades:

Unterbrechungen bestehender Arbeitslasten während Knoten-Upgrades minimieren

Zusätzlich zu den allgemeinen Best Practices, die in den vorherigen Abschnitten beschrieben werden, empfehlen wir Ihnen, zusätzliche, erweiterte Konfigurationen in Betracht zu ziehen, um den Upgradeprozess weiter an Ihre Clusterumgebung und die Anforderungen Ihrer Arbeitslasten anzupassen.

Zusätzliche Überlegungen für bestimmte Arbeitslastprofile

Bestimmte Arten von Arbeitslasten und Clusterumgebungen erfordern zusätzliche Vorbereitungen für Clusterupgrades. Wenn Ihre Arbeitslast in eine oder mehrere der folgenden Kategorien fällt, sollten Sie diese zusätzlichen Aspekte berücksichtigen:

  • Arbeitslasten, die auf Maschinen ausgeführt werden, die nicht live migriert werden: GKE-Knoten, die Compute Engine-Instanzen sind, die GKE für Sie erstellt, erfordern regelmäßig Wartung der zugrunde liegenden Infrastruktur. Die meisten Compute Engine-Instanzen können live migriert werden. Das bedeutet, dass laufende Arbeitslasten bei dieser Wartung nicht unterbrochen werden. Bestimmte Maschinentypen können jedoch nicht live migriert werden. Das bedeutet, dass Arbeitslasten, die auf den GKE-Knoten ausgeführt werden, unterbrochen werden können. Beschleuniger wie GPUs und TPUs für KI-/ML-Arbeitslasten können nicht live migriert werden. Weitere Informationen finden Sie unter Hostwartung in GKE.
  • Arbeitslasten mit eingeschränkter Kapazität: Wenn Ihre Arbeitslasten Maschinentypen mit eingeschränkter Kapazität verwenden, sind bei Clusterupgrades zusätzliche Überlegungen erforderlich. Weitere Informationen finden Sie unter Ressourcen für Knoten-Upgrades sicherstellen.
  • Zustandsorientierte Arbeitslasten: Wenn Ihre Arbeitslasten zustandsorientiert sind und bestimmte Anforderungen an das ordnungsgemäße Herunterfahren und Neustarten haben, sind bei Cluster-Upgrades zusätzliche Überlegungen erforderlich. Weitere Informationen finden Sie unter Arbeitslasten auf Unterbrechungen vorbereiten.

In den folgenden Abschnitten erfahren Sie, wie Sie die verfügbaren Tools verwenden können, um diese Arten von Arbeitslasten zu aktualisieren.

Upgradestrategie für Knoten auswählen

Im GKE-Standardmodus bietet GKE verschiedene Strategien für Knotenupgrades, mit denen festgelegt wird, wie die einzelnen Knoten in Ihrem Knotenpool aktualisiert werden. Durch Auswahl einer Upgradestrategie für Ihren Standard-Knotenpool können Sie den Prozess mit dem richtigen Verhältnis von Geschwindigkeit, Arbeitslastunterbrechung, Risikominderung, Ressourcenkapazität und Kostenoptimierung auswählen. Sie können die Parameter der Strategie auch so konfigurieren, dass sie Ihren Anforderungen am besten entsprechen. Weitere Informationen finden Sie unter Informationen zu Knotenupgrade-Strategien und Upgrade in einer ressourcenknappen Umgebung.

Im GKE Autopilot-Modus verwaltet GKE die Knoten-Upgrades und Sie müssen die verwendete Strategie nicht auswählen. Weitere Informationen finden Sie unter Surge-Upgrades für Autopilot-Cluster.

Toleranz für Unterbrechungen festlegen

Verwenden Sie Budgets für Pod-Störungen (PDBs), um sicherzustellen, dass Ihre Arbeitslasten eine ausreichende Redundanz aufweisen, wenn GKE die Knoten während Upgrades neu erstellt, was die Anzahl der Replikate für eine Arbeitslast vorübergehend reduzieren kann.

Wenn ein PDB festgelegt ist, werden die Pods in Ihrer Anwendung von GKE nicht beendet, wenn die Anzahl der Pods das konfigurierte Limit nicht übersteigt. GKE-Upgrades berücksichtigen ein PDB bis zu 60 Minuten lang. Außerdem werden Sie von GKE benachrichtigt, wenn das Leeren eines Knotens durch eine PDB blockiert wird oder das PDB-Zeitlimit erreicht ist und die Pods trotz des PDB-Verstoßes zwangsweise gelöscht werden. Weitere Informationen finden Sie unter Störende Ereignisse während eines Knotenpool-Upgrades.

Anwendung ordnungsgemäß beenden

Sie können das ordnungsgemäße Beenden konfigurieren, damit Arbeitslasten genügend Zeit haben, sich auf das Herunterfahren vorzubereiten. Bei Knotenupgrades berücksichtigt GKE die Einstellungen für die ordnungsgemäße Beendigung bis zu 60 Minuten lang bei den standardmäßigen Surge-Upgrades und bis zu 24 Stunden lang bei Blau/Grün-Upgrades und automatisch skalierten Blau/Grün-Upgrades (Vorabversion).

Weitere Informationen zum Konfigurieren der Einstellungen für die ordnungsgemäße Beendigung finden Sie unter GKE so konfigurieren, dass Arbeitslasten ordnungsgemäß beendet werden.

Erweiterten Kanal für Langzeitsupport verwenden

Wenn Sie für Ihren Cluster länger eine Nebenversion beibehalten möchten, sollten Sie den Cluster im erweiterten Kanal registrieren. In dieser Version unterstützt die GKE eine Nebenversion etwa 24 Monate lang. Mit der erweiterten Version steuern Sie Upgrades von Nebenversionen. GKE führt nur dann automatische Upgrades am Ende des Supports durch, wenn Sie das Upgrade nicht selbst initiieren. Weitere Informationen finden Sie unter Langzeitsupport mit dem Extended Channel erhalten.

Wenn Sie eine Nebenversion nicht länger als den Standardsupportzeitraum beibehalten müssen, aber trotzdem Nebenversionsupgrades steuern möchten, verwenden Sie stattdessen Wartungsausschlüsse mit dem Bereich „Keine Nebenversionsupgrades“.

Damit Sie den Kanal optimal nutzen können, empfehlen wir Ihnen, die folgenden Best Practices zu beachten. Einige dieser Best Practices erfordern einige manuelle Maßnahmen, einschließlich des manuellen Upgrades eines Clusters und des Änderns des Release-Kanals. eines Clusters. Sehen Sie sich die folgenden unterstützten Szenarien sowie Wann der erweiterte Kanal nicht verwendet werden sollte an.

Nebenversion vorübergehend länger beibehalten

Wenn Sie einen Cluster vorübergehend länger als den standardmäßigen 14-monatigen Supportzeitraum auf einer Nebenversion belassen müssen, um beispielsweise die Verwendung verworfener APIs zu minimieren, die in der nächsten Nebenversion entfernt werden, gehen Sie so vor: Sie können den Cluster vorübergehend von einem anderen Release-Version in den erweiterten Kanal verschieben, um weiterhin Sicherheitspatches zu erhalten, während Sie das Upgrade auf die nächste Nebenversion vorbereiten. Wenn Sie bereit sind, ein Upgrade auf die nächste Nebenversion durchzuführen, führen Sie ein Upgrade des Clusters manuell durch und verschieben Sie dann den Cluster zurück in den ursprünglichen Release-Kanal.

Ein- bis zweimal pro Jahr Upgrades von Nebenversionen

Wenn Sie beim Upgrade auf eine neue Nebenversion nur eine minimale Unterbrechung des Cluster wünschen, aber weiterhin einige neue Features erhalten möchten, gehen Sie so vor:

  • Registrieren Sie einen Cluster im erweiterten Kanal.
  • Führen Sie ein- oder zweimal pro Jahr zwei aufeinanderfolgende Upgrades von Nebenversionen durch. Führen Sie beispielsweise ein Upgrade von 1.33 auf 1.34 und dann auf 1.35 durch.

Dadurch wird sichergestellt, dass der Cluster auf einer verfügbaren Nebenversion bleibt, Funktionen von neuen Nebenversionen erhält, die Upgrades von Nebenversionen aber nur ausgeführt werden, wenn Sie entscheiden, dass der Cluster bereit ist.

Wann sollte der erweiterte Kanal nicht verwendet werden?

Wenn Sie den erweiterten Kanal für den vorgesehenen Zweck verwenden möchten, sind manuelle Maßnahmen erforderlich. Das folgende Szenario veranschaulicht die Folgen der Verwendung der erweiterten Release-Version ohne aktive Verwaltung der Nebenversion Ihres Clusters.

Nichts tun und weiterhin kleinere Upgrades in derselben Häufigkeit erhalten

Wenn Sie für Ihren Cluster dauerhaft die Nebenversion beibehalten möchten, registrieren Sie Ihren Cluster für den erweiterten Kanal und ergreifen Sie keine weiteren Maßnahmen. Alle Nebenversionen werden irgendwann nicht mehr unterstützt und GKE aktualisiert Cluster automatisch von nicht unterstützten Nebenversionen. GKE aktualisiert diesen Cluster also von einer nicht unterstützten Nebenversion auf eine bald nicht mehr unterstützte Nebenversion, was im Durchschnitt etwa alle vier Monate der Fall ist. Bei diesem Ansatz erhält der Cluster genauso häufig Upgrades von Nebenversionen wie bei anderen Release-Versionen, neue Funktionen jedoch später.

Nächste Schritte