Intra-mesh routing

With route tables, you can set up intra-mesh routing for the apps that you expose with a virtual gateway. To enable intra-mesh routing, app developers set up routes for each app or service within or outside the mesh, and specify the policies that must be applied before requests are forwarded to the app.

What are routes and how do they work?

A route defines how to match an incoming request, and what actions you want to perform on a matched request. To identify and match a request, you choose one or more request parameters, such as an HTTP header, HTTP method, URI, or request path. Then, you specify how to respond to the incoming request.

In Gloo Mesh, you can choose between the following actions to respond to incoming requests.

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:
  • Kubernetes service: The most commonly used option where you route the request directly to a service in a specified cluster.
  • Virtual destination: Used to route incoming requests across multiple clusters based on locality.
  • Static destination: Used to route incoming requests to a service that is hosted outside the service mesh.
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.
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.
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.

What benefits do route tables offer?

Route tables separate the configuration and ownership of routing rules from the gateway giving you more flexibility to organize routing rules and assign resources to the right team. For example, an app owner or developer might want to configure how requests are routed to their apps, but they might not want to interact with mesh operators who usually are in charge of configuring the gateways, or deciding on custom domains and authorization policies.

By separating these configurations, you can also reuse the same route table to configure your north-south and east-west gateways at the same time, or to apply the same traffic management policy to multiple routes within your service mesh. This setup significantly reduces the number of routing rules and policies that you must configure and manage for your service mesh.

The following image shows an example of how you can define different routing rules for incoming requests in a route table. If a request comes in for app A, the route table directly forwards the request to app A in cluster 1. To route a request to app B, the route table forwards the request to a Gloo Mesh virtual destination. The virtual destination is aware of where the closest app B instance is located and forwards the request to cluster 2.

Using route tables with virtual gateways and virtual destinations