Kubernetes infrastructure now saved from 'minor repair bulldozer'
The Kubernetes community has released the latest version of Cluster API at version number 1.12 and it is described as a “significant update” for developers.
A Kubernetes “sub-project” focused on providing declarative APIs and tooling to simplify provisioning, upgrading and operating multiple Kubernetes clusters, Cluster API was started by the Kubernetes Special Interest Group (SIG) Cluster Lifecycle.
The Cluster API project uses Kubernetes-style application programming interfaces (APIs) and patterns to automate cluster lifecycle management for platform operators.
Renovation frustrations
The industry standard has been focused on immutable infrastructure for many years now, but, in v1.12 of Cluster API, we can enjoy the introduction of “in-place updates” and “chained upgrades”, allowing for smarter, less disruptive “renovations” of existing infrastructure.
To explain how chained upgrades work, let’s say that once the developer triggers an update by changing the desired version for a Cluster, Cluster API computes an upgrade plan and then starts executing it… this is all rather than (for example) update the Cluster to v1.33.0 and then v1.34.0 and then v1.35.0, checking on progress at each step, a chained upgrade lets software engineers go directly to v1.35.0.
“Just as Kubernetes 1.35 recently introduced In-Place Pod Resizing to stop restarting software unnecessarily, Cluster API v1.12 brings that same logic to the underlying servers. This marks a maturation point for cloud native tech: moving from a rigid “destroy and replace” philosophy to a flexible, evolutionary approach,” noted the team.
Using Cluster API, the supporting infrastructure, like virtual machines, networks, load balancers and VPCs, as well as the Kubernetes cluster configuration are all defined in the same way that application developers operate deploying and managing their workloads.
Key highlights:
End of “Bulldoze and Rebuild”: Previously, changing a minor setting (like a user credential) required a full machine rollout—deleting the old server and creating a new one. The new In-place Updates feature allows platform engineers to modify specific machine details without disrupting the workload, acting more like a home renovation than a demolition.
“Skipping Grades” with Chained Upgrades: Administrators often fall behind on Kubernetes versions because the upgrade process is tedious. The new Chained Upgrades feature allows users to jump multiple versions (e.g., from v1.25 to v1.28) in a single operation. The system automatically computes and executes the intermediate upgrade plan, reducing the manual toil required to keep clusters secure.
Smarter Resource Usage: By allowing “mutable” infrastructure when it makes sense, organisations can prevent sudden increases in resource use and the extra work that comes with frequently changing servers
The development team (in this case with Fabrizio Pandini as spokesperson in his role as principal engineer at Broadcom, Kubernetes SIG Cluster Lifecycle tech lead & Cluster API Maintainer) say that this release lowers the barrier to entry for maintaining secure, up-to-date Kubernetes clusters.
“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. What does this mean in practice? Users simply have to change the Cluster or the Machine spec (just as with previous Cluster API releases) and Cluster API will automatically trigger in-place updates or chained upgrades when possible and advisable,” blogged Pandini.
It addresses the “maintenance debt” that plagues many platform teams by automating complex lifecycle tasks that used to be manual.
Software developers are urder to adopt the new version but also be warned i.e. the fact that you can now easily upgrade by more than one minor version is not an excuse to not patch your cluster frequently!
