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

In dieser Referenzarchitektur werden die Vorteile der externen Freigabe 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 zu einer zusätzlichen Fehlerdomain wird. Beispielsweise erreicht die Computing-Infrastruktur eines Dienstes mit einem Service Level Objective (SLO) von 99,9% bei Bereitstellung in einem einzelnen GKE-Cluster ein SLO von 99,9999 %, wenn sie in zwei GKE-Clustern (1:(0,001)2) bereitgestellt wird. Sie können Nutzern auch die Möglichkeit bieten, eingehende Anfragen automatisch an das am wenigsten latente und am wenigsten verfügbare Mesh-Ingress-Gateway weiterzuleiten.

Weitere 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 zum Mesh: Service Mesh-Anwendungen über GKE Gateway verfügbar machen.

Architektur

Das folgende Architekturdiagramm zeigt, wie Daten durch 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 Load-Balancer Google Cloud unter Verwendung seines eigenen von Google verwalteten TLS-Zertifikats beendet wird
  • 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-aktiviertem mTLS.

Diese Referenzarchitektur enthält die folgenden beiden Eingangsebenen:

  • 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 über mehrere Regionen hinweg und sendet Anfragen an den nächsten intakten 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 komplementäre Rollen für jede Ebene. Für das Erreichen der folgenden Ziele optimiert Google Cloud die geeignetsten Features aus der Cloud-Ingress-Ebene und der Mesh-Ingress-Ebene:

  • Sorgen Sie für niedrige Latenz.
  • Verfügbarkeit erhöhen
  • Verwenden Sie die Sicherheitsfunktionen der Cloud-Ingress-Ebene.
  • Verwenden Sie die Features der Mesh-Ingress-Ebene für Sicherheit, Autorisierung und Beobachtbarkeit.

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 eingebunden ist, können diese Dienste hervorragend auf Edge-Geräten außerhalb des Mesh-Netzwerks ausgeführt werden:

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

Die Routinglogik ist auf der Cloud-Ingress-Ebene in der Regel einfach. Für Multi-Cluster- und multiregionale Umgebungen kann es jedoch komplexer sein.

Aufgrund der kritischen Funktion von Load-Balancern für das 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 wie Sie diesen Zugriff gewähren.

Eingehender Mesh-Traffic

In Kombination mit Cloud-Ingress bietet die Mesh-Ingress-Ebene einen Einstiegspunkt für Traffic zum Eintritt in das Service Mesh. Die Ebene bietet auch Back-End-mTLS, Autorisierungsrichtlinien und einen flexiblen Abgleich von regulären Ausdrücken.

Die Bereitstellung eines externen Anwendungs-Load-Balancings außerhalb des Mesh-Netzwerks mit einer Mesh-Ingress-Ebene bietet erhebliche Vorteile, insbesondere für die Verwaltung des Internettraffics. Service Mesh- und Istio-Ingress-Gateways ermöglichen eine erweiterte Routing- und Trafficverwaltung im Mesh. Einige Funktionen sind jedoch besser für die Edge-Umgebung des Netzwerks geeignet. Die Nutzung von Internet-Edge-Netzwerken über den externen Application Load Balancer vonGoogle Cloudkann erhebliche Leistungs-, Zuverlässigkeits- oder sicherheitsbezogene Vorteile gegenüber dem Mesh-basierten Ingress bieten.

Verwendete Produkte und Funktionen

In der folgenden Liste sind alle Google Cloud -Produkte und -Features zusammengefasst, die von dieser Referenzarchitektur verwendet werden:

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

Flotten

Zum Verwalten von Multi-Cluster-Bereitstellungen 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 auf ganze Gruppen von Clustern ausweiten. Verwenden Sie das Flottenprinzip der Namespace-Gleichheit, um Reibungspunkte bei der Clusterverwaltung zu reduzieren. Achten Sie darauf, dass Sie für jeden GKE-Cluster in einer Flotte alle Mesh-Ingress-Gateways auf dieselbe Weise konfigurieren.

Stellen Sie außerdem Anwendungsdienste konsistent bereit, damit der Service Balancing-Reader im Namespace-Konto mit einem identischen Dienst in jedem GKE-Cluster in der Flotte verknüpft ist. Die Prinzipien der Einheitlichkeit und Vertrauen, die in einer Flotte vorausgesetzt werden, ermöglichen es Ihnen, die gesamte Palette flottenfähiger Features in GKE Enterprise und Google Cloudzu nutzen.

East-West-Routingregeln innerhalb des Service Mesh und Trafficrichtlinien werden auf der Mesh-Ingress-Ebene verarbeitet. Die Mesh-Ingress-Ebene wird auf jedem GKE-Cluster in der Flotte bereitgestellt. Konfigurieren Sie jedes Mesh-Ingress-Gateway auf die gleiche Weise und beachten Sie dabei das Prinzip der Namespace-Gleichheit.

Obwohl es nur einen Konfigurationscluster für GKE Gateway gibt, sollten Sie Ihre GKE Gateway-Konfigurationen für alle GKE-Cluster in der Flotte synchronisieren.

Wenn Sie einen neuen Konfigurationscluster nominieren müssen, verwenden Sie ConfigSync. ConfigSync sorgt dafür, dass alle diese Konfigurationen in allen GKE-Clustern in der Flotte synchronisiert werden, und hilft, den Abgleich 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 Verhalten der Netzwerkbelastung getrennt vom Routing der Anwendung steuern.

Mit den Proxys können Sie auch Routing und Richtlinien auf externen Mesh-Traffic anwenden, bevor er bei einem Anwendungs-Sidecar eingeht. Mesh-Ingress definiert die Behandlung von Traffic, wenn er einen Knoten im Mesh erreicht. Externe Komponenten müssen jedoch definieren, wie der Traffic zuerst beim Mesh eingeht.

Zum Verwalten von externem Traffic benötigen Sie einen Load-Balancer, der sich außerhalb des Mesh-Netzwerks befindet. Diese Referenzarchitektur verwendet Cloud Load Balancing, das über GKE-Gatewayressourcen bereitgestellt wird, um das Deployment zu automatisieren.

GKE Gateway- und Multi-Cluster-Dienste

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

Beim Bereitstellen von GKE Gateway-Ressourcen in Ihrem GKE-Cluster überwacht der Gateway-Controller die Gateway API-Ressourcen. Der Controller gleicht Cloud Load Balancing-Ressourcen ab, um das durch die 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:

  • Gibt an, ob sich die Back-End-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 sich über mehrere GKE-Cluster erstrecken oder in einem einzelnen Cluster enthalten sein.

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

In dieser Referenzarchitektur wird erläutert, wie Anwendungsdienste über einen externen Application Load Balancer extern verfügbar gemacht werden. 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 dieGoogle Cloud -Komponenten des Load-Balancers 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.

Für den Multi-Cluster-Ingress werden MultiClusterService-Ressourcen erstellt. Ein Multi-Cluster-Gateway benötigt ServiceExport-Ressourcen und verweist auf ServiceImport-Ressourcen.

Wenn Sie ein Multi-Cluster-Gateway verwenden, können Sie die zusätzlichen Funktionen des zugrunde liegenden Google Cloud Load-Balancers durch Erstellen von Richtlinien aktivieren. Die mit dieser Referenzarchitektur verknüpfte Bereitstellungsanleitung zeigt, wie Sie eine Google Cloud Armor-Sicherheitsrichtlinie konfigurieren, um Back-End-Dienste vor Cross-Site-Scripting zu schützen.

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

Systemdiagnose

Die Verwendung von zwei Schichten des L7-Load-Balancings ist die Systemdiagnose. Sie müssen jeden Load-Balancer konfigurieren, um den Status der nächsten Schicht zu prüfen. Das GKE-Gateway prüft den Status der Mesh-Ingress-Proxys und das Mesh-Netzwerk prüft im Gegenzug den Zustand der Anwendungs-Back-Ends.

  • Cloud-Ingress: In dieser Referenzarchitektur konfigurieren Sie denGoogle Cloud -Load-Balancer über GKE Gateway, um den Status der Mesh-Ingress-Proxys an den bereitgestellten 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 Load-Balancer Google Cloud 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 GKE-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 zum Entwickeln einer Architektur, 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 den Zertifikatmanager einbinden.

Internetclients authentifizieren sich bei ö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 Zertifikatmanager CertificateMap verweisen. Der nächste Hop befindet sich zwischen dem Google Front End (GFE) und dem Mesh-Ingress-Proxy. Dieser Hop wird standardmäßig verschlüsselt.

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

Wenn Sie HTTP/2 mit TLS-Verschlüsselung zwischen dem Clustergateway und dem eingehenden Mesh-Netzwerk aktivieren, können Sie ein selbst signiertes oder ein öffentliches Zertifikat zum Verschlüsseln des Traffics verwenden. Sie können ein selbst signiertes oder ein öffentliches Zertifikat verwenden, da sich das GFE nicht authentifiziert. Diese zusätzliche Verschlüsselungsebene wird in der Bereitstellungsanleitung dieser Referenzarchitektur demonstriert.

Um einen unsachgemäßen Umgang mit Zertifikaten zu verhindern, sollten Sie öffentliche Zertifikate nicht wiederverwenden. Verwenden Sie separate Zertifikate für jeden Load-Balancer im Service Mesh.

Zum Erstellen externer DNS-Einträge und TLS-Zertifikate wird in der Bereitstellungsanleitung 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 geeigneten Domainnamen und erstellen Sie einen A-Eintrag, der auf die globale IP-Adresse des Application Load Balancers bei Ihrem DNS-Dienstanbieter verweist.

Wenn das von Ihnen verwendete Service Mesh TLS vorschreibt, 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 Load-Balancer Google Cloud , vom Load-Balancer zum Mesh-Ingress-Proxy und vom Ingress-Proxy zum Sidecar-Proxy.

Zuverlässigkeit und Ausfallsicherheit

Ein wichtiger Vorteil des multiregionalen Edge-to-Mesh-Musters mit mehreren Clustern besteht darin, dass alle Features des Service Mesh für das East-West-Load-Balancing verwendet werden können, z. B. Traffic zwischen Anwendungsdiensten.

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

Ein alternativer Ansatz für die Verarbeitung des Ost-West-Traffics sind Multi-Cluster-Dienste für alle Anwendungsdienste, die in GKE-Clustern bereitgestellt werden. Bei Verwendung von Multi-Cluster-Diensten in GKE-Clustern in einer Flotte werden Dienstendpunkte in einer ClusterSet zusammengefasst. Wenn ein Dienst einen anderen Dienst aufrufen muss, kann er einen beliebigen fehlerfreien Endpunkt für den zweiten Dienst aufrufen. Da Endpunkte rotierend ausgewählt werden, kann sich der ausgewählte Endpunkt in einer anderen Zone oder Region befinden.

Ein Hauptvorteil der Verwendung eines Service Mesh für East-West-Traffic gegenüber Multi-Cluster-Diensten besteht darin, dass das Service Mesh das Ort-Load-Balancing verwenden kann. Lokal-Load-Balancing ist kein Feature von Multi-Cluster-Diensten. Sie können es jedoch über eine DestinationRule konfigurieren.

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

Kostenoptimierung

Wenn diese Multi-Cluster-Architektur allgemein in einem Unternehmen eingeführt wird, sind Cloud Service Mesh und Multi-Cluster-Gateway in Google Kubernetes Engine (GKE) Enterprise enthalten. Darüber hinaus bietet GKE Enterprise viele Features, mit denen Sie GKE-Cluster, -Anwendungen und andere Prozesse in großem Umfang verwalten und steuern können.

Bereitstellung

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

Nächste Schritte

Beitragende

Autoren:

Weitere Beitragende: