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, z. B. zum manuellen Konfigurieren eines externen Load-Balancers. Es gibt eine begleitende Anleitung für dieses Dokument, die zeigt, wie Sie eine GKE-Multi-Cluster-Umgebung mit Multi-Cluster-Ingress upgraden. Dieses Dokument richtet sich an Google Cloud-Administratoren, die für die Verwaltung von Flotten für GKE-Cluster verantwortlich sind.
Notwendigkeit einer Multi-Cluster-Architektur
In diesem Abschnitt werden verschiedene Gründe dafür erläutert, warum Sie eine Multi-Cluster-Kubernetes-Architektur benötigen.
Kubernetes als Infrastruktur
In diesem Dokument werden Kubernetes-Cluster als Infrastrukturkomponenten betrachtet. Die Infrastruktur kann entfernt werden. Infrastrukturkomponenten müssen nicht besonders gehandhabt werden, da die Komponenten bestimmte Zwecke erfüllen sollen. Kubernetes soll Entwicklern und Operatoren die Automatisierung und Orchestrierung ermöglichen, damit sie Verbrauchern containerbasierte Anwendungen und Dienste bereitstellen können. Verbraucher können interne Teams, andere Dienste oder externe Kunden sein.
Häufige Multi-Cluster-Szenarien
Neben dem Argument „Kubernetes als Infrastruktur“ gibt es eine Reihe von Gründen, die für eine Multi-Cluster-Umgebung sprechen:
- Geografie: Viele Services müssen sich in mehreren Regionen befinden. Wenn Sie einen Service näher an einem Nutzer – also in seiner Region – platzieren, können Sie damit für eine bessere Nutzererfahrung sorgen. Im Vergleich zur Bereitstellung von einer einzigen Region aus bieten Sie so nämlich eine geringere Latenz. Ein Kubernetes-Cluster wird in einer einzelnen Region ausgeführt. Für multiregionale Bereitstellungen sind mehrere Kubernetes-Cluster in mehreren Regionen erforderlich. Multi-Cloud- oder Hybrid-Cloud-Umgebungen erfordern ebenfalls mehrere Cluster in jeder Umgebung. Kubernetes-Cluster befinden sich außerdem häufig zusammen mit den (zustandsorientierten) Datenquellen des Service am selben Standort. Bestimmte Anwendungen müssen möglicherweise am selben Standort (Region und Zone) wie das Backend befinden. Dazu zählen beispielsweise relationale Datenbankverwaltungssysteme (Relational Database Management System, RDBMS).
- Mandanten und Umgebungen: Kubernetes-Cluster sind auf Mehrmandantenfähigkeit ausgelegt. Mehrere Teams können einen einzelnen Cluster für ihre jeweiligen Services gemeinsam nutzen. Kubernetes bietet Standardressourcen wie Namespaces, rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC), Netzwerkrichtlinien und Authentifizierung, um die Zugriffssteuerung in mehrmandantenfähigen Umgebungen angemessen zu konfigurieren. In einigen Fällen können sich bestimmte Services aufgrund von Unternehmensrichtlinien, Datenschutz, Sicherheit oder Branchenverordnungen nicht zusammen mit anderen Services in einem Cluster befinden. In solchen Fällen sind mehrere Cluster erforderlich, um bestimmte Mandanten in separate Cluster zu unterteilen. Umgebungen (Entwicklung, Staging und Produktion) werden häufig auch als separate Cluster erstellt. Der Zugriffsbereich und die Arten von Anwendungen, die in verschiedenen Umgebungen installiert sind, variieren erheblich und sollten als separate Cluster verwaltet werden.
- Zusammensetzung und Funktion: Manchmal wird ein Cluster erstellt, um eine bestimmte Funktion auszuführen. So verwenden Workflows für maschinelles Lernen beispielsweise Kubeflow oder Datenanalysejobs. Hierfür sind möglicherweise Knoten mit GPUs oder anderen Hardwareanforderungen für Instanzcluster erforderlich, die sich aus Spot-VMs zusammensetzen und für Batchanalysejobs genutzt werden. Möglicherweise gelten diese Hardwareanforderungen jedoch nicht für andere Services. Diese Workflows sind nicht unbedingt für den Betrieb des Unternehmens notwendig und können sitzungsspezifische Cluster (kurzlebige Cluster) erfordern. Freigegebene Dienste wie Beobachtbarkeit (Logging, Messwerte und Traces) und CI/CD-Tools sollten sich besser in ihren eigenen Plattform-Administratorclustern befinden. Separate funktionsspezifische Cluster werden häufig für Workflows genutzt, die nicht geschäftskritisch sind.
- Ausfallsicherheit: Häufig werden mehrere Cluster verwendet, um die Ausfallsicherheit in einer Umgebung zu erhöhen. Jeder Cluster hat einen Wirkungsbereich. In diesem Zusammenhang ist ein Wirkungsbereich die Anzahl der Services, die aufgrund eines fehlerhaften Clusters, einer fehlerhaften Konfiguration oder eines Clusters, der aufgrund einer geplanten oder ungeplanten Wartung offline geht, beeinträchtigt werden. Wenn Sie eine große Anzahl von kleineren Clustern haben, haben Sie eine große Anzahl kleinerer Wirkungsbereiche. Wenn ein Service in zwei Clustern vorhanden ist, verteilt sich die Last gleichmäßig auf die Cluster. Wenn ein Cluster offline geht, wirkt sich dies auf 50 % des Traffics aus. Würde derselbe Service von einem einzelnen Cluster bereitgestellt werden, würde jedes Ereignis in diesem Cluster zu einem Ausfall von 100 % für diesen Service führen. Aus diesem Grund werden für die Notfallwiederherstellung oft auch mehrere Cluster verwendet.
In diesem Dokument geht es um den Aspekt der Ausfallsicherheit von Multi-Cluster-Bereitstellungen.
Multi-Cluster und verteilte Services
Ein verteilter Service ist ein Kubernetes-Service, der in mehreren Kubernetes-Clustern bereitgestellt wird. Verteilte Services sind zustandslose Services, die sich in mehreren Clustern identisch verhalten. Das bedeutet, dass ein verteilter Service denselben Kubernetes-Service-Namen hat und im selben Namespace in mehreren Clustern implementiert wird. Kubernetes-Services sind an den Kubernetes-Cluster gebunden, in dem sie ausgeführt werden. Wenn ein Kubernetes-Cluster offline geht, gilt dies auch für den Kubernetes-Service. Verteilte Services werden von einzelnen Kubernetes-Clustern abstrahiert. Wenn ein oder mehrere Kubernetes-Cluster ausgefallen sind, ist der verteilte Service möglicherweise online und befindet sich innerhalb des Service Level Objective (SLO).
Im folgenden Diagramm ist frontend ein verteilter Service, der in mehreren Clustern mit demselben Service-Namen und Namespace ausgeführt wird.
Bei dieser Architektur ist der frontend-Service nicht an einen einzelnen Cluster gebunden und wird im Diagramm konzeptionell als Ebene dargestellt, die die Ebene der Kubernetes-Clusterinfrastruktur umfasst. Wenn einer der einzelnen Cluster, in denen der frontend-Service ausgeführt wird, ausfällt, bleibt frontend weiterhin online.
In einzelnen Clustern werden zusätzliche Services ausgeführt: der accounts- und der ledger-Service. Ihre Betriebszeit und Verfügbarkeit hängen von der Betriebszeit des Kubernetes-Clusters ab, in dem sie sich befinden.
Ausfallsicherheit ist einer der Gründe, der für Multi-Cluster-Bereitstellungen spricht. Verteilte Services erstellen robuste Dienste in einer Multi-Cluster-Architektur. Zustandslose Dienste sind hervorragende Kandidaten für verteilte Dienste in einer Multi-Cluster-Umgebung. Die folgenden Anforderungen und Überlegungen gelten für die Arbeit mit verteilten Services:
Multi-Cluster-Netzwerke: Sie können für einen verteilten Service bestimmten Traffic an Cluster senden, in denen dieser Service ausgeführt wird. Verwenden Sie hierfür eine Multi-Cluster-Technologie für eingehenden Traffic wie Multi-Cluster-Ingress oder Ihre eigene externe Load-Balancer- oder Proxy-Lösung. Unabhängig von der verwendeten Option können Sie steuern, wann, wo und wie viel Traffic an eine bestimmte Instanz eines verteilten Service weitergeleitet wird. Das folgende Diagramm zeigt einen Load-Balancer, der Traffic an einen verteilten
frontend-Service sendet. Dieser wird in zwei GKE-Clustern ausgeführt.
Beobachtbarkeit: Verwenden Sie Tools, um Ihre SLOs – normalerweise Verfügbarkeit und Latenz – gemeinsam für einen verteilten Service zu messen. Diese Konfiguration bietet eine globale Ansicht der Leistung der einzelnen Services in mehreren Clustern. Der verteilte Service ist in den meisten Beobachtbarkeitslösungen zwar nicht gut definiert, Sie können aber einzelne Kubernetes-Service-Messwerte erfassen und kombinieren. Lösungen wie Cloud Monitoring oder Open-Source-Tools wie Grafana stellen Kubernetes-Service-Messwerte bereit. Service-Mesh-Lösungen wie Istio und Anthos Service Mesh stellen auch Service-Messwerte bereit, ohne dass eine Instrumentierung erforderlich ist.
Service-Platzierung: Kubernetes-Services bieten Fehlertoleranz auf Knotenebene innerhalb eines einzelnen Kubernetes-Clusters. Das bedeutet, dass ein Kubernetes-Service Knotenausfällen standhalten kann. Bei Knotenausfällen weist ein Kubernetes-Steuerungsebenenknoten Pods automatisch fehlerfreien Knoten zu. Ein verteilter Service bietet Fehlertoleranz auf Clusterebene. Das bedeutet, dass ein verteilter Service Clusterausfällen standhalten kann. Wenn Sie die Kapazität für einen verteilten Service planen, müssen Sie diese Service-Platzierung berücksichtigen. Ein verteilter Service muss nicht in jedem Cluster ausgeführt werden. In welchen Clustern ein verteilter Service ausgeführt wird, hängt von den folgenden Anforderungen ab:
- Wo und in welchen Regionen ist der Service erforderlich?
- Wie sieht das erforderliche SLO für den verteilten Service aus?
- Welche Art von Fehlertoleranz ist für den verteilten Service erforderlich – auf Clusterebene, zonal oder regional? Benötigen Sie beispielsweise mehrere Cluster in einer einzelnen Zone oder mehrere Cluster über Zonen in einer einzelnen Region oder in mehreren Regionen hinweg?
Welchem Ausfallgrad sollte der verteilte Service im schlimmsten Fall standhalten können? Die folgenden Optionen sind auf Clusterebene verfügbar:
- N+1 (N steht für die Anzahl der Cluster, die zur Erfüllung der Anforderungen an die Dienstkapazität erforderlich sind). Ein verteilter Service kann einem einzelnen Clusterausfall standhalten.
- N+2. Ein verteilter Service kann zwei gleichzeitigen Ausfällen standhalten. Dies ist beispielsweise der Fall, wenn ein Kubernetes-Service sowohl geplant als auch ungeplant in zwei Clustern gleichzeitig ausfällt.
Rollout und Rollback: Verteilte Services, z. B. Kubernetes-Services, ermöglichen graduelle Rollouts und Rollbacks. Im Gegensatz zu Kubernetes-Services ist es bei verteilten Services möglich, dass Cluster eine zusätzliche Bereitstellungseinheit für schrittweise Veränderungen bilden. Rollouts und Rollbacks hängen auch von den Anforderungen an den Service ab. In einigen Fällen kann es erforderlich sein, für alle Cluster gleichzeitig ein Dienst-Upgrade durchzuführen, beispielsweise bei einer Fehlerkorrektur. In anderen Fällen muss die Änderung möglicherweise langsam bzw. clusterweise eingeführt werden. Durch dieses graduelle Rollout wird das Risiko für den verteilten Service verringert, indem schrittweise Änderungen am Dienst vorgenommen werden. Dies kann jedoch je nach Anzahl der Cluster länger dauern. Es gibt keine optimale Upgradestrategie. Häufig werden mehrere Rollout- und Rollback-Strategien abhängig von den Anforderungen des verteilten Service verwendet. Wichtig ist, dass verteilte Services graduelle und kontrollierte Änderungen in der Umgebung ermöglichen.
Geschäftskontinuität und Notfallwiederherstellung (Business Continuity and Disaster Recovery, BCDR): Diese Begriffe werden oft zusammen verwendet. Geschäftskontinuität bezieht sich auf die Fortsetzung wichtiger Dienste bei einem größeren (geplanten oder nicht geplanten) Ereignis. Notfallwiederherstellung verweist wiederum auf die Schritte, die unternommen werden oder erforderlich sind, um Geschäftsvorgänge nach solchen Ereignissen wieder in den Normalzustand zu versetzen. Es gibt viele Strategien für BCDR, die in diesem Dokument nicht behandelt werden. BCDR erfordert einen gewissen Grad an Redundanz in Systemen und Services. Das Wichtigste bei verteilten Services ist, dass sie an mehreren Standorten (Cluster, Zonen und Regionen) ausgeführt werden.
BCDR-Strategien sind häufig von den oben erläuterten Rollout- und Rollback-Strategien abhängig. Wenn Rollouts z. B. schrittweise oder kontrolliert durchgeführt werden, können die Auswirkungen eines Programmfehlers oder einer fehlerhaften Konfigurationsübertragung frühzeitig erkannt werden, ohne dass eine große Anzahl von Nutzern betroffen ist. Im großen Maßstab und in Kombination mit einer schnellen Änderungsrate (z. B. bei modernen CI/CD-Verfahren) ist es üblich, dass nicht allen Nutzern die gleiche Version eines verteilten Service bereitgestellt wird. BCDR-Planung und BCDR-Strategien in verteilten Systemen und Services unterscheiden sich von herkömmlichen monolithischen Architekturen. Bei herkömmlichen Systemen erfolgt eine Änderung umfassend und betrifft eine große Anzahl (oder möglicherweise alle) Nutzer. Ein Redundanz- oder Sicherungssystem muss vorhanden sein, falls es unerwünschte Auswirkungen im Rahmen eines Rollouts gibt. Bei verteilten Systemen und Services werden fast alle Änderungen nach und nach umgesetzt, damit sie sich nur auf eine kleine Anzahl von Nutzern auswirken.
Verwaltung des Clusterlebenszyklus: Wie kontrollierte Rollouts und Rollbacks ermöglichen auch verteilte Services das kontrollierte Verwalten des Clusterlebenszyklus. Verteilte Services bieten Ausfallsicherheit auf Clusterebene, damit Cluster bei der Wartung aus der Rotation genommen werden können. Die Verwaltung des Clusterlebenszyklus ist ein Prinzip verteilter Services, das nicht für Kubernetes-Services gilt.
Im weiteren Verlauf dieses Dokuments liegt der Schwerpunkt auf dem Clusterlebenszyklusaspekt von verteilten Services.
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.
In diesem Dokument geht es um die Verwaltung des Lebenszyklus in GKE. Sie können diese Konzepte jedoch auf andere Distributionen von Kubernetes anwenden.
GKE-Versionsverwaltung und -Upgrades
Bevor Strategien besprochen werden und die Verwaltung des Clusterlebenszyklus geplant werden kann, sollten Sie verstehen, was ein Clusterupgrade ausmacht.
Ein Cluster enthält zwei Komponenten: Steuerungsebenenknoten und Worker-Knoten. Für ein Kubernetes-Clusterupgrade müssen alle Knoten auf dieselbe Version aktualisiert werden. Kubernetes folgt einem semantischen Versionsverwaltungsschema.
Kubernetes-Versionen werden als X.Y.Z: ausgedrückt, wobei X die Hauptversion, Y die Nebenversion und Z die Patchversion ist. Nebenversionen werden ungefähr alle drei Monate (vierteljährlich) veröffentlicht und das Kubernetes-Projekt speichert Release-Zweige für die letzten drei Nebenversionen. Das bedeutet, dass eine neun Monate alte Kubernetes-Nebenversion nicht mehr gewartet wird. Möglicherweise sind dann API-Änderungen erforderlich, wenn Sie ein Upgrade auf die neueste Version ausführen. Kubernetes-Upgrades müssen regelmäßig erfolgen. Wir empfehlen, geplante GKE-Upgrades vierteljährlich oder alle zwei Quartale durchzuführen.
GKE-Cluster unterstützen das Ausführen von Kubernetes-Versionen von allen unterstützten Nebenversionen. Es sind immer mindestens zwei Nebenversionen verfügbar.
GKE hat folgende Clusterverfügbarkeitstypen:
- Einzelzonencluster: Ein einzelner Steuerungsebenenknoten und alle Knotenpools befinden sich in einer einzigen Zone in einer einzigen Region.
- Multizonale Cluster: Ein einzelner Steuerungsebenenknoten befindet sich in einer einzigen Zone und Knotenpools befinden sich in mehreren Zonen in einer einzigen Region.
- Regionale Cluster: Mehrere Steuerungsebenenknoten und Knotenpools befinden sich in mehreren Zonen in einer einzigen Region.
GKE ist ein verwalteter Dienst und bietet automatische Upgrades für Steuerungsebenenknoten und Worker-Knoten.
Automatische GKE-Upgrades
Ein automatisches GKE-Upgrade ist eine beliebte und oft verwendete Strategie für den Clusterlebenszyklus. Das automatische GKE-Upgrade bietet eine vollständig verwaltete Möglichkeit, GKE-Cluster immer auf unterstützte Versionen aktualisiert zu halten. Bei automatischen GKE-Upgrades werden für Steuerungsebenenknoten und Worker-Knoten separat Upgrades durchgeführt:
Automatische Masterupgrades: Standardmäßig werden Upgrades von GKE-Steuerungsebenenknoten automatisch ausgeführt. Einzelzonencluster und multizonale Cluster haben eine einzige Steuerungsebene (Steuerungsebenenknoten). Während Upgrades der Steuerungsebenenknoten werden Arbeitslasten weiterhin ausgeführt. Sie können jedoch erst neue Arbeitslasten bereitstellen, vorhandene Arbeitslasten ändern oder andere Änderungen an der Clusterkonfiguration vornehmen, wenn das Upgrade abgeschlossen ist.
Regionale Cluster haben mehrere Replikate der Steuerungsebene. Pro Replikat wird jeweils nur ein Upgrade durchgeführt. Während des Upgrades bleibt der Cluster hochverfügbar und jedes Replikat der Steuerungsebene ist nur während des Upgrades nicht verfügbar.
Automatische Upgrades von Worker-Knoten: Knotenpools werden nacheinander aktualisiert. Innerhalb eines Knotenpools werden Knoten nacheinander in einer nicht definierten Reihenfolge aktualisiert. Sie können die Anzahl der gleichzeitig aktualisierten Knoten ändern. Dieser Vorgang kann jedoch je nach Anzahl der Knoten und der Arbeitslastkonfigurationen mehrere Stunden dauern.
Lebenszyklusstrategie für automatische GKE-Upgrades
Wir empfehlen, wenn möglich automatische GKE-Upgrades zu verwenden. Bei automatischen GKE-Upgrades wird Nutzerfreundlichkeit gegenüber Kontrolle priorisiert. Automatische GKE-Upgrades bieten jedoch zahlreiche Möglichkeiten zu beeinflussen, wann und wie Cluster innerhalb bestimmter Parameter aktualisiert werden. Sie können die Wartungsfenster und -ausschlüsse beeinflussen. Release-Versionen beeinflussen die Versionsauswahl, während Knotenupgrade-Strategien die Reihenfolge und den Zeitpunkt von Knotenupgrades beeinflussen. Trotz dieser Steuerungsmöglichkeiten und regionalen Cluster (mit mehreren Kubernetes-Steuerungsebenen) gewährleisten automatische GKE-Upgrades nicht die Betriebszeit von Diensten. Wenn Sie eine oder mehrere der folgenden Funktionen benötigen, können Sie sich gegen die Nutzung des Features für automatische GKE-Upgrades entscheiden:
- Steuerung der genauen Version von GKE-Clustern
- Steuerung der genauen Zeit für das Upgrade von GKE
- Steuerung der Upgradestrategie (wie im nächsten Abschnitt beschrieben) für Ihre GKE-Flotte
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-Ingress zur Verwaltung des GKE-Clusterlebenszyklus verwenden
Fast jede Strategie hängt davon ab, inwieweit Traffic bei Upgrades per Drain beendet und zu anderen Clustern umgeleitet werden kann. Eine Lösung, die diese Multi-Cluster-Ingress-Funktion bereitstellt, ist Multi-Cluster-Ingress. Multi-Cluster-Ingress ist ein in Google Cloud gehosteter 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 Anthos Service Mesh oder Istio verwenden, die eine ähnliche Funktionalität in verteilten Services bieten.
Bei GKE-Multi-Cluster-Umgebungen können Sie mithilfe von Multi-Cluster-Ingress für die zuvor erläuterten Verwaltungsstrategien für den Clusterlebenszyklus Traffic an mehrere Cluster bearbeiten. Weitere Informationen finden Sie in der Anleitung zur Verwendung von Multi-Cluster-Ingress für GKE-Upgrades mithilfe der Blau/Grün-Strategie.