Cluster API v1.12: Introducing In-place Updates and Chained Upgrades
Source: Kubernetes Blog
Source: Kubernetes Blog
Cluster API v1.12.0 – In‑place Updates & Chained Upgrades
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 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 Machine spec (as with previous releases).
- Cluster API automatically triggers 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 immutable‑infrastructure‑inspired approach has several advantages:
- Simple to explain, predictable, consistent, and easy to reason about for users and engineers.
- Simple to implement – it relies only on two core primitives: create and delete.
- Implementation‑agnostic – it does not depend on Machine‑specific choices (OS, bootstrap mechanism, etc.).
As a result, Machine rollouts drastically reduce the number of variables to consider when managing the lifecycle of a host server that runs Nodes.
Note: While immutability brings many benefits, both Kubernetes and Cluster API are evolving to allow users to minimize workload disruption whenever possible.
Recent improvements to immutable rollouts
- In‑place propagation of changes affecting only Kubernetes resources, avoiding unnecessary rollouts.
- Tainting outdated nodes with
PreferNoSchedule, reducing Pod churn by optimizing rescheduling during rollouts. - Delete‑first rollout strategy, making immutable rollouts easier on bare‑metal or resource‑constrained environments.
The new in‑place update feature
With the v1.12.0 release, Cluster API introduces update extensions that let users modify existing Machines in‑place, without deleting and recreating them.
- Both KubeadmControlPlane and MachineDeployments support in‑place updates based on the new extension.
- This fundamentally expands what is possible in Cluster API.
How do in‑place updates work?
- The user changes the desired state of Machines.
- Cluster API chooses the best tool to achieve that state.
- It can pick immutable rollouts or in‑place update extensions.
- Both are considered valid; the controller selects the most appropriate mechanism for the specific change.
From the maintainers’ perspective:
- In‑place updates are ideal for changes that don’t require a node drain or Pod restart (e.g., updating Machine user credentials).
- When a workload will be disrupted anyway, a rollout is preferred.
Cluster API remains extensible: anyone can create their own update extension and decide when/how to use in‑place updates, trading off some benefits of immutable rollouts.
Deep dive: Attend the session “In‑place Updates with Cluster API: The Sweet Spot Between Immutable and Mutable Infrastructure” at KubeCon EU in Amsterdam!
Chained Upgrades
ClusterClass and managed topologies in Cluster API already provide a powerful framework for Kubernetes‑as‑a‑Service platforms.
v1.12.0 takes this further by allowing upgrades across multiple Kubernetes minor versions in a single operation—a chained upgrade.
- Users declare a target Kubernetes version.
- Cluster API safely orchestrates the required intermediate steps, eliminating the need to manually manage each minor upgrade.
How chained upgrades work
- The user updates the desired version for a Cluster.
- Cluster API computes an upgrade plan.
- The plan is executed:
- Control‑plane and worker Machines are upgraded in a strictly controlled order.
- The process repeats as many times as needed to reach the final version.
Instead of manually upgrading to v1.33.0 → v1.34.0 → v1.35.0 and checking progress at each step, a chained upgrade lets you go directly to v1.35.0.
- Worker Machines skip intermediate minor releases whenever allowed by the Kubernetes version‑skew policies, minimizing upgrade steps.
- Extensibility remains central: upgrade‑plan runtime extensions can influence how the plan is computed and executed.
Summary
- In‑place updates give you the flexibility to modify Machines without full rollouts, while still preserving the simplicity of immutable operations when appropriate.
- Chained upgrades streamline multi‑step version jumps, reducing manual effort and risk.
Both features reinforce Cluster API’s commitment to simplicity, usability, and extensibility.
## Upgrade Hooks
Lifecycle hooks can be used to automate other tasks that must be performed during an upgrade, e.g. upgrading an addon after the control‑plane update completes.
From our perspective, chained upgrades are most useful for users that struggle to keep up with Kubernetes minor releases. For example, they may want to upgrade only once per year and then jump three versions (n‑3 → n). **But be warned:** the fact that you can now easily upgrade by more than one minor version is **not** an excuse to skip frequent patching!
---
## Release Team
I would like to thank all the contributors, the maintainers, and all the engineers that volunteered for the release team.
The reliability and predictability of Cluster API releases—one of the most appreciated features from our users—is only possible thanks to the support, commitment, and hard work of its community.
Kudos to the entire Cluster API community for the **v1.12.0** release and all the great releases delivered in 2025!
---
## Getting Involved
If you are interested in contributing, learn about the **[Cluster API contributing guidelines](#)**.
---
## What’s Next?
If you read the Cluster API manifesto, you’ll see how the sub‑project claims the right to remain unfinished, recognizing the need to continuously evolve, improve, and adapt to the changing needs of Cluster API’s users and the broader Cloud Native ecosystem.
As Kubernetes itself continues to evolve, 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 an exciting **2026**!
---
## Useful Links
- **[Cluster API](#)**
- **[Cluster API v1.12.0 release](#)**
- **[In‑place update proposal](#)**
- **[Chained upgrade proposal](#)**