Ü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.

Ü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 mit Sidecar-Proxys und Gateway-Proxys. Die Traffic Director-Unterstützung für proxylose gRPC-Anwendungen bietet ein zusätzliches Bereitstellungsmodell, bei dem gRPC-Anwendungen in ein Service Mesh integriert werden können, ohne einen Sidecar-Proxy zu benötigen. Eine vollständige Übersicht über die Funktionsweise von Traffic Director finden Sie in der Übersicht zu Traffic Director.

In einem typischen Beispiel stellt ein gRPC-Client eine Verbindung mit einem gRPC-Server her, der Ihre Back-End-Logik hostet. Traffic Director stellt den gRPC-Clients Informationen darüber zur Verfügung, welche Server kontaktiert werden sollen, wie Anfragen an mehrere Instanzen eines Servers per Load-Balancing verteilt werden und wie Anfragen verarbeitet werden, wenn ein Server nicht ausgeführt wird.

Funktionsweise von Traffic Director mit gRPC-Anwendungen

Traffic Director konfiguriert gRPC-Clients mit einer unterstützten gRPC-Version, ähnlich wie Sidecar-Proxys (z. B. Envoy) konfiguriert werden. Proxylose gRPC-Anwendungen, die direkt mit Traffic Director verbunden sind, benötigen jedoch keine Sidecar-Proxys. Stattdessen verwendet Traffic Director Open Source xDS v2 APIs, um gRPC-Anwendungen direkt zu konfigurieren. Diese gRPC-Anwendungen dienen als xDS-Clients und stellen eine Verbindung zur globalen Steuerungsebene von Traffic Director her. Nachdem sie verbunden wurden, erhalten gRPC-Anwendungen eine dynamische Konfiguration von der Steuerungsebene, wodurch die Endpunkterkennung, Load-Balancing, regionales Failover, Systemdiagnosen und mehr aktiviert werden.

Dieser Ansatz ermöglicht zusätzliche Traffic Director-Bereitstellungsmuster. In der ersten Abbildung unten wird ein Service Mesh mithilfe eines Sidecar-Proxys aktiviert.

Ein Service Mesh, das mit einem Sidecar-Proxy aktiviert wird (zum Vergrößern klicken)
Ein Service Mesh, das mit einem Sidecar-Proxy aktiviert wird (zum Vergrößern klicken)

Traffic Director konfiguriert einen Sidecar-Proxy mithilfe von xDS v2 APIs. Der gRPC-Client kommuniziert mit dem gRPC-Server über den Sidecar-Proxy.

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

Ein mit proxylosem gRPC aktiviertes Service Mesh (zum Vergrößern klicken)
Ein mit proxylosem gRPC aktiviertes Service Mesh (zum Vergrößern klicken)

Wenn Sie nur gRPC-Dienste bereitstellen, die von Traffic Director konfiguriert wurden, können Sie ein Service Mesh erstellen, ohne Proxys bereitzustellen. Das erleichtert die Bereitstellung von Service Mesh-Funktionen in Ihren gRPC-Anwendungen.

Schema zur Namensauflösung

So funktioniert die Namensauflösung für proxylose Bereitstellungen:

  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, beispielsweise im Ziel-URI xds:///foo.myservice.
  2. Der gRPC-Client löst den hostname:port im Ziel-URI durch Senden einer LDS-Anfrage an Traffic Director aus.
  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 foo.myservice, foo.myservice:80 und foo.myservice:8080 unterschiedliche Regeln.

Namensauflösung mit unterschiedlichen Bereitstellungstypen

Das Namensauflösungsschema ist für proxylose Bereitstellungen und für 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 erhalten. Der gRPC-Client kommuniziert dann direkt mit dem gRPC-Server.

Sie können Sidecar- und proxylose Bereitstellungsmuster kombinieren, um mehr Flexibilität zu erhalten. Das ist besonders hilfreich, wenn Ihre Organisation und Ihr Netzwerk mehrere Teams mit unterschiedlichen Featureanforderungen, operativen Anforderungen und gRPC-Versionen unterstützen.

In der folgenden Abbildung kommunizieren sowohl proxylose gRPC-Clients als auch gRPC-Clients, die einen Sidecar-Proxy verwenden, mit einem gRPC-Server.

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

Die gRPC-Clients mit Sidecar-Proxys verwenden das Namensauflösungsschema dns.

Anwendungsfälle

Diese Beispiele veranschaulichen, wie Sie ein Service Mesh mit Ihren proxylosen gRPC-Diensten verwenden können.

In den folgenden Anwendungsfällen erfahren Sie, wann Sie Traffic Director mit proxylosen gRPC-Anwendungen verwenden können. Beachten Sie, dass Ihre Bereitstellung proxylose gRPC-Anwendungen, gRPC-Anwendungen mit Sidecars oder eine Kombination aus beiden umfassen kann.

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 gesamte Ressourcenverbrauch der ausgeführten Sidecar-Proxys zunimmt. 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 sein, 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 Sie keine Sidecar-Proxys bereitstellen 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 ist eventuell auch nicht möglich, den Netzwerkstack eines Computers so zu konfigurieren, dass er abgefangen und weitergeleitet wird, z. B. mit iptables. In diesem Fall können Sie Traffic Director mit proxylosen gRPC-Anwendungen verwenden, um Service Mesh-Funktionen zu Ihren gRPC-Anwendungen hinzuzufügen.

Heterogenes Service Mesh

Da sowohl proxylose gRPC-Anwendungen als auch Envoy mit Traffic Director kommunizieren, kann Ihr Service Mesh beide Bereitstellungsmodelle enthalten. Dadurch können Sie die spezifischen Betriebs-, Leistungs- und Featureanforderungen verschiedener Anwendungen und Entwicklungsteams erfüllen.

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

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

Wenn ein gRPC-Client mit einem Sidecar-Proxy bereitgestellt wird, wird DNS verwendet, um den Hostnamen aufzulösen, mit dem eine Verbindung hergestellt wird. Der Traffic wird vom Sidecar-Proxy abgefangen, um Service Mesh-Funktionen bereitzustellen.

Sie können festlegen, ob ein gRPC-Client die proxylose Route oder die Sidecar-Route verwendet, um mit einem gRPC-Server zu kommunizieren. Dazu ändern Sie das verwendete Namensauflösungsschema. Proxylose Clients verwenden das Namensauflösungsschema xds und Sidecar-Proxys verwenden das Namensauflösungsschema dns. Einige gRPC-Clients können sogar die proxylose Route verwenden, wenn sie mit einem bestimmten gRPC-Server kommunizieren, aber die Sidecar-Route verwenden, wenn sie mit einem anderen gRPC-Server kommunizieren. Auf diese Weise können Sie schrittweise zu einer proxylosen Bereitstellung migrieren.

Erstellen Sie dazu einen neuen Traffic Director-Dienst, der von Ihrem proxylosen gRPC-Client verwendet wird. Sie können Traffic Director für die vorhandenen und neuen Versionen mit denselben APIs konfigurieren.

Service Mesh mit einem gRPC-Client, der über proxylose und proxybasierte Mechanismen mit unterschiedlichen Diensten kommuniziert (zum Vergrößern klicken)
Service Mesh mit einem gRPC-Client, der über proxylose und proxybasierte Mechanismen mit unterschiedlichen 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 dieser Anleitung beschrieben werden. Einige dieser Einschränkungen sind nur vorübergehend, da proxyloses gRPC noch nicht alle Features von Envoy unterstützt, und andere an die Verwendung von RPCs gebunden sind. Zum Beispiel werden HTTP-Weiterleitungen mit gRPC nicht unterstützt. Wir empfehlen Ihnen, sich mit den Konzepten und der Konfiguration von Traffic Director vertraut zu machen, um das Konfigurationsmodell in dieser Anleitung besser zu verstehen.

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

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

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.

Weiterleitungsregel

In der Regel erstellen Sie die Weiterleitungsregel mithilfe der virtuellen IP-Adresse und des Ports des Dienstes, den Sie konfigurieren. Ein gRPC-Client, der das Schema zur Namensauflösung xds verwendet, führt keinen DNS-Lookup durch, um den Hostnamen im Kanal-URI aufzulösen. Stattdessen löst ein solcher Client den hostname[:port] im Ziel-URI durch Senden einer LDS-Anfrage an Traffic Director auf. Es wird kein DNS-Lookup ausgeführt und es ist kein DNS-Eintrag für den Hostnamen erforderlich. Als Ergebnis 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 in der URL-Zuordnung nach einer übereinstimmenden Hostregel, die dem Zielproxy zugeordnet ist, auf den die Weiterleitungsregel verweist.

Daher muss für eine Weiterleitungsregel, die auf einen gRPC-Zielproxy mit dem Feld validateForProxyless auf TRUE verweist, die IP-Adresse 0.0.0.0 eingestellt sein. Wenn validateForProxyless auf TRUE gesetzt ist, werden Konfigurationen abgelehnt, die eine andere IP-Adresse als 0.0.0.0 angeben.

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 mit dem in der Hostregel angegebenen Port übereinstimmen.
  • Wenn mehrere Weiterleitungsregeln einen Port haben, der mit dem Port im Ziel-URI übereinstimmt, sucht Traffic Director in den Hostregeln der URL-Zuordnungen, auf die von allen diesen Weiterleitungsregeln verwiesen wird, nach einer passenden 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. Platzhalterzeichen in den Hostregeln und Standardregeln einer URL-Zuordnung werden übersprungen.

Wenn mehrere Übereinstimmungen gefunden werden, ist das Verhalten nicht definiert und kann zu unvorhersehbarem Verhalten führen. Dies geschieht im Allgemeinen, wenn die 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 verwiesen wird, die denselben Port angeben.

gRPC-Zielproxy

Zielproxys verweisen auf URL-Zuordnungen, die wiederum Regeln enthalten, die zur Weiterleitung von Traffic an das richtige Back-End verwendet werden. Verwenden Sie bei der Konfiguration von Traffic Director für gRPC-Anwendungen einen gRPC-Zielproxy und keinen Ziel-HTTP-Proxy, unabhängig davon, ob Sie proxylose gRPC-Anwendungen oder gRPC-Anwendungen mit Envoy verwenden.

Ziel-gRPC-Proxys haben ein Feld namens 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 proxylosem gRPC kompatibel ist.

Im gcloud-Befehlszeilentool 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 Back-End-Dienst angegeben sind, abgelehnt werden. Beachten Sie auch, dass die Konfigurationsvalidierung 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. Die URL-Zuordnung 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. Dieser URI 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 in 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.

  • Der Ziel-URI xds:///myservice stimmt mit der Hostregel myservice in der URL-Zuordnung überein.
  • Der Ziel-URI xds:///myservice stimmt nicht mit der Hostregel myservice:80 in der URL-Zuordnung überein.
  • Der Ziel-URI xds:///myservice:80 stimmt nicht mit der Hostregel myservice in 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 von URL-Zuordnungen.

Systemdiagnosen

Eine gRPC-Systemdiagnose kann den Status eines gRPC-Dienstes prüfen, der auf einer Back-End-VM oder NEG ausgeführt wird.

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

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

Back-End-Dienst

Der Back-End-Dienst definiert, wie ein gRPC-Client mit einem gRPC-Server kommuniziert. Legen Sie beim Erstellen eines Back-End-Dienstes für gRPC das Protokollfeld auf GRPC fest.

  • Ein Back-End-Dienst, für den das Protokoll GRPC festgelegt ist, kann von gRPC-Anwendungen auch über einen Sidecar-Proxy aufgerufen werden. 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 Netzwerk-Endpunktgruppen (NEGs) in Google Kubernetes Engine als Back-Ends zum Hosten Ihrer gRPC-Serverinstanzen verwenden.

Beschränkungen

  • Sie können in der Google Cloud Console keine Back-End-Dienste und Routingregelzuordnungen konfigurieren. Die Cloud Console ist für diese Ressourcen schreibgeschützt.

  • gRPC 1.30.0 (mit dem neuesten Patch) unterstützt derzeit proxylose gRPC-Anwendungen in den Sprachen C++, Java, Go, Python, PHP, Ruby und C#.

  • Proxyloses gRPC unterstützt die Endpunkterkennung, Routing, Load-Balancing und Ladeberichte.

    • Wenn Sie Features benötigen, die nicht unterstützt werden, z. B. die erweiterte Trafficverwaltung, konfigurieren Sie Ihre gRPC-Clients so, dass sie proxylose gRPC-Dienste nur für eine Teilmenge der Dienste verwenden. Sie können Sidecar-Proxys zur Kommunikation mit Servern verwenden, die Funktionen benötigen, die noch nicht von proxylosen gRPC-Diensten unterstützt werden.
    • Hostabgleichsregeln werden mit Ausnahme von Platzhalterzeichen unterstützt.
    • Pfadregeln und Routingregeln werden nicht unterstützt. Für den Pfad-Matcher, der von der Hostregel verwendet wird, kann nur ein Standarddienst konfiguriert sein.
  • In der gRPC-Version 1.30.0 wird nur Round Robin-Load-Balancing unterstützt. Andere Load-Balancing-Algorithmen werden nicht unterstützt.

    • Traffic Director stellt dem gRPC-Client eine priorisierte, gewichtete Liste der Orte (eine Instanzgruppe oder eine NEG) zur Verfügung. Traffic Director berechnet dies auf Grundlage der nächstgelegenen verfügbaren Zone, deren Kapazität und dem Balancing-Modus des Back-End-Dienstes. Für eine bestimmte Anfrage wählt der gRPC-Client anhand von Priorität und Gewichtung eine oder mehrere Standorte aus und führt Round Robin-Load-Balancing für die Back-Ends an diesen Standorten aus.
  • Failover: Das Failover von einer Zone zu einer anderen Zone (einem anderen Ort) beginnt, wenn die aktuelle Zonenkapazität unter 50 % fällt. Dieser Schwellenwert kann nicht konfiguriert werden.

  • In einigen Fällen können die Konfigurationsbefehle für einen gRPC-Zielproxy und eine Weiterleitungsregel, die auf einen gRPC-Zielproxy verweisen, bis zu einer Minute dauern.

  • Wenn Sie die Hostregel einer URL-Zuordnung ändern, um von einem Back-End-Dienst zu einem anderen zu wechseln, wird der Traffic möglicherweise unterbrochen, während die neue Konfiguration an die Clients übertragen wird. Um dies zu vermeiden, führen Sie die Bereitstellung mit Sidecar-Proxys bereit und implementieren Sie die Trafficaufteilung mit gewichteten Back-End-Diensten. Verschieben Sie den Traffic dann langsam vom alten zum neuen Back-End-Dienst.

Einschränkungen für URL-Zuordnungen

In dieser Version gelten die folgenden Einschränkungen für URL-Zuordnungen:

  • Der von der Hostregel verwendete Pfad-Matcher kann nur einen Standarddienst konfigurieren.
  • Pfadregeln und Routingregeln werden nicht unterstützt.
  • In Hostregeln für URL-Zuordnungen werden keine Platzhalterzeichen unterstützt.
  • Die unter Erweiterte Trafficverwaltung konfigurieren beschriebenen erweiterten Features zur Trafficverwaltung werden nicht unterstützt.

Nächste Schritte