Cluster API enables declarative, Kubernetes-native management of cluster lifecycles. Platform teams define their desired cluster state, and controllers handle the continuous reconciliation needed to maintain it.
Just as Kubernetes uses StatefulSets or Deployments to orchestrate Pods, Cluster API provides KubeadmControlPlane for managing control plane Machines and MachineDeployments for worker Node groups.
The v1.12.0 release marks a significant evolution, streamlining common operations through two major capabilities: in-place updates and chained upgrades.
Simplicity meets power
Version 1.12.0 showcases the project's ability to deliver substantial innovation while maintaining backward compatibility and minimizing disruption for existing users.
In practical terms, users modify the Cluster or Machine specification as they always have. The difference: Cluster API now intelligently determines whether to apply changes through in-place updates or chained upgrades based on the context.
In-place updates: selective mutability
Traditionally, Cluster API handles Machine spec changes through rollouts—creating new Machines and deleting old ones, mirroring how Kubernetes manages Pods in Deployments.
This immutable infrastructure approach offers clear benefits:
- Predictable behavior that's straightforward to understand and communicate
- Simple implementation using only create and delete operations
- Platform-agnostic design independent of OS or bootstrap choices
Machine rollouts reduce complexity when managing host servers running Kubernetes Nodes.
Yet both Kubernetes and Cluster API have evolved to minimize unnecessary workload disruption. Cluster API has progressively refined its rollout strategy with features like:
- In-place propagation for Kubernetes resource-only changes, eliminating needless rollouts
- PreferNoSchedule taints on outdated nodes to reduce Pod churn during rollouts
- Delete-first rollout strategy for bare metal and resource-constrained environments
The new in-place update capability represents the next evolution in this progression.
With v1.12.0, Cluster API supports update extensions that modify existing Machines without replacement. Both KubeadmControlPlane and MachineDeployments leverage this functionality, fundamentally expanding what's achievable within Cluster API.
When users update Machine specifications, Cluster API now evaluates the optimal approach—choosing between immutable rollouts and in-place update extensions based on the nature of the change.
This isn't about choosing sides between immutability and mutability. Cluster API treats both as valid tools and selects the appropriate mechanism for each scenario.
The maintainers recommend in-place updates for changes that don't require node drains or Pod restarts—updating Machine credentials, for instance. When workload disruption is inevitable anyway, traditional rollouts remain the better choice.
True to its extensible architecture, Cluster API allows custom update extensions, giving teams flexibility to define their own in-place update policies while understanding the trade-offs involved.
Dive deeper into this feature at In-place Updates with Cluster API: The Sweet Spot Between Immutable and Mutable Infrastructure at KubeCon EU in Amsterdam.
Chained upgrades: multi-version leaps
ClusterClass and managed topologies have established Cluster API as a foundation for Kubernetes-as-a-Service platforms.
Version 1.12.0 enhances this foundation with chained upgrades, enabling multi-version Kubernetes upgrades in a single operation.
Users specify a target Kubernetes version, and Cluster API orchestrates the intermediate steps automatically—no manual progression through each minor version required.
When you update a Cluster's desired version, Cluster API generates an upgrade plan and executes it. Instead of manually stepping through v1.33.0, then v1.34.0, then v1.35.0, a chained upgrade takes you directly to v1.35.0.
The system upgrades control plane and worker Machines in a controlled sequence, repeating as necessary to reach the target state. Worker Machines skip intermediate minor releases when Kubernetes version skew policies allow, optimizing the upgrade path.
Extensibility remains central: upgrade plan runtime extensions influence plan computation, while lifecycle hooks automate related tasks like post-control-plane addon upgrades.
Chained upgrades particularly benefit teams that upgrade annually across multiple versions (n-3 → n). However, the ease of multi-version upgrades shouldn't discourage regular patching—security and stability still demand frequent updates.
Acknowledging the community
This release reflects the dedication of contributors, maintainers, and release team volunteers whose collective effort makes Cluster API's reliable release cadence possible.
The v1.12.0 release and the strong momentum throughout 2025 demonstrate the community's commitment to excellence.
Interested in contributing? Review the Cluster API contributing guidelines.
Looking ahead
The Cluster API manifesto embraces continuous evolution, acknowledging the need to adapt to changing user requirements and the broader cloud native landscape.
As Kubernetes advances, Cluster API will continue enhancing upgrade safety, minimizing disruption, and strengthening the building blocks for large-scale Kubernetes platform management.
Innovation drives the project forward—expect an exciting 2026.
Useful links:
