Background
Since the advent of cloud computing, there have been predictions about the end of use cases for on-premises data centers. Yet, we continue to see major organizations across many verticals opting for multi-cloud scenarios. Often, one of the clouds is a 'private cloud' or, in other words, on-prem. For organizations standardizing on different private cloud technologies, approaches like running Kubernetes on VMware Cloud Director show how the same cloud native principles can be applied consistently beyond OpenStack-based environments.
On-prem is alive and not going anywhere
That said, many organizations want to get on the cloud native bandwagon to reap the associated benefits. These benefits include resilience, agility, and productivity. Besides, in a multi-cloud world, portability is also a desired benefit. However, these same organizations need to adhere to data sovereignty requirements and/or cost control in a more granular manner than clouds offer.
Not to mention open source
If you are using OpenStack, you are probably already a fan of open source. So, from the open source point of view, OpenStack and Cluster API are a match made in heaven. Rooted in Kubernetes, it allows organizations to standardize the API across clouds and on-prem installations. Thus, unifying the way workloads run in any cloud, even a private one — all based on open source goodness. In similar hybrid scenarios — especially in distributed industrial environments — approaches like seamless Industrial IoT management with Azure Arc integration demonstrate how centralized governance and visibility can extend consistently across both private OpenStack installations and public cloud resources.
Giant Swarm and Cluster API OpenStack
Cluster API is an upstream project that then breaks down into specific providers. To implement Cluster API on OpenStack, we based our work on upstream. During our work, we contributed back to upstream in order to share our discoveries and learnings with the community at large.
Cluster API covers most of the provisioning of infrastructure. We took this and applied it to real-world experience customer needs. As a result, we built additional operators to solve things that were overlooked, or deferred by upstream, for example:
We use GitOps to manage manifests that declare the desired state for clusters. In order to update/upgrade API, controllers require existing/old configurations. GitOps and tools based in declarative APIs, like Helm, were not cutting it. To resolve this, we introduced an additional operator. It allows our users to keep the newest desired state in the git repository, using that as the benchmark for the comparison needed.
The upstream infrastructure operator for Openstack doesn't handle the deletion of resources created by applications in workload clusters. To solve this, we implemented a cleaner operator. It uses OpenStack tags to get the job done. Thanks to this feature, users can delete clusters without worrying about the fallout that leftovers can cause.
In closing
Getting a workload cluster up and running boils down to creating a chart with the cluster details. Next, the controllers ensure the cluster is provisioned properly. Finally, the management cluster is the user interface (API) that allows managing clusters as deployments. This is also where Giant Swarm runs operators that complete the platform experience. We are now at the point where a major customer uses a robust beta we developed, and we are looking toward general availability by the end of 2022.
Check out the Giant Swarm implementation of Cluster API on GitHub. In addition, you can catch up on the basics of Cluster API in general by watching our webinar on the subject.
If you are running OpenStack and are headed on your cloud native journey, contact us to see how we can help you accelerate it.
