Federated services

In the following example, Gloo federates the services for the apps in each cluster. The hostnames follow the format <service_name>.<namespace>.svc.<cluster_name>.<host_suffix>. You can choose the <host_suffix> in the workspace settings.

The client in cluster1 can call either hostname to get the service that backs the hostname.

• app.ns.svc.cluster1-host returns the response from app-v1 in cluster1.
• app.ns.svc.cluster2-host returns the response from app-v2 in cluster2. Because the backing service is in a different cluster than the client, the request is routed through the east-west gateway.

In this scenario, the app-v2 in cluster2 has multiple replicas that back the app.ns.svc.cluster2-host federated hostname.

The client in cluster1 can call either hostname to get the service that backs the hostname.

• app.ns.svc.cluster1-host returns the response from app-v1 in cluster1.
• app.ns.svc.cluster2-host returns the response from one of the replicas of app-v2 in cluster2. The east-west gateway automatically load balances between the replicas.

Instead of calling the federated hostnames, in this scenario the client calls a route that is defined in a route table.

• The route table configures different routes to forward to each cluster's app.
• You can set weights for each route, such as to set priority for a route to return responses from the local cluster first.
• Requests on route1 are returned by app-v1 in cluster1.
• Requests on route2 are returned by app-v2 in cluster2.

Besides setting route weights, you can use route tables in combination with policies to manage traffic. For example, you can apply an outlier detection policy to the federated service to force client traffic to the local instance of the app.

• The route table configures different routes to forward to the federated hostnames for each cluster's app.
• An outlier detection policy applies to the Kubernetes service for app-v1.
• Requests on route1 or route2 are returned by app-v1 in cluster1 because app-v1 is local to the client.

One thing to keep in mind is that workspace-level federation and route tables perform load balancing.

• The route table configures different routes to forward to each cluster's app.
• Requests on route1 are returned by app-v1 in cluster1. If app-v1 in cluster1 fails, 503 responses are still returned to the client.
• Requests on route2 are returned by app-v2 in cluster2.

To avoid 503 responses, you can apply an outlier detection policy to the Kubernetes service that backs the federated hostname for the app. Then, unhealthy replicas of app-v2 are removed from the load balancing pool.

To set up failover, use virtual destinations instead of workspace-level federation.

The client in cluster1 can call either hostname to get the service that backs the hostname.

• app.ns.svc.cluster1-host returns the response from app-v1 in cluster1.
• app.ns.svc.cluster2-host returns the response from one of the replicas of app-v2 in cluster2. The east-west gateway automatically load balances between the replicas.
• The outlier detection policy on the app service detects when a replica becomes unhealthy and removes it from load balancing. This way, responses for app.ns.svc.cluster2-host are still successful.

In the following example, you create a virtual destination to federate access to services across clusters.

• The client in cluster1 calls the app.global hostname that is defined in the virtual destination to group together the app-v1 and app-v2 services.
• Responses are load balanced from both app-v1 in cluster1 and app-v2 in cluster2.

To force local traffic, you can apply an outlier detection policy to the virtual destination.

• The client in cluster1 calls the app.global hostname that is defined in the virtual destination.
• Responses are returned from app-v1 in cluster1 that is local to the client.

If you don't have a local service in the same cluster, then requests are load balanced across backing services in other clusters.

• The client in cluster1 calls the app.global hostname that is defined in the virtual destination.
• Responses are load balanced from the remote app-v2 in cluster2 and app-v3 in cluster-3.

The virtual destination with an outlier detection policy removes any unhealthy services from load balancing. As long as other healthy services back the virtual destination, the client continues to get back successful responses.

• The client in cluster1 calls the app.global hostname that is defined in the virtual destination.
• The outlier detection policy on the virtual destination ensures that the unhealthy app-v1 in cluster1 is removed from load balancing.
• Responses are load balanced from the remote app-v2 in cluster2 and app-v3 in cluster-3.

You can also decide where failover traffic goes with a failover policy. In the following example, the failover policy applies to the virtual destination, and prefers that traffic from cluster1 is failed over to cluster2.

• The client in cluster1 calls the app.global hostname that is defined in the virtual destination.
• The outlier detection policy on the virtual destination ensures that the unhealthy app-v1 in cluster1 is removed from load balancing.
• The failover policy on the virtual destination ensures that responses are returned only from app-v2 in cluster2.

Virtual destinations can also federate services outside the service mesh by selecting an external service.

• The client in cluster1 calls the app.global hostname that is defined in the virtual destination.
• Responses are load balanced from both app-v1 in cluster1 and app-v2 outside the mesh.

You can also implement similar scenarios as covered previously, such as forcing local traffic, setting up outlier detection, and configuring failover. For more information, see Routing to external services.

By using virtual destinations in combination with route tables, you get greater control of routing. The virtual destinations let you treat a bunch of similar services in different clusters as a group. But what if you want to route to only some of the backing services?

Instead of making separate virtual destinations, you can use the subset feature of route tables. In the following example, the route table selects the virtual destination for the app. Then, the subsets for the routes control the behavior.

• For requests on route1 in cluster1, the client gets back responses only from app-v1, not app-v2.
• For requests on route2 in cluster2, the client gets back responses only from app-v3, not app-v4.

For more route table possibilities, see the API docs.