Übersicht über Traffic Director mit proxylosen gRPC-Diensten

Dieser Leitfaden bietet eine Übersicht über die Architektur von Traffic Director mit proxylosen gRPC-Diensten, einschließlich Anwendungsfällen und Architekturmustern. In dieser Anleitung werden die älteren Traffic Director APIs behandelt. Informationen zu den Dienstrouting-APIs finden Sie in der Übersicht.

Die verwaltete Steuerungsebene von Traffic Director ermöglicht globales Routing, Load-Balancing und regionales Failover für Service Mesh- und Load-Balancing-Anwendungsfälle. Dazu gehören auch Bereitstellungen, die Sidecar- und Gateway-Proxys enthalten. Da Traffic Director proxylose gRPC-Anwendungen unterstützt, steht Ihnen ein zusätzliches Bereitstellungsmodell zur Verfügung. Hierbei können gRPC-Anwendungen Teil eines Service Mesh sein, ohne dass ein Sidecar-Proxy erforderlich ist.

In einem typischen Beispiel stellt ein gRPC-Client eine Verbindung mit einem gRPC-Server her, der Ihre Back-End-Logik hostet. Traffic Director informiert gRPC-Clients darüber, welche Server kontaktiert werden sollen, wie das Load-Balancing von Anfragen an mehrere Instanzen eines Servers erfolgt und was mit Anfragen geschehen soll, wenn ein Server nicht ausgeführt wird.

Eine vollständige Übersicht über die Funktionsweise von Traffic Director finden Sie unter Traffic Director – Übersicht.

Funktionsweise von Traffic Director mit gRPC-Anwendungen

Traffic Director konfiguriert gRPC-Clients mit einer unterstützten gRPC-Version. Dies ähnelt der Konfiguration von Sidecar-Proxys wie Envoy. Proxylose gRPC-Anwendungen, die direkt mit Traffic Director verbunden sind, benötigen jedoch keine Sidecar-Proxys. Stattdessen verwendet Traffic Director Open Source xDS APIs, um gRPC-Anwendungen direkt zu konfigurieren. Diese gRPC-Anwendungen dienen als xDS-Clients, die eine Verbindung zur globalen Steuerungsebene von Traffic Director herstellen. Nachdem sie verbunden wurden, erhalten gRPC-Anwendungen eine dynamische Konfiguration von der Steuerungsebene, wodurch die Endpunkterkennung, das Load-Balancing, regionales Failover und Systemdiagnosen möglich sind. Mithilfe dieses Ansatzes können Sie zusätzliche Traffic Director-Bereitstellungsmuster nutzen.

In der ersten Abbildung wird ein Service Mesh durch die Verwendung eines Sidecar-Proxys aktiviert.

Ein Service Mesh, das mithilfe eines Sidecar-Proxys aktiviert wird (zum Vergrößern klicken)

Zur Konfiguration eines Sidecar-Proxys verwendet Traffic Director xDS APIs. Clients kommunizieren über den Sidecar-Proxy mit dem Server.

In der zweiten Abbildung wird ein Service Mesh ohne einen Sidecar-Proxy aktiviert. Dazu wird ein proxyloser gRPC-Client verwendet.

Ein Service Mesh, das mit proxylosem gRPC aktiviert wurde (zum Vergrößern klicken)

Wenn Sie nur gRPC-Dienste bereitstellen, die von Traffic Director konfiguriert werden, können Sie ein Service Mesh erstellen, ohne überhaupt Proxys bereitzustellen. Dies erleichtert die Nutzung von Service Mesh-Funktionen in Ihren gRPC-Anwendungen.

Schema zur Namensauflösung

Die Namensauflösung funktioniert bei proxylosen Bereitstellungen auf folgende Weise:

1. Sie legen xds als Namensauflösungsschema im gRPC-Clientkanal fest, wenn eine Verbindung zu einem Dienst hergestellt wird. Der Ziel-URI hat das Format xds:///hostname:port. Wenn der Port nicht angegeben wird, ist der Standardwert 80, z. B. im Ziel-URI xds:///example.hostname.
2. Der gRPC-Client löst den hostname:port im Ziel-URI auf. Dazu wird eine LDS-Anfrage (Listener Discovery Service) an Traffic Director gesendet.
3. Traffic Director sucht die konfigurierten Weiterleitungsregeln mit einem übereinstimmenden Port. Anschließend wird die entsprechende URL-Zuordnung für eine Hostregel gesucht, die mit hostname:port übereinstimmt. Sie gibt die zugehörige Routingkonfiguration an den gRPC-Client zurück.

Die Hostregeln, die Sie in Traffic Director konfigurieren, müssen in allen URL-Zuordnungen eindeutig sein. Beispielsweise sind example.hostname, example.hostname:80 und example.hostname:8080 unterschiedliche Regeln.

Namensauflösung mit unterschiedlichen Bereitstellungstypen

Das Namensauflösungsschema ist für proxylose Bereitstellungen und Bereitstellungen, die Envoy-Proxys verwenden, unterschiedlich.

Der gRPC-Client verwendet das Namensauflösungsschema xds, um eine Verbindung zu einem Dienst herzustellen. Dadurch kann der Client die Dienstkonfiguration von Traffic Director empfangen. Der gRPC-Client kommuniziert dann direkt mit dem gRPC-Server.

Sie können proxylose Bereitstellungen und Bereitstellungen mit Sidecar-Proxys kombinieren, um mehr Flexibilität zu erhalten. Eine Kombination der Bereitstellungsmuster ist besonders hilfreich, wenn Ihre Organisation und Ihr Netzwerk mehrere Teams mit unterschiedlichen Feature- und Betriebsanforderungen sowie gRPC-Versionen unterstützen.

In der folgenden Abbildung kommunizieren sowohl gRPC-Clients mit einem Sidecar-Proxy als auch proxylose gRPC-Clients mit einem gRPC-Server. Die gRPC-Clients mit Sidecar-Proxys verwenden das Namensauflösungsschema dns.

Ein Service Mesh, das aus proxylosen gRPC-Clients und gRPC-Clients mit Sidecar-Proxys besteht (zum Vergrößern klicken)

Anwendungsfälle

Anhand der folgenden Anwendungsfälle können Sie besser nachvollziehen, wann Sie Traffic Director mit proxylosen gRPC-Anwendungen verwenden sollten. Ihre Bereitstellung kann proxylose gRPC-Anwendungen, gRPC-Anwendungen mit Sidecar-Proxys oder eine Kombination aus beidem umfassen.

Ressourceneffizienz in einem umfangreichen Service Mesh

Wenn Ihr Service Mesh Hunderte oder Tausende von Clients und Back-Ends umfasst, werden Sie unter Umständen feststellen, dass der Gesamtressourcenverbrauch für ausgeführte Sidecar-Proxys stetig anwächst. Wenn Sie proxylose gRPC-Anwendungen verwenden, müssen Sie keine Sidecar-Proxys in Ihre Bereitstellung aufnehmen. Ein proxyloser Ansatz kann zu Effizienzsteigerungen führen.

Leistungsstarke gRPC-Anwendungen

Für einige Anwendungsfälle ist jede Millisekunde der Anfrage- und Antwortlatenz von Bedeutung. In einem solchen Fall kann die Latenz geringer ausfallen, wenn Sie eine proxylose gRPC-Anwendung verwenden, statt alle Anfragen über einen clientseitigen Sidecar-Proxy und gegebenenfalls einen serverseitigen Sidecar-Proxy zu übertragen.

Service Mesh für Umgebungen, in denen keine Sidecar-Proxys bereitgestellt werden können

In einigen Umgebungen ist es eventuell nicht möglich, einen Sidecar-Proxy als zusätzlichen Prozess neben Ihrer Client- oder Serveranwendung auszuführen. Es kann auch sein, dass Sie den Netzwerk-Stack einer Maschine nicht zum Abfangen und Weiterleiten von Anfragen, z. B. mit iptables, konfigurieren können. In diesem Fall können Sie Traffic Director mit proxylosen gRPC-Anwendungen verwenden, um Service Mesh-Funktionen für Ihre gRPC-Anwendungen einzusetzen.

Heterogenes Service Mesh

Da sowohl proxylose gRPC-Anwendungen als auch Envoy mit Traffic Director kommunizieren, kann Ihr Service Mesh beide Bereitstellungsmodelle enthalten. Bei Verwendung beider Modelle können Sie die unterschiedlichen Betriebs-, Leistungs- und Featureanforderungen der verschiedenen Anwendungen und unterschiedlichen Entwicklungsteams erfüllen.

Von einem Service Mesh mit Proxys zu einem Mesh ohne Proxys migrieren

Wenn Sie bereits eine gRPC-Anwendung mit einem Sidecar-Proxy haben, der Traffic Director konfiguriert hat, können Sie auf eine proxylose gRPC-Anwendung umstellen.

Wenn ein gRPC-Client mit einem Sidecar-Proxy bereitgestellt wird, wird anhand von DNS der Hostname aufgelöst, mit dem eine Verbindung hergestellt wird. Der Sidecar-Proxy fängt Traffic ab, um Service-Mesh-Funktionen bereitzustellen.

Sie können festlegen, ob ein gRPC-Client die proxylose Route oder die Sidecar-Proxy-Route verwendet, um mit einem gRPC-Server zu kommunizieren. Dazu müssen Sie das verwendete Namensauflösungsschema ändern. Proxylose Clients verwenden das Namensauflösungsschema xds und Sidecar-Proxys das Namensauflösungsschema dns. Einige gRPC-Clients verwenden bei der Kommunikation mit einem gRPC-Server möglicherweise sogar die proxylose Route, während sie bei der Kommunikation mit einem anderen gRPC-Server die Sidecar-Proxy-Route nutzen. Auf diese Weise können Sie schrittweise zu einer proxylosen Bereitstellung migrieren.

Erstellen Sie einen neuen Traffic Director-Dienst, der von Ihrem proxylosen gRPC-Client verwendet wird, um von einem Service Mesh mit Proxys zu einem proxylosen Mesh zu migrieren. Mit den gleichen APIs können Sie Traffic Director für die bestehenden und neuen Versionen konfigurieren.

Service Mesh mit einem gRPC-Client, der über proxylose und proxybasierte Mechanismen mit verschiedenen Diensten kommuniziert (zum Vergrößern klicken)

Architektur und Ressourcen

Das Konfigurationsdatenmodell für proxylose gRPC-Dienste erweitert das Konfigurationsmodell von Traffic Director mit einigen Ergänzungen und Einschränkungen, die in diesem Leitfaden beschrieben werden. Einige dieser Einschränkungen gelten nur vorübergehend, da proxylose gRPC-Dienste nicht alle Features von Envoy unterstützen. Andere sind Bestandteil der Verwendung von RPCs. Beispielsweise werden HTTP-Weiterleitungen, die gRPC verwenden, nicht unterstützt. Damit Sie das Konfigurationsmodell in dieser Anleitung besser verstehen, sollten Sie sich mit den Konzepten und der Konfiguration von Traffic Director vertraut machen.

Das folgende Diagramm zeigt die Ressourcen, die Sie für proxylose gRPC-Anwendungen konfigurieren müssen.

Ressourcen, die in proxylosen gRPC-Anwendungen für Load-Balancing unterstützt werden (zum Vergrößern klicken)

Hinweis: Einige Funktionen von Traffic Director werden für proxylose gRPC-Anwendungen noch nicht unterstützt. Weitere Informationen finden Sie auf der Seite Features. Wenn Sie ein nicht unterstütztes Feature benötigen, können Sie Envoy mit Ihren gRPC-Anwendungen verwenden. Das Konfigurieren von Traffic Director für gRPC-Anwendungen, die Envoy verwenden, folgt im Allgemeinen dem in den folgenden Abschnitten beschriebenen Konfigurationsdatenmodell.

Routingregelzuordnungen

Mit einer Routingregelzuordnung wird festgelegt, wie Anfragen im Mesh-Netzwerk weitergeleitet werden. Sie besteht aus einer Weiterleitungsregel, einem Ziel-gRPC-Proxy und einer URL-Zuordnung. Routingregelzuordnungen gelten nur für Bereitstellungen, die die Load Balancing-APIs verwenden. Sie gelten nicht für die Service Routing APIs oder Gateway APIs.

Weiterleitungsregel

Im allgemeinen erstellen Sie die Weiterleitungsregel mithilfe der virtuellen IP-Adresse und des Ports des Dienstes, den Sie konfigurieren. Ein gRPC-Client, der das Namensauflösungsschema xds verwendet, führt keinen DNS-Lookup durch, um den Hostnamen im Kanal-URI aufzulösen. Stattdessen löst ein solcher Client hostname[:port] im Ziel-URI durch Senden einer LDS-Anfrage an Traffic Director auf. Es sind kein DNS-Lookup und kein DNS-Eintrag für den Hostnamen erforderlich.

Aus diesem Grund verwendet Traffic Director nur den im URI angegebenen Port, um die Weiterleitungsregel zu suchen. Die IP-Adresse wird dabei ignoriert. Der Standardwert des Ports ist 80. Dann sucht Traffic Director nach einer übereinstimmenden Hostregel in der URL-Zuordnung, die dem Zielproxy zugeordnet ist, auf den die Weiterleitungsregel verweist.

Daher muss für eine Weiterleitungsregel, die auf einen Ziel-gRPC-Proxy verweist, für den das Feld validateForProxyless auf TRUE gesetzt ist, die IP-Adresse auf 0.0.0.0 festgelegt sein. Wenn validateForProxyless auf TRUE gesetzt ist, werden Konfigurationen, die eine andere IP-Adresse als 0.0.0.0 angeben, abgelehnt. Bei dieser Prüfung werden keine doppelten Weiterleitungsregeln mit demselben Port in anderen Routingregelzuordnungen gefunden.

Wichtige Hinweise:

• Das Load-Balancing-Schema für die Weiterleitungsregel muss INTERNAL_SELF_MANAGED sein.
• Sie können mehrere Weiterleitungsregeln erstellen. Der IP:port muss für jede Weiterleitungsregel jedoch eindeutig sein. Der Port muss außerdem mit dem in der Hostregel angegebenen Port übereinstimmen.
• Wenn mehrere Weiterleitungsregeln einen mit dem Port im Ziel-URI übereinstimmenden Port haben, sucht Traffic Director in den Hostregeln der URL-Zuordnungen, auf die durch diese Weiterleitungsregeln verwiesen wird, nach einem übereinstimmenden hostname[:port]. Traffic Director sucht nach einer genauen Übereinstimmung zwischen dem hostname[:port] in der Hostregel und dem hostname[:port], der im Ziel-URI angegeben ist. Hostregeln und Standardregeln, die Platzhalterzeichen enthalten, werden übersprungen.

Werden mehrere Übereinstimmungen gefunden, ist das Verhalten nicht definiert und kann zu unvorhersehbarem Verhalten führen. Dies geschieht im Allgemeinen, wenn die beiden folgenden Bedingungen erfüllt sind:

• Derselbe Hostname wird für mehrere URL-Zuordnungen verwendet.
• Mehrere Weiterleitungsregeln mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED geben denselben Port an.

Aus diesem Grund wird empfohlen, nicht denselben Hostnamen für mehrere URL-Zuordnungen zu verwenden, auf die von Weiterleitungsregeln mit dem demselben Port verwiesen wird.

gRPC-Zielproxy

Zielproxys verweisen auf URL-Zuordnungen, die wiederum Regeln zur Weiterleitung von Traffic an das richtige Back-End enthalten. Verwenden Sie bei der Konfiguration von Traffic Director für gRPC-Anwendungen einen Ziel-gRPC-Proxy, jedoch keinen Ziel-HTTP-Proxy. Dabei spielt es keine Rolle, ob Sie proxylose gRPC-Anwendungen oder gRPC-Anwendungen mit Envoy verwenden.

Ziel-gRPC-Proxys haben ein Feld mit dem Namen validateForProxyless in der REST API. Der Standardwert ist FALSE. Wenn Sie dieses Feld auf TRUE setzen, werden Konfigurationsprüfungen aktiviert, damit Sie nicht versehentlich ein Feature aktivieren, das nicht mit proxylosen gRPC-Anwendungen kompatibel ist.

In der Google Cloud CLI entspricht das Flag --validate-for-proxyless dem Feld validateForProxyless.

Traffic Director für proxylose gRPC-Anwendungen unterstützt nicht alle Funktionen, die für gRPC-Anwendungen mit einem Sidecar-Proxy zur Verfügung stehen. Mit diesem Feld können Sie dafür sorgen, dass ungültige Konfigurationen, die möglicherweise in der URL-Zuordnung oder im Backend-Dienst angegeben sind, abgelehnt werden. Die Konfigurationsprüfung wird anhand der Features durchgeführt wird, die Traffic Director in der neuesten gRPC-Version unterstützt.

URL-Zuordnung

Die URL-Zuordnung definiert die Routingregeln, die Ihre proxylosen gRPC-Clients zum Senden von Traffic verwenden. Sie enthält eine oder mehrere Hostregeln im Format hostname:port. Jede dieser Hostregeln wird in einen Dienst aufgelöst.

Beim Konfigurieren des gRPC-Clients geben Sie den Ziel-URI für den Dienst an, den der Client kontaktieren muss. Dieser URI verwendet auch das Format hostname:port. Er entspricht dem Hostregeleintrag in der URL-Zuordnung.

Wenn Sie beispielsweise den Ziel-URI xds:///myservice:8080 in Ihrem gRPC-Client konfigurieren, sendet Traffic Director die Konfiguration, die der Hostregel der URL-Zuordnung für myservice:8080 entspricht. Diese Konfiguration enthält unter anderem eine Liste von Endpunkten. Dabei handelt es sich jeweils um ein Paar aus IP-Adresse/-Port, das bestimmten gRPC-Serverinstanzen entspricht.

Wenn Sie im Ziel-URI keinen Port angeben, wird 80 als Standardwert verwendet. Das bedeutet:

• Der Ziel-URI xds:///myservice stimmt mit der Hostregel myservice der URL-Zuordnung überein.
• Der Ziel-URI xds:///myservice:80 stimmt mit der Hostregel myservice:80 der URL-Zuordnung überein.
• Der Ziel-URI xds:///myservice stimmt nicht mit der Hostregel myservice:80 der URL-Zuordnung überein.
• Der Ziel-URI xds:///myservice:80 stimmt nicht mit der Hostregel myservice der URL-Zuordnung überein.

Der String im Ziel-URI und der String in der Hostregel der URL-Zuordnung müssen identisch sein.

Weitere Informationen finden Sie unter Einschränkungen für URL-Zuordnungen.

Systemdiagnosen

Eine gRPC-Systemdiagnose kann den Status eines gRPC-Dienstes prüfen, der auf einer Backend-VM-Instanz oder in einer Netzwerk-Endpunktgruppe (NEG) ausgeführt wird.

Wenn eine gRPC-Systemdiagnose nicht verwendet werden kann, weil Ihr gRPC-Server das gRPC-Systemdiagnoseprotokoll nicht implementiert, sollten Sie stattdessen eine TCP-Systemdiagnose verwenden. Verwenden Sie HTTP-, HTTPS- oder HTTP/2-Systemdiagnosen nicht.

Weitere Informationen finden Sie im Abschnitt zur gRPC-Systemdiagnose und unter Zusätzliches Flag für gRPC-Systemdiagnosen.

Backend-Dienst

Der Back-End-Dienst definiert, wie ein gRPC-Client mit einem gRPC-Server kommuniziert. Wenn Sie einen Back-End-Dienst für gRPC erstellen, legen Sie das Protokollfeld auf GRPC fest.

• gRPC-Anwendungen, die mit einem Protokoll konfiguriert sind, das auf GRPC gesetzt ist, kann auch über einen Sidecar-Proxy auf einen Back-End-Dienst zugreifen. In diesem Fall darf der gRPC-Client nicht das Namensauflösungsschema xds verwenden.

• In allen Traffic Director-Bereitstellungen muss das Load-Balancing-Schema für den Back-End-Dienst INTERNAL_SELF_MANAGED sein.

Back-Ends

Back-Ends hosten Ihre gRPC-Serverinstanzen. Sie können verwaltete oder nicht verwaltete Instanzgruppen in Compute Engine und zonale NEGs in Google Kubernetes Engine als Back-Ends zum Hosten Ihrer gRPC-Serverinstanzen verwenden.

Nächste Schritte

• Weitere Informationen zu den Dienstrouting-APIs und zu ihrer Funktionsweise finden Sie in der Übersicht.
• Informationen zu Routingregelzuordnungen und deren Verwaltung in Traffic Director-Bereitstellungen finden Sie unter Übersicht über die Traffic Director-Routingregelzuordnungen.
• Wie Sie Traffic Director mit proxylosen gRPC-Anwendungen konfigurieren, erfahren Sie unter Einrichten von Traffic Director mit proxylosen gRPC-Diensten vorbereiten.
• Weitere Informationen zu Einschränkungen für proxylose gRPC-Bereitstellungen finden Sie unter Limits und Einschränkungen mit proxylosen gRPC-Anwendungen.