Übersicht über Cloud Service Mesh mit proxylosen gRPC-Diensten
Dieser Leitfaden bietet Ihnen einen Überblick über die Architektur von Cloud Service Mesh mit proxylosen gRPC-Diensten, einschließlich Anwendungsfällen und Architekturmustern.
Die verwaltete Steuerungsebene von Cloud Service Mesh ermöglicht globales Routing, und regionalem Failover für Service Mesh- und Load-Balancing-Anwendungsfälle. Dazu gehören auch Bereitstellungen, die Sidecar- und Gateway-Proxys enthalten. Cloud Service Mesh-Unterstützung für proxylose gRPC-Anwendungen bietet ein zusätzliches Bereitstellungsmodell, bei dem gRPC-Anwendungen ohne einen Sidecar-Proxy zu verwenden.
In einem typischen Beispiel stellt ein gRPC-Client eine Verbindung mit einem gRPC-Server her. das Ihre Back-End-Logik hostet. Mit Cloud Service Mesh können Ihre gRPC-Clients Informationen darüber, welche Server kontaktiert werden müssen, wie das Load-Balancing von Anfragen Serverinstanzen und was mit Anfragen zu tun ist, wenn ein Server nicht ausgeführt wird.
Eine vollständige Übersicht über die Funktionsweise von Cloud Service Mesh finden Sie in der Cloud Service Mesh – Übersicht
Funktionsweise von Cloud Service Mesh mit gRPC-Anwendungen
Cloud Service Mesh konfiguriert gRPC-Clients mit einer unterstützte gRPC-Version, ähnlich wie Sidecar-Proxys wie Envoy konfiguriert sind. Sie können jedoch proxylose gRPC-Anwendungen, die direkt mit Cloud Service Mesh verbunden sind, Sidecar-Proxys. Stattdessen nutzt Cloud Service Mesh Open-Source-xDS-APIs, um gRPC-Anwendungen direkt konfigurieren. Diese gRPC-Anwendungen fungieren als xDS. und eine Verbindung zur globalen Steuerungsebene von Cloud Service Mesh 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. Dieser Ansatz ermöglicht ein zusätzliches Cloud Service Mesh Bereitstellungsmustern.
In der ersten Abbildung wird ein Service Mesh durch die Verwendung eines Sidecar-Proxys aktiviert.
Zum Konfigurieren eines Sidecar-Proxys verwendet Cloud Service Mesh xDS APIs. Kunden über den Sidecar-Proxy mit dem Server kommunizieren können.
In der zweiten Abbildung wird ein Service Mesh ohne einen Sidecar-Proxy aktiviert. Dazu wird ein proxyloser gRPC-Client verwendet.
Wenn Sie nur gRPC-Dienste bereitstellen, die von Cloud Service Mesh konfiguriert werden, können Sie ein Service Mesh erstellen, ohne Proxys bereitzustellen. Dies erleichtert die Nutzung von Service Mesh-Funktionen in Ihren gRPC-Anwendungen.
Namensauflösung
Die Namensauflösung funktioniert bei proxylosen Bereitstellungen auf folgende Weise:
- Sie legen
xds
als Namensauflösungsschema im gRPC-Clientkanal fest, wenn eine Verbindung zu einem Dienst hergestellt wird. Der Ziel-URI hat das Formatxds:///hostname:port
. Wenn der Port nicht angegeben wird, ist der Standardwert 80, z. B. im Ziel-URIxds:///example.hostname
. - Der gRPC-Client löst die
hostname:port
im Ziel-URI auf, indem er eine Listener Discovery Service (LDS) an das Cloud Service Mesh senden. - Cloud Service Mesh sucht die konfigurierten Weiterleitungsregeln,
einen ü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 Cloud Service Mesh konfigurieren, dürfen nur einmal vorkommen
alle URL-Zuordnungen. 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.
sodass der Client die Dienstkonfiguration von
Cloud Service Mesh. 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
.
Anwendungsfälle
Die folgenden Anwendungsfälle helfen Ihnen zu verstehen, in welchen Fällen Cloud Service Mesh mit proxylosen gRPC-Anwendungen. 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
Cloud Service Mesh mit proxylosen gRPC-Anwendungen zur Einführung von Diensten
Mesh-Funktionen zu Ihren gRPC-Anwendungen.
Heterogenes Service Mesh
Da sowohl proxylose gRPC-Anwendungen als auch Envoy mit Cloud Service Mesh kann Ihr Service Mesh beide Bereitstellungsmodelle enthalten. Wenn Sie beide Modelle einbeziehen, können Sie dem jeweiligen operativen, Leistung und Funktionsanforderungen verschiedener Anwendungen und unterschiedlicher Entwicklungsteams.
Von einem Service Mesh mit Proxys zu einem Mesh ohne Proxys migrieren
Wenn Sie bereits eine gRPC-Anwendung mit einem Sidecar-Proxy haben, Wenn Cloud Service Mesh konfiguriert ist, können Sie zu einer proxylosen gRPC-Anwendung wechseln.
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 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.
Für die Migration von einem Service Mesh mit Proxys zu einem Mesh ohne Proxys müssen Sie Erstellen Sie einen neuen Cloud Service Mesh-Dienst, den Ihr proxyloser gRPC-Client verwendet. Sie können dieselben APIs verwenden, um Cloud Service Mesh für die vorhandenen und neue Versionen zu erstellen.
Architektur und Ressourcen
Das Konfigurationsdatenmodell für proxylose gRPC-Dienste erweitert die Cloud Service Mesh-Konfigurationsmodell 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. sind mit der Verwendung von RPCs verbunden. Beispielsweise werden HTTP-Weiterleitungen, die gRPC verwenden, nicht unterstützt. Damit Sie das Konfigurationsmodell in diesem Leitfaden besser verstehen, empfehlen, sich mit Cloud Service Mesh vertraut zu machen Konzepte und Konfiguration.
Das folgende Diagramm zeigt die Ressourcen, die Sie für proxylose gRPC-Anwendungen konfigurieren müssen.
<ph type="x-smartling-placeholder">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, da Ihr gRPC-Server Implementieren Sie das gRPC-Systemdiagnoseprotokoll. verwenden Sie stattdessen eine TCP-Systemdiagnose. keine HTTP-, HTTPS- oder HTTP/2-Systemdiagnose.
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.
Legen Sie beim Erstellen eines Back-End-Dienstes für gRPC das Protokollfeld auf GRPC
fest.
Es kann auch auf einen Backend-Dienst zugegriffen werden, für den das Protokoll
GRPC
festgelegt ist. von gRPC-Anwendungen über einen Sidecar-Proxy. In diesem Fall darf der gRPC-Client nicht das Namensauflösungsschemaxds
verwenden.In allen Cloud Service Mesh-Bereitstellungen hat das Load-Balancing-Schema für die Back-End-Dienst muss
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 zur Vorbereitung der Konfiguration von Cloud Service Mesh mit proxylosen gRPC-Anwendungen finden Sie unter Einrichtung mit Envoy und proxylosen Arbeitslasten vorbereiten
- Weitere Informationen zu Einschränkungen für proxylose gRPC-Bereitstellungen finden Sie unter Limits und Einschränkungen mit proxylosen gRPC-Anwendungen.