Cloud Service Mesh Service Routing APIs – Übersicht

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

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

Cloud Service Mesh bietet Dienstnetzwerkfunktionen für Ihre Anwendungen, einschließlich erweiterter Trafficverwaltung, 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 Dienstrouting-APIs für die Konfiguration von Cloud Service Mesh. Diese APIs dienen dazu, die gesamte Konfiguration des Mesh-Netzwerks.

Das Service-Routing-Modell verwendet API-Ressourcen namens Mesh, Gateway und Route. Diese Ressourcen ermöglichen eine kontextrelevantere 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 der folgenden Typen:

  • HTTPRoute
  • GRPCRoute
  • TCPRoute
  • TLSRoute

Die Google Cloud Console bietet keine Unterstützung für das Dienstrouting APIs Sie müssen diese API-Ressourcen mithilfe der Google Cloud CLI oder der REST APIs

Anwendungsfälle und Vorteile

Mit den Service Routing 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 Dienst-Routing-APIs verwenden protokoll- und routenspezifische Ressourcen, die unabhängigen Dienstinhabern konfiguriert wurden und sind. Dieser Ansatz bietet verschiedene Vorteile.

• Dienstinhaber haben jetzt Autonomie darüber, wie sie Richtlinien und Trafficverwaltung für ihre eigenen 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 für Updates nicht auf Mesh-Administratoren verlassen. Routenplanung.

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

Mit dem neuen Service Routing API-Modell können Dienstinhaber mithilfe einer freigegebenen VPC und anderen Verbindungsmethoden eine freigegebene Mesh-Infrastruktur nutzen, gleichzeitig aber unabhängige Kontrolle über ihre Dienste behalten. 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 dargestellte Bereitstellung leitet Service Mesh-Traffic, bei dem die SNI-Erweiterung den Wert service1 hat, an den Backend-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)

gRPC-Hauptunterstützung

Sie können proxylose gRPC-Clients mithilfe von gRPC-Grundlagen wie dem Abgleich nach Methode konfigurieren.

Trafficaufteilung für TCP-Traffic

Sie können die gewichtete Trafficaufteilung für TCP-Traffic implementieren mehrere Back-End-Dienste nutzen. 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 empfangen die Konfiguration von Cloud Service Mesh durch Beitritt zum Service Mesh, das durch Mesh identifiziert wird Name der Ressource. Die Mesh-Ressource unterstützt die folgenden Bereitstellungen auf 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-Dienst Ressourcen. Die Dienste werden über die Backend-Dienst-API konfiguriert. Ich Erstellen Sie 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)

Um die Verwaltung Ihres Service Mesh zu vereinfachen, können Sie alle Route-Ressourcen auflisten, die mit einer Mesh- oder Gateway-Ressource verknüpft sind.

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-Diensts 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 Datenebene haben die Envoy-Proxys die im Ingress-Gateway-Modus ausgeführt werden, müssen auch denselben Bereichsparameter an Cloud Service Mesh, um die Gateway-Konfiguration zu erhalten. 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, zu einer Mesh- oder Gateway-Ressource, die in einem zentralisierten Verwaltungsprojekt 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 Admin-Projekt) als Mesh-Administratorprojekt aus, in dem Sie eine Mesh-Ressource erstellen. Der Inhaber des Mesh-Verwaltungsprojekts autorisiert Route Ressourcen von anderen Projekte auf die Ressource Mesh verweisen können, sodass die Routingkonfiguration anderen Projekten benötigt, um Teil des Mesh-Netzwerks zu werden. Eine Mesh-Datenebene, ob Envoy oder gRPC, fordert die Konfiguration vom Administratorprojekt an und empfängt eine Vereinigung aller Routen, die mit Mesh verbunden sind. Bei einem Gateway werden die Routen außerdem über alle Gateways hinweg, die denselben Bereich verwenden, zusammengeführt.

Das Administratorprojekt Mesh kann ein beliebiges von Ihnen ausgewähltes Projekt sein. Die Konfiguration funktioniert, solange die zugrunde liegenden Projekte eine VPC-Netzwerkverbindung haben, entweder über freigegebene VPC oder über 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 Berechtigungen des Typs networkservices.mesh.*.
• Gateway-Administratoren benötigen networkservices.gateways.*-Berechtigungen.
• Dienstinhaber müssen networkservices.grpcRoutes.*-, networkservices.httpRoutes.*- oder networkservices.tcpRoutes.*-Berechtigungen haben.

Mesh-Administratoren müssen dem Dienst die Berechtigung networkservices.mesh.use erteilen damit die Dienstinhaber ihre Route-Ressourcen an die Mesh. Dasselbe Modell gilt für Gateway-Ressourcen.

Wenn Sie alle IAM-Berechtigungen für Mesh-Ressourcen sehen möchten, wechseln Sie zur Referenzseite für IAM-Berechtigungen und suche nach meshes.

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

Überlegungen und Einschränkungen

• Die Google Cloud Console unterstützt die Service Routing APIs nicht.
• Verwenden Sie die xDS API-Version 3 oder höher.
  • Mindest-Envoy-Version von 1.20.0 (da die Dienst-Routing-APIs wird nur in xDS Version 3 unterstützt)
  • 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 Dienstrouting-APIs verwenden.
• Die Service Routing APIs sind nicht mit den älteren APIs abwärtskompatibel.
• 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 einem Mesh oder Ressource vom Typ Gateway 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.