Gloo Federation

Gloo Federation allows users to manage the configuration for all of their Gloo instances from one place, no matter what platform they run on. In addition Gloo Federation elevates Gloo’s powerful routing features beyond the environment they live in, allowing users to create all new global routing features between different Gloo instances. Gloo Federation enables consistent configuration, service failover, unified debugging, and automated Gloo discovery across all of your Gloo instances.

Purpose and Use cases

The main purpose of Gloo Federation is to create a single place to manage any number of Gloo instances, while simultaneously allowing for seamless global routing rules between any number of said instances.

With this in mind the main use cases are as follows:

Core Concepts

Gloo Federation is composed of some core concepts and features detailed below.

Admin Cluster

Gloo Federation is composed of Kubernetes Custom Resource Definitions (CRDs) and a controller pod that watches the custom resources and executes actions. The controller deployment and CRDs are created in an administrative cluster and dedicated namespace. This cluster could be a separate Kubernetes cluster that is not running Gloo, or Gloo Federation could be deployed on an existing cluster running one or more Gloo instances.

Cluster Registration and Gloo Discovery

Gloo Federation is capable of discovering Gloo instances on any clusters that have been registered with the service. Local and remote instances of Gloo are managed by adding the cluster housing Gloo to Gloo Federation. When a cluster is added, Gloo Federation creates a service account, cluster role, and cluster role binding on the cluster. The service account is granted access to discover and configure the instances of Gloo. The kubeconfig data for the service account is stored in a Kubernetes secret on the administrative cluster.

Federated Components

Gloo Federation provides the ability to push configuration down to multiple Gloo instances. This is done by creating a custom resource of the proper federated resource type and specifying which clusters and namespaces should have that configuration applied. Adding a new federated resource can be done either through glooctl or kubectl.

The federated configuration data is stored in the following Custom Resource types:

Each of these CRDs closely corresponds to the local version of Gloo resources like Gateways, Upstreams, and Virtual Services.

Gloo Federation also includes a role-based access control framework to enable granular control over access to the resources controlled by Gloo Federation. Users and groups can be associated with roles that grant them the ability to execute a limited set of actions on a particular resource. Gloo Federation’s RBAC model closely resembles the Kubernetes model for service accounts, roles, and role bindings.

Next Steps

Now that you have an idea of how Gloo Federation is structured and the features it enables, we recommend taking it for a test drive using our Gloo Federation getting started guide.