Today, we announce Cluster API v1.0 is production-ready and officially moving to v1beta1 APIs. To move from the maturity level of an alpha project Cluster API has demonstrated growing adoption, feature maturity, and a strong commitment to community and inclusive innovation.

Cluster API is a Kubernetes project that enables declarative management for Kubernetes, using APIs to easily create, configure, and update clusters. It is an end-to-end approach that can simplify the repetitive tasks of the Kubernetes lifecycle, while maintaining consistency and repeatability across a unified infrastructure. 

From the beginning of time Cluster API has seen contributions from a wide range of companies including VMware, Microsoft, Weaveworks, Google, Mattermost, IBM, RedHat, D2iQ, Equinix, Apple, Talos Systems, Spectro Cloud, Daimler TSS, Ericsson, Giant Swarm, AppsCode, Intel, Twilio, New Relic, Amazon, and many more.

Cluster API’s main goal is to make cluster lifecycle management boring. Our APIs and extensibility model has a proven production record; over time we aim to solidify our foundations even further and build abstractions to simplify the experience for end users.


Twilio – Cluster API on-premise bare metal

At Twilio we are leveraging Cluster API in production for our SendGrid email infrastructure. We run upwards of 100 production Kubernetes clusters on bare metal servers distributed across various geographic data centers.

We have found value in Cluster API’s overall topology, specifically with the paradigm of having a management cluster. We take advantage of management clusters as our dedicated infrastructure on which the team can build, manage, and secure the suite of applications that manage our company’s growing fleet of Kubernetes clusters.

We are excited for the v1.0 release of Cluster API, as it marks the beginning of our next phase of commitment to the project and yet even more contributions moving forward.

Twilio – Kris Nóva – Senior Principal Engineer

Twilio – J. Brandt Buckley – Principal Engineer

Giant Swarm – Cluster API on clouds and on-premise

At Giant Swarm we decided to go all-in on Cluster API and replace our custom controllers and API with the upstream equivalents. We are integrating it with our distributed approach of management clusters to manage a fleet of hundreds of workload clusters, contributing our learnings to upstream along the way.

The modular architecture and declarative nature of Cluster API aligns perfectly with our principles and vision of how infrastructure should be managed, driving further the idea of Kubernetes as a platform of platforms. Joining the community in this effort and working together on a better cluster management future for everyone is a very motivating and rewarding experience.

We are very excited about the v1.0 release of Cluster API as we are in the process of making the Cluster API-based iteration of our product ready for a smooth transition for our customers on different providers by early next year.

Giant Swarm – Puja Abbassi – VP Product

Spectro Cloud

Cluster API is one of the foundational open source components of our platform that enables our customers to manage any type of cluster, anywhere, at scale. As the requirements for enterprise-grade, production environments have changed, the need to manage Kubernetes infrastructure holistically is becoming a necessity. Cluster API is probably one of the most important projects for the community and the key to making not just Kubernetes, but the whole open source ecosystem more accessible and manageable. 

We’re beyond excited for the upcoming Cluster-API v1.0 release and look forward to more customers and vendors adopting it.

Spectro Cloud – Jun Zhou – Chief Architect

Talos Systems

At Talos, we’ve been fans of Cluster API since day 1. We have several customers (ourselves included!) using CAPI to provision and maintain Talos clusters across a variety of bare metal and cloud environments.

The modularity and general forethought of the CAPI project has allowed us to build our own providers specific to Talos OS, helping to extend the Kubernetes declarative paradigm to cluster provisioning and the OS.  In doing so, our use of CAPI allowed us the ability to build other projects on top of this solid base. Having such a framework for handling Talos clusters has greatly improved the usability of our products.

We’re very pleased to see the v1.0 release coming out as we continue our work on top of this awesome project! 

Talos Systems – Spencer Smith – Senior Principal SW Engineer

Daimler TSS – Cluster API on-premise OpenStack

As platform team at Daimler TSS we run and operate around 700 Kubernetes clusters and 3,500 machines all over the world in on-premise data centers.  By migrating to Cluster API we replaced our legacy provisioning, consisting of Terraform, custom self-written tools and Kubernetes operators. 

With the cloud native mindset in our heart, our ambition is to provide tons of fully managed Kubernetes clusters with great customer experience.

Cluster API enhances our portfolio by enabling the management of off-premise cloud providers. At the same time it simplifies the provisioning and upgrading of our existing infrastructure. Managing clusters the Kubernetes style feels like the most natural way and perfectly fits into the existing workflow.

After the migration of our on-premise clusters to Cluster API we are looking forward to taking the next step: the provisioning of clusters to other providers and a higher engagement with the Kubernetes community.

 Daimler TSS – Christian Schlotter – Software Engineer

Daimler TSS – Tobias Giese – Software Engineer

Daimler TSS – Sean Schneeweiss – Software Engineer

New Relic – Managing Infrastructure for The New Relic One Observability Platform

Cluster API is an exciting piece of the Kubernetes cluster fleet management system at New Relic. This system helps our engineers better manage the lifecycle of many Kubernetes clusters deployed in public clouds. Cluster API enables us to simplify cluster fleet automation by providing a consistent, simple, and declarative API for creating, configuring, and upgrading Kubernetes clusters and their node pools. In addition to this, Cluster API makes it easier for us to provide a consistent, self-service interface for our engineers to manage their infrastructure. Because of Cluster API, our engineers rarely need to look at the underlying cloud provider consoles and APIs. Instead, they can manage the infrastructure directly in Kubernetes in the form of Cluster API resources. We are proud to have contributed to the Cluster API project and we are excited for the 1.0 release and beyond!

New Relic – Dane Thorsen – Lead Software Engineer

Red Hat

At Red Hat we have been involved with the Cluster API project since its earliest days, having incorporated the Machine API component into our Red Hat OpenShift 4 cluster autoscaling, node autorecovery and ephemeral/spot instance abilities. Building a core component of our OpenShift infrastructure management on this common upstream ancestry has been a successful experience, and we look forward to adding more of Cluster API’s capabilities in the future through projects like HyperShift that empower our users to separate control plane and management concerns from production workloads. We are excited to see Cluster API reach 1.0 and congratulate all the contributors on reaching this milestone!

Red Hat – Michael McCune – Principal Software Engineer

Deutsche Telekom Technik

At Deutsche Telekom Technik we are tasked with providing Kubernetes clusters for telco workloads like 4G/5G Core, IMS, FTTH, RAN, Edge and many more, and also a number of related management applications (OSS). These workloads not only require deployments at large data centers, but also at hundreds of small on-premise locations across Germany. From the very beginning in 2019 we were fully convinced that CAPI is the way to go for us and in early 2020 we went to production with v1alpha2, but switched soon to v1alpha3 which brought a major breakthrough in usability and manageability. We run our clusters mainly on vSphere (CAPV) and on Bare Metal (Metal3) using centralized management clusters. 

ClusterAPI has helped us a lot making the task of managing widely varied Infrastructure in a lot of Data Centers possible and manageable with a small but dedicated SRE team. Especially the declarative approach, which pairs well with GitOps, has helped us a lot in that regard.

As we are putting more and more of critical telco services on a CAPI managed fleet, we are very happy to see ClusterAPI moving to stable. However, from our experience so far we can freely state that the experience in regards to software stability has been nothing but stellar.  Many thanks to all folks involved!

Deutsche Telekom – Maximilian Rink – Senior SRE

Deutsche Telekom – Vuk Gojnic – Teamlead of Kubernetes Engine Squad

United States Army

The Enterprise Cloud Management Agency under the Army CIO and the Army Software Factory are leveraging Cluster API in production for our upstream cluster automation. We run Kubernetes clusters across numerous impact levels and environments. We need a way to declare those clusters to meet compliant and secure defaults while also providing a regional control plane that can enforce those defaults. 

We have found value in Cluster API with the management cluster, acting as this regional control plane, helping stand up additional clusters that different services and components can quickly be installed on. Cluster API serves as the basis for portions of the DoD Enterprise DevSecOps Reference Design Multi-Cluster CNCF Kubernetes for this reason. 

ECMA and the Army Software Factory look forward to the v1.0 release of the Cluster API, which will allow us to scale and automate our processes to enable enterprise reach for Army customers. 

US Army – Paul Puckett – Director, Enterprise Cloud Management Agency 

US Army – LTC Vito Errico – Director, Army Software Factory

Microsoft – Azure

Microsoft’s involvement in Cluster API started in earnest about 2 years ago with the intent of providing a better open source story for users of self-managed Kubernetes clusters everywhere, including Azure. In the infancy of Kubernetes on Azure, AKS Engine was the tool used to provision Kubernetes clusters. Its source code resides within the Azure GitHub organization, not in the CNCF. With AKS Engine, users were able to create self-managed clusters on Azure, but there was little congruence between the experience on Azure and other infrastructure providers. This all changed with Cluster API. Now, there is a shared interface for building infrastructure across providers.

Over the past year the Azure Container Upstream team has migrated its upstream Kubernetes tests to the Cluster API ecosystem so that validation for Azure Kubernetes scenarios uses only open source, CNCF tools.. This is a big win for both the community and for Microsoft. We are able to validate Kubernetes on Azure with tools that are community owned and maintained in collaboration. In the near future, all of the Kubernetes validation tests for Azure will be run using Cluster API.

Microsoft – David Justice – Principal Engineering Lead

AWS – Cluster API for Amazon EKS Anywhere

One of the goals of Amazon EKS Anywhere is to enable customers to provision a Kubernetes cluster on an infrastructure provider of their choice, using Amazon EKS Distro. Another goal is to provide a declarative way of managing these clusters. Cluster API’s tenets of being infrastructure agnostic, offering a pluggable model for adding new providers as needed, and its declarative approach for managing Kubernetes clusters and nodes aligned very well with our goals, and so we decided to use it in Amazon EKS Anywhere for cluster provisioning and life cycle management operations including scaling, upgrades and deletion.

For Amazon EKS Anywhere we were able to further leverage Cluster API’s declarative style by providing Flux integration for a GitOps-driven cluster life cycle and configuration management. Interactions with the Cluster API community have been of great value while achieving these goals.

We are excited for the v1.0 release and look forward to collaborating more with the community and contributing to the project.

AWS – Chandler Hoisington – General Manager EKS Anywhere 

AWS – Jackson West – Software Development Manager

AWS – Rajashree Mandaogane – Software Development Engineer II

D2iQ

D2iQ recognizes that cluster lifecycle management is a complex problem that requires a flexible, but reliable solution, and it recognizes that working toward both goals is best done within a community. Our software helps our customers manage large numbers of clusters across different infrastructures. We use multiple Cluster API Infrastructure Providers, and contribute back to community-maintained ones. Cluster API’s architecture allows us to collaborate with the community on common problems, and to plug in specialized components where we need them. 

To us, the v1.0 release confirms our own experience with Cluster API: its design has evolved over time and matured, its implementation is production-ready, and the project community is rich with expertise and diverse viewpoints. We look forward to this release, and to many more in the future.

D2iQ – Daniel Lipovetsky – Staff Software Engineer

D2iQ – Deepak Goel – Chief Technology Officer

Samsung SDS

Samsung SDS has been interested in the Cluster API Project since the early days and is currently using Cluster API as the core technology for the managed Kubernetes service in the SDS Cloud. We implemented our own provider to use the Cluster API in a way that is more suitable for SDS Cloud. Cluster API enables Kubernetes cluster provisioning to be consistent and scalable in various IaaS. We are trying to extend our service to provide Kubernetes service in a multi-hybrid cloud environment by taking these advantages.

We believe that Cluster API will become the foundation for managing cluster lifecycle in the cloud-native ecosystem following Kubernetes’s path. The v1.0 release has given us confidence in the direction we are heading, and we sincerely thank everyone who contributed. We look forward to contributing much more through various activities in the community. Congratulations!

Samsung SDS – Hansol Park – Senior Engineer

Samsung SDS – Kangsub Song – Senior Engineer

Samsung SDS – Moonhyuk Choi – Senior Engineer

SK Telecom 

At SK Telecom, we are providing Kubernetes service as a part of our multi, hybrid cloud offering for large enterprise companies in financial, media, broadcasting sectors. From early 2019, we have believed that Cluster API is the right way to abstract the complex nature of cluster lifecycle management. We have fully leveraged Cluster API’s Kubernetes-native and declarative nature with Kustomize, Helm, and Argo toolchains. Now, we are provisioning enterprise-ready Kubernetes clusters with add-on services via Argo CD in GitOps style on the public clouds. We are planning to extend it toward on-premise environments. 

We are very excited for the v1.0 release.  We have learned a lot from everyone in the community, and certainly will contribute back to the community as much as possible. We are looking forward to what we can do with this wonderful community! 

SK Telecom – Jaesuk Ahn – Cloud Native Development Lead
SK Telecom – Seungkyu Ahn – Senior SW Engineer & Korea Kubernetes Community Lead 

VMware

The Cluster API project is central to VMware’s efforts to bring cloud native tools to a wider audience. VMware empowers its enterprise customers in their transformation journey, and Cluster API provides the consistent experience across infrastructure providers in a multi-cloud world. By working with a wide set of others in the community, we can, as that community, make it easy to deploy and manage Kubernetes clusters in a consistent way across all sorts of infrastructure — from vSphere to public cloud to bare metal. The newly released ClusterClass feature further simplifies things by providing a much simpler interface for defining and sharing cluster patterns. By creating a better toolset for platform teams, they can, in turn, provide even more automatic, fast and easy internal products to application teams.  The end result is app teams shipping faster and safer.

VMware – Joe Beda – Principal Engineer – Tanzu

At VMware we believe that competition makes us individually better, but collaboration makes the world better. We are proud to have walked the journey with the Kubernetes community from CAPI’s inception to its current production ready form. As a system it fundamentally redefines the model for deploying and maintaining Kubernetes clusters, bringing the power of Kubernetes control patterns to the world of infrastructure management at scale. Hearty congratulations to the community on the v1.0 release. We look forward to this project’s future, not only as a fundamental part of our Tanzu product line but as an increasingly fundamental part of the vibrant Kubernetes ecosystem.

VMware – Craig McLuckie – Vice President – Modern Apps and Management

Frequently Asked Questions (FAQ)


Why move from alpha to 1.0?

The move to v1.0/v1beta1 is the recognition that Cluster API is already used in production by many companies, reflecting the fact that the project’s team is already operating at production level no matter of the semantic version previously applied to our codebase or the label in front of our APIs.  

What makes this production ready?

In the last year the Cluster API community invested a lot of effort on stabilization of both code, APIs, documentation, and on extensive test signals which inform Kubernetes releases.

Also, we are providing automatic conversion between API versions, automatic upgrades via the clusterctl tool, and all our recent API versions have been supported for more than one year.

But what really matters, the main signal that marks this project as production ready, is the feedback from our users.

Will this impact the speed of development?

Being production ready won’t impact speed of development of Cluster API  because the project team is already structured to work while providing production level guarantees.


In practice, the project already has a series of mechanisms for incubating new features, like e.g. feature flags or the experimental folder, and all the new features like Machine Pools and ClusterClass are already being developed following this approach.

Conversely, after graduation to v1.0/v1beta1 we expect our user base to grow and consequently an influx of new use cases and feature requests to boost our roadmap.


There are a lot of great ideas and opportunities ahead!
  

Where can I find out more about the project?

Chat with us on the Kubernetes Slack: #cluster-api

Join the SIG Cluster Lifecycle Google Group to receive calendar invites and gain access to documents.

Join our community meetings on Zoom, every Wednesday at 10AM Pacific Time.

What is next for the project?

The Cluster API community is currently working hard to deliver ClusterClass and managed topologies, a feature that will greatly simplify how you can provision, upgrade, and operate multiple Kubernetes clusters in a declarative way.

But there is much more on the roadmap: better integration with the cluster autoscaler project, new extensibility points allowing pluggable load balancer solutions, managed external etcd clusters, pluggable runtime extensions, and more to come!

Stay tuned!

The Cluster API Maintainers.