With route tables, you can route incoming requests to the apps in your clusters that you expose with a virtual gateway. To enable routing, app developers set up routes for each app or service in your Gateway cluster environment, and specify the policies that must be applied before requests are forwarded to the app.
For more information about how to set up routing to a service within one cluster, see Route within one cluster.
Benefits of intra-mesh routing with Gloo Platform
Gloo Gateway provides several custom resources, including route tables and virtual destinations, to simplify your routing setup.
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 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 apply the same traffic management policy to multiple routes. This setup significantly reduces the number of routing rules and policies that you must configure and manage for your cluster environment.
The following image shows an example of how you can define a simple routing rule 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.
Virtual destinations provide a more flexible abstraction for the services that back up the routes in your route table. With virtual destinations, you can define unique internal hostnames for apps that are available in one cluster or spread across multiple clusters, and route to these apps via these hostnames. Kubernetes services might change as you deploy different versions and updates to your apps. By using a virtual destination, you can consistently select the appropriate backing services with Kubernetes labels. This approach helps your setup dynamically scale and adjust to underlying application changes. Virtual services also automatically set up intelligent multicluster routing.
The following image shows an example of how you can define different routing rules for incoming requests in a route table.
app-a: If a request comes in for app A, the route table directly forwards the request to app A in cluster 1.
app-b: To route a request to app B, the route table forwards the request to a Gloo virtual destination. The virtual destination knows where the closest app B instance is located and forwards the request to cluster 2.
When your app is deployed without Istio sidecars, Gloo Gateway uses plaintext to route the request to your app. To secure communications with mTLS instead, consider using Gloo Mesh Enterprise alongside Gloo Gateway to set up an Istio service mesh for your workloads.