Cloud Service Mesh with Google Cloud APIs supported features
This document summarizes the features available in Cloud Service Mesh.
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.A Cloud Service Mesh consists of your applications, an xDS-compatibledata plane (theopen source Envoy proxy or gRPCproxyless data plane), and Cloud Service Mesh as your control plane.
In the following tables, the valueN/A (not applicable) means that a featurecannot be supported because it is not compatible with the particularCloud Service Mesh configuration. A blank space, without either a checkmark or N/A, means that the feature is not supported.
Some of these features are available only with the load balancing APIs. Westrongly recommend that you use theservice routing APIsand that you don't create new deployments using the load balancingAPIs.
Supported xDS version
Cloud Service Mesh uses open source xDS control plane APIs to configureEnvoy and proxyless gRPC clients. These clients act on behalf of yourapplication code to deliver Cloud Service Mesh's application networkingcapabilities.
Only xDS v3 is supported. Migrate to xDS v3 if you are using xDS v2. For informationabout how to migrate, seeMigrate from xDS v2 to xDS v3.
Platforms to run mesh services
You can run applications on the following platforms and adopt them into a globalservice mesh that Cloud Service Mesh configures.
| Feature | Supported |
|---|---|
| Compute Engine virtual machine (VM) instances | ✔ |
| Google Kubernetes Engine (GKE) container instances | ✔ |
| Kubernetes on Compute Engine container instances | ✔ |
Services management
Services in a mesh that Cloud Service Mesh configures benefit fromthe following:
Service discovery. When an application in your mesh wants to reachanother application, it can call on that service by name.
Backend autoscaling. Instances that run your application code scale upor down dynamically based on your needs.
Automatic endpoint registration. As new instances are created or removed,they are automatically associated with your service.
| Feature | Supported |
|---|---|
| Automated deployment of sidecar proxies for Compute Engine VMs | ✔ |
| Automated injection of sidecar proxies for GKE Pods | ✔ |
| Service discovery based on hostname | ✔ |
| Instance autoscaling based on CPU utilization | ✔ |
| Instance autoscaling based on traffic load/serving capacity (Compute Engine VMs in managed instance groups, or MIGs, only) | ✔ |
| Instance autohealing based on configurable health checks | ✔ |
| Automatic endpoint registration for Compute Engine VMs | ✔ |
| Automatic endpoint registration for GKE container instances/Pods | ✔ |
| API to programmatically add or remove endpoints | ✔ |
Endpoints for your data plane traffic
Microservices use the data plane to reach services in your mesh andoutside of your mesh. Cloud Service Mesh lets you separateapplication logic from networking logic so that your application only needs tosend requests to the data plane (for example, the sidecar proxy runningalongside the application). The data plane then sends requests to thecorrect endpoint.
In the following table, applications described as being in the mesh are thoseapplications that use the Cloud Service Mesh-managed data plane to communicatewith other services. Those applications can sendtraffic to in-mesh services and services outside of the mesh.
| Feature | Supported |
|---|---|
| VM-based applications in the mesh | ✔ |
| Container-based applications in the mesh | ✔ |
| VM-based applications outside of the mesh | ✔ |
| Container-based applications outside of the mesh | ✔ |
| Applications running in on-premises data centers | ✔ |
| Applications in multicloud environments | ✔ |
Data plane topologies
In the service mesh model, your applications use a data plane to communicate.This data plane often consists of sidecar proxies deployed alongside yourapplications. Cloud Service Mesh is highly flexible and supports dataplane topologies that fit your service networking needs.
| Feature | Supported |
|---|---|
| Sidecar proxies running alongside applications | ✔ |
| Proxyless gRPC applications | ✔ |
| Middle proxies between two applications in a mesh | ✔ |
| Edge proxies at the boundary of your mesh | ✔ |
| Mesh spanning multiple GKE clusters and/or Compute Engine VMs in multiple regions | ✔ |
Programmatic, API-driven configuration
All configuration is exposed through our REST API and dashboard out-of-the-box,letting you automate changes across large teams and manage changesprogrammatically. Some features cannot be configured by using the Google Cloud console.
| Feature | Supported |
|---|---|
| REST APIs | ✔ |
| Google Cloud console | ✔ |
| Google Cloud CLI | ✔ |
| Cloud Deployment Manager | ✔ |
| Terraform support | ✔ |
Language support with proxyless gRPC applications
You can create proxyless gRPC applications that work with Cloud Service Meshusing the following programming languages. The service mesh features supportedin various implementations and versions of gRPC are listed onGitHub.
| Language | Supported |
|---|---|
| Java | ✔ |
| Go | ✔ |
| C++ | ✔ |
| Python | ✔ |
| Ruby | ✔ |
| PHP | ✔ |
| Node | ✔ |
Request protocols
Applications can use the following request protocols when they use theCloud Service Mesh-configured data plane to communicate.
| Feature | Supported |
|---|---|
| HTTP | ✔ |
| HTTPS | ✔ |
| HTTP/2 | ✔ |
| TCP | ✔ |
| gRPC | ✔ |
Service security
Cloud Service Mesh supports service security with the followingconfigurations.
| Feature | Envoy | gRPC |
|---|---|---|
| TLS with GKE Pods | ✔ | ✔ |
| mTLS with GKE Pods | ✔ | ✔ |
| Access control and authorization | ✔ | ✔ |
| Rate limiting with Google Cloud Armor | ✔ |
Routing and traffic management
Cloud Service Mesh supports advanced traffic management policies that youcan use to steer, split, and shape traffic as it passes through your data plane.
Some advanced traffic management features are not availablewith proxyless gRPC services, and none of the advanced trafficmanagement features are available with the target TCP proxy resource.
The following features are not supported when Cloud Service Meshhandles TCP (non-HTTP(S)) traffic.
| Feature | Supported with Envoy proxy configured to handle HTTP(S) or gRPC traffic | Supported with proxyless gRPC |
|---|---|---|
| HTTP/Layer 7 request routing based on suffix/prefix/full/regex match on: | ||
| • Hostname | ✔ | ✔ |
| • Path | ✔ | ✔ |
| • Headers | ✔ | ✔ |
| • Method | ✔ | N/A |
| • Cookies | ✔ | ✔ |
| • Request parameters | ✔ | N/A |
| Fault injection | ✔ | ✔ |
| Configurable timeouts | ✔ | N/A SeeMax stream duration. |
| Retries | ✔ | ✔ Exceptper retry timeout |
| Redirects | ✔ | |
| URI rewrites | ✔ | |
| Request/response header transformations | ✔ | |
| Traffic splitting | ✔ | ✔ |
| Traffic mirroring | ✔ | |
| Outlier detection | ✔ | ✔ |
| Circuit breaking | ✔ | ✔ OnlymaxRequests |
| Max stream duration | ✔ | ✔ |
Load balancing
You can configure advanced load-balancing methods and algorithms to load balanceat the service, backend group (instance groups or network endpoint groups), andindividual backend or endpoint levels. For more information, see theBackend services overview andAdvanced load balancing overview.
| Feature | Supported with Envoy proxy configured to handle HTTP(s), TCP, or gRPC traffic | Supported with proxyless gRPC |
|---|---|---|
| Backend (instance group or network endpoint group) selection based on region (prefer nearest region with healthy backend capacity) | ✔ | ✔ |
| Backend selection using rate-based (requests per second) balancing mode. | ✔ Not supported with TCP (non-HTTP(S)) traffic. | ✔ |
| Backend selection based on utilization-based balancing mode (VMs in Compute Engine instance groups only) | ✔ | ✔ |
| Configurable maximum capacity per backend (Compute Engine and GKE only) | ✔ | ✔ |
Backend selection based on configurable load-balancing policies. For information about each built-in policy, see |
|
|
Service resiliency
Cloud Service Mesh supports capabilities that help you improve the resiliency ofyour services. For example, you can use Cloud Service Mesh to implement ablue-green deployment pattern, canary testing, or circuit breaking(Envoy,gRPC).
| Feature | Supported with Envoy proxy configured to handle HTTP(s), TCP, or gRPC traffic | Supported with proxyless gRPC |
|---|---|---|
| Service selection based on weight-based traffic splits | ✔ | ✔ |
| Circuit breaking | ✔ | ✔ OnlymaxRequests |
Service and backend capacity management
Cloud Service Mesh takes service and backend capacity into account to promoteoptimal distribution of traffic across your services' backends. Cloud Service Meshis integrated with the Google Cloud infrastructure so that it automaticallycollects capacity data. You can also set and configure capacity manually.
| Feature | Supported |
|---|---|
| Automatically tracks backend capacity and utilization, based on CPU, for VM instances in a managed instance group (MIG). | ✔ |
| Manual capacity and overrides for VM and container instances in MIGs and network endpoint groups (NEGs) based on request rate. | ✔ |
| Manual capacity draining. | ✔ |
Failover
Enterprise workloads generally rely on high-availability deployments to improveservice uptime. Cloud Service Mesh supports these types of deployments byenabling multi-zone/multi-region redundancy.
| Feature | Supported |
|---|---|
| Automatic failover to another zone within the same region that has healthy backend capacity. | ✔ |
| Automatic failover to nearest region with healthy backend capacity. | ✔ |
Health checks
Cloud Service Mesh supports centralized health checking to determine backendhealth.
For reference information, see theHealth checks overview.
| Feature | Supported |
|---|---|
| gRPC health checks | ✔ |
| HTTP health checks | ✔ |
| HTTPS health checks | ✔ |
| HTTP/2 health checks | ✔ |
| TCP health checks | ✔ |
Configurable health checks:
| ✔ |
| Configurable request path (HTTP, HTTPS, HTTP/2) | ✔ |
| Configurable request string or path (TCP or SSL) | ✔ |
| Configurable expected response string | ✔ |
Observability
Observability tools provide monitoring, debugging, and performance informationto help you understand your service mesh. The following capabilities are eitherprovided by default or configured in your data plane. Your application codedoesn't need to do anything special to generate this observability data.
The service health dashboard is available with proxyless gRPC services, butyou cannot configure data plane logging and tracing. Cloud Service Meshcannot configure a gRPC application's logging and tracing. You canenable logging and tracing by following the instructions in the troubleshootingsections or gRPC guides available on open source sites. For example, to enablemetrics collection and tracing in your proxyless gRPC services, you can useOpenTelemetry.
| Feature | Supported with proxies | Supported with proxyless gRPC services |
|---|---|---|
| Service health dashboard | ✔ | ✔ |
| Data plane logging | ✔ | ✔ |
| Data plane tracing | ✔ | ✔ |
Session affinity
Client-server communications often involve multiple successive requests. In sucha case, it's helpful to route successive client requests to the samebackend or server. Cloud Service Mesh provides configurable options tosend requests from a particular client, on a best effort basis, to the samebackend as long as the backend is healthy and has capacity. For more information,see theBackend services overview.
| Feature | Supported with HTTP(S) proxies | Supported with TCP proxies | Supported with proxyless gRPC services |
|---|---|---|---|
| Client IP address | ✔ | ✔ | |
| HTTP cookie | ✔ | N/A | |
| HTTP header | ✔ | N/A | ✔ |
| Generated cookie (sets client cookie on first request) | ✔ | N/A |
Network topologies
Cloud Service Mesh supports common Google Cloud network topologies.
| Feature | Supported |
|---|---|
| Single network in a Google Cloud project | ✔ |
| Multiple meshes in a Google Cloud project | ✔ |
| Multiple gateways in a Google Cloud project | ✔ |
| Shared VPC (single network shared across multiple Google Cloud projects) | ✔ |
For a detailed explanation of how Shared VPC is supported withCloud Service Mesh, seeLimitations.
Compliance
Cloud Service Mesh is compliant with the following standards.
| Compliance certification | Supported |
|---|---|
| HIPAA | ✔ |
| ISO 27001, ISO 27017, ISO 27018 | ✔ |
| SOC1, SOC2, SOC3 | ✔ |
| PCI DSS | ✔ |
What's next
- To learn more about Cloud Service Mesh, see theCloud Service Mesh overview.
- To find uses cases and architecture patterns for proxyless gRPC services, see theProxyless gRPC services overview.
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2026-02-19 UTC.