Best Practices für das Upgrade von Clustern

Auf dieser Seite finden Sie Best Practices, um Ihre GKE-Cluster (Google Kubernetes Engine) nahtlos auf dem neuesten Stand zu halten, sowie Empfehlungen zur Erstellung einer Upgradestrategie, die Ihren Anforderungen entspricht und die Verfügbarkeit und Zuverlässigkeit Ihrer Umgebungen erhöht. Mithilfe dieser Informationen können Sie Ihre Cluster bei minimalen Unterbrechungen auf dem aktuellen Stand halten, sodass sie stabil und sicher laufen.

Informationen zum Verwalten automatischer Clusterupgrades in Produktionsumgebungen, die mit Flotten organisiert sind, finden Sie unter Clusterupgrades mit Roll-out-Sequenzierung.

Mehrere Umgebungen einrichten

Im Rahmen Ihres Workflows zur Bereitstellung von Softwareupdates empfehlen wir die Verwendung mehrerer Umgebungen. In mehreren Umgebungen können Sie Risiken und unerwünschte Ausfallzeiten minimieren, indem Sie Software- und Infrastrukturupdates getrennt von Ihrer Produktionsumgebung testen. Sie sollten zumindest eine Produktionsumgebung und eine Vor- oder Testumgebung haben.

Folgende Umgebungen werden empfohlen:

Umgebung Beschreibung
Produktion Dient zur Bereitstellung von Live-Traffic für Endnutzer geschäftskritischer Geschäftsanwendungen.
Staging Wird verwendet, um sicherzustellen, dass alle neuen Änderungen aus vorherigen Umgebungen wie vorgesehen funktionieren, bevor die Änderungen in der Produktion bereitgestellt werden.
Test Wird für die Leistungsbenchmark, Test- und QA-Arbeitslasten mit dem GKE-Release verwendet, den Sie in der Produktion verwenden. In dieser Umgebung können Sie das Upgrade der Steuerungsebene und der Knoten testen, bevor Sie dies in der Produktion tun.
Entwicklung Wird für die aktive Entwicklung verwendet, die auf der in der Produktion ausgeführten Version basiert. In dieser Umgebung erstellen Sie Fehlerkorrekturen und inkrementelle Änderungen, die in der Produktion bereitgestellt werden.
Canary Wird als sekundäre Entwicklungsumgebung verwendet, um neuere Kubernetes-Versionen zu testen. Mit GKE-Features und APIs können Sie die Produkteinführungszeit verkürzen, sobald diese Releases als Standardversion übernommen wurden.

Cluster in Releasekanälen registrieren

Kubernetes veröffentlicht häufig Releaseupdates, um Sicherheitsupdates bereitzustellen, bekannte Probleme zu beheben und neue Features einzuführen. Mit GKE-Releasekanälen können Sie einen Ausgleich zwischen Stabilität und Feature-Set der im Cluster bereitgestellten Version erzielen. Wenn Sie einen neuen Cluster in einem Releasekanal registrieren, verwaltet Google automatisch die Version und aktualisiert den Rhythmus des Clusters und seiner Knotenpools.

Im Folgenden finden Sie einige empfohlene Umgebungen und die zugehörigen Releasekanäle, in denen Cluster registriert werden sollten, um sie mit den neuesten GKE- und Kubernetes-Updates auf dem neuesten Stand zu halten:

Umgebung Release-Version Beschreibung
Produktion Stable- oder Regular-Kanal Um Stabilität und Versionsreife zu erhalten, verwenden Sie den Stable- oder den Regular-Kanal für Produktionsarbeitslasten.
Staging Wie Produktion Verwenden Sie denselben Releasekanal wie die Produktion, damit Ihre Tests erkennen können, auf welche Version die Produktion aktualisiert wird.
Test
Entwicklung
Canary Rapid Verwenden Sie den Rapid Channel, um die neuesten Kubernetes-Versionen zu testen und der Kurve einen Schritt voraus zu sein, indem Sie neue GKE-Features oder APIs testen. Sie können die Produkteinführungszeit verkürzen, wenn die Version in Rapid auf die Version aktualisiert wird, die Sie für die Produktion verwenden.
– Erweitert Verwenden Sie den erweiterten Kanal, um Ihren Cluster länger auf einer Nebenversion zu halten und gleichzeitig weiterhin Sicherheitspatches nach dem Ende des Standardsupports zu erhalten. Weitere Informationen finden Sie unter Erweiterten Kanal für Langzeitsupport verwenden.

Cluster-Steuerungsebenen werden immer regelmäßig aktualisiert, unabhängig davon, ob Ihr Cluster in einer Release-Version registriert ist oder nicht.

Kontinuierliche Upgradestrategie erstellen

Nachdem Sie Ihren Cluster in einem Release-Kanal registriert haben, wird dieser Cluster regelmäßig auf die Version aktualisiert, die die Qualitäts- und Stabilitätsleiste des Kanals erfüllt. Diese Aktualisierungen umfassen Sicherheits- und Fehlerkorrekturen, die auf jedem Kanal mit zunehmender Genauigkeit angewendet werden:

  • Patches werden nach und nach auf die Steuerungsebene und die Knoten in allen Versionen übertragen, wodurch die Zeit bis zur Inbetriebnahme des Stable Channel für Rapid und Regular Channels aufgewendet wird.
  • Die Steuerungsebene wird zuerst aktualisiert, gefolgt von Knoten zur Einhaltung der Kubernetes OSS-Richtlinie. kubelet darf nicht neuer als kube-apiserver sein.
  • GKE führt automatisch Patches für Kanäle basierend darauf ein, wie wichtig oder kritisch sie sind.
  • Der Stable Channel erhält nur kritische Patches.

Updates zu neuen GKE-Versionen erhalten

Informationen zu neuen Versionen werden auf der Hauptseite der GKE-Versionshinweise sowie in einem RSS-Feed veröffentlicht. Jede Version hat eine vereinfachte und dedizierte Seite mit Versionshinweisen (z. B. Versionshinweise für den Stable Channel) mit Informationen zur empfohlenen GKE-Version für diesen Kanal.

Verwenden Sie Pub/Sub und abonnieren Sie Benachrichtigungen, um proaktiv Updates zu GKE-Upgrades zu erhalten, bevor die Upgrades erfolgen.

Sobald eine neue Version verfügbar ist, sollten Sie ein Upgrade planen, bevor die Version zur Standardversion auf Ihren Geräten wird. Dieser Ansatz ermöglicht bei Bedarf eine bessere Kontrolle und Planbarkeit, da GKE das automatische Upgrade für Cluster überspringen kann, die bereits vorab aktualisiert wurden.

Neue Patch- und Nebenversionen testen und prüfen

Alle Versionen durchlaufen interne Tests, unabhängig vom Kanal, in dem sie veröffentlicht wurden. Wir empfehlen jedoch dringend, häufige Aktualisierungen und Patches aus vorgelagerten Kubernetes-Releases und GKE zu testen, bevor Sie die Releases in Ihre Produktionsumgebung einführen, insbesondere Upgrades von Kubernetes-Nebenversionen.

Jeder Releasekanal bietet zwei Versionen: Standard und Verfügbar.

  • Neue Patchreleases sind eine Woche vor der Standardeinstellung verfügbar.
  • Neue Kubernetes-Nebenreleases sind vier Wochen vor der Standardeinstellung verfügbar.

GKE aktualisiert Cluster automatisch auf die Standardversion. Wenn Sie mehr Kontrolle über den Upgradeprozess haben möchten, empfehlen wir, ein Upgrade auf eine verfügbare Version durchzuführen. Automatische GKE-Upgrades überspringen manuell aktualisierte Cluster.

Ein empfohlener Ansatz zur Automatisierung und Optimierung von Upgrades würde Folgendes umfassen:

  • Eine Vorproduktionsumgebung, in der die verfügbare Version verwendet wird.
  • Upgrade-Benachrichtigungen, die im Cluster eingerichtet werden, um Ihr Team über neue verfügbare Versionen zum Testen und Zertifizieren zu informieren.
  • Eine Produktionsumgebung, die über die Standardversion für einen Releasekanal abonniert wurde.
  • Graduelle Einführung neuer verfügbarer Versionen für Produktionscluster. Wenn z. B. mehrere Produktionscluster vorhanden sind, beginnt ein gradueller Upgradeplan, bei dem ein Teil dieser Cluster auf die verfügbare Version aktualisiert wird, während die anderen in der Standardversion bleiben, gefolgt von zusätzlichen Teilupgrades, bis das Upgrade zu 100 % vollständig ist.

In der folgenden Tabelle sind die Releaseereignisse und die empfohlenen Aktionen zusammengefasst:

Ereignis Empfohlene Maßnahmen
Die neue Version X wird in einem Kanal verfügbar gemacht. Führen Sie ein manuelles Upgrade des Testclusters durch und qualifizieren und testen Sie die neue Version.
Version X wird zur Standardversion. GKE startet automatische Upgrades auf die Standardversion. Erwägen Sie ein Upgrade der Produktion vor dem Gerätepool.
GKE startet das automatische Upgrade der Cluster. Erlauben Sie Clustern den Erhalt automatischer Upgrades oder verschieben Sie das Upgrade mithilfe von Wartungsfenstern.

Upgradestrategie für Patchreleases

Dies ist eine empfohlene Upgradestrategie für Patchreleases unter Verwendung eines Szenarios, bei dem Folgendes gilt:

  • Alle Cluster haben den Stable Channel abonniert.
  • Neue verfügbare Versionen werden zuerst für den Staging-Cluster eingeführt.
  • Für den Produktionscluster wird automatisch ein Upgrade auf die neuen Standardversionen durchgeführt.
  • Neue verfügbare Versionen für GKE regelmäßig überwachen.
Zeit Ereignis Was soll ich tun?
T – 1 Woche Eine neue Patchversion ist verfügbar. Aktualisieren Sie die Staging-Umgebung.
T Patchversion wird zur Standardversion. Eventuell sollten Sie die Produktionssteuerungsebene im Voraus aktualisieren, um bessere Vorhersagen zu treffen.
T GKE beginnt mit dem Upgrade der Steuerungsebenen auf die Standardversion. Wir empfehlen Ihnen, schon bald die Produktionsknotenpools zu aktualisieren, um bessere Vorhersagen zu treffen.
T + 1 Woche GKE beginnt mit dem Upgrade von Clusterknotenpools auf die Standardversion. GKE führt automatisch Upgrades für Cluster aus, wobei die manuell aktualisierten Cluster übersprungen werden.

Upgradestrategie für neue Nebenversionen

Dies ist eine empfohlene Upgradestrategie für neue Nebenversionen:

Zeit Ereignis Was soll ich tun?
T – 3 Wochen Neue Nebenversion verfügbar Upgrade der Teststeuerungsebene
T – 2 Wochen
  1. Wenn das Upgrade der Steuerungsebene erfolgreich war, sollten Sie die Produktionssteuerungsebene im Voraus aktualisieren.
  2. Upgrade der Testknotenpools.
T – 1 Woche Führen Sie bei einem erfolgreichen Upgrade ein Upgrade der Produktionsknotenpools im Voraus aus.
T Nebenversion wird zur Standardversion.
T GKE beginnt mit dem Upgrade der Clustersteuerungsebenen auf die Standardversion. Erstellen Sie ein Ausschlussfenster, wenn vor der Produktionseinführung mehr Tests oder Maßnahmen zur Reduzierung erforderlich sind.
T + 1 Woche GKE beginnt mit dem Upgrade von Clusterknotenpools auf die Standardversion. GKE führt automatisch Upgrades für Cluster aus, wobei die manuell aktualisierten Cluster übersprungen werden.

Unterbrechungen bestehender Arbeitslasten während eines Upgrades reduzieren

Es ist wichtig, dass Sie Ihre Cluster mithilfe von Sicherheitspatches und Fehlerkorrekturen aktualisieren, um die Integrität Ihrer Cluster und die Geschäftskontinuität zu gewährleisten. Regelmäßige Updates schützen Ihre Arbeitslasten vor Sicherheitslücken und Fehlern.

Wartungsfenster und Ausschlüsse planen

Um die Zuverlässigkeit Ihrer Upgrades zu verbessern und Upgrades an Außendienstzeiten anzupassen, können Sie automatische Upgrades sowohl der Steuerungsebene als auch der Knoten durch Erstellen eines Wartungsfensters steuern. GKE berücksichtigt Wartungsfenster. Wenn der Upgradeprozess über das festgelegte Wartungsfenster hinaus ausgeführt wird, versucht GKE, den Vorgang zu unterbrechen und während des nächsten Wartungsfensters fortzusetzen.

GKE folgt einem mehrtägigen Rolloutzeitplan, um neue Versionen zur Verfügung zu stellen sowie automatische Steuerungsebenen und Knoten für Cluster in verschiedenen Regionen zu aktualisieren. Der Rollout geht in der Regel über vier oder mehr Tage und umfasst einen Zeitpuffer, um Probleme zu beobachten und zu überwachen. In einer Multi-Cluster-Umgebung können Sie für jeden Cluster ein separates Wartungsfenster verwenden, um das Rollout in allen Clustern zu sequenzieren. Sie können beispielsweise steuern, wann Cluster in verschiedenen Regionen Wartungsarbeiten erhalten, indem Sie für jeden Cluster unterschiedliche Wartungsfenster festlegen.

Ein weiteres Tool zur Reduzierung von Störungen, insbesondere in Zeiten hoher Nachfrage, sind Wartungsausschlüsse. Verwenden Sie Wartungsausschlüsse, um eine automatische Wartung während dieser Zeiträume zu verhindern. Wartungsausschlüsse können für neue oder vorhandene Cluster festgelegt werden. Sie können Ausschlüsse auch zusammen mit Ihrer Upgradestrategie verwenden. Beispielsweise kann es sinnvoll sein, ein Upgrade auf einen Produktionscluster zu verschieben, wenn eine Test- oder Staging-Umgebung aufgrund eines Upgrades fehlschlägt.

Toleranz für Unterbrechungen festlegen

Möglicherweise kennen Sie das Konzept der Replikate in Kubernetes. Replikate sorgen für Redundanz Ihrer Arbeitslasten, um Leistung und Reaktionsfähigkeit zu verbessern. Wenn dieses Flag festgelegt ist, wird die Anzahl der Pod-Replikate gesteuert, die zu einem bestimmten Zeitpunkt ausgeführt werden. Bei der Wartung entfernt Kubernetes jedoch die zugrunde liegenden Knoten-VMs, wodurch die Anzahl der Replikate reduziert werden kann. Damit Ihre Arbeitslasten auch während der Wartung eine ausreichende Anzahl von Replikaten haben, sollten Sie ein Budget für Pod-Störungen (PDB) verwenden.

In einem Budget für Pod-Störungen können Sie eine Anzahl (oder einen Prozentsatz) von Pods definieren, die beendet werden können, selbst wenn durch das Beenden der Pods die aktuelle Anzahl an Replikaten unter dem gewünschten Wert liegt. Durch diesen Vorgang kann das Entfernen von Knoten beschleunigt werden, da nicht mehr gewartet werden muss, bis die migrierten Pods voll funktionsfähig sind. Stattdessen werden Pods gemäß der PDB-Konfiguration von einem Knoten entfernt, damit durch das Deployment fehlende Pods auf anderen verfügbaren Knoten bereitgestellt werden können. Sobald das PDB festgelegt ist, fährt GKE keine Pods in der Anwendung herunter, wenn die Anzahl der Pods gleich oder unter einem konfigurierten Limit liegt. GKE folgt einem PDB bis zu 60 Minuten.

Upgrades von Knotenpools steuern

In GKE können Sie eine Strategie für das Upgrade des Knotens auswählen, um festzustellen, wie die Knoten in Ihren Knotenpools aktualisiert werden. Knotenpools verwenden standardmäßig Surge-Upgrades. Bei Surge-Upgrades muss für den Upgradeprozess für GKE-Knotenpools jede VM im Knotenpool neu erstellt werden. Bei einem Rolling Update wird eine neue VM mit der neuen Version erstellt. Dafür müssen Sie alle Pods, die auf dem alten Knoten ausgeführt werden, herunterfahren und die Pods auf den neuen Knoten verschieben. Ihre Arbeitslasten können mit ausreichender Redundanz (Replikaten) ausgeführt werden. Sie können sich auf Kubernetes verlassen, um Pods nach Bedarf zu verschieben und neu zu starten. Eine vorübergehend reduzierte Anzahl von Replikaten kann jedoch weiterhin zu Störungen für Ihr Unternehmen führen und die Leistung der Arbeitslast verlangsamen, bis Kubernetes wieder den gewünschten Zustand erreicht hat (d. h. die minimale Anzahl der benötigten Replikate erfüllt). Eine solche Unterbrechung können Sie mit Surge-Upgrades vermeiden.

Während eines Upgrades mit aktiviertem Surge-Upgrade sichert GKE zuerst die für das Upgrade erforderlichen Ressourcen (Maschinen), erstellt dann einen neuen aktualisierten Knoten und drosselt erst dann den alten Knoten und schaltet ihn schließlich ab. So bleibt die erwartete Kapazität während des Upgrades erhalten.

Bei großen Clustern, für die das Upgrade länger dauern kann, können Sie die Ausführungszeit für das Upgrade verkürzen. Aktualisieren Sie dazu jeweils mehrere Knoten gleichzeitig. Verwenden Sie Surge-Upgrade mit maxSurge=20, maxUnavailable=0, um GKE anzuweisen, 20 Knoten gleichzeitig zu aktualisieren, ohne vorhandene Kapazitäten zu verwenden.

Erweiterten Kanal für Langzeitsupport verwenden

Wenn Sie Ihren Cluster länger in einer Nebenversion behalten möchten, folgen Sie den Best Practices zur Registrierung Ihres Clusters für den erweiterten Kanal. Mit diesem Kanal unterstützt GKE eine Nebenversion für etwa 24 Monate. Weitere Informationen finden Sie unter Langzeitsupport mit dem erweiterten Kanal erhalten.

Befolgen Sie die folgenden Best Practices, um den Kanal optimal nutzen zu können. 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.

Vorübergehend länger in einer Nebenversion bleiben

Wenn Sie einen Cluster vorübergehend länger als den 14-monatigen Standardsupportzeitraum beibehalten müssen, um beispielsweise die Verwendung verworfener APIs zu minimieren, die in der nächsten Nebenversion entfernt wurden, führen Sie den folgenden Prozess aus: “ 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.

Nebenversionen werden ein- bis zweimal pro Jahr aktualisiert.

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 von Nebenversionen durch. Beispielsweise können Sie ein Upgrade von 1.30 auf 1.31 auf 1.32 ausführen.

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 Auswirkungen der Verwendung des erweiterten Kanals ohne aktive Verwaltung der Nebenversion des Clusters.

Nichts tun und Nebenversionsupgrades mit der gleichen 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. Letztendlich werden alle Nebenversionen nicht mehr unterstützt und GKE aktualisiert Cluster automatisch von nicht unterstützten Nebenversionen. GKE aktualisiert diesen Cluster daher von einer nicht unterstützten Nebenversion auf eine bald nicht unterstützte Nebenversion, die durchschnittlich etwa alle vier Monate beträgt. Dies bedeutet, dass der Cluster auf anderen Release-Versionen genauso häufig Upgrades für Nebenversionen erhält, später aber neue Features erhält.

Zusammenfassung der Checkliste

In der folgenden Tabelle sind die Aufgaben zusammengefasst, die für eine Upgradestrategie empfohlen werden, um Ihre GKE-Cluster nahtlos auf dem neuesten Stand zu halten:

Best Practice Aufgaben
Mehrere Umgebungen einrichten
Cluster in Releasekanälen registrieren
Kontinuierliche Upgradestrategie erstellen
Unterbrechungen bestehender Arbeitslasten reduzieren

Nächste Schritte