Cloud Service Mesh-Dienstrouting-APIs – Übersicht

Hinweis: In dieser Anleitung werden nur Cloud Service Mesh mit Google Cloud APIs und keine Istio APIs unterstützt. Weitere Informationen finden Sie unter Cloud Service Mesh – Übersicht.

Dieses Dokument richtet sich an Mesh-Netzwerk- oder Plattformadministratoren und Dienstentwickler, die mit den Konzepten von Cloud Service Mesh und Service Mesh vertraut sind und Cloud Service Mesh in Compute Engine mit VM-Instanzen bereitstellen. Dieses Dokument gilt für Bereitstellungen mit Envoy- und gRPC-Clients. Weitere Informationen zu Cloud Service Mesh-Konzepten finden Sie in der allgemeinen Übersicht.

Cloud Service Mesh bietet Dienstnetzwerkfunktionen für Ihre Anwendungen, einschließlich erweiterter Traffic-Verwaltung, Beobachtbarkeit und Sicherheit. Die Konfiguration und der Betrieb eines Service Mesh ist jedoch für Mesh-Administratoren und Dienstentwickler eine komplexe Aufgabe.

In diesem Dokument werden die Service Routing APIs zum Konfigurieren von Cloud Service Mesh beschrieben. Diese APIs sollen die gesamte Mesh-Konfiguration vereinfachen und verbessern.

Das Dienstroutingmodell verwendet API-Ressourcen namens Mesh, Gateway und Route. Diese Ressourcen bieten eine kontextrelevante Konfiguration, wenn Sie die Steuerungsebene des Dienstnetzwerks definieren.

In diesem Dokument werden das folgende Service Routing API-Modell und die entsprechenden Ressourcen vorgestellt.

• MeshRessource
  • Dienst-zu-Dienst-Trafficverwaltung (Ost-West) für Envoy-Sidecar-Proxys und proxylose gRPC-Clients.

• GatewayRessource

  • Trafficverwaltung und Sicherheitskonfiguration für Envoy-Proxys, die als Ingress-Gateways fungieren und externen Clients eine Verbindung zum Service Mesh (Nord-Süd) ermöglichen.

• Route-Ressourcen mit den folgenden Typen:

  • HTTPRoute
  • GRPCRoute
  • TCPRoute
  • TLSRoute

Die Google Cloud Console bietet keine Unterstützung für die Dienstrouting-APIs. Sie müssen diese API-Ressourcen mit der Google Cloud CLI oder den REST APIs implementieren.

Anwendungsfälle und Vorteile

Mit den Dienstrouting-APIs können Sie Cloud Service Mesh sowohl für proxylose gRPC- als auch für Envoy-Proxy-Bereitstellungen konfigurieren. Das Service Routing API-Modell bietet mehrere wichtige Vorteile.

Im folgenden Diagramm sind zwei Dienste im Service Mesh durch eine Mesh-Ressource verbunden. Die beiden HTTPRoute-Ressourcen konfigurieren das Routing. Der Mesh- oder Plattformadministrator verwaltet die Ressource Mesh und die beiden Dienstinhaber erstellen die Routingkonfiguration für ihre Dienste.

Ost-West-Dienst-zu-Dienst-Traffic in einem Service Mesh (zum Vergrößern klicken)

Das rollenorientierte API-Design ermöglicht eine klare Trennung von Zuständigkeiten

Mit den Service Routing APIs können Sie die Aufgaben der Mesh-Konfiguration basierend auf Organisationsrollen trennen:

• Mesh-Administratoren können das logische Mesh-Netzwerk und die Infrastruktur für eingehenden Traffic definieren.
• Dienstinhaber (Anwendungsentwickler) können unabhängig Zugriffsmuster für ihre Dienste definieren. Sie können auch Richtlinien zur Trafficverwaltung für ihre Dienste definieren und anwenden.

Im folgenden Diagramm stellen Cloud Load Balancing und eine Gateway-Ressource ein Ingress-Gateway für Traffic bereit, der von einem Client außerhalb des Mesh-Netzwerks in das Mesh eintritt. Der Mesh-Administrator konfiguriert und verwaltet die Gateway-Ressource, während die Dienstinhaber ihre eigenen Dienste und das Trafficrouting konfigurieren und verwalten.

Nord-Süd-Traffic in das Mesh über ein Gateway (zum Vergrößern klicken)

Verbesserte Zuverlässigkeit mit Selfservice-Modell

Die Dienstrouting-APIs verwenden protokoll- und routenspezifische Ressourcen, die unabhängige Dienstinhaber konfiguriert werden können und deren Inhaber sind. Dieser Ansatz bietet verschiedene Vorteile.

• Dienstinhaber können selbst entscheiden, wie sie Richtlinien und Traffic-Verwaltung für ihre Dienste konfigurieren möchten.
• Das Aktualisieren einer Route-Ressource wirkt sich nicht auf andere Route-Ressourcen im Mesh aus. Der Aktualisierungsprozess ist zuverlässiger, da Dienstinhaber kleine Konfigurationen verwalten.
• Der für den Zieldienst oder Hostnamen verantwortliche Dienstinhaber ist Inhaber jeder Route-Ressource.
• Dienstinhaber müssen sich nicht darauf verlassen, dass Mesh-Administratoren das Routing aktualisieren.

Ein Service Mesh aktivieren, das sich über mehrere Projekte in Umgebungen mit freigegebener VPC erstreckt

Mit dem Service Routing API-Modell können Dienstinhaber eine Shared-Mesh-Infrastruktur nutzen, die eine freigegebene VPC und andere Verbindungsmethoden verwendet, und behalten gleichzeitig die unabhängige Kontrolle über ihre Dienste. Beispielsweise können Dienstinhaber die Route-Ressourcen in ihren eigenen Projekten definieren. Plattformadministratoren können ein Mesh in einem zentral verwalteten Hostprojekt definieren und dann Dienstinhabern IAM-Berechtigungen gewähren, um ihre Route-Ressourcen an ein freigegebenes Mesh oder Gateway anzuhängen. Das folgende Diagramm zeigt ein Beispiel für eine freigegebene VPC.

Projektübergreifende Verweise mit freigegebener VPC (zum Vergrößern klicken)

Mit den Service Routing APIs können Sie auch Service Mesh-Clients verwenden, die über VPC-Netzwerk-Peering mit verschiedenen Netzwerken verbunden sind.

Traffic anhand des Servernamenindikators weiterleiten

Mit der Ressource TLSRoute können Sie TLS-verschlüsselten Traffic anhand des Servernamenindikators (Server Name Indication, SNI) im TLS-Handshake weiterleiten. Sie können den TLS-Traffic so konfigurieren, dass er an die entsprechenden Backend-Dienste weitergeleitet wird. Konfigurieren Sie dazu die SNI-Übereinstimmung in der Ressource TLSRoute. In diesen Bereitstellungen leiten Proxys nur Traffic weiter und die TLS-Sitzung wird an der Ziel-Backend-Instanz beendet.

Die TLSRoute-Ressource wird nur mit Envoy-Proxys unterstützt, die als Sidecar-Proxys oder Gateways bereitgestellt werden.

TLSRoute Ressource, die an eine Mesh-Ressource angehängt ist

Die im folgenden Diagramm gezeigte Bereitstellung leitet jeden Service Mesh-Traffic, bei dem die SNI-Erweiterung den Wert service1 hat, an den Back-End-Dienst service1 weiter. Außerdem wird Service Mesh-Traffic, bei dem die SNI-Erweiterung den Wert service2 hat, an den Backend-Dienst service2 weitergeleitet. Der SNI-Erweiterungswert und der Backend-Dienstname sind unabhängig voneinander.

TLSRoute Ressource und Mesh Ressource (zum Vergrößern klicken)

TLSRoute Ressource, die an eine Gateway-Ressource angehängt ist

Die im folgenden Diagramm dargestellte Bereitstellung leitet allen eingehenden Traffic für die Ressource Gateway, bei dem die SNI-Erweiterung den Wert serviceA hat, an den Backend-Dienst serviceA weiter. Darüber hinaus wird jeder eingehende Traffic fürGateway, bei dem die SNI-Erweiterung den Wert serviceB hat, an den Backend-Dienst serviceB weitergeleitet. Der SNI-Erweiterungswert und der Backend-Dienstname sind unabhängig voneinander. Der SNI-Erweiterungswert und der Header in HTTP-Anfragen sind ebenfalls unabhängig voneinander.

Die Gateway-Ressource beendet die TLS-Verbindung nicht beim Envoy-Proxy von Gateway. Stattdessen wird die TLS-Verbindung beim entsprechenden Backend-Dienst beendet. Der Gateway kann keine auf der TLS-Ebene verschlüsselten Informationen prüfen, mit Ausnahme des ClientHello, der eine SNI-Erweiterung im Nur-Text-Format enthält. Gateway führt in diesem Modus eine TLS-Passthrough-Funktion durch. Die verschlüsselte ClientHello wird nicht unterstützt.

TLSRoute Ressource und Gateway Ressource (zum Vergrößern klicken)

Core-gRPC-Unterstützung

Sie können proxylose gRPC-Clients konfigurieren, indem Sie Kernattribute von gRPC verwenden, z. B. den Abgleich nach Methode.

Trafficaufteilung für TCP-Traffic

Sie können eine gewichtete Trafficaufteilung für TCP-Traffic über mehrere Back-End-Dienste hinweg implementieren. Sie können Muster wie Canary-Einführungen (Blau/Grün) konfigurieren, wenn Sie Ihren Dienst aktualisieren. Mit der Trafficaufteilung können Sie den Traffic auch kontrolliert ohne Migration migrieren.

Traffic abfangen

Wenn Sie die Mesh- und Gateway-Ressourcen der Service Routing API verwenden, wird der gesamte Traffic automatisch abgefangen. Weitere Informationen finden Sie unter Optionen für die Einrichtung einer Compute Engine-VM mit automatischer Envoy-Bereitstellung.

Architektur und Ressourcen

In diesem Abschnitt werden das Service Routing API-Modell und seine Ressourcen beschrieben. Außerdem erfahren Sie, wie die Service Routing API-Ressourcen zusammenarbeiten.

Mesh-Ressource

Die Mesh-Ressource stellt eine Instanz eines Service Mesh dar. Sie erstellen damit ein logisches Service Mesh in Ihrem Projekt. Jede Mesh-Ressource muss im Projekt einen eindeutigen Namen haben. Nachdem eine Mesh-Ressource erstellt wurde, kann ihr Name nicht mehr geändert werden.

Mesh API-Ressource mit Envoy-Sidecar-Datei und proxylosen gRPC-Bereitstellungen (zum Vergrößern klicken)

Auf die Mesh-Ressource wird in der Route-Ressource verwiesen, um Routen für Dienste hinzuzufügen, die Teil des Mesh-Netzwerks sind.

Envoy-Proxy- und proxylose gRPC-Clients erhalten die Konfiguration von Cloud Service Mesh, indem sie dem Service Mesh beitreten, das durch den Namen der Mesh-Ressource identifiziert wird. Die Ressource Mesh unterstützt die folgenden Bereitstellungen der Datenebene:

• Envoy wird zusammen mit der Anwendung als Sidecar-Proxys ausgeführt
• Proxylose gRPC-Clients
• Mischung aus Envoy-Sidecar-Datei und proxylosen gRPC-Clients

Route-Ressource

Die Route-Ressource wird verwendet, um das Routing zu den Diensten einzurichten. Es gibt vier verschiedene Arten der Route API-Ressource. Sie definieren das Protokoll, mit dem Traffic an einen Backend-Dienst weitergeleitet wird.

• HTTPRoute
• GRPCRoute
• TCPRoute
• TLSRoute

Die API enthält nicht die Route API wortwörtlich. Die einzigen konfigurierbaren API-Ressourcen sind HTTPRoute, GRPCRoute, TCPRoute und TLSRoute.

Die Route-Ressource verweist auf eine oder mehrere Ressourcen vom Typ Mesh und Gateway, um die Routen hinzuzufügen, die Teil der entsprechenden Mesh- oder Gateway-Konfiguration sind. Eine Route-Ressource kann auf Gateway- und Mesh-Ressourcen verweisen.

Die Ressource Route verweist auch auf eine oder mehrere Back-End-Dienstressourcen. Die Dienste werden mithilfe der Back-End-Dienst-API konfiguriert. Sie erstellen eine Back-End-Dienstressource, die auf ein oder mehrere MIG- oder NEG-Back-Ends verweist.

Das folgende Diagramm zeigt die Beziehungen zwischen den Ressourcen Mesh, Gateway und Route sowie der Backend-Dienstressource und ihren Backends.

Route API-Ressourcen (zum Vergrößern klicken)

Sie definieren andere Funktionen zur Trafficverwaltung wie Routing, Headeränderungen und Zeitlimits sowie die gewichtete Trafficaufteilung in Route-Ressourcen. Im folgenden Diagramm definiert eine HTTPRoute-Ressource beispielsweise eine Trafficaufteilung von 70 % / 30 % zwischen zwei Backend-Diensten.

Gewichtete Trafficaufteilung (zum Vergrößern klicken)

Sie können alle Route-Ressourcen auflisten, die an eine Mesh- oder Gateway-Ressource angehängt sind, um die Verwaltung Ihres Service Mesh zu vereinfachen.

TLSRoute-Ressource

Verwenden Sie die Ressource TLSRoute, um TLS-Traffic anhand von SNI-Hostnamen und dem ALPN-Namen (Application-Layer Protocol Negotiation) an Backend-Dienste weiterzuleiten. Die TLSRoute-Konfiguration impliziert eine TLS-Weiterleitung, in der der Envoy-Proxy keinen TLS-Traffic beendet.

Die TLSRoute-Ressource verweist auf eine oder mehrere Ressourcen vom Typ Mesh und Gateway, um die Routen hinzuzufügen, die Teil der entsprechenden Mesh- oder Gateway-Konfiguration sind.

Die TLSRoute-Ressource verweist auch auf eine oder mehrere Backend-Dienstressourcen. Die Dienste werden mithilfe der API-Ressource des Back-End-Dienstes konfiguriert.

Gateway-Ressource

Die Gateway-Ressource wird verwendet, um Envoy-Proxys darzustellen, die als Ingress-Gateways fungieren und externen Clients eine Verbindung zum Service Mesh (Nord-Süd-Traffic) ermöglichen können. Diese Ressource hat Überwachungsports und einen scope-Parameter. Der Envoy-Proxy, der als Ingress-Gateway fungiert, bindet an die angegebenen Ports und an 0.0.0.0, die alle IP-Adressen auf der lokalen VM darstellen. Das folgende Diagramm zeigt Envoy-Proxys, die als Ingress-Dienst bereitgestellt und von der Gateway-Ressource konfiguriert werden. In diesem speziellen Beispiel werden Envoy-Proxys so konfiguriert, dass sie Port 80 auf eingehende Verbindungen von Clients überwachen.

Die API-Ressource Gateway unterstützt nur die Envoy-Proxy-Datenebene. Proxylose gRPC-Dienste werden nicht unterstützt. gRPCRoutes werden in der Gateway-Ressource unterstützt, aber der gRPC-Traffic wird vom Envoy-Proxy weitergeleitet, der als mittlerer Proxy fungiert.

Eingehender Service Mesh-Traffic über eine Gateway-Ressource (zum Vergrößern klicken)

Gateway-Ressource (zum Vergrößern klicken)

Was ist ein Gateway-Bereich und eine zusammengeführte Gateway-Konfiguration?

Eine Gateway-Ressourceninstanz stellt die Ports und die Konfiguration dar, die für den an diesen Ports empfangenen Traffic spezifisch sind. Die API-Ressource Gateway hat den Parameter scope, mit dem die Konfiguration von zwei oder mehr Gateway-Ressourcen logisch gruppiert und zusammengeführt wird.

Wenn Sie beispielsweise möchten, dass die Gateway-Proxys die Ports 80 und 443 überwachen, um HTTP- bzw. HTTPS-Traffic zu empfangen, erstellen Sie zwei Gateway-Ressourcen. Konfigurieren Sie eine Gateway-Ressource mit Port 80 für den HTTP-Traffic und die andere mit Port 443 für HTTPS-Traffic. Geben Sie in jedem Wert das Feld scope an. Cloud Service Mesh führt die einzelnen Konfigurationen aller Gateways mit demselben Bereich dynamisch zusammen. Auf der Seite der Datenebene müssen die Envoy-Proxys, die im Ingress-Gateway-Modus ausgeführt werden, auch Cloud Service Mesh denselben Bereichsparameter zur Verfügung stellen, um die Gateway-Konfiguration zu empfangen. Beachten Sie, dass Sie beim Erstellen der Gateway-Ressource einen Bereich angeben und zwar den gleichen Bereich wie der Bootstrap-Parameter für die Proxys.

Verhalten beim Zusammenführen von Gateway-Ressourcen (zum Vergrößern klicken)

Im Folgenden finden Sie wichtige Überlegungen zur Gateway-Ressource:

• Der Bereichsparameter Gateway ist obligatorisch. Geben Sie den Bereich in der Gateway-Ressource und in der Bootstrap-Konfiguration der Envoy-Proxys an, auch wenn nur ein Gateway vorhanden ist.
• Beim Erstellen einer Gateway-Ressource wird kein Dienst mit einem Envoy-Proxy bereitgestellt. Die Bereitstellung des Envoy-Proxys ist ein separater Schritt.
• Die Gateway-Ressource hat einen type, der den Typ der Ingress-Bereitstellung darstellt. Dieses Feld ist für die zukünftige Verwendung reserviert. Der einzige derzeit unterstützte Wert ist OPEN_MESH. Dies ist der Standardwert und er kann nicht geändert werden.

Mesh-Bereitstellungen mit gemischten Protokollen und Datenebenen

Sie können eine gemischte Datenebenen-Bereitstellung haben, d. h. mit Envoy-Proxy und proxylosem gRPC im selben Mesh. Beachten Sie beim Erstellen solcher Bereitstellungen Folgendes:

• Envoy-Sidecar-Bereitstellungen unterstützen alle Routen (HTTPRoute, GRPCRoute und TCPRoute und TLSRoute).
• Proxylose gRPC-Bereitstellungen unterstützen nur GRPCRoute.
• GRPCRoute ist auf Features beschränkt, die nur von proxylosen gRPC-Bereitstellungen unterstützt werden.

Unterstützte Topologien in freigegebenen VPC-Umgebungen mehrerer Projekte

Cloud Service Mesh unterstützt das Hinzufügen von Route-Ressourcen, die in anderen Projekten definiert sind, einer Mesh- oder Gateway-Ressource, die in einem zentralen Administrationsprojekt definiert ist. Autorisierte Dienstinhaber können ihre Dienstrouting-Konfigurationen direkt zu Mesh oder Gateway hinzufügen.

Projektübergreifende Verweise zwischen Mesh- und Route-Ressourcen (zum Vergrößern klicken)

In einem typischen projektübergreifenden Szenario wählen Sie ein Projekt (Hostprojekt oder zentral gesteuertes Administrationsprojekt) als Mesh-Verwaltungsprojekt aus, in dem Sie eine Mesh-Ressource erstellen. Der Inhaber des Mesh-Verwaltungsprojekts autorisiert Route-Ressourcen aus anderen Projekten dazu, auf die Ressource Mesh zu verweisen. Dadurch kann die Routingkonfiguration anderer Projekte Teil des Mesh-Netzwerks sein. Eine Mesh-Datenebene, ob Envoy oder gRPC, fordert die Konfiguration vom Administrationsprojekt an und empfängt eine Union aller an Mesh angehängten Routen. Bei einem Gateway werden die Routen außerdem über alle Gateways hinweg, die denselben Bereich verwenden, zusammengeführt.

Das Verwaltungsprojekt Mesh kann ein beliebiges Projekt sein, das Sie auswählen. Die Konfiguration funktioniert, solange die zugrunde liegenden Projekte eine VPC-Netzwerkverbindung haben, entweder über freigegebene VPC oder VPC-Netzwerk-Peering.

IAM-Berechtigungen und -Rollen

Im Folgenden finden Sie die IAM-Berechtigungen, die zum sicheren Abrufen, Erstellen, Aktualisieren, Löschen, Auflisten und Verwenden der Mesh- und Route-Ressourcen erforderlich sind.

• Mesh-Administratoren benötigen die Berechtigung networkservices.mesh.*.
• Gateway-Administratoren benötigen die Berechtigung networkservices.gateways.*.
• Dienstinhaber müssen networkservices.grpcRoutes.*-, networkservices.httpRoutes.*- oder networkservices.tcpRoutes.*-Berechtigungen haben.

Mesh-Administratoren müssen Dienstinhabern die Berechtigung networkservices.mesh.use erteilen, damit diese ihre Ressourcen vom Typ Route an die Ressource Mesh anhängen können. Dasselbe Modell gilt für Gateway-Ressourcen.

Wenn Sie alle IAM-Berechtigungen für Mesh-Ressourcen sehen möchten, rufen Sie die Referenzseite für IAM-Berechtigungen auf und suchen Sie nach meshes.

Es sind keine zusätzlichen vordefinierten Rollen erforderlich. Die vorhandene vordefinierte Rolle Compute Network Admin (roles/compute.networkAdmin) hat standardmäßig die Berechtigung networkservices.*. Möglicherweise müssen Sie den zuvor beschriebenen Berechtigungen die benutzerdefinierten Rollen hinzufügen.

Überlegungen und Einschränkungen

• Die Service Routing APIs werden von der Google Cloud Console nicht unterstützt.
• Sie benötigen Version 3 der xDS API oder höher.
  • Mindest-Envoy-Version 1.20.0 (da die Service Routing APIs nur unter xDS Version 3 unterstützt werden)
  • gRPC-Bootstrap-Generator-Mindestversion 0.14.0
• Die TLSRoute-Ressource wird nur mit Envoy-Proxys unterstützt, die als Sidecar-Proxys oder Gateways bereitgestellt werden.
• Nur Compute Engine-VMs mit automatischer Envoy-Bereitstellung und GKE-Pods mit automatischer Envoy-Einfügung werden unterstützt. Sie können die manuelle Bereitstellung nicht mit den Service Routing APIs verwenden.
• Die Service Routing APIs sind nicht abwärtskompatibel mit den älteren APIs.
• Wenn eine TCPRoute-Ressource mit einer Mesh-Ressource verknüpft ist, kann der für den TCP-Traffic verwendete Port nur für den Traffic verwendet werden, der durch diese TCPRoute beschrieben wird.
  • Ihre Bereitstellungen können beispielsweise eine TCPRoute-Ressource, die Port "8000" entspricht, und eine HttpRoute-Ressource enthalten. Wenn beide an dieselbe Mesh-Ressource angehängt sind, kann der von der HTTPRoute-Ressource weitergeleitete Traffic Port 8000 nicht verwenden, auch wenn sich die zugrunde liegenden IP-Adressen unterscheiden. Diese Einschränkung stammt aus der Envoy-Proxy-Implementierung, die der mit dem Port übereinstimmenden Route Vorrang gewährt.
• Die Gateway-Ressource stellt keinen verwalteten Load-Balancer bereit und erstellt keinen Envoy-Dienst dynamisch.
• Automatisch bereitgestellte Envoy-Befehle, die als Ingress-Gateways dienen, dürfen das Argument serving_ports nicht für das Flag --service-proxy enthalten.
• Die automatisch bereitgestellte Envoy-Datei unterstützt nicht die Bereitstellung einer Projektnummer, die anders ist als das Projekt der VM.

Nächste Schritte

• Informationen zum Auflisten von Routenressourcen, die mit einer Mesh- oder Gateway-Ressource verknüpft sind, finden Sie unter Route-Ressourcen auflisten. Diese Feature befindet sich im Vorschaumodus.
• Informationen zu den Service Routing APIs finden Sie in der Dokumentation zu den Network Services APIs.