In diesem Dokument wird beschrieben, wie Sie Upgrades in einer GKE-Multi-Cluster-Umgebung (Google Kubernetes Engine) entwerfen, planen und implementieren. Obwohl in diesem Dokument Multi-Cluster-Ingress für Upgrades verwendet wird, können die Konzepte auf andere Lösungen angewendet werden. Dieses Dokument richtet sich an Google Cloud Administratoren, die für die Verwaltung von Flotten für GKE-Cluster verantwortlich sind.
Verwaltung des GKE-Clusterlebenszyklus
Die Verwaltung des Clusterlebenszyklus kann als die Strategien und Planungen definiert werden, die für den Betrieb einer fehlerfreien und aktualisierten Flotte von Kubernetes-Clustern erforderlich sind, ohne dass Dienst-SLOs verletzt werden. Mit den richtigen Strategien und Planungen sollte die Verwaltung des Clusterlebenszyklus routinemäßig, erwartungsgemäß und ereignislos ablaufen.
Weitere Informationen zur Verwaltung der GKE-Version eines Clusters finden Sie unter GKE-GKE-ClusterClusterupgrades. Weitere Informationen zum Verwalten aller Arten von Änderungen während des Lebenszyklus eines Clusters finden Sie unter Clusterlebenszyklusänderungen verwalten, um Unterbrechungen zu minimieren.
Verwaltung des Multi-Cluster-Lebenszyklus in GKE
In diesem Abschnitt werden verschiedene Verwaltungsstrategien für den Multi-Cluster-Lebenszyklus in GKE und deren Planung beschrieben.
Planung und Design
Die GKE-Multi-Cluster-Architektur spielt eine Rolle bei der Auswahl einer Strategie für die Verwaltung des Clusterlebenszyklus. Bevor wir auf diese Strategien eingehen können, müssen bestimmte Designentscheidungen erörtert werden, die sich auf die Verwaltungsstrategie für den Clusterlebenszyklus auswirken oder davon betroffen sein können.
Clustertyp
Wenn Sie automatische GKE-Upgrades als Verwaltungsstrategie für den Clusterlebenszyklus verwenden, kann der Typ des Clusters eine Rolle spielen. Regionale Cluster haben beispielsweise mehrere Steuerungsebenenknoten, die automatisch nacheinander aktualisiert werden. Zonale Cluster haben wiederum einen einzelnen Steuerungsebenenknoten. Sollten Sie keine automatischen GKE-Upgrades verwenden und alle Kubernetes-Cluster als entfernbare Infrastruktur erachten, spielt es möglicherweise keine Rolle, welchen Clustertyp Sie auswählen, wenn Sie sich für eine Verwaltungsstrategie für den Clusterlebenszyklus entscheiden. Sie können die im Abschnitt Verwaltung des GKE-Multi-Cluster-Lebenszyklus beschriebenen Strategien auf jeden Clustertyp anwenden.
Clusterplatzierung und -anzahl
Berücksichtigen Sie die folgenden Faktoren, wenn Sie sich bezüglich der Clusterplatzierung und -anzahl entscheiden:
- Zonen und Regionen, in denen sich Cluster befinden müssen
- Anzahl und Größe der benötigten Cluster
Der erste Faktor ist in der Regel leicht zu berücksichtigen, da die Zonen und Regionen von Ihrem Unternehmen und den Regionen bestimmt werden, in denen Sie Ihre Nutzer bedienen.
Die Berücksichtigung der Anzahl und Größe von Clustern fällt normalerweise in die folgenden Kategorien, die jeweils Vor- und Nachteile haben:
- Geringe Anzahl großer Cluster: Sie können die Redundanz und Ausfallsicherheit von regionalen Clustern nutzen und einen oder zwei große regionale Cluster pro Region platzieren. Dieser Ansatz erzeugt einen geringen operativen Aufwand bei der Verwaltung mehrerer Cluster. Der Nachteil ist, dass aufgrund des großen Wirkungsbereichs viele Dienste gleichzeitig betroffen sein können.
- Große Anzahl kleiner Cluster: Sie können eine große Anzahl kleiner Cluster erstellen, um den Wirkungsbereich des Clusters zu reduzieren, da Ihre Dienste auf viele Cluster verteilt sind. Dieser Ansatz eignet sich auch für kurzlebige sitzungsspezifische Cluster, z. B. Cluster, die eine Batcharbeitslast ausführen. Der Nachteil dieses Ansatzes ist ein höherer operativer Aufwand, da es mehr Cluster gibt, für die ein Upgrade durchgeführt werden muss. Für eine höhere Anzahl von Steuerungsebenenknoten können zusätzliche Kosten anfallen. Sie können die Kosten und den hohen operativen Aufwand durch Automatisierung, eine vorausschauende Planung und Strategie sowie eine sorgfältige Koordination zwischen den betroffenen Teams und Diensten kompensieren.
In diesem Dokument wird kein Ansatz gegenüber dem anderen bevorzugt. Es sollen lediglich Optionen vorgestellt werden. In einigen Fällen können Sie beide Designmuster für verschiedene Dienstkategorien auswählen.
Die folgenden Strategien funktionieren bei beiden Designs.
Kapazitätsplanung
Bei der Kapazitätsplanung ist es wichtig, die ausgewählte Strategie für den Clusterlebenszyklus zu berücksichtigen. Die folgenden üblichen Dienstlast- und Wartungsereignisse müssen bei der Kapazitätsplanung berücksichtigt werden:
- Geplante Ereignisse wie Clusterupgrades
- Ungeplante Ereignisse wie Clusterausfälle, z. B. fehlerhafte Konfigurationsübertragungen und Rollouts
Bei der Kapazitätsplanung müssen alle Gesamt- oder Teilausfälle berücksichtigt werden. Wenn Sie das Design nur auf geplante Wartungsereignisse ausrichten, müssen alle verteilten Services einen zusätzlichen Cluster haben, damit Sie jeweils einen Cluster aus der Rotation herausnehmen und so mehrere Upgrades ausführen können, ohne die Leistung des Dienstes zu verschlechtern. Dieser Ansatz wird auch als N+1-Kapazitätsplanung bezeichnet. Wenn Sie das Design auf geplante und ungeplante Wartungsereignisse ausrichten, müssen alle verteilten Dienste zwei (oder mehr) zusätzliche Cluster haben, um die erforderliche Kapazität zu erreichen: einen für das geplante Ereignis und einen für ein nicht geplantes Ereignis, falls es während des geplanten Wartungsfensters auftritt. Dieser Ansatz wird auch als N+2-Kapazitätsplanung bezeichnet.
In Multi-Cluster-Architekturen werden häufig die Begriffe Draining und Spilling verwendet. Diese Begriffe beziehen sich auf das Entfernen (Draining) des Traffics aus einem Cluster und das Weiterleiten (Spilling) des Traffics zu anderen Clustern während Upgrade- und Wartungsereignissen. Dieser Vorgang erfolgt mithilfe von Netzwerklösungen wie Multi-Cluster-Ingress oder anderen Load-Balancing-Methoden. Die umsichtige Nutzung von Draining und Spilling ist ein zentraler Bestandteil der Verwaltungsstrategien für den Clusterlebenszyklus. Wenn Sie die Kapazität planen, sollten Sie Draining- und Spilling-Vorgänge berücksichtigen. Wenn z. B. ein einzelner Cluster per Drain beendet wird, müssen Sie prüfen, ob die anderen Cluster über genügend Kapazitäten verfügen, um den zusätzlichen weitergeleiteten Traffic zu verarbeiten. Darüber hinaus sollten Sie für eine ausreichende Kapazität in der Zone oder Region sorgen und sich überlegen, ob Traffic an eine andere Region gesendet werden soll (wenn ein einzelner regionaler Cluster pro Region verwendet wird). Das folgende Diagramm zeigt, dass Traffic aus einem Cluster entfernt (auch als „Draining“ bezeichnet) und an einen anderen Cluster gesendet wird, der denselben verteilten Dienst ausführt.
Cluster und verteilte Services
Das service-basierte Clusterdesign legt fest, dass die Clusterarchitektur (Anzahl, Größe und Standort) von den Services bestimmt wird, die zur Ausführung in den Clustern erforderlich sind. Daher hängt die Platzierung Ihrer Cluster davon ab, wo die verteilten Services benötigt werden. Berücksichtigen Sie bei der Wahl der Platzierung verteilter Services Folgendes:
- Standortanforderung: Über welche Regionen muss der Service bereitgestellt werden?
- Wichtigkeit: Wie wichtig ist die Verfügbarkeit eines Service für das Unternehmen?
- SLO: Welche Service Level Objectives gibt es für den Dienst (normalerweise abhängig von der Wichtigkeit)?
- Ausfallsicherheit: Wie robust muss der Service sein? Muss er Cluster-, Zonen- oder sogar Regionsausfällen standhalten?
Bei der Planung von Clusterupgrades müssen Sie die Anzahl der Services berücksichtigen, auf die sich ein einzelner Cluster auswirkt, wenn er entfernt wird. Beachten Sie auch, dass diese Services zu anderen geeigneten Clustern weitergeleitet werden müssen. Cluster können einen oder mehrere Mandanten umfassen. Cluster mit einem einzigen Mandanten stellen nur einen einzigen Service oder ein Produkt bereit, das durch eine Reihe von Services repräsentiert wird. Diese Cluster teilen den Cluster nicht mit anderen Services oder Produkten. Mehrmandantenfähige Cluster können viele Services und Produkte ausführen, die normalerweise in Namespaces partitioniert sind.
Auswirkungen auf Teams
Ein Clusterereignis wirkt sich nicht nur auf Services aus, sondern kann auch Auswirkungen auf Teams haben. Beispielsweise muss das DevOps-Team während eines Clusterupgrades möglicherweise seine CI/CD-Pipelines weiterleiten oder anhalten. Ebenso können Supportteams über geplante Ausfälle benachrichtigt werden. Automatisierung und Tools müssen vorhanden sein, um die Auswirkungen auf mehrere Teams zu verringern. Ein Cluster- oder Clusterflottenupgrade sollte als routinemäßig und ereignislos erachtet werden, wenn alle Teams darüber benachrichtigt werden.
Timing, Planung und Koordination
Kubernetes veröffentlicht vierteljährlich eine neue Nebenversion und wartet die letzten drei Versionen. Sie sollten das Timing von Clusterupgrades sorgfältig planen. Eine Vereinbarung darüber, wann diese Upgrades durchgeführt werden, muss zwischen den Dienstinhabern, Dienstoperatoren und Plattformadministratoren festgelegt sein. Berücksichtigen Sie bei der Planung von Upgrades die folgenden Fragen:
- Wie häufig führen Sie ein Upgrade aus? Führen Sie Upgrades quartalsweise oder gemäß einem anderen Zeitplan durch?
- Wann erfolgt das Upgrade? Führen Sie das Upgrade zu Beginn des Quartals durch, wenn sich die Geschäftsabläufe verlangsamen, oder während anderer Betriebsunterbrechungen, die von Ihrer Branche bestimmt werden?
- Wann sollten Sie kein Upgrade durchführen? Haben Sie eine klare Planung für ungeeignete Zeitpunkte für Upgrades? Vermeiden Sie beispielsweise Spitzenereignisse wie Black Friday, Cyber Monday oder wichtige Konferenzen und andere branchenspezifische Veranstaltungen?
Es ist wichtig, eine Strategie zu haben, die klar mit den Service-Inhabern sowie den operativen Teams und dem Supportteam kommuniziert wird. Es sollte keine Überraschungen geben und jeder sollte wissen, wann und wie Upgrades der Cluster durchgeführt werden. Dies erfordert eine klare Koordination mit allen beteiligten Teams. Es sind mehrere Teams, die mit einem einzelnen Service interagieren. In der Regel können diese Teams in folgende Kategorien eingeteilt werden:
- Der Service-Entwickler, der für das Erstellen und Codieren der Geschäftslogik in einen Service verantwortlich ist.
- Der Service-Operator, der für die sichere und zuverlässige Ausführung des Service verantwortlich ist. Diese Operatoren können sich aus mehreren unterschiedlichen Teams wie den Richtlinien- oder Sicherheitsadministratoren, den Netzwerkadministratoren und den Supportteams zusammensetzen.
Während Clusterupgrades muss jeder mit dem anderen kommunizieren, damit er in diesem Zeitraum geeignete Maßnahmen ergreifen kann. Ein möglicher Ansatz ist, Upgrades auf die gleiche Weise wie für ein Ausfallereignis zu planen. Sie haben einen Incident Commander, einen Chatroom und einen Aufarbeitungsprozess, auch wenn keine Nutzer betroffen sind. Weitere Informationen finden Sie unter Reaktion auf Vorfälle.
Strategien für den GKE-Clusterlebenszyklus
In diesem Abschnitt werden die wichtigsten Verwaltungsstrategien für den Clusterlebenszyklus beschrieben, die häufig in der GKE-Multi-Cluster-Architektur verwendet werden. Dabei ist zu beachten, dass eine Strategie nicht für alle Szenarien funktioniert und Sie möglicherweise mehrere Strategien für verschiedene Dienstkategorien und Geschäftsanforderungen auswählen müssen.
Rolling Updates
Das folgende Diagramm zeigt die Strategie für Rolling Updates.
Mit einem Load-Balancer wird der gesamte Traffic aus einem GKE-Cluster entfernt und es wird ein Clusterupgrade durchgeführt. Die entfernte Trafficlast wird an einen anderen GKE-Cluster weitergeleitet.
Rolling Updates sind die einfachste und kostengünstigste Wahl unter den in diesem Dokument beschriebenen Strategien. Sie beginnen mit n Clustern, in denen die Version old_ver (oder die aktuelle Produktionsversion) ausgeführt wird. Sie entfernen anschließend jeweils m Cluster auf einmal, wobei m kleiner als n ist. Anschließend löschen und erstellen Sie neue Cluster mit der neuen Version oder upgraden die entfernten Cluster.
Die Entscheidung, ob neue Cluster gelöscht werden oder ein Upgrade für sie durchgeführt wird, hängt von der Größe der Cluster sowie davon ab, ob die Cluster eine unveränderliche Infrastruktur bilden sollen. Bei einer unveränderlichen Infrastruktur werden nicht fortwährend Clusterupgrades durchgeführt, da es sonst im Laufe der Zeit zu unerwünschten Ergebnissen kommen könnte. Stattdessen erstellen Sie neue Cluster und vermeiden unvorhergesehene Konfigurationsabweichungen.
Wenn Sie GKE verwenden, können Sie einen GKE-Cluster mit einem einzigen Befehl oder einem API-Aufruf erstellen. Für eine neue Clusterstrategie muss die gesamte Clusterkonfiguration (Clustermanifeste) außerhalb des Clusters gespeichert werden, üblicherweise in Git. Sie können dann dieselbe Konfigurationsvorlage für den neuen Cluster verwenden. Bei einem neuen Cluster sollten Sie darauf achten, dass Ihre CI/CD-Pipelines auf den richtigen Cluster verweisen. Nachdem der Cluster ordnungsgemäß konfiguriert wurde, können Sie den Traffic langsam wieder zurück in den Cluster übertragen, während Sie die SLOs für die Services im Blick behalten.
Der Vorgang wird für alle Cluster wiederholt. Abhängig von Ihrer Kapazitätsplanung können Sie Upgrades für mehrere Cluster gleichzeitig durchführen, ohne Service-SLOs zu verletzen.
Wenn Sie Einfachheit und Erschwinglichkeit gegenüber Ausfallsicherheit vorziehen, verwenden Sie die Strategie mit Rolling Updates. Bei dieser Strategie wird die erforderliche Kapazität der GKE-Flotte für alle verteilten Dienste nicht überschritten.
Im folgenden Diagramm werden der Zeitplan und die erforderliche Service-Kapazität während eines GKE-Clusterupgrades in einer Multi-Cluster-Architektur verglichen.
Das obige Diagramm zeigt, dass die Kapazität zur Unterstützung der Dienste während des GKE-Upgradeprozesses nie unter den Anforderungen liegt. Wenn der zu aktualisierende GKE-Cluster aus der Rotation entfernt wird, werden die anderen Cluster vertikal skaliert, damit sie die Last unterstützen.
Blau/Grün-Upgrades
Das folgende Diagramm zeigt eine Blau/Grün-Upgradestrategie.
Im vorherigen Diagramm wird ein neuer GKE-Cluster hinzugefügt, in dem die neue Version ausgeführt wird. Dann wird ein Load-Balancer verwendet, um Traffic an den neuen Cluster zu senden und gleichzeitig einen der alten Cluster langsam per Drain zu beenden, bis kein Traffic an ihn gesendet wird. Der vollständig per Drain beendete alte Cluster kann dann entfernt werden. Für die verbleibenden Cluster kann derselbe Vorgang ausgeführt werden.
Die Blau/Grün-Upgradestrategie bietet zusätzliche Ausfallsicherheit.
Diese Strategie ähnelt einem Rolling Update, ist jedoch teurer. Der einzige Unterschied besteht darin, dass Sie nicht zuerst vorhandene Cluster entfernen, sondern erst einmal m neue Cluster mit der Version erstellen, wobei m kleiner oder gleich n ist. Sie fügen die neuen Cluster in die CI/CD-Pipelines ein und leiten dann den Traffic während der Überwachung der Service-SLOs langsam weiter. Wenn die neuen Cluster den gesamten Traffic übernehmen, entfernen und löschen Sie die Cluster mit der älteren Version.
Die Blau/Grün-Strategie für das Upgrade von Clustern entspricht einer Blau/Grün-Strategie, die normalerweise für Services verwendet wird. Wenn Sie mehrere neue Cluster gleichzeitig erstellen, steigen zwar die Gesamtkosten, aber Sie können die Zeit für das Upgrade der Flotte verkürzen. Die zusätzlichen Kosten gelten nur für die Dauer des Upgrades, wenn zusätzliche Cluster verwendet werden. Der Vorteil der Erstellung neuer Cluster besteht erst einmal darin, dass bei einem Ausfall ein Rollback durchgeführt werden kann. Sie können den neuen Cluster auch testen, bevor Sie Produktionstraffic an ihn senden. Da diese Cluster und ihre alten Versionen nur für einen kurzen Zeitraum nebeneinander bestehen, sind die zusätzlichen Kosten minimal.
Wenn Sie Wert auf Einfachheit und Ausfallsicherheit statt auf Erschwinglichkeit legen, verwenden Sie die Blau/Grün-Upgradestrategie. Weitere Cluster werden zuerst hinzugefügt und überschreiten die erforderliche Kapazität der GKE-Flotte für die Dauer des Upgrades.
Im vorherigen Diagramm wird durch das Hinzufügen eines neuen Clusters vorübergehend die verfügbare Kapazität über die erforderliche Kapazität hinaus erhöht, während ein anderer Cluster in der Flotte per Drain beendet und aus der Flotte entfernt wird. Nach dem Entfernen eines der alten (vollständig per Drain beendeten) Cluster wird die erforderliche Kapazität jedoch wiederhergestellt. Diese Kapazitätsänderung wird hervorgehoben, da die Kosten bei diesem Modell abhängig von der Anzahl und Größe der Cluster in der Flotte steigen können.
Canary-Clusterupgrades
Ein Canary-Clusterupgrade ist die robusteste und komplexeste Wahl unter den in diesem Dokument beschriebenen Strategien. Diese Strategie abstrahiert die Verwaltung des Clusterlebenszyklus vollständig von der Verwaltung des Service-Lebenszyklus. So profitieren Sie von dem niedrigsten Risiko und der größten Ausfallsicherheit für Ihre Dienste. Bei der vorherigen Rolling-Update- und Blau/Grün-Upgradestrategie wird Ihre komplette GKE-Flotte auf einer einzelnen Version verwaltet. Bei dieser Strategie verwalten Sie hingegen zwei oder möglicherweise drei Flotten von GKE-Clustern, in denen unterschiedliche Versionen ausgeführt werden. Anstatt ein Upgrade der Cluster durchzuführen, migrieren Sie Services im Laufe der Zeit von einer Flotte von Clustern zur anderen. Wenn die älteste GKE-Flotte per Drain beendet wurde, d. h., dass alle Services zur nächsten versionierten GKE-Flotte migriert wurden, löschen Sie die Flotte.
Für diese Strategie müssen Sie mindestens zwei GKE-Flotten verwalten – eine für die aktuelle Produktionsversion und eine für die nächste mögliche Produktionsversion. Sie können auch mehr als zwei GKE-Flotten verwalten. Zusätzliche Flotten bieten mehr Flexibilität, bedeuten aber auch, dass Ihre Kosten und der operative Aufwand steigen. Diese zusätzlichen Flotten sind nicht das Gleiche wie Cluster in verschiedenen Umgebungen, z. B. Entwicklungs-, Staging- und Produktionsumgebungen. Nicht-Produktionsumgebungen eignen sich hervorragend zum Testen der Kubernetes-Features und -Services mit Nicht-Produktionstraffic.
Bei dieser Strategie, bei der Canary-Clusterupgrades verwendet werden, verwalten Sie mehrere Versionen der GKE-Flotte in der Produktionsumgebung. Dies ist mit Canary-Release-Strategien vergleichbar, die häufig von Services verwendet werden. Bei Canary-Service-Bereitstellungen kann der Service-Inhaber Probleme immer einer bestimmten Version des Service zuordnen. Bei Canary-Clustern muss der Service-Inhaber auch die Versionen der GKE-Flotte berücksichtigen, in denen seine Services ausgeführt werden. Eine einzelne verteilte Service-Version kann möglicherweise in mehreren Versionen der GKE-Flotte ausgeführt werden. Die Migration eines Service kann schrittweise erfolgen, sodass Sie die Auswirkungen des Service auf die neue Flotte sehen können, bevor der gesamte Traffic für den Service an die neuen versionierten Cluster gesendet wird.
Das folgende Diagramm zeigt, dass bei der Verwaltung verschiedener Flotten von GKE-Clustern der Clusterlebenszyklus komplett vom Dienstlebenszyklus abstrahiert werden kann.
Das obige Diagramm zeigt den verteilten Service frontend, der langsam von einer GKE-Clusterflotte zur nächsten Flotte migriert wird. Diese führt die neue Version aus, bis die ältere Flotte im Laufe der Zeit vollständig per Drain beendet wurde. Nachdem die Flotte per Drain beendet wurde, kann sie entfernt werden. Anschließend kann eine neue Flotte erstellt werden. Alle Dienste werden zur nächsten Flotte migriert und die älteren Flotten werden beim Beenden entfernt.
Wenn Sie vor allem Wert auf Ausfallsicherheit legen, verwenden Sie die Strategie für Canary-Clusterupgrades.
Upgradestrategie auswählen
Das folgende Diagramm kann Ihnen bei der Entscheidung helfen, welche Strategie für Ihre Service- und Geschäftsanforderungen am besten geeignet ist.
Das obige Diagramm ist ein Entscheidungsbaum, der Ihnen als Hilfestellung bei der Auswahl der passenden Upgradestrategie dienen soll:
- Wenn Sie keine vollständige Kontrolle über die genaue Version und den Zeitpunkt des Upgrades benötigen, können Sie das in GKE verfügbare Feature für automatische Upgrades wählen.
- Wenn Ihre Priorität auf niedrigen Kosten liegt, können Sie die Strategie für Rolling Updates wählen.
- Wenn Ihre Priorität auf dem Gleichgewicht zwischen Erschwinglichkeit und Ausfallsicherheit liegt, können Sie die Blau/Grün-Strategie wählen.
- Wenn Ihre Priorität vor allem auf Ausfallsicherheit statt auf Erschwinglichkeit liegt, können Sie die Strategie für Canary-Clusterupgrades wählen.
Multi-Cluster-Traffic-Management für den GKE-Clusterlebenszyklus
Um die Dienstverfügbarkeit während Multi-Cluster-Upgrades aufrechtzuerhalten, müssen Sie den Traffic zwischen Clustern umleiten. Sie können diesen Traffic entweder mit einem Multi-Cluster-Gateway (empfohlen) oder mit Multi-Cluster-Ingress verwalten. Multi-Cluster-Gateway ist der Nachfolger von Multi-Cluster-Ingress und bietet einen ausdrucksstärkeren und rollenorientierten Ansatz für die Dienstvernetzung.
Multi-Cluster-Gateway zur Verwaltung des Clusterlebenszyklus verwenden
Multi-Cluster-Gateways (MCG) verwenden die Gateway API, um den Traffic für Dienste zu verwalten, die in mehreren GKE-Clustern innerhalb einer Flotte bereitgestellt werden.
Der GKE Gateway-Controller ist ein von Google gehosteter Dienst, der in einem bestimmten Konfigurationscluster nach Gateway- und HTTPRoute-Ressourcen sucht. Der Controller stellt automatisch eine Load-Balancing-Infrastruktur bereit und verwaltet sie. So wird ein einheitlicher Einstiegspunkt für Anwendungen in allen Clustern der Flotte geschaffen. Mit dieser Architektur können Sie den Lebenszyklus des Load-Balancers von den einzelnen GKE-Clustern entkoppeln, in denen sich die Arbeitslasten befinden.
Für die Verwaltung des GKE-Clusterlebenszyklus ermöglicht das Multi-Cluster-Gateway erweiterte Strategien zur Traffic-Steuerung:
- Blau/Grün-Upgrades: Stellen Sie einen neuen „grünen“ Cluster bereit und verlagern Sie den Traffic schrittweise vom „blauen“ Cluster, indem Sie die Gewichte in der HTTPRoute-Ressource ändern.
- Kapazitätsbasiertes Load-Balancing: Traffic wird automatisch umgeleitet, wenn ein Dienst in einem Cluster sein definiertes Kapazitätslimit erreicht. So wird er bei laufenden Upgrades vor Überlastung geschützt.
- Systemdiagnosebasiertes Failover: Überwachen Sie den Zustand von Back-Ends in allen Clustern und leiten Sie den Traffic automatisch von einem Cluster um, der geleert wird oder Probleme hat.
Weitere Informationen finden Sie in der Anleitung zum Bereitstellen eines Multi-Cluster-Gateways für die gewichtete Traffic-Aufteilung.
Multi-Cluster-Ingress zur Verwaltung des Clusterlebenszyklus verwenden
Eine weitere Lösung für die Multi-Cluster-Trafficverwaltung ist Multi-Cluster-Ingress. Multi-Cluster-Ingress ist ein in Google Cloudgehosteter Multi-Cluster-Ingress-Controller für GKE-Cluster, der die Bereitstellung von Ressourcen für das gemeinsame Load-Balancing in Clustern und Regionen unterstützt. Multi-Cluster-Ingress ist eine Lösung, bei der Sie Clienttraffic zu einem verteilten Dienst leiten können, der in vielen Clustern in vielen Regionen ausgeführt wird. Wie bei Ingress für GKE wird Cloud Load Balancing verwendet, um Traffic an einen Back-End-Dienst zu senden. Der Backend-Dienst ist der verteilte Service. Der Backend-Dienst sendet Traffic an mehrere Backends, bei denen es sich um Kubernetes-Services handelt, die in mehreren GKE-Clustern ausgeführt werden. Für den Service-zu-Service-Traffic über Cluster können Sie Service-Mesh-Technologien wie Cloud Service Mesh oder Istio verwenden, die eine ähnliche Funktionalität in verteilten Services bieten.
Weitere Informationen finden Sie in der Anleitung zum Aktualisieren einer GKE-Umgebung mit mehreren Clustern mit Multi-Cluster-Ingress.