Gloo Federation Brings Unified Control Plane, Stitchable APIs Across Multicluster Deployments
For enterprises operating at scale and requiring high availability, ensuring failover at the Kubernetes node level simply isn’t enough. Instead, many are operating in a multicluster environment, ensuring that even if something fails at the cluster level their applications will remain operational.
For companies also running Solo.io‘s Gloo API gateway and ingress controller, this multicluster environment had become a pain point, as each cluster would require its own Gloo deployment, which in turn meant configuration, management, and control plane. In response, Solo.io has launched Gloo Federation, which brings together multiple Gloo instances deployed across clusters, clouds, and regions, allowing for configuration and traffic management through a unified control plane.
“What we see in our big customers is that each of them has a lot of clusters in a lot of locations and they’re putting Gloo in each of them, which is totally fine, but the only problem is that now it’s very distributed. Basically, they can’t see what’s going on everywhere, or manage it. They personally do each cluster by itself and configure it and make sure that it’s all good,” said Solo.io CEO Idit Levine.
With federation, Levine said, not only is Gloo able to discover all the other Gloo instances within various clusters and provide a single point for management and configuration, it is also able to collect all of the data from those instances, providing a singular location for troubleshooting as well. Gloo Federation’s centralized control plane allows admins to handle configuration on a deployment-wide or individual instance basis, and provides failover capabilities and location-based routing. On this last point, Levine noted that location-based routing can provide access to end-user data in scenarios where it might not otherwise be available due to local data governance restrictions.
Another feature that Levine highlighted was the handling of role-based access control (RBAC) by Gloo, which abstracts away some complexity around permissions and takes it out of the hands of Kubernetes, through the user of Kubernetes hooks.
“With multiclusters there is always complexity. RBAC is who can do what. You want to change the configuration of the routing? Are you allowed to? That’s dangerous, because you can take everything down on the network. Now, this complexity becomes mine. Before that, it was Kubernetes’ complexity,” said Levine.
Beyond the direct implications of federating Gloo itself and handling the complexity introduced by distribution, Levine also noted another downstream benefit — the ability to stitch together APIs across clusters into a singular “API Product.” In the company’s recent launch of its Istio developer portal, it introduced these API Products as end-user facing APIs that are stitched together from multiple internal APIs. Gloo Federation now extends that ability out beyond the cluster.
“You can take one microservice from one cluster, one microservice from another cluster, and unite them into an API Product. The microservices potentially can be in a different location, or on a different continent even, and you still can show it to the user as one application,” said Levine, explaining that this also allows disparate teams to share microservices. “I think it’s extremely powerful and it does not exist. That we took the world and basically brought it together, that’s where the power is.”
Gloo Federation is available to Gloo Enterprise customers on a trial basis and interested users learn more at an upcoming webinar.
Feature image by Gerd Altmann from Pixabay.
At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: feedback@thenewstack.io.
