Gloo Edge federation

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

Purpose and Use cases

The main purpose of Gloo Edge Federation is to create a single place to manage any number of Gloo Edge 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 Edge Federation is composed of some core concepts and features detailed below.

Admin Cluster

Gloo Edge 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 Edge, or Gloo Edge Federation could be deployed on an existing cluster running one or more Gloo Edge instances.

Cluster Registration and Gloo Edge Discovery

Gloo Edge Federation is capable of discovering Gloo Edge instances on any clusters that have been registered with the service. Local and remote instances of Gloo Edge are managed by adding the cluster housing Gloo Edge to Gloo Edge Federation. When a cluster is added, Gloo Edge 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 Edge. The kubeconfig data for the service account is stored in a Kubernetes secret on the administrative cluster.

Figure of Gloo Fed registration

Federated Components

Gloo Edge Federation provides the ability to push configuration down to multiple Gloo Edge 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 Edge resources like Gateways, Upstreams, and Virtual Services.

Figure of Gloo Fed resources

Cross-cluster failover

Gloo Edge Federation helps platform operators to apply a localized fail-over strategy when a local service is not available.

Figure of Gloo Fed failover scenario

Global RBAC

Gloo Edge Federation also includes a role-based access control framework to enable granular control over access to the resources controlled by Gloo Edge 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 Edge Federation’s RBAC model closely resembles the Kubernetes model for service accounts, roles, and role bindings.

Next Steps

Want to spin up a demo environment to quickly validate the federation process? Try out the Getting Started guide.