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.
Phase 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 Um Stabilität und Versionsreife zu erhalten, verwenden Sie den Stable Channel oder den Regular Channel für Produktionsarbeitslasten.
Phase 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.

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 Richtlinie Kubernetes OSS (d. h. kubelet darf nicht höher 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.

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 Tasks
Mehrere Umgebungen einrichten
Cluster in Releasekanälen registrieren
Kontinuierliche Upgradestrategie erstellen
Unterbrechungen bestehender Arbeitslasten reduzieren

Nächste Schritte