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 des externen Freigebens 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 einheitlich in mehreren GKE-Clustern bereitstellen. Jeder Cluster wird so zu einer zusätzlichen Fehlerdomain. Die Compute-Infrastruktur eines Dienstes mit einem Service Level Objective (SLO) 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 des Freigebens von Service-Mesh-fähigen Anwendungen erfahren möchten, die in einem einzelnen Cluster ausgeführt werden, lesen Sie den Leitfaden 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-Szenarien fließen:

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

Das vorherige Diagramm zeigt die folgenden Datenflussszenarien:

  • Vom Client, der am Google Cloud Load Balancer mit seinem eigenen von Google verwalteten TLS-Zertifikat endet.
  • Vom Google Cloud Load Balancer zum Mesh-Ingress-Proxy mit seinem eigenen selbst signierten TLS-Zertifikat.
  • Vom Mesh-Ingress-Gateway-Proxy zu den Sidecar-Proxys der Arbeitslast mit Service-Mesh-fähigem mTLS.

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 Multi-Cluster-HTTP(S)-Load-Balancing-Ebene 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-Netzwerk 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 optimiert die am besten geeigneten Funktionen der Cloud-Ingress-Ebene und der Mesh-Ingress-Ebene:

  • Niedrige Latenz bieten
  • Verfügbarkeit erhöhen
  • Sicherheitsfunktionen der Cloud-Ingress-Ebene verwenden
  • Sicherheits-, Autorisierungs- und Beobachtbarkeitsfunktionen der Mesh-Ingress-Ebene verwenden

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 auf der Cloud-Ingress-Ebene einfach. Für Multi-Cluster- und Multi-Region-Umgebungen kann sie 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 administrativen Zugriffsrechte für diese Ebene festlegen und 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 flexiblen regulären Ausdrucksabgleich.

Das Bereitstellen eines externen Application Load Balancers außerhalb des Mesh-Netzwerks mit einer Mesh-Ingress-Ebene bietet entscheidende Vorteile, insbesondere für die Internet-Trafficverwaltung. 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 Google Cloud's externen Application Load Balancer kö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: 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, die zum Erstellen von Containeranwendungen im Unternehmen mithilfe der Infrastruktur von Google und GKE verwendet 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.
  • Zertifikatmanager: Ein Dienst, mit dem Sie TLS-Zertifikate für die Verwendung mit Cloud Load Balancing erwerben und verwalten können.

Flotten

Zum Verwalten von Multi-Cluster-Bereitstellungen verwenden GKE 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, verwenden Sie das Flottenprinzip der Namespace-Gleichheit. Konfigurieren Sie für jeden GKE-Cluster in einer Flotte alle Mesh-Ingress-Gateways auf dieselbe Weise.

Stellen Sie außerdem Anwendungsdienste einheitlich bereit, sodass sich der Dienstsaldo 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 und Google Cloudnutzen können.

Ost-West-Routingregeln innerhalb des Service Mesh und Trafficrichtlinien 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. Mit Config Sync können Sie sicherstellen, dass alle diese Konfigurationen in allen GKE-Clustern in der Flotte synchronisiert werden, und vermeiden, dass eine nicht aktuelle Konfiguration abgeglichen wird.

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. Um die Bereitstellung zu automatisieren, wird in dieser Referenzarchitektur Cloud Load Balancing verwendet, das über GKE Gateway-Ressourcen bereitgestellt wird.

GKE Gateway und Multi-Cluster-Dienste

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 in 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 verteilt sind (in derselben Flotte).
  • Der Status der Clients (extern oder intern).
  • Die erforderlichen Funktionen des Load Balancers, darunter die Einbindung in Cloud Armor-Sicherheitsrichtlinien.
  • 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 auf Gateway-Klassen verweisen, haben die Klassen, die in Multi-Cluster-Szenarien verwendet werden können, einen Klassennamen, der mit -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 Multi-Cluster-Application Load Balancer erstellen.

Zum Bereitstellen von Anwendungsdiensten in Multi-Cluster-Szenarien können Sie die Google Cloud Load Balancer-Komponenten auf zwei Arten definieren:

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

Multi-Cluster-Ingress basiert auf dem Erstellen 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 Richtlinienerstellen. 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 zielen auf die Backend-Dienste in der Flotte ab, 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 den Status der Mesh-Ingress-Proxys und das Mesh-Netzwerk prüft die Integrität der Anwendungs-Back-Ends.

  • Cloud-Ingress: In dieser Referenzarchitektur konfigurieren Sie den Google 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 Anleitungen 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 beim Verschlüsseln und Bereitstellen von Zertifikaten. GKE Gateway wird für diese Sicherheitszwecke in Zertifikatmanager eingebunden.

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. Sie können in Ihrer Gateway-Definition auf einen ZertifikatmanagerCertificateMap verweisen. 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 öffentliches Zertifikat verwenden, um den Traffic zu verschlüsseln. Sie können ein selbst signiertes oder öffentliches Zertifikat verwenden, da das GFE sich nicht authentifiziert. Diese zusätzliche Verschlüsselungsebene wird im Bereitstellungsleitfaden zu dieser Referenzarchitektur veranschaulicht.

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

Der Bereitstellungsleitfaden für diese Referenzarchitektur verwendet Cloud Endpoints, um externe DNS-Einträge und TLS-Zertifikate zu erstellen. Mit Cloud Endpoints können Sie eine extern verfügbare cloud.goog-Subdomain erstellen. Verwenden Sie in Szenarien auf Unternehmensebene einen geeigneteren Domainnamen und erstellen Sie einen A-Eintrag, der auf die IP-Adresse des globalen Application Load Balancers in Ihrem DNS-Dienstanbieter 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 Architektur diagramm 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 Multi-Region-Musters „Edge zu Mesh“ besteht darin, dass alle Funktionen des Service Mesh für das Ost-West-Load-Balancing verwendet werden können, z. B. für den 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 Status aus. Wenn der 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-Dienste für alle Anwendungsdienste, die in GKE-Clustern bereitgestellt werden. Wenn Sie Multi-Cluster-Dienste in GKE-Clustern in einer Flotte verwenden, werden die Dienstendpunkte in einem ClusterSet zusammengefasst. Wenn ein Dienst einen anderen Dienst aufrufen muss, kann er einen beliebigen fehlerfreien Endpunkt für den zweiten Dienst verwenden. Da die Endpunkte abwechselnd ausgewählt werden, kann sich der ausgewählte Endpunkt in einer anderen Zone oder einer anderen Region befinden.

Ein wichtiger Vorteil der Verwendung von Service Mesh für Ost-West-Traffic anstelle von Multi-Cluster-Diensten besteht darin, dass Service Mesh das Load-Balancing nach Standort verwenden kann. Das Load-Balancing nach Standort ist keine Funktion von Multi-Cluster-Diensten, kann aber über eine DestinationRule konfiguriert werden.

Nach der Konfiguration versucht ein Aufruf von einem Dienst zu einem anderen Dienst zuerst, einen Dienstendpunkt in derselben Zone zu erreichen, und 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.

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: