Routing overview

Use Gloo Platform'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.

Overview of routing setup with Gloo Platform by persona

  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:

Supported route types and features

Gloo Platform supports the following route types:

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

Area HTTP routes TCP routes
Gloo product
  • Gloo Gateway for ingress traffic (north-south)
  • Gloo Mesh for service mesh traffic (east-west)
  • Gloo Mesh for service mesh traffic (east-west)
Route metadata
  • Route name
  • Route labels
Request matching Incoming request matching for HTTP traffic, including to match on the URI path, header, query, and HTTP method Incoming request matching for TCP traffic
Routing actions All routing actions: Select routing actions:
Supported destinations All destinations:
  • Kubernetes service
  • Gloo virtual destination
  • Gloo external service
  • Gloo cloud provider (such as for AWS Lambdas)
Select destinations:
  • Kubernetes service
  • Gloo virtual destination
Supported hosts
  • Internal Kubernetes hosts (e.g., svc.cluster.local)
  • Ingress host (north-south traffic)
  • Mesh host (east-west traffic)
  • Internal Kubernetes hosts (e.g., svc.cluster.local)
Multicluster support
  • Gloo workspace-level federation
  • Gloo virtual destination groupings
  • Gloo workspace-level federation
  • Gloo virtual destination groupings
Supported policies All routing policies None

Routing actions

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.

Type of action Description
Route to a destination Directly forward the request to a destination within the service mesh. The destination can be one of the following:
  • Gloo virtual destination: Used to route incoming requests across multiple clusters based on locality.
  • Gloo external service: Used to route incoming requests to a service that is hosted outside the service mesh. Available only for HTTP routes.
  • Gloo cloud provider: Used to route the request to a serverless function in a cloud provider, such as AWS Lambda. Available only with a Gloo Gateway license and for HTTP routes.
  • Kubernetes service: Used to route the request directly to a service in a specified cluster. In most cases, however, you create a virtual destination that is backed by Kubernetes services.
Direct response Rather than routing the request to the upstream service within your service mesh, you send back a pre-defined body and HTTP status response to the client. If necessary, headers can be specified using the Header Modification feature in the enclosing route. Available only for HTTP routes.
Redirect response The request is not routed to the upstream service within the service mesh. Instead, you send back a location header containing the alternate URL you want your client to redirect to. Available only for HTTP routes.
Delegate to a route table The decision for what to do with an incoming request is delegated to one or more route tables. This can be very useful when the number of routes configured on a given gateway starts to become large, and multiple teams need to make route edits. Available only for HTTP routes.
GraphQL Expose your backing API services with route-level customization logic by using Gloo Gateway as a GraphQL server. For more information, see the Gloo Gateway GraphQL docs.

Applying overlapping route configuration

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:

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