Cloud Service Mesh with proxyless gRPC services overview

This guide provides you with an overview of the architecture of Cloud Service Meshwith proxyless gRPC services, including use cases and architecture patterns.

Note: This guide only supports Cloud Service Mesh with Google Cloud APIs anddoes not support Istio APIs. For more information see,Cloud Service Mesh overview.

Cloud Service Mesh's managed control plane enables global routing, load balancing,and regional failover for service mesh and load-balancing use cases. Thisincludes deployments that incorporate sidecar proxies and gateway proxies.Cloud Service Mesh support for proxyless gRPC applications offers anadditional deployment model in which gRPC applications can participate in aservice mesh without needing a sidecar proxy.

In a typical example, a gRPC client establishes a connection with a gRPC serverthat hosts your backend logic. Cloud Service Mesh gives your gRPC clientsinformation about which servers to contact, how to load balance requests tomultiple instances of a server, and what to do with requests if a server is notrunning.

For a complete overview of how Cloud Service Mesh works, see theCloud Service Mesh overview.

How Cloud Service Mesh works with gRPC applications

Cloud Service Mesh configures gRPC clients with asupported gRPC version,similarly to how sidecar proxies such as Envoy are configured. However,proxyless gRPC applications connected directly to Cloud Service Mesh don't needsidecar proxies. Instead, Cloud Service Mesh uses open source xDS APIs toconfigure gRPC applications directly. These gRPC applications act as xDSclients, connecting to Cloud Service Mesh's global control plane. Afterthey're connected, gRPC applications receive dynamic configuration fromthe control plane, enabling endpoint discovery, load balancing, regionalfailover, and health checks. This approach enables additional Cloud Service Meshdeployment patterns.

In the first illustration, a service mesh is enabled by using a sidecar proxy.

To configure a sidecar proxy, Cloud Service Mesh uses xDS APIs. Clients communicate with the server through the sidecar proxy.

In the second illustration, a service mesh is enabled without a sidecar proxyby using a proxyless gRPC client.

If you are deploying only gRPC services that Cloud Service Mesh configures,you can create a service mesh without deploying any proxies at all. Thismakes it easier to bring service mesh capabilities to your gRPC applications.

Name resolution

Name resolution works for proxyless deployments in the following ways:

1. You setxds as the name resolution scheme in the gRPC client channel whenconnecting to a service. The target URI is formatted asxds:///hostname:port.When the port is not specified, the default value is 80—for example, inthe target URIxds:///example.hostname.
2. The gRPC client resolves thehostname:port in the target URI by sending alistener discovery service (LDS) request to Cloud Service Mesh.
3. Cloud Service Mesh looks up the configured forwarding rules that havea matching port. It then looks up the corresponding URL map for a host rulethat matcheshostname:port. It returns the associated routing configurationto the gRPC client.

The host rules that you configure in Cloud Service Mesh must be unique acrossall URL maps. For example,example.hostname,example.hostname:80,andexample.hostname:8080 are all different rules.

Name resolution with different deployment types

The name resolution scheme is different for proxyless deployments anddeployments that use Envoy proxies.

The gRPC client uses thexds name resolution scheme to connect to a service,allowing the client to receive the service configuration fromCloud Service Mesh. The gRPC client then communicates directly with thegRPC server.

You can combine sidecar proxy and proxyless deployment patterns for increasedflexibility. Combining patterns is especially helpful when your organization andnetwork support multiple teams with different feature requirements, operationalneeds, and gRPC versions.

In the following illustration, both proxyless gRPC clients and gRPC clientswith a sidecar proxy communicate with a gRPC server. The gRPC clients withsidecar proxies use thedns name resolution scheme.

Use cases

The following use cases help you understand when you might want to useCloud Service Mesh with proxyless gRPC applications. Your deployment can includeproxyless gRPC applications, gRPC applications with sidecar proxies, or a mix ofboth.

Resource efficiency in a large-scale service mesh

If your service mesh includes hundreds or thousands of clients and backends,you might find that the total resource consumption from running sidecar proxiesstarts to add up. When you use proxyless gRPC applications, you don't need tointroduce sidecar proxies to your deployment. A proxyless approach can resultin efficiency gains.

High-performance gRPC applications

For some use cases, every millisecond of request and response latency matters.In such a case, you might find reduced latency when you use a proxyless gRPCapplication, instead of passing every request through a client-side sidecarproxy and, potentially, a server-side sidecar proxy.

Service mesh for environments where you can't deploy sidecar proxies

In some environments, you might not be able to run a sidecar proxy as anadditional process alongside your client or server application. Or, you mightnot be able to configure a machine's network stack for request interception andredirection—for example, by usingiptables.In this case, you can useCloud Service Mesh with proxyless gRPC applications to introduce servicemesh capabilities to your gRPC applications.

Heterogeneous service mesh

Because both proxyless gRPC applications and Envoy communicate withCloud Service Mesh, your service mesh can include both deployment models.Including both models lets you satisfy the particular operational,performance, and feature needs of different applications and differentdevelopment teams.

Migrate from a service mesh with proxies to a mesh without proxies

If you already have a gRPC application with a sidecar proxy thatCloud Service Mesh configured, you can transition to a proxyless gRPC application.

When a gRPC client is deployed with a sidecar proxy, it uses DNS toresolve the hostname that it is connecting to. The sidecar proxy interceptstraffic to provide service mesh capabilities.

You can define whether a gRPC client uses the proxyless route or the sidecarproxy route to communicate with a gRPC server by modifying the name resolutionscheme that it uses. Proxyless clients use thexds name resolution scheme, whilesidecar proxies use thedns name resolution scheme. Some gRPC clients mighteven use the proxyless route when talking to one gRPC server, but use the sidecarproxy route when talking to another gRPC server. This lets you gradually migrateto a proxyless deployment.

To migrate from a service mesh with proxies to a mesh without proxies, youcreate a new Cloud Service Mesh service that your proxyless gRPC client uses.You can use the same APIs to configure Cloud Service Mesh for the existing andnew versions.

Architecture and resources

The configuration data model for proxyless gRPC services extends theCloud Service Mesh configuration model, with some additions and limitationsthat are described in this guide. Some of these limitations are temporarybecause proxyless gRPC does not support all of Envoy's features, and othersare inherent to using RPCs. For example, HTTP redirects that use gRPC are notsupported. To help you understand the configuration model in this guide, werecommend that you familiarize yourself with Cloud Service Meshconceptsandconfiguration.

The following diagram shows the resources that you must configure for proxylessgRPC applications.

Note: Some Cloud Service Mesh capabilities are not supported with proxylessgRPC applications. For details, see theFeatures page. If you require an unsupportedfeature, you can use Envoy with your gRPC applications. ConfiguringCloud Service Mesh for gRPC applications that use Envoy generally follows thesame configuration data model described in the following sections.

Health checks

A gRPC health check can check the status of a gRPC service that is running ona backend virtual machine (VM) instance or a network endpoint group (NEG).

If a gRPC health check cannot be used because your gRPC server does notimplement thegRPC health checking protocol,use a TCP health check instead. don't use an HTTP, HTTPS, or HTTP/2 health check.

For more information, seegRPC health check andAdditional flag for gRPC health checks.

Backend service

The backend service defines how a gRPC client communicates with a gRPC server.When you create a backend service for gRPC, set the protocol field toGRPC.

• A backend service configured with a protocol set toGRPC can also be accessedby gRPC applications through a sidecar proxy. In that situation, the gRPCclient must not use thexds name resolution scheme.

• In all Cloud Service Mesh deployments, the load-balancing scheme for thebackend service must beINTERNAL_SELF_MANAGED.

Backends

Backends host your gRPC server instances. You can usemanaged or unmanaged instance groups in Compute Engineandzonal NEGsin Google Kubernetes Engine as backends to host your gRPC server instances.

What's next

• To learn about the service routing APIs and how they work, see theoverview.
• To prepare to configure Cloud Service Mesh with proxyless gRPC applications, seePrepare to set up with Envoy and proxyless workloads.
• To learn about limitations that apply to proxyless gRPC deployments, seeLimits and limitations with proxyless gRPC.