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 beschrieben, die sich daraus ergeben, dass Anwendungen extern über Google Kubernetes Engine-Gateways (GKE) freigegeben werden, 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 dann zu einer zusätzlichen Fehlerdomäne. Beispiel: Die Recheninfrastruktur eines Dienstes mit einem SLO von 99,9% bei der Bereitstellung in einem einzelnen GKE-Cluster erreicht bei der Bereitstellung in zwei GKE-Clustern einen SLO von 99,9999 % (1 − (0,001)2). Sie können Nutzern auch die Möglichkeit bieten, eingehende Anfragen automatisch an das Mesh-Ingress-Gateway mit der geringsten Latenz und Verfügbarkeit weiterzuleiten.

Informationen zu den Vorteilen der Bereitstellung von Service Mesh-fähigen Anwendungen, die in einem einzelnen Cluster ausgeführt werden, finden Sie unter Von Edge zu Mesh: Service Mesh-Anwendungen über GKE Gateway verfügbar machen.

Architektur

Das folgende Architekturdiagramm zeigt, wie Daten über 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 mit seinem eigenen von Google verwalteten TLS-Zertifikat am Google Cloud-Load Balancer endet.
  • 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 Arbeitslast mithilfe von Service Mesh-fähigem mTLS.

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

  • Cloud Ingress: In dieser Referenzarchitektur wird die Kubernetes Gateway API (und der GKE Gateway Controller) verwendet, um die externe, mehrstufige 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 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 gemeinsam verwenden, haben sie jeweils unterschiedliche Rollen. Um die folgenden Ziele zu erreichen, werden in Google Cloud die am besten geeigneten Funktionen der Cloud-Ingress-Ebene und der Mesh-Ingress-Ebene optimiert:

  • Niedrige Latenz.
  • Verfügbarkeit erhöhen.
  • Verwenden Sie die Sicherheitsfunktionen der Cloud-Eingangsschicht.
  • 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 recht einfach. Bei 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 außerdem weniger flexibel und dynamisch als eine entwicklergesteuerte Infrastruktur. Berücksichtigen Sie diese Faktoren, wenn Sie die Administratorzugriffsrechte für diese Ebene und die Art und Weise festlegen, 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. Außerdem bietet die Schicht Backend-mTLS, Autorisierungsrichtlinien und flexibles reguläres Ausdrucks-Matching.

Das Bereitstellen eines externen Anwendungs-Load Balancings 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 von Google Cloud könnte erhebliche Vorteile in Bezug auf die Leistung, Zuverlässigkeit oder Sicherheit gegenüber dem mesh-netzwerk-basierten Ingress bieten.

Verwendete Produkte und Funktionen

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

  • GKE Enterprise: Ein verwalteter Kubernetes-Dienst, mit dem Sie Containeranwendungen in großem Maßstab mithilfe der Google-Infrastruktur bereitstellen und betreiben können. Für diese Referenzarchitektur muss sich jeder der GKE-Cluster, der eine Anwendung bereitstellt, in derselben Flotte befinden.
  • Flotten und Multi-Cluster-Gateways: Dienste, mit denen Containeranwendungen in Unternehmensgröße mit der Google-Infrastruktur 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.
  • Zertifikatmanager: Mit diesem Dienst können Sie TLS-Zertifikate für die Verwendung mit Cloud Load Balancing erwerben und verwalten.

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. Achten Sie darauf, dass Sie für jeden GKE-Cluster in einer Flotte alle Mesh-Eingangsgateways auf die gleiche Weise konfigurieren.

Außerdem sollten Sie Anwendungsdienste einheitlich bereitstellen, damit sich der Dienst „servicebalance-reader“ im Namespacekonto 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 Cloud nutzen 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 der Flotte bereitgestellt. Konfigurieren Sie jedes Mesh-Ingress-Gateway auf die gleiche Weise und halten Sie sich dabei an das Prinzip der Namespace-Gleichheit der Flotte.

Es gibt zwar einen einzelnen Konfigurationscluster für das GKE-Gateway, Sie sollten Ihre GKE-Gateway-Konfigurationen jedoch für alle GKE-Cluster in der Flotte synchronisieren.

Wenn Sie einen neuen Konfigurationscluster festlegen möchten, verwenden Sie ConfigSync. Config Sync trägt dazu bei, dass alle Konfigurationen in allen GKE-Clustern der Flotte synchronisiert werden, und hilft, eine Abgleichung 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. In dieser Referenzarchitektur wird Cloud Load Balancing verwendet, das über GKE Gateway-Ressourcen bereitgestellt wird, um die Bereitstellung zu automatisieren.

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 und verbessert die Ingress-Ressource.

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 oder verteilt auf mehrere GKE-Cluster (in derselben Flotte) befinden.
  • 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. Gateway-Klassen, die in Multi-Cluster-Szenarien verwendet werden können, haben einen Klassennamen, der auf -mc endet.

In dieser Referenzarchitektur wird erläutert, wie Sie Anwendungsdienste extern über einen externen Application Load Balancer bereitstellen. Wenn Sie jedoch ein Gateway verwenden, können Sie auch einen regionalen internen Application Load Balancer mit mehreren Clustern erstellen.

Wenn Sie Anwendungsdienste in Multi-Cluster-Szenarien bereitstellen möchten, können Sie die Google Cloud-Load Balancer-Komponenten auf zwei Arten definieren:

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

Für Multi-Cluster-Ingress müssen MultiClusterService-Ressourcen erstellt werden. Für ein Multi-Cluster-Gateway müssen ServiceExport-Ressourcen erstellt und auf ServiceImport-Ressourcen verwiesen werden.

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 erfahren Sie, wie Sie eine Google Cloud Armor-Sicherheitsrichtlinie konfigurieren, um Backend-Dienste vor Cross-Site Scripting zu schützen.

Diese Richtlinienressourcen sind auf die Back-End-Dienste in der Flotte ausgerichtet, die über mehrere Cluster hinweg verfügbar sind. In Multi-Cluster-Szenarien müssen alle 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 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 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 beim Verschlüsseln und Bereitstellen von Zertifikaten. Aus Sicherheitsgründen ist GKE Gateway in Certificate Manager eingebunden.

Internetclients authentifizieren sich mit öffentlichen Zertifikaten und stellen eine Verbindung zum externen Load Balancer als ersten Hop in der Virtual Private Cloud (VPC) her. Sie können in Ihrer Gateway-Definition auf einen Certificate Manager CertificateMap 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 jedoch die Eigentumsrechte an den Verschlüsselungsschlüsseln besitzt, 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 sich das GFE nicht damit authentifiziert. Diese zusätzliche Verschlüsselungsebene wird im zugehörigen Bereitstellungsleitfaden 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.

Zum Erstellen externer DNS-Einträge und TLS-Zertifikate wird im Bereitstellungsleitfaden für diese Referenzarchitektur Cloud Endpoints verwendet. 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 globale IP-Adresse des Application Load Balancers bei Ihrem DNS-Anbieter verweist.

Wenn das von Ihnen verwendete Service Mesh TLS erfordert, wird der gesamte Traffic zwischen Sidecar-Proxys und dem 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 mehrstufigen, mehrregionalen Edge-to-Mesh-Musters ist, dass alle Funktionen des Service Mesh für das Ost-West-Load Balancing verwendet werden können, z. B. für Traffic zwischen Anwendungsdiensten.

In dieser Referenzarchitektur wird ein GKE-Gateway mit mehreren Clustern 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), seiner Verfügbarkeit und seinem Zustand aus. Wenn Traffic das Istio-Ingress-Gateway (Mesh-Ingress) erreicht, wird er über das Service Mesh an die entsprechenden Backends weitergeleitet.

Ein alternativer Ansatz für die Verarbeitung des East-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 Dienstendpunkte in einer ClusterSet zusammengefasst. Wenn ein Dienst einen anderen Dienst aufrufen muss, kann er auf jeden aktiven Endpunkt des zweiten Dienstes ausgerichtet werden. Da Endpunkte nach einem Rotationsprinzip ausgewählt werden, kann sich der ausgewählte Endpunkt in einer anderen Zone oder Region befinden.

Ein wichtiger Vorteil der Verwendung eines Service Mesh für Ost-West-Traffic anstelle von Multi-Cluster-Diensten besteht darin, dass das 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 wird bei einem Aufruf von einem Dienst an einen anderen zuerst versucht, einen Dienstendpunkt in derselben Zone zu erreichen. Anschließend wird in derselben Region wie der aufrufende Dienst versucht. Der Aufruf wird nur dann auf einen Endpunkt in einer anderen Region ausgerichtet, wenn ein Dienstendpunkt in derselben Zone oder Region nicht verfügbar ist.

Kostenoptimierung

Wenn Sie diese Multi-Cluster-Architektur in einem Unternehmen weithin einführen, sind Cloud Service Mesh und das Multi-Cluster-Gateway in der Google Kubernetes Engine (GKE) Enterprise Edition enthalten. Darüber hinaus 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: