Gloo Gateway federation

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

Purpose and Use cases

The main purpose of Gloo Gateway Federation is to create a single place to manage any number of Gloo Gateway 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 Gateway resources (Upstreams, Virtual Services, etc.) for many different Gloo Gateway instances, in one centralized location. These resources will automatically take care of syncing the resources with the intended target, and monitoring their status.
• Gloo Gateway Discovery: When given access to user’s Kubernetes clusters and other environments, Gloo Gateway Federation can discover any Gloo Gateway 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 Gateway instances, for failover in case the original Upstream is unhealthy.
• Debugging: Gloo Gateway Discovery is constantly monitoring all Gloo Gateway 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 Gateway 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 Gateway Federation is composed of some core concepts and features detailed below.

Admin Cluster

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

• Dedicated Admin cluster
• Shared cluster

Cluster Registration and Gloo Gateway Discovery

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

Federated Components

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

Cross-cluster failover

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

Global RBAC

Gloo Gateway Federation also includes a role-based access control framework to enable granular control over access to the resources controlled by Gloo Gateway 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 Gateway 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.