Container zu Google Cloud migrieren: Migration zu einer Multi-Cluster-GKE-Umgebung

Last reviewed 2023-05-08 UTC

In diesem Dokument wird erläutert, wie Sie die Migration von einer Google Kubernetes Engine-Umgebung (GKE) zu einer neuen GKE-Umgebung planen, gestalten und umsetzen. Wird dies nicht richtig durchgeführt, kann das Verschieben von Anwendungen von einer Umgebung in eine andere eine schwierige Aufgabe sein. Daher müssen Sie die Migration sorgfältig planen und ausführen.

Dieses Dokument ist Teil einer mehrteiligen Reihe zur Migration zu Google Cloud. Eine Übersicht über die Reihe finden Sie unter Migration zu Google Cloud: Migrationspfad auswählen.

Dieses Dokument ist Teil einer Reihe zur Migration von Containern zu Google Cloud:

Dieses Dokument bietet nützliche Informationen, wenn Sie von einer GKE-Umgebung zu einer anderen GKE-Umgebung migrieren möchten. Dieses Dokument ist auch hilfreich, wenn Sie die Möglichkeit zur Migration in Betracht ziehen und sich ein Bild davon machen möchten.

Gründe für die Migration von einer GKE-Umgebung zu einer anderen GKE-Umgebung:

Für das Entwerfen der Architektur Ihrer neuen Umgebung empfehlen wir die Verwendung einer Multi-Cluster-GKE-Umgebung. Durch das Bereitstellen und Konfigurieren mehrerer GKE-Cluster in Ihrer Umgebung gehen Sie so vor:

  • Reduzieren Sie die Wahrscheinlichkeit, dass es in Ihrer Architektur einen Single Point of Failure gibt. Wenn beispielsweise ein Cluster ausfällt, können andere Cluster übernehmen.
  • Nutzen Sie die größere Flexibilität einer Multi-Cluster-Umgebung. Wenn Sie beispielsweise Änderungen auf eine Teilmenge Ihrer Cluster anwenden, können Sie die Auswirkungen von Fehlern begrenzen, die durch fehlerhafte Konfigurationsänderungen verursacht werden. Sie können dann die Änderungen prüfen, bevor Sie sie auf Ihre verbleibenden Cluster anwenden.
  • Lassen Sie Ihre Arbeitslasten clusterübergreifend kommunizieren. Zum Beispiel können in einem Cluster bereitgestellte Arbeitslasten mit Arbeitslasten kommunizieren, die in einem anderen Cluster bereitgestellt sind.

Die Anleitung in diesem Dokument gilt auch für eine Single-Cluster-GKE-Umgebung. Wenn Sie zu einer Single-Cluster-GKE-Umgebung migrieren, ist die Verwaltung Ihrer Umgebung im Vergleich zu einer Multi-Cluster-Umgebung weniger komplex. Eine Single-Cluster-Umgebung profitiert jedoch nicht von der höheren Flexibilität, Zuverlässigkeit und Robustheit einer Multi-Cluster-GKE-Umgebung.

Diese Grafik veranschaulicht den Migrationsprozess:

Migrationspfad mit vier Phasen

Das im vorherigen Diagramm dargestellte Framework hat die folgenden Phasen, die unter Migration zu Google Cloud: Einstieg definiert werden:

  1. Arbeitslasten bewerten und erkennen
  2. Grundlagen planen und aufbauen
  3. Arbeitslasten bereitstellen
  4. Umgebung optimieren

Sie verfolgen die vorherigen Phasen bei jedem Migrationsschritt. Dieses Dokument basiert auch auf Konzepten, die unter Container zu Google Cloud migrieren: Von Kubernetes zu GKE migrieren erläutert werden. Es enthält gegebenenfalls nützliche Links.

Umgebung prüfen

In der Bewertungsphase erfassen Sie Informationen über die Quellumgebung und die zu migrierenden Arbeitslasten. Diese Bewertung ist sehr wichtig für die Migration und für die Anpassung der Ressourcen, die Sie für die Migration und die Zielumgebung benötigen. In der Bewertungsphase gehen Sie so vor:

  1. Ein umfassendes Inventar Ihrer Anwendungen erstellen.
  2. Die Anwendungen nach ihren Attributen und Abhängigkeiten katalogisieren.
  3. Die Teams auf Google Cloud vorbereiten.
  4. Einen Test und einen Proof of Concept für Google Cloud erstellen.
  5. Die Gesamtbetriebskosten (TCO) der Zielumgebung berechnen.
  6. Die Arbeitslasten auswählen, die als Erstes migriert werden sollen.

Die folgenden Abschnitte basieren auf dem Dokument Migration zu Google Cloud: Arbeitslasten bewerten und erkennen. Sie bieten jedoch Informationen, die sich speziell auf die Bewertung von Arbeitslasten beziehen, die Sie zu neuen GKE-Clustern migrieren möchten.

Unter Von Kubernetes zu GKE migrieren: Umgebung prüfen wird beschrieben, wie Sie Kubernetes-Cluster und -Ressourcen, z. B. ServiceAccounts und PersistentVolumes, bewerten. Die Informationen gelten auch für die Bewertung Ihrer GKE-Umgebung.

Inventar erstellen

Zum Festlegen des Umfangs einer Migration müssen Sie Ihre aktuelle GKE-Umgebung kennen. Zuerst sammeln Sie Informationen zu Ihren Clustern und konzentrieren sich dann auf die in diesen Clustern bereitgestellten Arbeitslasten und die Abhängigkeiten der Arbeitslasten. Am Ende der Bewertungsphase haben Sie zwei Inventare: eines für Ihre Cluster und eines für die in diesen Clustern bereitgestellten Arbeitslasten.

Unter Von Kubernetes zu GKE migrieren: Inventar erstellen wird beschrieben, wie Sie das Inventar Ihrer Kubernetes-Cluster und -Arbeitslasten erstellen. Es gilt auch für das Erstellen des Inventars Ihrer GKE-Umgebungen. Bevor Sie mit diesem Dokument fortfahren, folgen Sie dieser Anleitung, um das Inventar Ihrer Kubernetes-Cluster zu erstellen.

Nachdem Sie der Anleitung Von Kubernetes zu GKE migrieren: Inventar erstellen gefolgt sind, verfeinern Sie das Inventar. Berücksichtigen Sie zum Abschließen des Inventars Ihrer GKE-Cluster und -Knotenpools GKE-spezifische Aspekte und Features für jeden Cluster und Knotenpool, einschließlich der folgenden:

Beim Erstellen Ihres Inventars finden Sie möglicherweise einige GKE-Cluster, die im Rahmen der Migration außer Betrieb genommen werden müssen. Einige Google Cloud-Ressourcen werden nicht gelöscht, wenn Sie die GKE-Cluster löschen, die sie erstellt haben. Achten Sie darauf, dass Ihr Migrationsplan die Deaktivierung dieser Ressourcen umfasst.

Informationen zu weiteren potenziellen GKE-spezifischen Aspekten und Features finden Sie in der GKE-Dokumentation.

Bewertung abschließen

Nachdem Sie das Inventar erstellt haben, die sich auf Ihre GKE-Cluster und -Arbeitslasten beziehen, schließen Sie die restlichen Aktivitäten der Bewertungsphase unter Container zu Google Cloud migrieren: Von Kubernetes zu GKE migrieren ab.

Grundlagen planen und aufbauen

In der Planungsphase stellen Sie die Grundlage, die Cloud-Infrastruktur und die Dienste bereit, die Ihre Arbeitslasten in Google Cloud unterstützen, und konfigurieren sie. In der Planungsphase gehen Sie so vor:

  • Erstellen Sie eine Ressourcenhierarchie.
  • Konfigurieren Sie die Identitäts- und Zugriffsverwaltung.
  • Richten Sie die Abrechnung ein.
  • Richten Sie die Netzwerkverbindung ein.
  • Erhöhen Sie die Sicherheit.
  • Richten Sie Monitoring und Benachrichtigungen ein.

Achten Sie beim Einrichten der Netzwerkverbindung darauf, dass in Ihren Subnetzen genügend IP-Adressen für die Zuweisung von Knoten, Pods und Services vorhanden sind. Wenn Sie das Netzwerk für Ihre Cluster einrichten, planen Sie die Zuweisung von IP-Adressen sorgfältig. Sie können beispielsweise privat verwendete öffentliche IP-Adressen für GKE konfigurieren. Die sekundären IP-Adressbereiche, die Sie für Pods und Services in Ihren Clustern festlegen, können nach der Zuweisung nicht mehr geändert werden. Seien Sie besonders vorsichtig, wenn Sie einen Pod- oder Service-Bereich von /22 (1.024 Adressen) oder kleiner zuweisen. Andernfalls ist es möglich, dass keine IP-Adressen mehr für Pods und Services vorhanden sind, wenn Ihr Cluster wächst. Weitere Informationen finden Sie unter IP-Adressbereichsplanung.

Wir empfehlen, ein separates freigegebenes Subnetz für interne Load-Balancer zu verwenden, das Sie für Ihre GKE-Umgebung erstellen. Wenn Sie den Kubernetes-Service type: LoadBalancer verwenden, können Sie ein Load-Balancer-Subnetz angeben. Wenn Sie interne HTTP(S)-Load-Balancer konfigurieren, müssen Sie ein Nur-Proxy-Subnetz konfigurieren.

Wenn Sie die Grundlage Ihrer GKE-Umgebung erstellen möchten, müssen Sie die Aktivitäten der Planungs- und Aufbauphase unter Container zu Google Cloud migrieren: Von Kubernetes zu GKE migrieren abschließen.

Arbeitslasten bereitstellen

In der Bereitstellungsphase gehen Sie so vor:

  1. Zielumgebung bereitstellen und konfigurieren
  2. Daten aus der Quellumgebung in die Zielumgebung migrieren
  3. Arbeitslasten in der Zielumgebung bereitstellen

Dieser Abschnitt enthält Informationen, die sich speziell auf die Bereitstellung von Arbeitslasten in GKE beziehen. Er basiert auf den Informationen unter Von Kubernetes zu GKE migrieren: Arbeitslasten bereitstellen.

Laufzeitplattform und -umgebungen bewerten

Für eine flexiblere, zuverlässigere und besser wartbare Infrastruktur empfehlen wir Ihnen, eine Multi-Cluster-Architektur zu entwerfen und zu implementieren. In einer Multi-Cluster-Architektur haben Sie mehrere GKE-Produktionscluster in Ihrer Umgebung. Wenn Sie beispielsweise in Ihrer Umgebung mehrere GKE-Cluster bereitstellen, können Sie erweiterte Strategien für den Clusterlebenszyklus implementieren, wie z. B. Rolling-Upgradesoder Blau/Grün-Upgrades. Weitere Informationen zu Multi-Cluster-GKE-Architekturdesigns und ihren Vorteilen finden Sie unter Multi-Cluster-GKE-Upgrades mit Multi-Cluster-Ingress.

Wenn Sie Ihre Umgebung in mehreren Clustern ausführen, müssen Sie zusätzliche Herausforderungen berücksichtigen, z. B.:

  • Sie müssen die Konfigurationsverwaltung, die Service Discovery und die Kommunikation, die Einführung von Anwendungen und das Load-Balancing für eingehenden Traffic anpassen.
  • Möglicherweise müssen Sie zusätzliche Software in Ihrem Cluster sowie zusätzliche Automatisierung und Infrastruktur ausführen.

Zum Bewältigen dieser Herausforderungen benötigen Sie möglicherweise Pipelines für Continuous Integration/kontinuierliche Bereitstellung (CI/CD), um die Konfiguration von Clustern sequenziell zu aktualisieren, um die Auswirkungen von Fehlern zu minimieren. Unter Umständen benötigen Sie Load-Balancer, um den Traffic von einem Cluster auf andere Cluster zu verteilen.

Die manuelle Verwaltung Ihrer Infrastruktur ist fehleranfällig und kann aufgrund von fehlerhafter Konfiguration und fehlender interner Dokumentation zum aktuellen Status Ihrer Infrastruktur zu Problemen führen. Zur Minderung der Risiken aufgrund dieser Probleme empfehlen wir, die Infrastruktur als Codemuster anzuwenden. Wenn Sie dieses Muster anwenden, behandeln Sie die Bereitstellung Ihrer Infrastruktur genauso wie den Quellcode Ihrer Arbeitslasten.

Es gibt mehrere Architekturoptionen für Ihre GKE-Multi-Cluster-Umgebung, die weiter unten in diesem Abschnitt beschrieben werden. Die Auswahl einer Option hängt von mehreren Faktoren ab und keine Option ist von Natur aus besser als die anderen. Jeder Typ hat Stärken und Schwächen. So wählen Sie einen Architekturtyp aus:

  1. Legen Sie eine Reihe von Kriterien fest, um die Arten von Architekturen von Multi-Cluster-GKE-Umgebungen zu bewerten.
  2. Prüfen Sie jede Option anhand der Bewertungskriterien.
  3. Wählen Sie die Option aus, die Ihren Anforderungen am besten entspricht.

Wenn Sie die Kriterien zur Bewertung der Architekturtypen von Multi-Cluster-GKE-Umgebungen festlegen möchten, verwenden Sie die von Ihnen durchgeführte Umgebungsbewertung, um die benötigten Features zu identifizieren. Sortieren Sie die Features nach Wichtigkeit. Nachdem Sie Ihre Arbeitslasten und Ihre Umgebung geprüft haben, sollten Sie beispielsweise die folgenden Bewertungskriterien berücksichtigen, die absteigend nach Wichtigkeit geordnet sind:

  1. Von Google verwaltete Lösung Bevorzugen Sie von Google verwaltete oder selbstverwaltete Dienste oder Produkte?
  2. Schnittstellen zur Interaktion mit der Architektur. Gibt es eine maschinenlesbare Schnittstelle, mit der Sie interagieren können? Ist die Schnittstelle als offener Standard definiert? Unterstützt die Schnittstelle deklarative Anweisungen, imperative Anweisungen oder beides?
  3. Dienste außerhalb der GKE-Umgebung verfügbar machen. Können Sie Ihre Arbeitslasten mit der Architektur außerhalb des GKE-Clusters verfügbar machen, in dem sie bereitgestellt werden?
  4. Kommunikation zwischen Clustern. Unterstützt die Architektur Kommunikationskanäle zwischen Clustern? Unterstützen Ihre Arbeitslasten eine verteilte Architektur? Dieses Kriterium ist wichtig, um Arbeitslasten mit verteiltem Design, wie Jenkins, zu unterstützen.
  5. Traffic-Verwaltung. Unterstützt die Architektur erweiterte Features zur Traffic-Verwaltung wie Fehlerinjektion, Traffic-Verschiebung und Zeitüberschreitungen und Wiederholungen von Anfragen, Schutzschalter und Traffic-Spiegelung? Sind diese Features einsatzbereit oder müssen Sie sie selbst implementieren?
  6. Zusätzliche Tools bereitstellen und konfigurieren. Müssen Sie zusätzliche Hardware- oder Softwarekomponenten bereitstellen und konfigurieren?

Google Cloud bietet die folgenden Optionen, um die Architektur einer Multi-Cluster-GKE-Umgebung zu entwerfen. Zur Auswahl der besten Option für Ihre Arbeitslasten sollten Sie sie zuerst mit den von Ihnen festgelegten Bewertungskriterien vergleichen. Verwenden Sie eine beliebige, geordnete Skala, um jeder Entwurfsoption eine Punktzahl für jedes Bewertungskriterium zuzuweisen. Zum Beispiel können Sie jeder Umgebung für jedes Bewertungskriterium eine Punktzahl von 1 bis 10 zuweisen. Die folgenden Optionen werden in aufsteigender Reihenfolge danach dargestellt, wie viel Aufwand für die Verwaltung der neuen Multi-Cluster-GKE-Umgebung erforderlich ist.

  1. Multi-Cluster-Ingress und Multi-Cluster-Service-Discovery
  2. Multi-Cluster-Ingress und Anthos Service Mesh
  3. Traffic Director
  4. Kubernetes- und selbstverwaltete DNS-Eintragsaktualisierungen

In den folgenden Abschnitten werden diese Optionen im Detail beschrieben und es wird eine Liste der Kriterien zur Bewertung der einzelnen Optionen bereitgestellt. Gegebenenfalls können Sie einigen der Kriterien Punktzahlen zuweisen, indem Sie die Produktdokumentation lesen. Beispiel: Durch Lesen der Dokumentation können Sie Anthos Service Mesh anhand einiger der zuvor festgelegten Bewertungskriterien bewerten. Allerdings müssen Sie möglicherweise detailliertere Benchmarks und Simulationen entwerfen und ausführen, um für andere Kriterien Punktzahlen verteilen zu können. So kann es beispielsweise erforderlich sein, die Leistung verschiedener Multi-Cluster-GKE-Architekturen zu vergleichen, um zu beurteilen, ob sie für Ihre Arbeitslasten geeignet sind.

Multi-Cluster-Ingress und Multi-Cluster-Service-Discovery

Multi-Cluster-Ingress ist ein von Google verwalteter Dienst, mit dem Sie Arbeitslasten unabhängig von der Bereitstellung des GKE-Clusters verfügbar machen können. Darüber hinaus können Sie freigegebene Load-Balancer für GKE-Cluster und regionenübergreifend konfigurieren. Weitere Informationen zur Verwendung von Multi-Cluster-Ingress in einer Multi-Cluster-GKE-Umgebung finden Sie unter Multi-Cluster-GKE-Upgrades mit Multi-Cluster-Ingress und Migration mit Istio-Mesh-Erweiterung unterstützen.

Multi-Cluster-Service-Discovery ist ein Kubernetes-nativer, clusterübergreifender Service-Discovery- und Konnektivitätsmechanismus für GKE. Multi-Cluster-Service-Discovery baut auf der Kubernetes-Service-Ressource auf, damit Anwendungen über Clustergrenzen hinweg erkannt und miteinander verbunden werden können. Verwenden Sie die folgende Liste, geordnet nach relativer Wichtigkeit, um Multi-Cluster-Ingress und Multi-Cluster-Service-Discovery anhand der zuvor festgelegten Kriterien zu bewerten:

  1. Von Google verwaltete Lösung Multi-Cluster-Service-Discovery ist ein vollständig verwaltetes Feature von GKE. Es konfiguriert Ressourcen (Cloud DNS-Zonen und -Einträge, Firewallregeln und Traffic Director), damit Sie sie nicht selbst verwalten müssen.
  2. Schnittstellen zur Interaktion mit der Architektur. Services werden mithilfe einer deklarativen Kubernetes-Ressource namens ServiceExport in andere Cluster exportiert.
  3. Dienste außerhalb der GKE-Umgebung verfügbar machen. Wenn Sie Multi-Cluster-Ingress und Multi-Cluster-Service-Discovery verwenden, können Sie Ihre Arbeitslasten außerhalb Ihrer GKE-Cluster verfügbar machen, unabhängig davon, wo sie bereitgestellt wurden.
  4. Kommunikation zwischen Clustern. Sie können vorhandene Services in andere GKE-Cluster exportieren, indem Sie ein ServiceExport-Objekt deklarieren. GKE-Cluster in derselben Flotte importieren automatisch Services, die Sie mit ServiceExport-Objekten exportieren. Multi-Cluster-Service-Discovery richtet eine virtuelle IP-Adresse für jeden exportierten Service ein. Multi-Cluster-Service-Discovery konfiguriert Traffic Director-Ressourcen, Cloud DNS und Firewallregeln automatisch, um mithilfe einer einfachen Variante der Kubernetes-DNS-Konvention Services zu erkennen und eine Verbindung zu ihnen herzustellen. Wenn Sie beispielsweise den Service my-svc erreichen möchten, können Sie den Namen my-svc.my-ns.svc.clusterset.local verwenden.
  5. Traffic-Verwaltung. Multi-Cluster-Service-Discovery konfiguriert einfache Layer-3/4-Verbindungen und verwendet DNS für die Service Discovery. Es bietet keine Funktionen zur Traffic-Verwaltung.
  6. Zusätzliche Tools bereitstellen und konfigurieren. Sie können Multi-Cluster-Service-Discovery einrichten, indem Sie Google APIs aktivieren. Es ist keine Installation zusätzlicher Tools erforderlich. Weitere Informationen finden Sie unter Container zu Google Cloud migrieren: Migration zu einer Multi-Cluster-GKE-Umgebung mit Multi-Cluster-Service-Discovery und Multi-Cluster-Ingress.

Multi-Cluster-Ingress und Anthos Service Mesh

Ein Service Mesh ist ein Architekturmuster, das bei den Netzwerk-Herausforderungen verteilter Anwendungen hilfreich ist. Zu diesen Herausforderungen gehören Service Discovery, Load-Balancing, Fehlertoleranz, Traffic-Steuerung, Beobachtbarkeit, Authentifizierung, Autorisierung und Verschlüsselung während der Übertragung. Typische Service-Mesh-Implementierungen bestehen aus einer Datenebene und einer Steuerungsebene. Die Datenebene ist für die direkte Verarbeitung und Weiterleitung des Traffics an die Zielarbeitslasten verantwortlich, normalerweise mithilfe von Sidecar-Proxys. Die Steuerungsebene bezieht sich auf die Komponenten, die die Datenebene konfigurieren.

Wenn Sie das Service-Mesh-Muster in Ihrer Infrastruktur implementieren, können Sie zwischen zwei Google Cloud-Produkten wählen: Anthos Service Mesh und Traffic Director. Beide Produkte bieten eine Steuerungsebene zum Konfigurieren eines L7-Netzwerks (Anwendungsschicht) für mehrere GKE-Cluster. Anthos Service Mesh basiert auf Istio und bietet deklarative Open-Source-APIs. Traffic Director basiert auf einer Kombination aus Google-Load-Balancing-Features und Open-Source-Technologien und bietet imperative Google APIs.

Anthos Service Mesh ist eine von Google verwaltete Toolsuite, mit der Sie Ihre Arbeitslasten unabhängig von dem GKE-Cluster, in dem sie bereitgestellt werden, und ohne Ändern Ihres Anwendungscodes verbinden, verwalten, schützen und überwachen können. Weitere Informationen zur Verwendung von Anthos Service Mesh zum Einrichten eines Mesh-Netzwerks, das sich über mehrere GKE-Cluster erstreckt, finden Sie unter GKE-Cluster zu Anthos Service Mesh hinzufügen. Verwenden Sie die folgende Liste, geordnet nach der relativen Wichtigkeit, um Multi-Cluster-Ingress und Anthos Service Mesh anhand der zuvor festgelegten Kriterien zu bewerten:

  1. Von Google verwaltete Lösung Sowohl Multi-Cluster-Ingress als auch Anthos Service Mesh sind vollständig verwaltete Produkte. Sie müssen diese Produkte nicht bereitstellen, da Google sie für Sie verwaltet.
  2. Schnittstellen zur Interaktion mit der Architektur. Anthos Service Mesh verwendet Istio als Kernelement. Die Anthos Service Mesh API unterstützt die deklarative Konfiguration, die auf dem Kubernetes-Ressourcenmodell basiert.
  3. Dienste außerhalb der GKE-Umgebung verfügbar machen. Mit Ingress-Gateways mit Multi-Cluster-Ingress und Anthos Service Mesh können Sie Ihre Arbeitslasten außerhalb Ihrer GKE-Cluster verfügbar machen.
  4. Kommunikation zwischen Clustern. Anthos Service Mesh richtet sichere Kommunikationskanäle direkt zwischen Pods ein, unabhängig davon, in welchem Cluster sie ausgeführt werden. So brauchen Sie diese Kommunikationskanäle nicht mit zusätzlichem Aufwand bereitstellen und konfigurieren. Anthos Service Mesh nutzt das Konzept der Flotten und der Dienstgleichheit, um GKE-Service-Discovery auf mehrere Cluster zu erweitern. Daher müssen Sie Ihre Arbeitslasten nicht ändern, um Arbeitslasten zu erkennen, die in anderen Clustern im Mesh-Netzwerk ausgeführt werden.
  5. Traffic-Verwaltung. Anthos Service Mesh bietet erweiterte Features zur Traffic-Verwaltung, mit denen Sie steuern können, wie eingehender Traffic gesichert und an Arbeitslasten weitergeleitet wird. Anthos Service Mesh unterstützt zum Beispiel alle Istio-Traffic-Verwaltungsfeatures wie Fehlerinjektion, Zeitüberschreitungen und Wiederholungen von Anfragen, Trennschalter, Traffic-Spiegelung und Traffic-Verschiebung. Sie können diese Features zur Traffic-Verwaltung auch verwenden, um die Migration zu einer neuen GKE-Umgebung zu vereinfachen. Sie können beispielsweise den Traffic schrittweise von der alten zur neuen Umgebung verschieben.
  6. Zusätzliche Tools bereitstellen und konfigurieren. Wenn Sie Multi-Cluster-Ingress verwenden möchten, müssen Sie die Voraussetzungen für Multi-Cluster-Service-Discovery erfüllen. Sie müssen jedoch keine zusätzlichen Tools in Ihren GKE-Clustern installieren. Wenn Sie Anthos Service Mesh verwenden möchten, müssen Sie es in Ihren Clustern installieren.

Traffic Director

Traffic Director ist eine verwaltete Steuerungsebene für das Anwendungsnetzwerk. Sie können damit umfangreiche Service-Mesh-Topologien mit erweiterten Features zur Traffic-Verwaltung und Beobachtbarkeit bereitstellen und konfigurieren. Weitere Informationen zu Traffic Director finden Sie unter Traffic Director – Übersicht und Traffic Director-Features. Zum Bereitstellen und Konfigurieren eines Service Mesh, das sich über mehrere GKE-Cluster erstreckt, können Sie eine Multi-Cluster- oder eine Multi-Umgebungs-Traffic Director-Konfiguration verwenden. Verwenden Sie die folgende Liste, geordnet nach relativer Wichtigkeit, um Traffic Director anhand der zuvor festgelegten Kriterien zu bewerten:

  1. Von Google verwaltete Lösung Traffic Director ist ein vollständig verwaltetes Produkt. Sie müssen solche Produkte nicht bereitstellen, da Google sie für Sie verwaltet.
  2. Schnittstellen zur Interaktion mit der Architektur. Sie können Traffic Director mithilfe der Google Cloud Console, der Google Cloud CLI, der Traffic Director API oder Tools wie Terraform konfigurieren. Traffic Director unterstützt ein imperatives Konfigurationsmodell und baut auf Open-Source-Produkten und -Technologien auf, z. B. xDS und gRPC.
  3. Dienste außerhalb der GKE-Umgebung verfügbar machen. Traffic Director bietet und konfiguriert Load-Balancer für die Verarbeitung von eingehendem Traffic von außerhalb des Dienstnetzwerks.
  4. Kommunikation zwischen Clustern. Die Traffic Director-Steuerungsebene bietet APIs, mit denen Sie Endpunkte (z. B. GKE-Pods in mehreren Clustern) in Dienst-Back-Ends gruppieren können. Diese Back-Ends können dann von anderen Clients im Mesh aus weitergeleitet werden. Traffic Director ist nicht direkt in die GKE-Service-Discovery eingebunden. Sie können die Integration jedoch optional mit einem Open-Source-Controller wie gke-autoneg-controller automatisieren. Optional können Sie auch Multi-Cluster-Service-Discovery verwenden, um die GKE-Service-Discovery auf mehrere Cluster zu erweitern.
  5. Traffic-Verwaltung. Traffic Director bietet erweiterte Features zur Traffic-Verwaltung, mit denen Sie die Migration zu einer neuen GKE-Umgebung vereinfachen und die Zuverlässigkeit Ihrer Architektur verbessern können. Informationen zum Konfigurieren von Features wiedetailliertem Traffic-Routing, gewichteter Traffic-Aufteilung, Traffic-Spiegelung und Feinabstimmung des Load-Balancings finden Sie unter Erweiterte Traffic-Verwaltung konfigurieren.
  6. Zusätzliche Tools bereitstellen und konfigurieren. Traffic Director wird nicht in Ihren GKE-Clustern ausgeführt. Informationen zum Bereitstellen und Konfigurieren von Traffic Director finden Sie unter Traffic Director-Einrichtung vorbereiten. Informationen zum Konfigurieren der Sidecar-Pods, die Traffic Director in das Dienstnetzwerk aufnehmen muss, finden Sie unter Traffic Director mit Envoy auf GKE-Pods bereitstellen.

Kubernetes- und selbstverwaltete DNS-Eintragsaktualisierungen

Wenn Sie keine zusätzliche Software in Ihrem Cluster installieren möchten und die Features eines Service Mesh nicht benötigen, können Sie die Option für Kubernetes- und selbstverwaltete DNS-Eintragsaktualisierungen auswählen.

Sie können zwar die Erkennung und Konnektivität zwischen Clustern mit dieser Option konfigurieren, wir empfehlen jedoch, eine der anderen in diesem Dokument beschriebenen Optionen auszuwählen. Der Aufwand für den Betrieb einer selbstverwalteten Lösung überschreitet deutlich die Vorteile, die Sie im Gegenzug erhalten könnten. Beachten Sie auch die folgenden wichtigen Einschränkungen:

Wenn Sie einen Service mit type: LoadBalancer oder ein Ingress-Objekt in einem GKE-Cluster erstellen, erstellt GKE automatisch Netzwerk-Load-Balancer und HTTP(S)-Load-Balancer, um diesen Service mithilfe der IP-Adresse des Load-Balancers verfügbar zu machen. Sie können die IP-Adressen der Load-Balancer verwenden, um mit Ihren Services zu kommunizieren. Wir empfehlen jedoch, die Abhängigkeit von IP-Adressen zu vermeiden, indem Sie diese IP-Adressen DNS-Einträgen mit Cloud DNS oder Service Directory-Endpunkten zuordnen, die Sie mithilfe von DNS abfragen können, und wir empfehlen, dass Sie Ihre Clients für die Verwendung dieser DNS-Einträge konfigurieren. Sie können mehrere Instanzen des Service bereitstellen und alle resultierenden IP-Adressen des Load-Balancers dem zugehörigen DNS-Eintrag oder dem Service Directory-Endpunkt zuordnen.

Wenn Sie eine Instanz eines Service entfernen möchten, entfernen Sie zuerst die IP-Adresse des zugehörigen Load-Balancers aus dem entsprechenden DNS-Eintrag oder dem Service Directory-Endpunkt. Prüfen Sie dann, ob der DNS-Cache der Clients aktualisiert wurde, und entfernen Sie dann den Service.

Sie können Ihre Arbeitslasten so konfigurieren, dass sie über verschiedene GKE-Cluster hinweg miteinander kommunizieren können. Dazu machen Sie Ihre Dienste zuerst außerhalb des Clusters mithilfe von internen TCP/UDP-Load-Balancern oder internen HTTP(S)-Load-Balancern verfügbar. Anschließend ordnen Sie die IP-Adressen der Load-Balancer den DNS-Einträgen oder Service Directory-Endpunkten zu. Schließlich erstellen Sie Services mit type: ExternalName, die in jedem Cluster auf diese DNS-Einträge oder Service Directory-Endpunkte verweisen.

Optional können Sie einen zusätzlichen Ingress-Controller verwenden, um einen einzelnen Load-Balancer und einen Cloud DNS-Eintrag oder Service Directory-Endpunkt für mehrere Arbeitslasten freizugeben. Wenn Sie beispielsweise einen Ingress-Controller in einem Cluster bereitstellen, können Sie ihn so konfigurieren, dass Anfragen an den Load-Balancer, den GKE für diesen Ingress-Controller erstellt, an mehrere Services weitergeleitet werden. Mit einem zusätzlichen Ingress-Controller können Sie die Anzahl der DNS-Einträge oder Service Directory-Endpunkte reduzieren, die Sie verwalten müssen.

Verwenden Sie die folgende Liste, geordnet nach der relativen Wichtigkeit, um Kubernetes- und selbstverwaltete DNS-Eintragsaktualisierungen anhand der zuvor festgelegten Kriterien zu bewerten:

  1. Von Google verwaltete Lösung Sie verwalten die Kubernetes-Objekte, die Teil dieser Lösung sind, selbst. Cloud DNS, Service Directory und Load Balancing sind von Google verwaltete Dienste.
  2. Schnittstellen zur Interaktion mit der Architektur. GKE nutzt Kubernetes als Kernelement und unterstützt sowohl imperative als auch deklarative Konfigurationsmodelle.
  3. Dienste außerhalb der GKE-Umgebung verfügbar machen. Sie können DNS-Einträge, Service Directory-Endpunkte und Load-Balancer verwenden, um Dienste für Clients außerhalb Ihrer GKE-Cluster verfügbar zu machen.
  4. Kommunikation zwischen Clustern. Mit Diensten mit type: ExternalName können Sie Endpunkte definieren, die auf Dienste verweisen, die im anderen GKE-Cluster bereitgestellt sind. Bei dieser Konfiguration können die Dienste miteinander kommunizieren, als ob sie im selben Cluster bereitgestellt wären.
  5. Traffic-Verwaltung. Die Lösung bietet keine zusätzlichen Funktionen zur Traffic-Verwaltung als die, die bereits von Kubernetes und GKE angeboten werden. Diese Option unterstützt beispielsweise keine Partitionierung von Traffic zwischen verschiedenen Clustern.
  6. Zusätzliche Tools bereitstellen und konfigurieren. Für diese Option muss keine zusätzliche Software bereitgestellt und in Ihren GKE-Clustern konfiguriert werden. Optional können Sie einen Ingress-Controller installieren.

Architektur auswählen

Nachdem Sie allen Kriterien für jede Option einen Wert zugewiesen haben, berechnen Sie die Gesamtpunktzahl jeder Option. Um die Gesamtpunktzahl für jede Option zu berechnen, addieren Sie alle Bewertungen dieser Entwurfsoption für die Kriterien. Beispiel: Wenn eine Umgebung 10 Punkte für ein Kriterium und 6 Punkte für ein anderes Kriterium erhalten hat, ist die Gesamtpunktzahl dieser Option 16.

Sie haben auch die Möglichkeit, jedem Kriterium verschiedene Gewichtungen zuzuweisen, damit Sie die Bedeutung des jeweiligen Kriteriums darstellen können. Wenn beispielsweise eine von Google verwaltete Lösung bei Ihrer Bewertung wichtiger ist als die Unterstützung einer Architektur mit verteilter Arbeitslast, könnten Sie Multiplikatoren definieren, die dies widerspiegeln: einen Multiplikator von 1,0 für eine von Google verwaltete Lösung und einen Multiplikator von 0,7 für die Architektur mit verteilter Arbeitslast. Mit diesen Multipliers können Sie dann die Gesamtpunktzahl einer Option berechnen.

Nachdem Sie die Gesamtpunktzahl der bewerteten Umgebungen berechnet haben, sortieren Sie die Umgebungen nach ihrer Gesamtpunktzahl in absteigender Reihenfolge. Wählen Sie dann die Option mit dem höchsten Wert für die gewünschte Umgebung aus.

Es gibt mehrere Möglichkeiten, diese Daten darzustellen. Sie können die Ergebnisse beispielsweise mit einem Diagramm visualisieren, das zur Darstellung von multivariaten Daten geeignet ist, wie z. B. als Netzdiagramm.

Daten aus Ihrer alten Umgebung in die neue Umgebung migrieren

Informationen zum Migrieren von Daten aus Ihrer alten Umgebung in die neue finden Sie unter Von Kubernetes zu GKE migrieren: Daten aus Ihrer alten Umgebung in die neue Umgebung migrieren.

Arbeitslasten bereitstellen

Informationen zum Migrieren von Daten aus Ihrer alten Umgebung in die neue Umgebung finden Sie unter Arbeitslasten bereitstellen.

Mit allen in diesem Dokument vorgeschlagenen Architekturen können Sie Ihre Arbeitslasten ohne Ausfallzeit oder Umstellungsfenster von einer vorhandenen GKE-Umgebung in eine neue Multi-Cluster-Umgebung migrieren. So migrieren Sie Ihre Arbeitslasten ohne Ausfallzeiten:

  1. Binden Sie Ihre vorhandenen Legacy-GKE-Cluster vorübergehend in die neue Multi-Cluster-GKE-Umgebung ein.
  2. Stellen Sie Instanzen Ihrer Arbeitslasten in Ihrer neuen Multi-Cluster-Umgebung bereit.
  3. Migrieren Sie den Traffic schrittweise aus Ihrer vorhandenen Umgebung, damit Sie Ihre Arbeitslasten schrittweise zu den neuen GKE-Clustern migrieren und dann die Legacy-GKE-Cluster entfernen können.

Bereitstellung abschließen

Nachdem Sie Ihre Laufzeitplattform und -umgebungen bereitgestellt und konfiguriert haben, führen Sie die unter Von Kubernetes zu GKE migrieren: Arbeitslasten bereitstellen beschriebenen Aktivitäten aus.

Umgebung optimieren

Die Optimierung ist die letzte Phase Ihrer Migration. In dieser Phase machen Sie Ihre Umgebung effizienter als zuvor. Um Ihre Umgebung zu optimieren, führen Sie mehrere Iterationen der folgenden wiederholbaren Schleife aus, bis Ihre Umgebung Ihre Optimierungsanforderungen erfüllt:

  1. Aktuelle Umgebung, Teams und Optimierungsschleife bewerten
  2. Optimierungsanforderungen und -ziele festlegen
  3. Umgebung und Teams optimieren
  4. Optimierungsschleife verbessern

Informationen zum Optimieren Ihrer GKE-Umgebung finden Sie unter Von Kubernetes zu GKE migrieren: Umgebung optimieren.

Nächste Schritte