{"id":84017,"date":"2020-12-15T09:00:23","date_gmt":"2020-12-15T17:00:23","guid":{"rendered":""},"modified":"2025-06-23T11:31:36","modified_gmt":"2025-06-23T18:31:36","slug":"introducing-cluster-api-provider-azure-capz-kubernetes-cluster-management","status":"publish","type":"post","link":"https:\/\/opensource.microsoft.com\/blog\/2020\/12\/15\/introducing-cluster-api-provider-azure-capz-kubernetes-cluster-management\/","title":{"rendered":"Introducing the Cluster API Provider for Azure (CAPZ) for Kubernetes cluster management"},"content":{"rendered":"\n

Managing Kubernetes clusters is hard.<\/p>\n\n\n\n

Managing Kubernetes clusters at scale across a variety of infrastructures is\u2014well\u2014even harder.<\/p>\n\n\n\n

The Kubernetes community project Cluster API<\/a> (CAPI) enables users to manage fleets of clusters across multiple infrastructure providers. The Cluster API Provider for Azure<\/a> (CAPZ) is the solution for users who need to manage Kubernetes clusters on Azure IaaS. In the past, we have recommended AKS Engine for this common scenario.  While we will continue to provide regular, stable releases for AKS Engine, the Azure team is excited to share that CAPZ is now ready for users and will be our primary tool for enabling customers to operate self-managed Kubernetes clusters on Azure IaaS.<\/p>\n\n\n\n

Do you manage your own Kubernetes clusters?<\/h2>\n\n\n\n

Kubernetes is the dominant cross-platform tool for managing containerized applications. Azure Kubernetes Service<\/a> (AKS) is the managed service that makes it easy for users to run Kubernetes on Azure. AKS is mature, scalable, secure, and backed by Azure’s excellent support. But some users need to run clusters themselves and can\u2019t take advantage of AKS. Some need functionality that is not available in AKS yet or might never be because they require user access to the control plane.<\/p>\n\n\n\n

Some are running a service themselves on Azure that leverages Kubernetes and needs complete control, and others might need to run their own clusters for compliance or regulatory reasons (for example, financial services companies who can’t delegate management to another organization). Still, other users are developing new integrations with Kubernetes or Kubernetes features themselves, and need to be able to tweak, control, and test anything and everything. We call these clusters that users run themselves \u201cself-managed\u201d clusters.<\/p>\n\n\n\n

If you need to run self-managed clusters on Azure, whatever your reason, you\u2019ve come to the right place.<\/p>\n\n\n\n

Cluster API powers self-managed clusters on Azure<\/h2>\n\n\n\n

The Kubernetes community has long recognized the need for tooling to provide standardized lifecycle management of clusters independent of the infrastructure on which they run. In response SIG Cluster Lifecycle created the Cluster API sub-project:<\/p>\n\n\n\n

Cluster API is a Kubernetes sub-project focused on providing declarative APIs and tooling to simplify provisioning, upgrading, and operating multiple Kubernetes clusters. \u2013 The Cluster API Book<\/a><\/p>\n\n\n\n

Cluster API provides our team with a natural place to innovate in open source for users and expand community participation in solving Azure user problems at the same time. Thus, it made sense for us to spend the past 18 months investing in the Azure Provider for Cluster API<\/a> (CAPZ) to make it a fully functional project ready to realize the vision of Cluster API for every user.<\/p>\n\n\n\n

\"Cluster<\/figure>\n\n\n\n

<\/p>\n\n\n\n

The most recent CAPZ release, v0.4.10<\/a>, includes new capabilities such as GPU support, private clusters, and Azure API call tracing. Some of you may be reluctant to adopt a tool whose API is labeled alpha (v1alpha3 to be exact). You should take comfort in the knowledge that CAPI enables forward and backward compatibility of API versions so that when the project moves to v1alpha4, and then v1beta1, you\u2019ll be able to upgrade, and then use the API to output your objects with the new API version.<\/p>\n\n\n\n

Our team is thrilled with the CAPZ work because more of you will be able to effectively manage your cluster\u2019s entire lifecycle on Azure. It has also been fulfilling to drive innovations in the Cluster API community, like CAPI MachinePool<\/a>, which enables users to take advantage of each infrastructure provider\u2019s native VM scaling group capability. CAPI brings Kubernetes native cluster management and CAPZ enables this naturally on Azure infrastructure. Together in the community, we can deliver better capabilities for users more quickly.<\/p>\n\n\n\n

Users are already taking advantage of CAPI and CAPZ on Azure. The Azure provider community consists of amazing people from Azure, VMware, Red Hat, Weaveworks, and more. Community members are realizing the power of the Cluster API by using CAPZ for use cases that span from building new platforms and products, like Tanzu Kubernetes Grid,<\/a> to testing new hardware on multiple infrastructures.<\/p>\n\n\n\n

Users are also discovering new use cases for CAPI. For example, a recent example<\/a> uses CAPI and Helm to operate managed clusters. And our team is using CAPZ to validate new versions of, and features in, Kubernetes on Azure. Soon our upstream tests will move from using AKS Engine to CAPZ.<\/p>\n\n\n\n

But what about AKS Engine?<\/h2>\n\n\n\n

Our team, Azure Container Compute Upstream, has the following mission:<\/p>\n\n\n\n