Cluster API v1.12: Introducing in-place updates and chained upgrades
Source: CNCF Blog
Posted on February 9, 2026
by Fabrizio Pandini, Broadcom
CNCF projects highlighted in this post
Cluster API brings declarative management to the Kubernetes cluster lifecycle, allowing users and platform teams to define the desired state of clusters and rely on controllers to continuously reconcile toward it.
Similar to how you can use StatefulSets or Deployments in Kubernetes to manage a group of Pods, in Cluster API you can:
- use KubeadmControlPlane to manage a set of control‑plane Machines, or
- use MachineDeployments to manage a group of worker Nodes.
The Cluster API v1.12.0 release expands what is possible in Cluster API, reducing friction in common lifecycle operations by introducing in‑place updates and chained upgrades.
Emphasis on simplicity and usability
With v1.12.0, the Cluster API project demonstrates once again that this community can deliver a great amount of innovation while minimizing impact for users.
What does this mean in practice?
Users simply change the Cluster or the Machine spec (as with previous releases), and Cluster API will automatically trigger in‑place updates or chained upgrades when possible and advisable.
In‑place Updates
Like Kubernetes does for Pods in Deployments, when the Machine spec changes, Cluster API performs rollouts by creating a new Machine and deleting the old one.
This approach, inspired by the principle of immutable infrastructure, has several advantages:
- Simplicity – easy to explain, predictable, consistent, and easy to reason about.
- Implementation – relies only on two core primitives: create and delete.
- Portability – does not depend on Machine‑specific choices such as OS or bootstrap mechanism.
As a result, Machine rollouts drastically reduce the number of variables to consider when managing the lifecycle of a host server that runs Nodes.
While the benefits of immutability are clear, both Kubernetes and Cluster API are evolving to allow users to minimize workload disruption whenever possible. Over time, Cluster API has introduced several improvements to immutable rollouts, including:
- Support for in‑place propagation of changes affecting Kubernetes resources only – avoiding unnecessary rollouts.
- A way to taint outdated nodes with
PreferNoSchedule, reducing Pod churn during rollouts. - Support for the delete‑first rollout strategy, making immutable rollouts easier on bare‑metal or resource‑constrained environments.
The new in‑place update feature in Cluster API is the next step in this journey. With the v1.12.0 release, Cluster API introduces support for update extensions that allow users to modify existing Machines in‑place, without deleting and recreating them. Both KubeadmControlPlane and MachineDeployments support in‑place updates based on the new extension, expanding what is possible in Cluster API.
How do in‑place updates work?
- The user changes the desired state of Machines.
- Cluster API selects the best tool to achieve that state – either an immutable rollout or an in‑place update extension.
Note: This is not a competition between immutable rollouts and in‑place updates; Cluster API evaluates both options and selects the most appropriate mechanism for a given change.
From the maintainers’ perspective, in‑place updates are most useful for changes that don’t require a node drain or Pod restart (e.g., updating user credentials on a Machine). When a workload will be disrupted anyway, a traditional rollout is preferred.
Cluster API remains extensible – anyone can create their own update extension and decide when and how to use in‑place updates, trading off some benefits of immutable rollouts as needed.
For a deep dive, attend the session “In‑place Updates with Cluster API: The Sweet Spot Between Immutable and Mutable Infrastructure” at KubeCon EU in Amsterdam:
In‑place Updates with Cluster API (KubeCon EU 2026)
Chained Upgrades
ClusterClass and managed topologies in Cluster API together provide a powerful framework that serves as a building block for many platforms offering Kubernetes‑as‑a‑Service.
Now with v1.12… (the original text ends here)
This feature marks an important step forward by allowing users to upgrade by more than one Kubernetes minor version in a single operation, commonly referred to as a chained upgrade.
Instead of manually managing each minor upgrade, users can now declare a target Kubernetes version and let Cluster API safely orchestrate the required intermediate steps.
How Chained Upgrades Work
- Trigger an update – Change the desired version for a
Cluster. - Compute an upgrade plan – Cluster API determines the necessary intermediate versions.
- Execute the plan – Control‑plane and worker machines are upgraded in a strictly controlled order, repeating the process as many times as needed to reach the desired state.
For example, rather than updating a cluster sequentially to v1.33.0, then v1.34.0, and finally v1.35.0, a chained upgrade lets you go directly to v1.35.0.
Cluster API also optimizes the upgrade steps for worker machines: they will skip intermediate Kubernetes minor releases whenever allowed by the Kubernetes version‑skew policies.
Extensibility
- Upgrade‑plan runtime extensions – Influence how the upgrade plan is computed. See the runtime SDK docs.
- Lifecycle hooks – Automate tasks that must run during an upgrade (e.g., upgrading an add‑on after the control‑plane update). See the lifecycle‑hooks docs.
Note: Chained upgrades are especially useful for users who prefer infrequent upgrades (e.g., once per year) and want to jump several versions (n‑3 → n). However, the ability to upgrade multiple versions at once is not an excuse to skip regular patching.
Release Team
I would like to thank all the contributors, maintainers, and engineers who volunteered for the release team.
The reliability and predictability of Cluster API releases—one of the most appreciated features by our users—are possible only because of the community’s support, commitment, and hard work.
Kudos to the entire Cluster API community for the v1.12.0 release and all the great releases delivered in 2025!
If you are interested in getting involved, learn about the Cluster API contributing guidelines.
What’s Next?
If you read the Cluster API manifesto, you’ll see how the sub‑project embraces continuous evolution, improvement, and adaptation to the changing needs of its users and the broader Cloud Native ecosystem.
As Kubernetes itself evolves, the Cluster API sub‑project will keep advancing alongside it, focusing on:
- Safer upgrades
- Reduced disruption
- Stronger building blocks for platforms managing Kubernetes at scale
Innovation remains at the heart of Cluster API—stay tuned for exciting developments throughout 2026!
Useful Links
- Cluster API
- Cluster API v1.12.0 release
- In‑place update proposal
- Chained upgrade proposal
- Learn more about VMware Cloud Foundation, a unified private‑cloud platform with integrated compute, storage, networking, security, and management.
This maintainer blog was originally published on kubernetes.io and is republished here with permission.