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:
- Federated Configuration: Federated Configuration allows users to define Gloo resources (Upstreams, Virtual Services, etc.) for many different Gloo instances, in one centralized location. These resources will automatically take care of syncing the resources with the intended target, and monitoring their status.
- Gloo Discovery: When given access to user’s Kubernetes clusters and other environments, Gloo Federation can discover any Gloo 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 instances, for failover in case the original Upstream is unhealthy.
- Debugging: Gloo Discovery is constantly monitoring all Gloo 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 checktoday, 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 instance they belong to. This system functions similarly to Kubernetes RBAC, so it will be very easy to pick up for all familiar!
Gloo Federation is composed of some core concepts and features detailed below.
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.
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.
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.