Best Practices für GKE-Clusterupgrades

In diesem Dokument finden Plattformadministratoren Best Practices für die Verwaltung von Google Kubernetes Engine-Cluster-Upgrades (GKE). Standardmäßig aktualisiert GKE die Version der Steuerungsebene und der Knoten Ihres Clusters automatisch, um neue Funktionen, Fehlerkorrekturen und Sicherheitspatches bereitzustellen, damit Ihre Umgebung leistungsfähig und sicher bleibt.

Damit diese automatischen Upgrades Ihren betrieblichen Anforderungen entsprechen und Unterbrechungen der Arbeitslast minimiert werden, bietet GKE Tools, mit denen Sie maximale Kontrolle haben. 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-Cluster upgraden.

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 über alle GKE-Best Practices 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 Cluster-Upgrades vorbereiten.

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

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

Mit Release-Kanälen 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 erhalten möchten, können Sie den Rapid Channel auswählen. Wenn Sie Versionen mit mehr nachgewiesener Stabilität bevorzugen, wählen Sie den Stable Channel aus. Weitere Informationen zur Auswahl zwischen bestimmten Channels finden Sie unter Welche Channels 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 einem Release-Channel 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 Unterstützung für eine Nebenversion, nachdem die Version im Regular channel zur Verfügung gestellt wurde. Dieser Support umfasst 14 Monate Standardsupport und etwa 10 Monate erweiterten Support, der mit dem Extended-Kanal verfügbar ist. Weitere Informationen dazu, wie GKE eine Nebenversion unterstützt, finden Sie unter Support für Nebenversionen.

Wenn Sie Ihren Cluster länger auf einer Nebenversion belassen und nach dem Ende des Standardsupports weiterhin Sicherheitspatches erhalten möchten oder die Durchsetzung des Endes des Standardsupports verhindern möchten, können Sie auch den Extended Channel verwenden. Weitere Informationen finden Sie weiter unten im Abschnitt Erweiterten Kanal für Langzeitsupport verwenden.

Wenn die Nebenversion das Ende des Supports erreicht, führt GKE je nach Release-Kanal, für den 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 GKE automatisch ein Upgrade Ihres Clusters durch.

Zeitpunkt von Upgrades mit Wartungsrichtlinien festlegen

Mit den folgenden Optionen können Sie festlegen, wann Upgrades möglich sind und wann nicht:

  • Wartungsfenster: Wählen Sie einen wiederkehrenden Zeitraum aus, in dem GKE Ihren Cluster aktualisieren kann, z. B. außerhalb der Hauptgeschäftszeiten. Wenn der Upgradeprozess über das Wartungsfenster hinaus ausgeführt wird, versucht GKE, den Vorgang zu unterbrechen und während des nächsten Wartungsfensters 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.
    • In komplexen Anwendungsfällen müssen Sie möglicherweise bestimmte Arten von Upgrades manuell durchfü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 durchführen oder GKE führt Upgrades Ihrer Cluster am Ende des Supports für die Nebenversion durch.
  • Wartungshäufigkeit: Bei erweiterten Anwendungsfällen können Sie das Mindestintervall zwischen zwei aufeinanderfolgenden automatischen Upgrades mit dem Budget für Clusterunterbrechungen steuern.

Durch das Konfigurieren von Wartungsrichtlinien können Sie die Vorhersagbarkeit von Upgrades erhöhen und dafür sorgen, dass Upgrades zu einem für Ihre Arbeitslasten optimalen Zeitpunkt erfolgen.

Roll-out von Upgrades für Cluster steuern

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

Folgende Umgebungen werden empfohlen:

Umgebung Beschreibung
Produktion Live-Traffic für Endnutzer geschäftskritischer Geschäftsanwendungen bereitstellen
Canary Testen Sie einen kleinen Teil der Produktionsumgebung, bevor alle Cluster aktualisiert werden.
Staging Prüfen Sie, ob alle neuen Änderungen aus vorherigen Umgebungen 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.
Entwicklung Verwenden Sie für die aktive Entwicklung dieselbe Version, die in der Produktion ausgeführt wird. In dieser Umgebung erstellen Sie Fehlerkorrekturen und inkrementelle Änderungen, die in der Produktion bereitgestellt werden.

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 Roll-outs in verschiedenen Umgebungen verwenden

Wenn Sie neue GKE-Versionen schrittweise in diesen Umgebungen einführen möchten, empfehlen wir die Verwendung von Rollout-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 die neue Version in GKE in Ihren Umgebungen eingeführt wird, können Sie prüfen, ob Ihre Clusterumgebung und Arbeitslasten wie erwartet mit der neuen Version ausgeführt werden.

Wenn Sie eine neue Umgebung konfigurieren, verwenden Sie die Roll-out-Sequenzierung mit benutzerdefinierten Phasen (Vorschau). Mit dieser neueren Version der Roll-out-Sequenz können Sie den Roll-out einer neuen Version für eine Flotte in mehrere Phasen unterteilen. Mit diesem Ansatz kann GKE beispielsweise eine Canary-Umgebung in der Produktion aktualisieren, bevor der Rest der Produktion aktualisiert wird. Eine allgemein verfügbare Version der Funktion, die ein lineareres Modell ohne benutzerdefinierte Phasen verwendet, finden Sie unter Cluster-Upgrades mit Rollout-Sequenzierung.

GKE-Patch- und Nebenversions-Upgrades testen

GKE aktualisiert Cluster automatisch auf einen neuen Patch, in der Regel wöchentlich. Nebenversions-Upgrades erfolgen jedoch nur etwa dreimal pro Jahr. Neue Kubernetes-Nebenversionen enthalten mehr Änderungen als Patches derselben Nebenversion. Wir empfehlen, die Einführung von Nebenversions-Upgrades in Ihren Umgebungen besonders sorgfältig zu überwachen, 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 Cluster-Upgrades empfehlen wir Folgendes:

  • Für alle Upgrades, einschließlich Patch- und Nebenversionsupgrades:
    • In den GKE-Versionshinweisen finden Sie Informationen zu Problemen und das Changelog 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.
  • Bei Nebenversions-Upgrades sollten Sie zusätzlich Folgendes beachten:
    • 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 als die Steuerungsebene sind. Weitere Informationen finden Sie unter Richtlinie zur Versionsabweichung in GKE.
  • Für Knotenupgrades:

Steuern, wie Upgrades ausgelöst werden

Standardmäßig aktualisiert GKE Cluster regelmäßig automatisch auf neue Versionen. Sie können jedoch auch manuelle Upgrades verwenden, um Ihren Cluster genau dann zu aktualisieren, wenn Sie es 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

  • Führen Sie Aktionen für laufende automatische oder manuelle Knotenupgrades aus, darunter die folgenden:

    • Upgrade abbrechen
    • Upgrade fortsetzen
    • Rollback eines Upgrade durchführen
    • Schließen Sie ein laufendes Upgrade ab.

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, können Sie die folgenden Tools verwenden, um Cluster-Upgrades zu beobachten. Mit Tools wie Benachrichtigungen, Statistiken und Empfehlungen sowie Protokollen können Sie den Status Ihrer Cluster im Blick behalten. Wir empfehlen Ihnen, insbesondere auf Benachrichtigungen zum Ende des Supports, Benachrichtigungen zum Beginn von Upgrades und Benachrichtigungen zu geplanten Upgrades für Nebenversionen zu achten. Richten Sie Benachrichtigungsrichtlinien ein, damit Sie diese Benachrichtigungen erhalten.

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

Für bestimmte Arten von Arbeitslasten und Clusterumgebungen sind zusätzliche Vorbereitungen für Clusterupgrades erforderlich. 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 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. Wichtig ist, dass Beschleuniger wie GPUs und TPUs für KI‑/ML-Arbeitslasten nicht live migriert werden können. Weitere Informationen finden Sie unter Unterbrechungen von GKE-Knoten verwalten, die nicht live migriert werden.
  • Arbeitslasten mit Kapazitätsbeschränkungen: Wenn für Ihre Arbeitslasten Maschinentypen mit Kapazitätsbeschränkungen verwendet werden, 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 der Durchführung von 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 das Knotenupgrade, mit denen festgelegt wird, wie die einzelnen Knoten in Ihrem Knotenpool aktualisiert werden. Durch Auswahl einer Upgradestrategie für Ihren Standardknotenpool können Sie den Prozess mit dem richtigen Verhältnis von Geschwindigkeit, Arbeitslastunterbrechung, Risikominderung und Kostenoptimierung auswählen. Sie können die Parameter der Strategie auch so konfigurieren, dass sie Ihren Anforderungen am besten entsprechen. Im GKE Autopilot-Modus verwaltet GKE die Knotenupgrades und Sie müssen die verwendete Strategie nicht auswählen. Weitere Informationen finden Sie unter Strategien für das Knotenupgrade.

Toleranz für Unterbrechungen festlegen

Verwenden Sie Budgets für Pod-Störungen (Pod Disruption Budgets, PDBs), um dafür zu sorgen, dass Ihre Arbeitslasten ausreichend redundant sind, wenn GKE die Knoten während Upgrades neu erstellt. Dadurch kann die Anzahl der Replikate für eine Arbeitslast vorübergehend reduziert werden.

Wenn ein PDB festgelegt ist, fährt GKE keine Pods in der Anwendung herunter, wenn die Anzahl der Pods gleich oder unter einem konfigurierten Limit liegt. Bei GKE-Upgrades wird ein PDB bis zu 60 Minuten lang berücksichtigt. 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 erzwungen 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 bei den standardmäßigen Surge-Upgrades und bis zu 24 Stunden bei Blau/Grün-Upgrades und automatisch skalierten Blau/Grün-Upgrades (Vorschau).

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 eine Nebenversion länger beibehalten möchten, sollten Sie Ihren Cluster im erweiterten Kanal registrieren. In diesem Channel wird eine Nebenversion von GKE etwa 24 Monate lang unterstützt. Mit dem Extended Channel steuern Sie Upgrades von Nebenversionen. GKE führt nur 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 nicht länger als den standardmäßigen Supportzeitraum auf einer Nebenversion bleiben müssen, aber trotzdem Nebenversionsupgrades steuern möchten, verwenden Sie stattdessen Wartungsausschlüsse mit dem Bereich „Keine Nebenversionsupgrades“.

Damit Sie den größtmöglichen Nutzen aus dem Channel ziehen, 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-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 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- bis zweimal pro Jahr zwei aufeinanderfolgende Upgrades auf die nächste Nebenversion 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. Im folgenden Szenario werden die Folgen der Verwendung des Extended Channel ohne aktive Verwaltung der Nebenversion Ihres Clusters veranschaulicht.

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 führt automatisch Upgrades von Clustern mit nicht unterstützten Nebenversionen durch. GKE führt also ein Upgrade dieses Clusters von einer nicht unterstützten Nebenversion auf eine bald nicht mehr unterstützte Nebenversion durch, was im Durchschnitt etwa alle vier Monate geschieht. Bei diesem Ansatz erhält der Cluster genauso häufig Upgrades von Nebenversionen wie bei anderen Release-Channels, neue Funktionen jedoch später.

Nächste Schritte