Cluster API version 1.12 introduces two innovations that should significantly simplify the management of Kubernetes clusters: in-place updates and chained upgrades.
The announcement arrived this week, per Kubernetes.io. Cluster API is used by many platform teams to define the desired state of clusters, after which controllers automatically ensure that the infrastructure is brought into line with this. Until now, a change in the Machine specification almost always meant a so-called immutable rollout. This involved creating a new Machine and removing the old one. This approach is predictable and robust, but inevitably leads to node drains and the rearrangement of workloads.
In-place updates change this. Depending on the nature of the change, Cluster API can now decide to modify an existing Machine on the spot without replacing it. This is particularly relevant for modifications that do not require a restart of Pods. Examples include changing credentials or configuration that does not directly impact running workloads. Both KubeadmControlPlane and MachineDeployments support this new capability through so-called update extensions. This shifts the boundary between immutable and mutable infrastructure and gives Cluster API more flexibility in how it implements changes.
Upgrading multiple Kubernetes versions in one step
The second major innovation is chained upgrades. Organizations that offer Kubernetes-as-a-Service or manage multiple clusters often lag behind with minor releases. Until now, upgrades had to be performed step by step, with each intermediate version having to be explicitly run through. In version 1.12, an administrator can directly specify a target version, after which Cluster API automatically draws up and executes an upgrade plan. The system internally runs through all the necessary intermediate steps in the correct order, without the administrator having to manage them separately.
In chained upgrades, control plane and worker nodes are updated in a strictly coordinated manner, with worker nodes able to skip intermediate versions if permitted by Kubernetes version skew policies. Extensibility also plays a role here. Through runtime extensions and lifecycle hooks, platform teams can influence the upgrade process and automate additional tasks, such as updating add-ons after a control plane upgrade.
According to the maintainers, these innovations are primarily intended to reduce the operational pressure on teams that struggle to keep up with the pace of Kubernetes releases. At the same time, the community emphasizes that the ability to upgrade multiple versions at once is not a substitute for regular patching.