Advanced traffic management overview

This document is intended for mesh or platform administrators and service developers who have an intermediate to advanced level of familiarity with Cloud Service Mesh and service mesh concepts and who determine and configure how traffic is managed in a Cloud Service Mesh deployment.

Cloud Service Mesh provides advanced traffic management capabilities that give you granular control over how traffic is handled. Cloud Service Mesh supports the following use cases:

• Fine-grained traffic routing of requests to one or more services.
• Weight-based traffic splitting to distribute traffic across multiple services.
• Traffic mirroring policies that send requests to one debugging service and copies to another. Traffic mirroring is not supported with the TCPRoute or the TLSRoute resource.
• Fine-tuned traffic distribution across a service's backends for improved load balancing.

These advanced traffic management capabilities let you meet your availability and performance objectives. One of the benefits of using Cloud Service Mesh for these use cases is that you can update how traffic is managed without needing to modify your application code.

Traffic management in a Cloud Service Mesh service mesh relies on the following resources:

• Mesh resource, which identifies the service mesh and represents the component that is responsible for forwarding traffic and applying policies. The Mesh resource also identifies the traffic interception port.
• Gateway resource, which identifies middle proxies and represents the component that listens on a list of IP address:port pairs, forwards traffic, and applies policies.
• Route resource, which can be one of several types, and which contains traffic routing information for the mesh. Route resources identify hostnames and ports that clients can use to route traffic to backend services. The following are the types of Route resources:
  • HTTPRoute, which is available only in meshes using Envoy proxies. When you use the HTTPRoute resource to configure the Envoy proxies to send HTTP requests, all the capabilities in this document are available.
  • TCPRoute, which is available only in meshes using Envoy proxies.
  • TLSRoute, which is available only in meshes using Envoy proxies.
  • GRPCRoute, which is available in meshes using Envoy sidecar proxies and proxyless gRPC. When you use proxyless gRPC services or applications with Cloud Service Mesh, some of the capabilities described in this document are not available.
• Backend service, with which Route resources are associated.

Configuration

To configure advanced traffic management, you use the same Route and backend services resources that you use when setting up Cloud Service Mesh. Cloud Service Mesh, in turn, configures your Envoy proxies and proxyless gRPC applications to enforce the advanced traffic management policies that you set up.

At a high level, you do the following:

1. Configure a Mesh resource to identify the service mesh.

2. Configure Route resources to do the following, based on the characteristics of the outbound request:

   1. Select the backend service to which requests are routed.

   2. Optionally, perform additional actions.

3. Configure the backend service to control how traffic is distributed to backends and endpoints after a destination service is selected.

Traffic routing and actions

In Cloud Service Mesh, traffic is routed based on values in the Mesh resource, Route resource, and backend service resource. All advanced traffic management capabilities related to routing and actions are configured by using the Route objects.

The following sections describe the advanced traffic management features that you can set up in the Route objects.

Request handling

When a client sends a request, the request is handled as described in the following steps:

1. The request is matched to a specific Route resource as follows:

   • If you're using Envoy:
     • The host header in the HTTP request is matched against the hostnames field in each HTTPRoute or GRPCRouteresource to select the correct Route resource for the request. Only the HTTPRoute and GRPCRoute resources have the hostnames field.
     • The IP address is matched for routing TCP traffic using TCPPRoute.
     • SNI and ALPN are used for TLS passthrough using TLSRoute.
     • The HTTPRoute and GRPCRoute resources associate with a Mesh or a Gateway must have unique hostnames. If you try to attach multiple routes that have conflicting hostnames, the configuration is rejected.
     • Similarly, the IP:Port field of the TCPRoute must be unique or the configuration is rejected.
     • Similarly, SNI and ALPN must be unique for the TLSRoute.
     • If there are overlapping hostnames, such as a.example.com and *.example.com, the request matches the more specific route.
   • If you're using proxyless gRPC:
     • Proxyless gRPC clients use the xds name resolution scheme. They resolve the hostname[:port] in the target URI by sending a request to Cloud Service Mesh.
     • Only the port of a GRPCRoute resource is compared to the port in the target URI (for example, xds:///example.hostname:8080). The target URI must exactly match the string in the hostnames field of the GRPCRoute.

2. The Route resource can contain further routing information and rules.

3. After the destination backend service is selected, traffic is distributed among the backends or endpoints for that destination backend service, based on the configuration in the backend service resource.

The second step is described in the following section, Simple routing based on host and path. The third step is discussed in Advanced routing and actions.

Simple routing based on host and path

Cloud Service Mesh supports a simplified routing scheme and a more advanced scheme. In the simple scheme, you specify a host and, optionally, a path. The request's host and path are evaluated to determine the backend service to which the request is routed.

• The request's host is the domain name portion of a URL—for example, the host portion of the URL http://example.com/video/ is example.com.
• The request's path is the part of the URL that follows the hostname—for example, the path portion of the URL http://example.com/video/ is /video.

You set up simple routing based on host and path in the routing rule map, which consists of the following:

• A global Mesh
• An HTTPRoute or a GRPCRoute

Most of the configuration is done in the HTTPRoute. After you create the initial routing rule map, you only need to modify the HTTPRoute resource.

The simplest rule is a default rule, in which you only specify a wildcard (*) host rule and a path matcher with a default service. After you create the default rule, you can add additional rules that specify different hosts and paths. Outbound requests are evaluated against these rules as follows:

• If a request's host (such as example.com) matches the hostname of HTTPRoute:

  1. The RouteRule is evaluated next. The RouteRule specifies how to match traffic and how to route traffic when traffic is matched.
  2. Each RouteRule contains one or more route matches that are evaluated against the request's path.
  3. If a match is found, the request is routed to the service specified in the RouteAction.

For more information about the HTTPRoute's resource fields and how they work, see the network service API documentation.

Advanced routing and actions

If you want to do more than route a request based on the request's host and path, you can set up advanced rules to route requests and perform actions.

At a high level, advanced routing and actions work as follows:

1. As with simple routing, the request's host is compared to the host rules that you configure in the HTTPRoute or GRPCRoute. If a request's host matches the hostname, the HTTPRoute or GRPCRoute is evaluated.
2. After a route is selected, you can apply actions.

Advanced routing

Advanced routing is similar to simple routing described previously, except that you can specify additional match conditions. For example, you can specify that a rule matches a request's header if the header's name matches exactly or only partially—for example, based on prefix or suffix. A rule can match based on evaluating the header name against a regular expression or on other criteria such as checking for the presence of a header.

For additional match conditions and details for headerMatches and queryParameterMatches, see the network services REST API page.

By combining host, path, header, and query parameters with match conditions, you can create highly expressive rules that fit your exact traffic management requirements. For details, see the following table.

Actions

Cloud Service Mesh lets you specify actions that your Envoy proxies or proxyless gRPC applications take when handling a request. The following actions can be configured by using Cloud Service Mesh.