Gloo Mesh Enterprise federates Gloo and Kubernetes resources so that services can communicate with each other across clusters within the workspace. To federate the resources, Gloo does the following:

  1. Discovers Gloo and Kubernetes resources in each workspace. As part of discovery, Gloo identifies the workspace settings to decide which resources should be available in which clusters and namespaces.
  2. Translates the Gloo and Kubernetes resources into underlying Istio resources such as virtual services, service entries, and Envoy filters.
  3. Copies the underlying Istio resources in each cluster and namespace that the Gloo or Kubernetes resource belongs to.

Because workspaces can span clusters, federation makes the resource available across clusters. For more details on the discovery and translation process, see Relay architecture.

Types of federation

Gloo can federate ungrouped services for an entire workspace, or groupings of services that you define in select Gloo custom resources. You can also use both types of federation together. In such a case, the behavior is determined by whether the services that back the host that you call are ungrouped or grouped.

Federation typeResourceUse caseDescription
Ungrouped, workspace-level federationWorkspace settingsSimple testing or initial migrationYou can enable federation for a workspace in the workspace settings. Then, Gloo creates separate Istio service entries in each cluster for the Kubernetes services of the workspace. In this type of federation, the destinations are not grouped for you. As such, you can’t take advantage of all the routing capabilities of Gloo resources, such as attaching policies to all the service entries at once. Instead, the recommended way to federate is to use Gloo resources that group destinations, like virtual destinations or external services.
Grouped, resource-specific federationExternal service, virtual destinationAny multicluster scenarioWhen you create one of these Gloo custom resources, Gloo automatically federates the resource across namespaces and clusters within the workspace. This type of federation lets you group the destinations, set up routes, and apply policies consistently.

Testing-only: Ungrouped federation at the workspace level

You can configure federation and the east-west gateway to use for multicluster traffic in the workspace settings. Then, Gloo federates each service to every namespace within that workspace, as well as any workspace that imports the service.

As part of the federation process, Gloo creates Istio service entries in each cluster for the Kubernetes services in a workspace, with unique hostnames in the format <service_name>.<namespace>.svc.<cluster_name>.<host_suffix>. Then, you can route to the federated host directly or by creating a route table for that host.

Workspace-level federation is not intended for high availability failover. Unlike with Gloo virtual destinations, workspace-level federation does not group the destinations for traffic. Depending on the number of services, this type of federation might cause issues at scale. You cannot attach other Gloo resources such as policies to these federated Kubernetes services. As such, workspace-level federation is for simple testing scenarios only. Otherwise, use virtual destinations or external services with route tables.

Flip through the following diagrams to understand how routing works with certain workspace-level federation scenarios.

Federation for grouped resources

When you create a virtual destination or external service, Gloo groups together and federates the backing services. Federation makes the service the resource represents available in each namespace within the workspace, across clusters and even other workspaces if you set up importing and exporting.

This way, you get intelligent, multicluster routing for the services that the virtual destinations or external services select. You also get consistent ingress control for the routes that the route tables select. Additionally, you can attach Gloo policies to these resources, such as to secure and shift traffic. Depending on the type of policy and your workspace settings, these policies might even apply across workspaces.

Flip through the following scenarios to understand how routing works for federated, grouped resources.