Click here: to donate by Credit Card
Or here: to donate by PayPal
Or by mail to: Free Republic, LLC - PO Box 9771 - Fresno, CA 93794
Thank you very much and God bless you.
Posted on 02/10/2026 7:42:42 AM PST by Cronos
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.
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 urged 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!
|
|
Click here: to donate by Credit Card Or here: to donate by PayPal Or by mail to: Free Republic, LLC - PO Box 9771 - Fresno, CA 93794 Thank you very much and God bless you. |
What?
Digital infrastructure using Kubernetes previously used a “bulldozer” approach, rebuilding entire sections to fix minor technical issues like security patches. New “in-place” update developments now allow for “surgical repair,” fixing specific parts without affecting the entire system.
Kubernetes infrastructure management is shifting from “immutable infrastructure” using a “cordon and drain” process for repairs to a “mutable infrastructure” approach with “in-place updates,” allowing for “chained upgrades” and reducing “configuration drift”. This change affects both the “Control Plane” and the “Data Plane” elements of a cluster.
I, for one, am neither surprised nor intimidated
Sounds like a Cluster Puck.
I have started many threads here related to setting up Windows and Linux... such as switching your license from Windows 10 to Windows 10 IoT Enterprise 2021 LTSC to continue receiving security updates. I use Docker containers for running various useful apps in Linux and in Docker Desktop in Windows both locally and in leased Virtual Machines. I think that I have occasionally discussed this here.
I do not have a problem with it, but I am curious why you felt that this article on Kubernetes would be an interesting topic for discussion here?
> “configuration drift”
Hilarious. i.e. we don’t want to touch the stuff that seems to be working ;-)
Love the video on the Rockwell Retro Encabulator! It should be required watching for kids in grade school like the Bell Labs videos were when I was a youngster.
https://youtu.be/pX4mlgwSKd4?list=PLLJCEJ9TqS1x_eWYbqdoDDc0Ot4mAtVgK
There have been a number of folks here who seem to think AI is some kind of antiChrist. I hope to show them that while it may be complex, at the end of the day it relies on plain 9ld plumbing. As AI shifts from experimental projects to core enterprise “connective tissue” (as mentioned in the article’s news sidebar), the underlying infrastructure must become more resilient and less prone to disruptive, “bulldozing” repairs. As I dig deeper into how we can use different models in my projects I find it less and less awe inspiring and more and more spaghetti code like issues arising
It was really none of my business but thank you for explaining this. There are a few here who understand what the article is discussing. The ones who are most qualified probably have not yet seen it. As you are no doubt already aware most of the others here are likely not very familiar with Kubernetes, Proxmox, Docker, or even Virtual Machines.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.