Gloo Federation Technical Deep Dive
As Idit mentioned in her blog, today we released Gloo Federation to enable multi-cluster federation and management of Gloo API Gateway. Over the past couple of years we have worked closely with our customers and end users to address their adoption of Kubernetes and application modernization with Gloo to secure and manage how the application APIs are exposed and accessed externally.
Gloo is installed into each application cluster that needs to have the APIs of the services running in that cluster exposed to clients outside of that cluster. The number of clusters grows, the number of instances of Gloo also grows, as does the need to configure and manage each instance. Gloo Federation is designed to help streamline the management of multi-cluster environments with a control plane that manages multiple Gloo environments centrally including configurations and routing across different clusters.
How Gloo Federation works
Gloo Federation works as a typical Kubernetes-native application with Custom Resources and Controllers with no additional infrastructure or custom configuration formats.
The Gloo Federation Controller can be installed into an existing cluster with Gloo API Gateway or to a new cluster independent of any Gloo instances or running application services. Once installed, the cluster register command provisions a service account, cluster role, and cluster role binding on the remote cluster and writes a secret to the Gloo Federation control plane allowing it to observe and make changes to the configurations on the remote cluster. This does not prevent admins from managing configurations at the individual cluster level, it merely adds the ability to define configs that can be applied globally across many clusters.
Features and Benefits
- Global Dashboard: This read only UI provides a quick way to view the status and all of the configurations across Gloo instances and clusters under management to provide deep visibility into the environment to pinpoint issues for effective troubleshooting. As an example, all of the respective upstreams and virtual services are displayed along with the status of these objects.
- Discovery: The Gloo Federation control plane continuously watches registered clusters, identifies existing Gloo installations, and stores the relevant information in the
GlooInstanceis visualized in the dashboard to provide a summary of the active instances, their status, and issues.
- Resource Federation: Define configuration objects in the central Gloo Federation control plane that can be propagated to any number of the Gloo instances under management. For example, admins can define a
Federated Upstreamand write a
Placementon it that defines which clusters and namespaces that upstream should be created on.
- Multi-Cluster Failover Routing: Define policies that route traffic to a specifically ordered list of upstreams across any Gloo instance on any cluster under management in the event that health checks fail. Gloo Federation discovers the locality information of all Gloo instances as well as the endpoints necessary for routing, which enables locality weighted load balancing among failover destinations.
- Role Based Access Control: This allows for user based permissions and access at the multi-cluster level to create, update, or delete various resource types and cluster or namespace destinations. This is an optional configuration for the administrator, if they would like to provide global resource federation access in addition to access at the individual cluster level.
- Consistent User Experience: Enhancements to the
glooctlCLI maintain a consistent user experience for Gloo admins with familiar commands like
uninstall, as well as a multi-cluster upgrade for
Watch this demo video to get an introduction into Gloo Federation for multi-cluster API gateway management.