Routing overview

Routing setup link

Use Gloo Mesh Gateway’s suite of traffic management custom resources to serve traffic along different routes. Review the following diagram for an overview by persona of how you might set up routing within your environment.

1. A client makes a request to your service along a certain host and route.
2. For requests that come in from outside your cluster environment, the request passes through an ingress gateway (north-south traffic). You can configure ingress gateways with a virtual gateway custom resource that your operator sets up. You have a few gateway setup options:
   • One gateway per host for the most control. In this scenario, make sure to specify the host to listen on in your virtual gateway configuration.
   • One gateway for multiple hosts. You might omit the host in your virtual gateway configuration, and let the route tables configure the host.
   • For internal requests (east-west traffic), you might not use a virtual gateway. If the client request originates in the same cluster, the request goes to the host as configured in a route table, a virtual destination, or the backing service itself. If the client request originates in a different cluster, the request first goes through the Istio east-west gateway and then to the host as configured in a route table, a virtual destination, or the backing service itself.
3. Your operators create policies that select routes or destinations to shift, secure, and otherwise control traffic to your apps. Your developers might also use select policies as part of app development, such as fault injection or retries. Either the ingress gateway or the Istio sidecar enforces the policy, depending on whether the policy is client- or server-side.
4. Your operators and developers collaborate on a route table that defines how traffic is routed for the host. Operators might configure sections such as hosts, while developers determine routing actions, backing destinations, and route names that match APIs. The route table defines several important aspects, including:
   • The host to listen for traffic requests on
   • The routes on the host to serve requests
   • The routing actions to take for each route, such as forwarding to a backing destination
   • The destination that fulfills the request, such as a Kubernetes service or Gloo virtual destination
   • Route weights, delegation, and specificity to control order
5. Your developers define service destinations that back the routes, such as grouping together multiple services with Gloo’s intelligent, multicluster virtual destinations.
6. Your developers deploy the application workloads that back the service destinations to respond to traffic requests along the route.

For more information about how routing works, see the following routing scenarios:

• Intra-cluster routing
• Multicluster routing
• Routing to external services that are outside of your cluster environment
• Federated services

Supported route types and features link

Gloo supports the following route types:

• HTTP routes: The most common use case for traffic at the Layer 7 application level of the OSI model. HTTP typically uses TCP to establish a connection, but then adds capabilities such as headers, queries, and methods. These extra capabilities let you perform advanced traffic management with Gloo routing actions and policies. For more information about HTTP, you can review docs such as the mdn web docs.
• TCP routes (Gloo Mesh Enterprise license required): A lower-level, Layer 4 connection-oriented protocol used for basic client-server traffic within your environment. A common example use case is to establish a low-latency connection to a local database. Gloo supports TCP routes only for Gloo Mesh Enterprise service mesh traffic within your cluster setup (east-west), not for Gloo Mesh Gateway ingress traffic (north-south). For more information about TCP, you can review docs such as the mdn web docs.
• TLS routes (Gloo Mesh Gateway license required): TLS is based on top of the TCP protocol and is responsible to encrypt traffic and authenticate requests on Layer 7, such as for HTTP requests, by using TLS certificates. With TLS routes, you can inspect the SNI field that is presented during the TLS handshake and set up custom routing to TLS services in the cluster based on that SNI. TLS routes require a TLS listener to be configured on the gateway that enables TLS passthrough. Note that because TLS traffic is not terminated at the gateway, the targeted destination must be capable of handling TLS traffic. For more information about TLS routes, see TLS passthrough for a host.

To understand Gloo’s advanced routing capabilities by protocol, review the following table. For more information, see the RouteTable API documentation.

Routing actions link

To perform a routing action on an incoming request, you must first match the request on certain characteristics, such as headers, methods, URIs, or request paths. After the request is matched, you can configure the following actions routing actions.

Applying overlapping route configuration link

In some cases, you might have overlapping route configuration in or across route tables. For example, within a single route table, you might define multiple types of matchers for a single route or host. Or for delegated route tables, you might define multiple methods of matching for the same route or host. However, in these cases, you can use weight and specificity values to indicate which routes should be applied in which order of priority. For example, see the specificity rules for routing to delegated tables. Incoming requests are matched to the highest-priority matchers in these cases.

Route table conflicts occur only when all three of the following conditions are met between two or more route tables:

• Each route table selects the same virtual gateway or workload.
• Each route table selects the same host.
• The route tables define conflicting route matchers.

Do not configure two or more route tables according to these conditions. Gloo cannot correctly process and forward traffic requests to routes in this case.