Cluster API (CAPI) is a Kubernetes sub-project under SIG Cluster Lifecycle that uses declarative, Kubernetes-style APIs to automate the full lifecycle — provisioning, upgrading, and deletion — of Kubernetes clusters across cloud, on-premises, and bare-metal environments. It solves the recurring problem of cluster-per-installer fragmentation by providing a unified API surface that any infrastructure provider can implement, keeping the same object model regardless of whether you target AWS, Azure, vSphere, or bare metal. The key mental model is management cluster controls workload clusters: a single management cluster runs CAPI controllers that reconcile the desired state of many downstream workload clusters, making fleet-wide operations — upgrades, health checks, scaling — as simple as editing a YAML resource.
What This Cheat Sheet Covers
This topic spans 15 focused tables and 124 indexed concepts, 101 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Core Concepts and Terminology
Every CAPI deployment involves a specific set of cluster roles and primitives. Understanding the difference between management cluster, workload cluster, and bootstrap cluster is the mandatory prerequisite for all other CAPI work.
| Concept | Example | Description | |
|---|---|---|---|
A Kind or K8s cluster running CAPI controllers | • The cluster where CAPI providers run and where all Cluster/Machine objects are stored • it provisions and manages all workload clusters | ||
kubectl get cluster -n default | • A cluster created and managed by CAPI controllers • intended for actual workloads, not CAPI tooling | ||
A temporary Kind cluster created before the management cluster | • A temporary cluster used to provision the permanent management cluster • deleted after the pivot operation | ||
clusterctl move --to-kubeconfig=mgmt.kubeconfig | The process of moving provider components and CAPI resources from a source management cluster to a target management cluster (or from bootstrap to permanent management cluster). | ||
CAPA (AWS), CAPZ (Azure), CAPG (GCP), CAPV (vSphere) | Implements provisioning of the actual VMs, networks, and load balancers for the cluster on a specific platform. | ||
CABPK (kubeadm), Talos bootstrap | Generates the cloud-init or Ignition script that turns a new VM into a Kubernetes node. | ||
KubeadmControlPlane (KCP), Talos control plane | Manages the lifecycle of control plane nodes, including etcd quorum and certificate management. | ||
CRD fields + expected reconcile behavior | The set of rules a provider must comply with — defined CRD fields and expected controller behaviors — to interoperate with the CAPI core. | ||
cluster.x-k8s.io/v1beta2 API group | The core set of APIs and controllers required to run any provider: Cluster, Machine, MachineDeployment, MachineSet, MachineHealthCheck, and related objects. | ||
CRDs + controller deployment + RBAC | • The YAML artifact published by each provider release, including CRDs, controller deployments, and RBAC • installed via clusterctl init. |