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 automatisch die Version der Steuerungsebene und der Knoten Ihres Clusters, um neue Funktionen, Fehlerkorrekturen und Sicherheitspatches bereitzustellen, damit Ihre Umgebung leistungsfähig und sicher bleibt.

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 aufrechtzuerhalten. 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 implementieren, können Sie sich auf einige dieser Arten von Änderungen vorbereiten. Weitere Informationen finden Sie unter Änderungen am Clusterlebenszyklus 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 auf 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
Auslösen von Upgrades steuern
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 Ihrer Release-Version profitieren, indem Sie die verfügbaren Versionen und automatischen Upgradeziele für die Release-Version 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.

Wählen Sie aus, 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 der Version „Extended“ verfügbar ist. Weitere Informationen dazu, wie GKE eine Nebenversion unterstützt, finden Sie unter Support für Nebenversionen.

Wenn Sie die Nebenversion Ihres Clusters länger beibehalten und auch nach dem Ende des Standardsupports noch Sicherheitspatches erhalten möchten oder wenn Sie die Durchsetzung des Endes des Standardsupports verhindern möchten, können Sie auch den erweiterten Kanal 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, auf der sie ausgeführt werden, das Ende des Supports erreicht. Andernfalls führt die GKE automatisch ein Upgrade des 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 großen 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 bestimmte Arten von Upgrades möglicherweise manuell ausführen, anstatt sie von GKE ausfü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. Andernfalls führt die GKE am Ende des Supports für die Nebenversion ein Upgrade Ihrer Cluster durch.
  • Wartungshäufigkeit: Für erweiterte Anwendungsfälle können Sie das Mindestintervall zwischen zwei aufeinanderfolgenden automatischen Upgrades mit dem Clusterunterbrechungsbudget 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 über Cluster hinweg 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 an Endnutzer senden.
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 Produktion bereitgestellt werden.
Test Führen Sie Benchmarking, Tests und Qualitätssicherung (QA) 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. Weitere Informationen finden Sie im folgenden Abschnitt.

Roll-out-Sequenzierung für die Bereitstellung in mehreren 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. GKE führt neue Versionen schrittweise in der von Ihnen konfigurierten Sequenz ein. Wenn GKE die neue Version in Ihren Umgebungen bereitstellt, 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 Roll-out-Sequenzierung mit benutzerdefinierten Phasen. Mit dieser neueren Version der Roll-out-Sequenzierung können Sie den Roll-out einer neuen Version für 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 wird in derGoogle Cloud -Konsole umfassender unterstützt, 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 führen im Vergleich zu Patches derselben Nebenversion zu einer größeren Anzahl von Änderungen. Wir empfehlen, die Einführung von Upgrades auf Nebenversionen in Ihren Umgebungen besonders sorgfältig zu prüfen, 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 Clusterupgrades 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 Änderungsprotokoll 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 Upgrades auf Nebenversionen 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-Änderungsprotokoll und unter Einstellung von Features 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 zur GKE-Versionsabweichung.
  • Für Knotenupgrades:

Auslösen von Upgrades steuern

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 durchführen.

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. Verwenden Sie Tools wie Benachrichtigungen, Statistiken und Empfehlungen sowie Logs, um den Status Ihrer Cluster im Blick zu behalten. Wir empfehlen Ihnen, besonders auf Benachrichtigungen zum Ende des Supports, Benachrichtigungen zum Start von Upgrades und Benachrichtigungen zu geplanten Upgrades für Nebenversionen zu achten. Richten Sie Benachrichtigungsrichtlinien ein, damit Sie diese Benachrichtigungen sehen.

In den folgenden Ressourcen finden Sie Details zu aktuellen Upgrades:

Unterbrechungen bestehender Arbeitslasten während Knotenupgrades minimieren

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

Weitere Überlegungen zu bestimmten Arbeitslastprofilen

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 die folgenden zusätzlichen Überlegungen berücksichtigen:

  • Arbeitslasten, die auf Maschinen ausgeführt werden, die nicht live migriert werden: GKE-Knoten, also Compute Engine-Instanzen, die GKE für Sie erstellt, erfordern regelmäßig Wartungsarbeiten an 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 Knotenupgrades sicherstellen.
  • Zustandsorientierte Arbeitslasten: Wenn Ihre Arbeitslasten zustandsorientiert sind und bestimmte Anforderungen für das ordnungsgemäße Herunterfahren und Neustarten haben, sind bei Clusterupgrades 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 zum Aktualisieren dieser Arten von Arbeitslasten verwenden können.

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 Knotenupgrades und Sie müssen keine bestimmte Strategie 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 ausreichend Redundanz haben, 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 ein 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 mit ordnungsgemäßer Beendigung herunterfahren

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 die Nebenversion beibehalten möchten, sollten Sie den Cluster im erweiterten Kanal registrieren. In dieser Version unterstützt 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 dennoch die Upgrades von Nebenversionen 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. Prüfen Sie die folgenden unterstützten Szenarien sowie Wann der erweiterte Kanal nicht verwendet werden sollte.

Nebenversion vorübergehend länger beibehalten

Wenn Sie einen Cluster vorübergehend länger als den 14-monatigen Standard-Supportzeitraum auf einer Nebenversion belassen müssen, um beispielsweise die Verwendung von verworfenen APIs zu vermeiden, die in der nächsten Nebenversion entfernt werden, gehen Sie so vor: Sie können den Cluster vorübergehend von einem anderen Release-Kanal in einen 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 die ursprüngliche Release-Version.

Upgrades von Nebenversionen ein- oder zweimal pro Jahr

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 Nebenversionen mit 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 Nebenversion, die bald nicht mehr unterstützt wird. Das geschieht im Durchschnitt etwa alle vier Monate. Bei diesem Ansatz erhält der Cluster Upgrades von Nebenversionen genauso häufig wie bei anderen Release-Versionen, neue Funktionen werden jedoch später bereitgestellt.

Nächste Schritte