Multicluster routing
Set up multicluster routing with virtual destinations.
You can easily set up intelligent multicluster routing for active-active and active-passive workloads in your service mesh by using virtual destinations. With virtual destinations, you can define unique internal hostnames for apps that are spread across multiple clusters, and enable service discovery for these apps within the mesh by adding the hostnames to the service mesh registry.
For more information about how to set up intra-mesh routing, see Route within or across clusters.
How does it work?
To reach a multicluster endpoint, your apps inside the mesh simply send a request to the internal hostname, and Gloo Mesh Enterprise then routes the request to the desired destination. Your apps do not need to know where the target app is deployed within the mesh. Instead, Gloo takes into account the context of the client request, such as the client location, where the target app is deployed within the mesh, and the routing rules that you defined to ensure that the request is routed in an efficient and secure manner.
Let’s take a look at an example multicluster setup to see how routing is done for active-active workloads in Kubernetes and how you can improve this scenario by using Gloo Mesh Enterprise.
Multicluster routing in Kubernetes
In the following example, client A in cluster 1 wants to send a request to app B. The app B deployment consists of multiple instances that are spread across multiple clusters. To achieve multicluster routing in Kubernetes, all participating clusters must be added to a global load balancer. The global load balancer is assigned a custom domain, such as mydomain.com and each app in the cluster must be configured to serve on a specific path, such as app-b. For client A to reach app B, client A must send a request over the internet to the global load balancer by using the mydomain.com/app-b address. The global load balancer uses round-robin to select a cluster and routes the request to the cluster’s ingress gateway, which then forwards the request to app B.
A major challenge in this setup is knowing where app B is deployed. The global load balancer is aware of the ingress gateway IP addresses and whether or not a certain cluster can be reached. However, the global load balancer does not know if app B is actually deployed in cluster 2 or 3, or whether app B is healthy to accept requests. Furthermore, client A must always leave the service mesh and go over the internet to send the request to the global load balancer, even though a local instance of app B exists.
Multicluster routing with Gloo Mesh Enterprise
Now let’s look at how you can improve this scenario with virtual destinations in Gloo Mesh Enterprise. To expose app B within the service mesh, you define a unique internal hostname, such as app-b.mesh.internal, and assign a target port to it, such as 80. Then, you use labels to select the services in your clusters that expose app B. Gloo Mesh Enterprise automatically discovers the app B service instances and creates the corresponding Istio custom resources, such as service entries, virtual services, and destination rules to enable peer-to-peer multicluster routing.
Because Gloo Mesh Enterprise is aware of where app B is deployed and whether an instance is healthy to accept incoming requests, any request from client A to app-b.mesh.internal:80 is routed directly to the closest app B instance without leaving the service mesh. In the following diagram, the closest instance is deployed within the same cluster.
But what happens if no local app B instance exists or the local instance becomes unavailable? Gloo Mesh Enterprise automatically updates the routing rules and gives priority to the next closest app B instance in another cluster. In the following diagram, the next closest app B instance is deployed to cluster 2. Instead of leaving the service mesh and going to the global load balancer, the request is now routed to the east-west gateway of cluster 2 directly, which forwards the request to app B.
With location-aware priority-based routing, you ensure that requests are always routed in an efficient and secure manner improving network latency, response time, availability, and reliability for your services within the mesh. Instead of duplicating the same deployments across all the clusters as you would do in a traditional Kubernetes setup, you can optimize your clusters and deploy your apps where you need them without configuring and updating custom routing rules for each cluster.
Applying overlapping virtual destination configuration
In some cases, you might have overlapping configuration across multiple virtual destinations. Gloo Mesh Enterprise validates the hosts that you specify in each virtual destination, and returns an error if a virtual destination that defines the same host already exists in your Gloo Mesh Enterprise environment. However, you can apply virtual destinations that define the same host in different workspaces, if the workspaces do not import or export the same virtual destination resources between them. For example, you might represent the same backend apps with the same host by applying a virtual destination in a staging workspace and by applying a virtual destination in a prod workspace. Because you do not import or export the virtual destination resources between these two workspaces, the virtual destination resources can be safely applied.