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.

Mehrere Umgebungen einrichten

Im Rahmen Ihres Workflows zur Bereitstellung von Softwareupdates empfehlen wir die Verwendung mehrerer Umgebungen. Mit mehreren Umgebungen können Sie Risiken und unerwünschte Ausfallzeiten minimieren, da Sie Software- und Infrastrukturupdates getrennt von Ihrer Produktionsumgebung testen können. Sie sollten mindestens eine Produktionsumgebung und eine Vorproduktions- 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 das Leistungsbenchmarking, Testen und die Qualitätssicherung der 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.

Kontinuierliche Upgradestrategie erstellen

Nachdem Sie Ihren Cluster in einem Releasekanal registriert haben, wird dieser Cluster regelmäßig auf die Version aktualisiert, die die Meßlatte an Qualität und Stabilität 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. Jeder Releasekanal hat eine vereinfachte und dedizierte Seite mit Versionshinweisen (z. B. Versionshinweise für Stable Channel) mit Informationen zur empfohlenen GKE-Version für diesen Kanal.

Damit Sie Updates zu GKE-Upgrades proaktiv erhalten, empfehlen wir die folgenden Methoden:

  1. Verwenden Sie die Kubernetes Engine API, um einen Upgrade-Workflow zu orchestrieren, wenn für Ihre Cluster ein Upgrade erforderlich ist.
  2. Verwenden Sie Pub/Sub und abonnieren Sie Benachrichtigungen für Upgrades, bevor die Upgrades erfolgen.

Sobald eine neue Version verfügbar ist, sollten Sie ein Upgrade planen, bevor die Version als Standard übernommen 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 (Beispielskript).
Zeit Ereignis Was soll ich tun?
T – 1 Woche Eine neue Patchversion ist verfügbar. Staging-Umgebung aktualisieren.
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 auf dem aktuellen Stand halten, 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 Planbarkeit Ihrer Upgrades zu verbessern und Upgrades an Zeiten außerhalb der Geschäftszeiten 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 den Vorgang während des nächsten Wartungsfensters fortzusetzen.

Das GKE-Rollout folgt einem viertägigen Zeitplan, der das Rollout auf vier Werktage verteilt und die Cluster in verschiedenen Regionen schrittweise aktualisiert. In einer Umgebung mit mehreren Clustern können Sie das viertägige Rollout verwenden, um Änderungen vorherzusagen, die geografisch auf verschiedene Regionen angewendet werden. Darüber hinaus können Sie Wartungsfenster verwenden, um die Ausfallverteilung in verschiedenen Clustern zu steuern und zu sequenzieren. Sie können beispielsweise steuern, wann Cluster in verschiedenen Regionen Wartungsarbeiten erhalten. Dazu legen Sie für jeden Cluster unterschiedliche Wartungsfenster fest.

Ein weiteres Tool zur Reduzierung von Unterbrechungen, insbesondere zu Zeiten hoher Nachfrage, sind Wartungsausschlüsse. Verwenden Sie Wartungsausschlüsse, um eine automatische Wartung während dieser Zeiten 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 für 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. Falls diese Option festgelegt ist, steuern Replikate die Anzahl der Pod-Replikate, die zu einer bestimmten Zeit 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 für Ihre Anwendungen haben, sollten Sie ein Pod-Unterbrechungsbudget (PDB) verwenden.

In einem Pod-Unterbrechungsbudget 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

Beim Upgradeprozess für GKE-Knotenpools wird jede VM im Knotenpool neu erstellt. Im Rahmen eines Rolling Updates wird eine neue VM mit der neuen Version (aktualisiertes Image) 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 Unterbrechungen für Ihr Unternehmen führen und die Arbeitslastleistung beeinträchtigen, bis Kubernetes den gewünschten Zustand wieder erreicht (d. h. die Mindestanzahl der erforderlichen Replikate). Eine solche Unterbrechung können Sie mit Surge-Upgrades vermeiden.

Während eines Upgrades bei aktiviertem Surge-Upgrade sichert GKE zuerst die für das Upgrade erforderlichen Ressourcen (Maschinen), erstellt dann einen neuen aktualisierten Knoten und entfernt erst dann den alten Knoten und fährt schließlich herunter. 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