Von Edge zu Multi-Cluster-Mesh: Global verteilte Anwendungen, die über GKE Gateway und Cloud Service Mesh verfügbar gemacht werden

Last reviewed 2024-06-30 UTC

In dieser Referenzarchitektur werden die Vorteile der externen Bereitstellung von Anwendungen über Google Kubernetes Engine-Gateways (GKE) beschrieben, die auf mehreren GKE-Clustern innerhalb eines Service Mesh ausgeführt werden. Dieser Leitfaden richtet sich an Plattformadministratoren.

Sie können die Ausfallsicherheit und Redundanz Ihrer Dienste erhöhen, indem Sie Anwendungen konsistent in mehreren GKE-Clustern bereitstellen, wobei jeder Cluster eine zusätzliche Fehlerdomain darstellt. Die Recheninfrastruktur eines Dienstes mit einem SLO (Service Level Objective) von 99,9% erreicht beispielsweise ein SLO von 99,9999 %, wenn sie in zwei GKE-Clustern bereitgestellt wird (1 – (0,001)2). Sie können Nutzern auch eine Umgebung bieten, in der eingehende Anfragen automatisch an das Mesh-Ingress-Gateway mit der geringsten Latenz und Verfügbarkeit weitergeleitet werden.

Wenn Sie mehr über die Vorteile der Bereitstellung von Service Mesh-fähigen Anwendungen erfahren möchten, die in einem einzelnen Cluster ausgeführt werden, lesen Sie Von Edge zu Mesh: Service Mesh-Anwendungen über GKE Gateway verfügbar machen.

Architektur

Das folgende Architekturdiagramm zeigt, wie Daten bei Cloud-Ingress und Mesh-Ingress fließen:

TLS-Verschlüsselung vom Client, einem Load Balancer und vom Mesh

Das obige Diagramm zeigt die folgenden Datenflussszenarien:

  • Vom Client, der am Google Cloud Load Balancer mit seinem eigenen von Google verwalteten TLS-Zertifikat beendet wird.
  • Vom Google Cloud Load-Balancer zum Mesh-Ingress-Proxy mit einem eigenen selbst signierten TLS-Zertifikat.
  • Vom Mesh-Ingress-Gateway-Proxy zu den Sidecar-Proxys der Arbeitslasten mit mTLS für Service Mesh.

Diese Referenzarchitektur enthält die folgenden beiden Ingress-Ebenen:

  • Cloud-Ingress:In dieser Referenzarchitektur verwenden Sie die Kubernetes Gateway API (und den GKE Gateway-Controller), um die externe, clusterübergreifende HTTP(S)-Load-Balancing-Schicht zu programmieren. Der Load Balancer prüft die Mesh-Ingress-Proxys in mehreren Regionen und sendet Anfragen an den nächstgelegenen fehlerfreien Cluster. Außerdem wird eine Google Cloud Armor-Sicherheitsrichtlinie implementiert.
  • Mesh-Ingress: Im Mesh führen Sie Systemdiagnosen direkt auf den Back-Ends durch, damit Sie das Load-Balancing und die Trafficverwaltung lokal ausführen können.

Wenn Sie die Ingress-Ebenen zusammen verwenden, gibt es für jede Ebene ergänzende Rollen. Um die folgenden Ziele zu erreichen, Google Cloud werden die am besten geeigneten Funktionen aus der Cloud-Ingress-Ebene und der Mesh-Ingress-Ebene optimiert:

  • Niedrige Latenz
  • Verfügbarkeit erhöhen
  • Sicherheitsfunktionen der Cloud-Eingangsschicht verwenden
  • Nutzen Sie die Sicherheits-, Autorisierungs- und Beobachtbarkeitsfunktionen der Mesh-Ingress-Ebene.

Cloud-Ingress

In Kombination mit Mesh-Ingress wird die Cloud-Ingress-Ebene am besten für Edge-Sicherheit und globales Load-Balancing verwendet. Da die Cloud-Ingress-Ebene in die folgenden Dienste integriert ist, eignet sie sich hervorragend für die Ausführung dieser Dienste am Netzwerkrand außerhalb des Mesh-Netzwerks:

  • DDoS-Schutz
  • Cloud-Firewalls
  • Authentifizierung und Autorisierung
  • Verschlüsselung

Die Routinglogik ist in der Regel unkompliziert. In Multi-Cluster- und Multi-Region-Umgebungen kann es jedoch komplexer sein.

Aufgrund der entscheidenden Funktion von Load-Balancern im Internet wird die Cloud-Ingress-Ebene wahrscheinlich von einem Plattformteam verwaltet, das die exklusive Kontrolle darüber hat, wie Anwendungen im Internet verfügbar gemacht und geschützt werden. Durch diese Steuerung wird diese Ebene weniger flexibel und dynamisch als eine entwicklergesteuerte Infrastruktur. Berücksichtigen Sie diese Faktoren, wenn Sie die Administratorzugriffsrechte für diese Ebene festlegen und entscheiden, wie Sie diesen Zugriff gewähren.

Mesh-Ingress

In Kombination mit Cloud-Ingress bietet die Mesh-Ingress-Ebene einen Einstiegspunkt für Traffic in das Service Mesh. Die Ebene bietet außerdem Backend-mTLS, Autorisierungsrichtlinien und flexibles Regex-Matching.

Das Bereitstellen eines externen Application Load Balancer außerhalb des Mesh-Netzwerks mit einer Mesh-Ingress-Ebene bietet entscheidende Vorteile, insbesondere für die Verwaltung von Internet-Traffic. Obwohl Service Mesh und Istio-Ingress-Gateways eine erweiterte Routing- und Trafficverwaltung im Mesh ermöglichen, sind einige Funktionen am Netzwerkrand besser geeignet. Die Nutzung der Vorteile eines Internet-Edge-Netzwerks durch den externen Application Load Balancer vonGoogle Cloudkönnte erhebliche Vorteile in Bezug auf die Leistung, Zuverlässigkeit oder Sicherheit gegenüber dem meshbasierten Ingress bieten.

Verwendete Produkte und Funktionen

In der folgenden Liste sind alle Google Cloud Produkte und ‑Funktionen zusammengefasst, die in dieser Referenzarchitektur verwendet werden:

  • GKE Enterprise: Ein verwalteter Kubernetes-Dienst, mit dem Sie Containeranwendungen in großem Maßstab mithilfe der Infrastruktur von Google bereitstellen und betreiben können. Für diese Referenzarchitektur müssen sich alle GKE-Cluster, die eine Anwendung bereitstellen, in derselben Flotte befinden.
  • Flotten und Multi-Cluster-Gateways: Dienste, mit denen containerisierte Anwendungen im Enterprise-Maßstab mit der Infrastruktur von Google und GKE Enterprise erstellt werden.
  • Google Cloud Armor: Ein Dienst, mit dem Sie Ihre Anwendungen und Websites vor Denial-of-Service- und Webangriffen schützen können.
  • Cloud Service Mesh: Ein vollständig verwaltetes Service Mesh, das auf Envoy und Istio basiert
  • Application Load Balancer: Ein proxybasierter L7-Load Balancer, mit dem Sie Ihre Dienste ausführen und skalieren können.
  • Certificate Manager: Ein Dienst, mit dem Sie TLS-Zertifikate für die Verwendung mit Cloud Load Balancing erwerben und verwalten können.

Flotten

Zur Verwaltung von Multi-Cluster-Deployments verwenden GKE Enterprise und Google Cloud Flotten, um Kubernetes-Cluster logisch zu gruppieren und zu normalisieren.

Mit einer oder mehreren Flotten können Sie die Verwaltung von einzelnen Clustern bis hin zu ganzen Clustergruppen optimieren. Um die Clusterverwaltung zu vereinfachen, sollten Sie das Flottenprinzip der Namespace-Gleichheit verwenden. Konfigurieren Sie alle Mesh-Ingress-Gateways in jedem GKE-Cluster in einer Flotte auf dieselbe Weise.

Stellen Sie außerdem Anwendungsdienste konsistent bereit, sodass sich der Dienst „balance-reader“ im Namespace-Konto auf einen identischen Dienst in jedem GKE-Cluster in der Flotte bezieht. Die Prinzipien der Gleichheit und des Vertrauens, die in einer Flotte vorausgesetzt werden, sind die Basis, mit der Sie das umfassende Portfolio an flottenfähigen Funktionen in GKE Enterprise und Google Cloudnutzen können.

Ost-West-Routingregeln innerhalb des Service Mesh und Traffic-Richtlinien werden auf der Mesh-Ingress-Ebene verarbeitet. Die Mesh-Ingress-Ebene wird in jedem GKE-Cluster in der Flotte bereitgestellt. Konfigurieren Sie jedes Mesh-Ingress-Gateway auf dieselbe Weise und halten Sie sich dabei an das Flottenprinzip der Namespace-Gleichheit.

Obwohl es einen einzelnen Konfigurationscluster für GKE Gateway gibt, sollten Sie Ihre GKE Gateway-Konfigurationen in allen GKE-Clustern in der Flotte synchronisieren.

Wenn Sie einen neuen Konfigurationscluster festlegen müssen, verwenden Sie ConfigSync. Config Sync sorgt dafür, dass alle diese Konfigurationen in allen GKE-Clustern in der Flotte synchronisiert werden, und hilft, die Abstimmung mit einer nicht aktuellen Konfiguration zu vermeiden.

Mesh-Ingress-Gateway

Istio 0.8 hat das Mesh-Ingress-Gateway eingeführt. Das Gateway bietet einen dedizierten Satz von Proxys, deren Ports für Traffic von außerhalb des Service Mesh freigegeben werden. Mit diesen Mesh-Ingress-Proxys können Sie das Bereitstellungsverhalten des Netzwerks getrennt vom Routing-Verhalten der Anwendung steuern.

Mit den Proxys können Sie außerdem Routing und Richtlinien auf externen Mesh-Traffic anwenden, bevor dieser am Anwendungs-Sidecar eingeht. Beim Mesh-Ingress wird die Handhabung des Traffics festgelegt, wenn er einen Knoten im Mesh-Netzwerk erreicht. Externe Komponenten müssen jedoch festlegen, wie der Traffic zuerst im Mesh-Netzwerk ankommt.

Zum Verwalten des externen Traffics benötigen Sie einen Load-Balancer außerhalb des Mesh-Netzwerks. Zur Automatisierung der Bereitstellung wird in dieser Referenzarchitektur Cloud Load Balancing verwendet, das über GKE Gateway-Ressourcen bereitgestellt wird.

GKE Gateway und Multi-Cluster-Services

Es gibt viele Möglichkeiten, Clients außerhalb des Clusters Anwendungszugriff zu gewähren. GKE Gateway ist eine Implementierung der Kubernetes Gateway API. GKE Gateway entwickelt die Ingress-Ressource weiter und verbessert sie.

Wenn Sie GKE Gateway-Ressourcen in Ihrem GKE-Cluster bereitstellen, überwacht der Gateway-Controller die Gateway API-Ressourcen. Der Controller gleicht Cloud Load Balancing-Ressourcen ab, um das von den Gateway-Ressourcen angegebene Netzwerkverhalten zu implementieren.

Wenn Sie GKE Gateway verwenden, hängt die Art des Load Balancers, den Sie zum Freigeben von Anwendungen für Clients verwenden, weitgehend von den folgenden Faktoren ab:

  • Ob sich die Backend-Dienste in einem einzelnen GKE-Cluster befinden oder auf mehrere GKE-Cluster (in derselben Flotte) verteilt sind.
  • Der Status der Clients (extern oder intern).
  • Die erforderlichen Funktionen des Load Balancers, darunter die Einbindung in Sicherheitsrichtlinien von Google Cloud Armor.
  • Die Anforderungen an die Reichweite des Service Mesh. Service Meshes können mehrere GKE-Cluster umfassen oder in einem einzelnen Cluster enthalten sein.

In Gateway wird dieses Verhalten durch Angabe der entsprechenden GatewayClass gesteuert. Wenn Sie sich auf Gateway-Klassen beziehen, haben die Klassen, die in Multi-Cluster-Szenarien verwendet werden können, einen Klassennamen, der auf -mc endet.

In dieser Referenzarchitektur wird beschrieben, wie Sie Anwendungsdienste extern über einen externen Application Load Balancer verfügbar machen. Wenn Sie Gateway verwenden, können Sie jedoch auch einen regionalen internen Application Load Balancer für mehrere Cluster erstellen.

Wenn Sie Anwendungsdienste in Multicluster-Szenarien bereitstellen möchten, können Sie dieGoogle Cloud -Load-Balancer-Komponenten auf zwei Arten definieren:

Weitere Informationen zu diesen beiden Ansätzen zum Bereitstellen von Anwendungsdiensten finden Sie unter Multi-Cluster-Load-Balancing-API für GKE auswählen.

Multi-Cluster-Ingress basiert auf der Erstellung von MultiClusterService-Ressourcen. Multi-Cluster-Gateway basiert auf dem Erstellen von ServiceExport-Ressourcen und dem Verweisen auf ServiceImport-Ressourcen.

Wenn Sie ein Multi-Cluster-Gateway verwenden, können Sie die zusätzlichen Funktionen des zugrunde liegenden Google Cloud Load-Balancers aktivieren, indem Sie Richtlinien erstellen. Im Bereitstellungsleitfaden zu dieser Referenzarchitektur wird beschrieben, wie Sie eine Google Cloud Armor-Sicherheitsrichtlinie konfigurieren, um Backend-Dienste vor Cross-Site-Scripting zu schützen.

Diese Richtlinienressourcen sind auf die Backend-Dienste in der Flotte ausgerichtet, die in mehreren Clustern verfügbar gemacht werden. In Multi-Cluster-Szenarien müssen alle diese Richtlinien auf die ServiceImport-Ressource und API-Gruppe verweisen.

Systemdiagnose

Die Verwendung von zwei Schichten des L7-Load-Balancings ist die Systemdiagnose. Sie müssen jeden Load Balancer so konfigurieren, dass er den Status der nächsten Ebene prüft. Das GKE-Gateway prüft die Integrität der Mesh-Ingress-Proxys und das Mesh-Netzwerk prüft die Integrität der Anwendungs-Back-Ends.

  • Cloud-Ingress: In dieser Referenzarchitektur konfigurieren Sie denGoogle Cloud Load-Balancer über das GKE Gateway, um den Status der Mesh-Ingress-Proxys auf den freigegebenen Systemdiagnose-Ports zu prüfen. Wenn ein Mesh-Proxy ausgefallen ist oder der Cluster, das Mesh-Netzwerk oder die Region nicht verfügbar ist, erkennt der Google Cloud Load-Balancer diese Bedingung und sendet keinen Traffic an den Mesh-Proxy. In diesem Fall wird der Traffic an einen alternativen Mesh-Proxy in einem anderen GKE-Cluster oder einer anderen Region weitergeleitet.
  • Mesh-Ingress: In der Mesh-Anwendung führen Sie Systemdiagnosen direkt auf den Back-Ends durch, damit Sie das Load-Balancing und die Trafficverwaltung lokal ausführen können.

Designaspekte

Dieser Abschnitt enthält eine Anleitung zur Verwendung dieser Referenzarchitektur, um eine Architektur zu entwickeln, die Ihren spezifischen Anforderungen an Sicherheit und Compliance, Zuverlässigkeit und Kosten entspricht.

Sicherheit, Datenschutz und Compliance

Das Architekturdiagramm in diesem Dokument enthält mehrere Sicherheitselemente. Die wichtigsten Elemente sind die Konfiguration der Verschlüsselung und die Bereitstellung von Zertifikaten. GKE Gateway lässt sich für diese Sicherheitszwecke in Certificate Manager einbinden.

Internetclients authentifizieren sich mit den öffentlichen Zertifikaten und stellen eine Verbindung zum externen Load-Balancer als erster Hop in der Virtual Private Cloud (VPC) her. Verweisen Sie auf einen Certificate Manager CertificateMap in Ihrer Gateway-Definition. Der nächste Hop befindet sich zwischen dem Google Front End (GFE) und dem Mesh-Ingress-Proxy. Dieser Hop ist standardmäßig verschlüsselt.

Die Verschlüsselung auf Netzwerkebene zwischen den GFEs und ihren Back-Ends wird automatisch angewendet. Wenn Ihre Sicherheitsanforderungen ergeben, dass der Plattforminhaber die Eigentumsrechte an den Verschlüsselungsschlüsseln behält, können Sie HTTP/2 mit TLS-Verschlüsselung zwischen dem Cluster-Gateway (dem GFE) und dem Mesh-Ingress (der Envoy-Proxy-Instanz) aktivieren.

Wenn Sie HTTP/2 mit TLS-Verschlüsselung zwischen dem Cluster-Gateway und dem Mesh-Ingress aktivieren, können Sie ein selbst signiertes oder ein öffentliches Zertifikat verwenden, um den Traffic zu verschlüsseln. Sie können ein selbst signiertes oder ein öffentliches Zertifikat verwenden, da das GFE sich nicht authentifiziert. Diese zusätzliche Verschlüsselungsebene wird im Bereitstellungsleitfaden zu dieser Referenzarchitektur veranschaulicht.

Verwenden Sie öffentliche Zertifikate nicht wieder, um einen unsachgemäßen Umgang mit Zertifikaten zu vermeiden. Verwenden Sie separate Zertifikate für jeden Load Balancer im Service Mesh.

Um das Erstellen externer DNS-Einträge und TLS-Zertifikate zu vereinfachen, wird im Bereitstellungsleitfaden für diese Referenzarchitektur Cloud Endpoints verwendet. Mit Cloud Endpoints können Sie eine extern verfügbare cloud.goog-Subdomain erstellen. In Enterprise-Szenarien sollten Sie einen geeigneteren Domainnamen verwenden und bei Ihrem DNS-Anbieter einen A-Eintrag erstellen, der auf die globale IP-Adresse des Application Load Balancers verweist.

Wenn das von Ihnen verwendete Service Mesh TLS erfordert, wird der gesamte Traffic zwischen Sidecar-Proxys und der gesamte Traffic zum Mesh-Ingress verschlüsselt. Das Architekturdiagramm zeigt die HTTPS-Verschlüsselung vom Client zum Google Cloud Load-Balancer, vom Load-Balancer zum Mesh-Ingress-Proxy sowie vom Ingress-Proxy zum Sidecar-Proxy.

Zuverlässigkeit und Ausfallsicherheit

Ein wichtiger Vorteil des Multi-Cluster- und multiregionalen Edge-to-Mesh-Musters besteht darin, dass alle Funktionen des Service Mesh für das Ost-West-Load-Balancing verwendet werden können, z. B. Traffic zwischen Anwendungsdiensten.

In dieser Referenzarchitektur wird ein Multi-Cluster-GKE-Gateway verwendet, um eingehenden Cloud-Ingress-Traffic an einen GKE-Cluster weiterzuleiten. Das System wählt einen GKE-Cluster basierend auf seiner Nähe zum Nutzer (basierend auf der Latenz) sowie seiner Verfügbarkeit und seinem Zustand aus. Wenn Traffic das Istio-Ingress-Gateway (den Mesh-Ingress) erreicht, wird er über das Service Mesh an die entsprechenden Back-Ends weitergeleitet.

Eine alternative Methode zum Verarbeiten des Ost-West-Traffics sind Multi-Cluster-Services für alle Anwendungsdienste, die in GKE-Clustern bereitgestellt werden. Wenn Sie Multi-Cluster-Dienste in GKE-Clustern in einer Flotte verwenden, werden Dienstendpunkte in einem ClusterSet zusammengefasst. Wenn ein Dienst einen anderen Dienst aufrufen muss, kann er auf einen beliebigen fehlerfreien Endpunkt des zweiten Dienstes abzielen. Da Endpunkte rotierend ausgewählt werden, kann sich der ausgewählte Endpunkt in einer anderen Zone oder Region befinden.

Ein wichtiger Vorteil der Verwendung von Service Mesh für Ost-West-Traffic anstelle von Multi-Cluster-Services ist, dass Service Mesh das Load-Balancing nach Standort verwenden kann. Load-Balancing für den Ort ist kein Feature von Multi-Cluster-Services, kann aber über eine DestinationRule konfiguriert werden.

Nach der Konfiguration wird bei einem Aufruf von einem Dienst an einen anderen Dienst zuerst versucht, einen Dienstendpunkt in derselben Zone zu erreichen, dann in derselben Region wie der aufrufende Dienst. Schließlich wird der Aufruf nur an einen Endpunkt in einer anderen Region weitergeleitet, wenn ein Dienstendpunkt in derselben Zone oder derselben Region nicht verfügbar ist.

Kostenoptimierung

Wenn Sie diese Multi-Cluster-Architektur unternehmensweit einführen, sind Cloud Service Mesh und Multi-Cluster-Gateway in der Google Kubernetes Engine (GKE) Enterprise Edition enthalten. Außerdem bietet GKE Enterprise viele Funktionen, mit denen Sie GKE-Cluster, Anwendungen und andere Prozesse im großen Maßstab verwalten und steuern können.

Bereitstellung

Informationen zum Bereitstellen dieser Architektur finden Sie unter Von Edge zu Multi-Cluster-Mesh: Global verteilte Anwendungen über GKE Gateway und Cloud Service Mesh bereitstellen.

Nächste Schritte

Beitragende

Autoren:

Weitere Beitragende: