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:

• Federated Configuration: Federated Configuration allows users to define Gloo Edge resources (Upstreams, Virtual Services, etc.) for many different Gloo Edge instances, in one centralized location. These resources will automatically take care of syncing the resources with the intended target, and monitoring their status.
• Gloo Edge Discovery: When given access to user’s Kubernetes clusters and other environments, Gloo Edge Federation can discover any Gloo Edge Instances running there, along with a plethora of important data related to management of the instances.
• Service Failover: Failover builds heavily on the two previous features by taking advantage of all of the information generated by discovery to enable multi-cluster routing configurations not possible before. Failover allows users to specify any number of Upstreams, from any Gloo Edge instances, for failover in case the original Upstream is unhealthy.
• Debugging: Gloo Edge Discovery is constantly monitoring all Gloo Edge Resources owned by the corresponding instances, and reporting the status of all of them in one easy to read place. The feature set is very similar to glooctl check today, but for all instances simultaneously, and running all of the time.
• Multi Cluster RBAC: Solo.io has developed a simple way of ensuring that users only have access to the resources that they are supposed to, no matter where they are, and which Gloo Edge instance they belong to. This system functions similarly to Kubernetes RBAC, so it will be very easy to pick up for all familiar!

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.

• Dedicated Admin cluster
• Shared cluster

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.

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:

• federatedauthconfigs.fed.gloo.solo.io
• federatedgateways.fed.gateway.solo.io
• federatedroutetables.fed.gateway.solo.io
• federatedsettings.fed.gloo.solo.io
• federatedupstreamgroups.fed.gloo.solo.io
• federatedupstreams.fed.gloo.solo.io
• federatedvirtualservices.fed.gateway.solo.io
• federatedauthconfigs.fed.enterprise.gloo.solo.io
• federatedratelimitconfigs.fed.ratelimit.solo.io

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

Cross-cluster failover

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

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.