Service Routing APIs für Traffic Director

Dieses Dokument richtet sich an Mesh- oder Plattform-Administratoren und Dienstentwickler, die fortgeschrittene Kenntnisse von Traffic Director und Service Mesh-Konzepten haben. Dieses Dokument gilt für Bereitstellungen mit Envoy- und gRPC-Clients. Weitere Informationen zu Konzepten von Traffic Director finden Sie in der allgemeinen Übersicht und in der Übersicht über proxylose gRPC-Dienste.

Traffic Director 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.

Dieses Dokument beschreibt die Service Routing APIs zum Konfigurieren von Traffic Director. Die APIs wurden entwickelt, um die Mesh-Konfiguration insgesamt zu vereinfachen und zu verbessern.

Dieses API-Modell ersetzt die älteren Ressourcen Weiterleitungsregel, Zielproxy und URL-Zuordnung durch 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.

• Mesh
  • Dienst-zu-Dienst-Trafficverwaltung (Ost-West) für Envoy-Sidecar-Proxys und proxylose gRPC-Clients.
  • Identifiziert das Service Mesh und stellt die Komponente dar, die für das Abfangen und Weiterleiten von Traffic sowie für die Anwendung von Richtlinien verantwortlich ist. Außerdem identifiziert sie den Port zum Abfangen des Traffics.
• Gateway
  • 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.
  • Identifiziert mittlere Proxys und stellt die Komponente dar, die eine Liste von IP-Adresse/Port-Paaren überwacht, Traffic weiterleitet und Richtlinien anwendet.
• Route
  • Identifiziert Hostnamen und Ports, die von Clients zum Weiterleiten von Traffic an Back-End-Dienste verwendet werden, und enthält komplexe Informationen zum Traffic-Routing. Es gibt verschiedene Arten von Route-Ressourcen.
  • 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. Außerdem gibt es keinen automatisierten Migrationspfad von den älteren APIs zu den Service Routing APIs. Wenn Sie eine vorhandene Bereitstellung ersetzen möchten, müssen Sie eine neue Traffic Director-Bereitstellung mit den Service Routing APIs erstellen und dann die alte Bereitstellung beenden.

Anwendungsfälle und Vorteile

Mit den Service Routing APIs können Sie Traffic Director 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

In der älteren Traffic Director API definiert die URL-Zuordnung das Routing für die Dienst-zu-Dienst-Kommunikation im Mesh-Netzwerk und für externen Traffic, der über einen verwalteten Load-Balancer in das Mesh eingeht. Wenn mehrere Teams eine einzelne URL-Zuordnungsressource bearbeiten, sind damit potenzielle Zuverlässigkeitsprobleme verbunden und die Delegierung der dienstspezifischen Konfiguration an Dienstinhaber wird erschwert.

Die Service Routing APIs führen protokoll- und routenspezifische Ressourcen ein, die von unabhängigen Dienstinhabern konfiguriert werden und diesen gehören können. 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-Netzwerk aus. Der Aktualisierungsvorgang ist auch weniger fehleranfällig, da Dienstinhaber viel kleinere 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 über die zentralisierte URL-Zuordnungsressource aktualisieren.

Nur relevante Optionen konfigurieren

Die Service Routing APIs ersetzen Weiterleitungsregeln, Zielproxys und URL-Zuordnungen. Sie müssen keine virtuellen IP-Adressen mehr von Ihrem VPC-Netzwerk (Virtual Private Cloud) für die Dienst-zu-Dienst-Kommunikation mit Sidecar-Proxys und proxylosen gRPC-Diensten zuweisen.

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)

Integrierte gRPC-Unterstützung

Sie können proxylose gRPC-Clients mit integrierten gRPC-Attributen wie dem Abgleich nach Methode konfigurieren, anstatt in äquivalente Pfade zu übersetzen und Pfad-Matcher zu verwenden.

Trafficaufteilung für TCP-Traffic

Sie können jetzt die gewichtete Traffic-Aufteilung für TCP-Traffic über mehrere Backend-Dienste 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 Traffic Director, indem sie dem Service Mesh beitreten, das durch den Namen der Mesh-Ressource identifiziert wird. Der Mesh-Name wird als Bootstrap-Parameter von automatisierten Envoy-Bereitstellung in Compute Engine und vom automatischer Envoy-Injektor in GKE unterstützt.

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 Route-Ressource verweist auch auf eine oder mehrere Backend-Dienstressourcen. Die Dienste werden über die Backend-Dienst-API mit dem vorhandenen Konfigurationsablauf konfiguriert. Die Dienstrouting-APIs ändern nicht die Definition von Back-End-Diensten und Systemdiagnosen in der Traffic Director-Konfiguration. Erstellen Sie dazu 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)

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 Backend-Diensts anhand des vorhandenen Konfigurationsablaufs und der APIs 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. Traffic Director führt die einzelnen Konfigurationen aller Gateways mit demselben Bereich dynamisch zusammen. Auf der Seite der Datenebene müssen die Envoy-Proxys, die im Modus für Ingress-Gateways ausgeführt werden, auch denselben Bereichsparameter für Traffic Director angeben, 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

Traffic Director 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 Administratorprojekt 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 über eine VPC-Netzwerkverbindung verfügen, 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 networkservices.mesh.*-Berechtigungen.
• Gateway-Administratoren benötigen networkservices.gateways.*-Berechtigungen.
• Dienstinhaber müssen networkservices.grpcRoutes.*-, networkservices.httpRoutes.*- oder networkservices.tcpRoutes.*-Berechtigungen haben.

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

Rufen Sie die Referenzseite für IAM-Berechtigungen auf und suchen Sie nach meshes, um alle IAM-Berechtigungen für Mesh-Ressourcen anzuzeigen.

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.

Service Routing APIs und ältere APIs im Vergleich

In diesem Abschnitt wird ein Themenvergleich zwischen den älteren APIs und den Service Routing APIs für Traffic Director vorgenommen.

	Ältere APIs	Service Routing APIs
API-Ressourcen	Weiterleitungsregel, Ziel-Proxy, URL-Zuordnung und Backend-Dienst.	Gateway, Mesh-Netzwerk, Route und Backend-Dienst.
IP-Adressen und Portnummern für Dienste	Sie müssen IP-Adressen und Portnummern für Ihre Dienste bereitstellen und Weiterleitungsregeln konfigurieren, die in allen Anwendungsfällen mit den IP:Port-Paaren übereinstimmen müssen. Sie müssen die IP-Adressen manuell den Hostnamen zuordnen oder die Catchall-IP-Adresse 0.0.0.0 verwenden.	Für Mesh- oder Gateway-Anwendungsfälle müssen Sie keine IP-Adressen konfigurieren. Für Gateway müssen Portnummern konfiguriert werden.
Service Mesh-Bereich	Traffic Director programmiert alle an das VPC-Netzwerk angehängten Proxys, sodass der Mesh-Bereich das VPC-Netzwerk ist.	Traffic Director programmiert keine Proxys basierend auf dem VPC-Netzwerk. Für die Ost-West-Dienst-zu-Dienst-Kommunikation verwenden Envoy- und proxylose gRPC-Clients den Namen der Ressource Mesh. Bei Anwendungsfällen für das Nord-Süd-Ingress-Gateway gibt es in der Gateway API einen scope-Parameter, der zulässt, dass mehrere Gateways mit einer zusammengeführten Konfiguration zusammen gruppiert werden.
Projektübergreifende Verweise in Umgebungen mit freigegebener VPC	Projektübergreifende Verweise werden nicht unterstützt. Alle API-Ressourcen müssen im selben Projekt konfiguriert werden.	Mesh- oder Gateway-Ressourcen können in einem zentral verwalteten Projekt (Hostprojekt) erstellt werden. Dienstinhaber können die Route-Ressourcen in Dienstprojekten in der freigegebenen VPC-Umgebung erstellen. Die Route-Ressourcen können sich auf das projektübergreifende Mesh oder Gateway beziehen.
Interception-Port	Der Bootstrap-Parameter TRAFFICDIRECTOR_INTERCEPTION_PORT muss in jeder Envoy-Verbindung angegeben werden, die eine Verbindung zu Traffic Director herstellt. Bei der automatischen Envoy-Bereitstellung in der Compute Engine API und der automatischen Sidecar-Einfügung in GKE ist dieser Wert standardmäßig 15001.	Der Interception-Port ist in der Ressource Mesh konfiguriert und gilt automatisch für alle Envoy-Instanzen, die eine Konfiguration für diesen Mesh anfordern. Wenn nicht angegeben, wird der Wert weiterhin auf 15001 gesetzt.

Bootstrapping-Envoy- und gRPC-Clients in Compute Engine und GKE

	Ältere APIs	Service Routing APIs
Automatische Envoy-Bereitstellung in Compute Engine verwenden	Wenn Sie die VM-Vorlage erstellen, geben Sie den Befehlszeilenparameter --service-proxy=enabled an, der den Envoy-Proxy mit den erforderlichen Attributen dynamisch startet.	Beim Erstellen der VM-Vorlage geben Sie zusätzliche Parameter an. Zum Beispiel --service-proxy=enabled, mesh=[MESH_NAME] (für Mesh-Netzwerke) oder --service-proxy=enabled, scope=[SCOPE_NAME] (für Gateways). Andere erforderliche Attribute werden dynamisch über Bootstrapping verknüpft. Für Envoys, die als Gateway dienen, darf serving_ports nicht im Befehlszeilenargument --service-proxy angegeben sein. Weitere Informationen finden Sie unter Optionen für die Einrichtung einer Compute Engine-VM mit automatischer Envoy-Bereitstellung.
Automatische Sidecar-Einfügung in GKE verwenden	Sie geben die erforderlichen Bootstrap-Attribute in der configMap des Sidecar-Injektors an.	Gleicher Workflow mit den neuen Attributen, die in der configMap angegeben sind.
Manuelle Sidecar-Einfügung in GKE verwenden	Wie hier beschrieben, muss der Anwendungs-Pod einen Envoy-Sidecar-Container haben, auf den ein Bootstrapping mit den erforderlichen Attributen angewendet wurde.	Gleicher Workflow mit den neuen Attributen.
gRPC-Clients mit Compute Engine oder GKE bereitstellen	Das Bootstrapping der Clientanwendung muss mit den erforderlichen Attributen erfolgen.	Gleicher Workflow mit den neuen Attributen.

Anwendungsfälle für Mesh-Netzwerke und Gateways konfigurieren

	Ältere APIs	Service Routing APIs
Dienst-zu-Dienst-mTLS in GKE	Folgen Sie der unter diesem Link beschriebenen Anleitung für Sidecar-basierte Bereitstellungen von Envoy. Folgen Sie dieser Anleitung für proxylose gRPC-basierte Bereitstellungen.	Es gelten dieselben Anleitungen. Die Client-TLS-Richtlinie und Server-TLS-Richtlinie muss jeweils auf die Ressourcen des Backend-Diensts bzw. der Endpunktrichtlinie angewendet werden. Da diese beiden APIs orthogonal zu den neuen APIs sind, bleibt der Konfigurationsablauf unverändert.
Bereitstellungen von Middle-Proxys (Ingress- oder Egress-Gateway) sichern	Die Anleitung dafür finden Sie hier. Die Ressourcen der Server-TLS-Richtlinie und der Autorisierungsrichtlinie sind mit der Ziel-HTTPS-Proxy-Ressource verknüpft.	Sie hängen die Ressourcen der Server-TLS-Richtlinie und der Autorisierungsrichtlinie an das Gateway an.

Überlegungen und Einschränkungen

• Die Service Routing APIs werden von der Google Cloud Console nicht unterstützt.
• Verwenden Sie die xDS API-Version 3 oder höher.
  • Envoy-Mindestversion 1.24.9.
  • 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.
• Terraform wird in dieser Release nicht unterstützt.
• 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 zu den verfügbaren Konfigurationen mit den Service Routing APIs finden Sie in den Leitfäden zur Einrichtung von Traffic Director für Dienstrouting.
• Informationen zu den Service Routing APIs finden Sie in der Dokumentation zu den Network Services APIs.