Cluster API versie 1.12 introduceert twee vernieuwingen die het beheer van Kubernetes-clusters merkbaar moeten vereenvoudigen: in-place updates en chained upgrades.
Dit is te lezen op Kubernetes.io. Cluster API wordt door veel platformteams gebruikt om de gewenste toestand van clusters vast te leggen, waarna controllers automatisch zorgen dat de infrastructuur hiermee in overeenstemming wordt gebracht. Tot nu toe betekende een wijziging in de Machine-specificatie vrijwel altijd een zogeheten immutable rollout. Daarbij werd een nieuwe Machine aangemaakt en de oude verwijderd. Deze aanpak is voorspelbaar en robuust, maar leidt onvermijdelijk tot node drains en het herschikken van workloads.
Met in-place updates verandert dit. Cluster API kan nu, afhankelijk van de aard van de wijziging, beslissen om een bestaande Machine ter plekke aan te passen zonder deze te vervangen. Dat is vooral relevant voor aanpassingen die geen herstart van Pods vereisen. Denk aan het wijzigen van credentials of configuratie die geen directe impact heeft op draaiende workloads. Zowel KubeadmControlPlane als MachineDeployments ondersteunen deze nieuwe mogelijkheid via zogeheten update extensions. Daarmee verschuift de grens tussen immutable en mutable infrastructuur en krijgt Cluster API meer flexibiliteit in hoe het wijzigingen doorvoert.
Meerdere Kubernetes-versies upgraden in één stap
De tweede grote vernieuwing is chained upgrades. Organisaties die Kubernetes-as-a-Service aanbieden of meerdere clusters beheren, lopen vaak achter met minor releases. Tot nu toe moesten upgrades stap voor stap worden uitgevoerd, waarbij elke tussenliggende versie expliciet moest worden doorlopen. In versie 1.12 kan een beheerder direct een doelversie opgeven, waarna Cluster API automatisch een upgradeplan opstelt en uitvoert. Het systeem doorloopt intern alle noodzakelijke tussenstappen in de juiste volgorde, zonder dat de beheerder deze afzonderlijk hoeft te managen.
Bij chained upgrades worden control plane en worker nodes strikt gecoördineerd geüpdatet, waarbij worker nodes tussenliggende versies kunnen overslaan als dat volgens de Kubernetes version skew policies is toegestaan. Ook hier speelt uitbreidbaarheid een rol. Via runtime extensions en lifecycle hooks kunnen platformteams het upgradeproces beïnvloeden en aanvullende taken automatiseren, zoals het bijwerken van addons na een control plane-upgrade.
Volgens de maintainers zijn deze vernieuwingen vooral bedoeld om de operationele druk te verlagen voor teams die moeite hebben om het tempo van Kubernetes-releases bij te houden. Tegelijkertijd benadrukt de community dat de mogelijkheid om meerdere versies tegelijk te upgraden geen vervanging is voor regelmatig patchen.