Het Kubernetes-project heeft versie 1.35 gelanceerd onder de codenaam ‘Timbernetes’. De release introduceert 60 nieuwe features. Het meest opvallende is de introductie van in-place updates van Pod resources, dat beheer van Kubernetes-workloads vereenvoudigt. Tegelijkertijd is de release een die zich kenmerkt door het afscheid van Ingress NGINX en cgroup v1-ondersteuning.
De naam ‘Timbernetes’ verwijst naar Yggdrasil, de wereldboom uit de Noordse mythologie. Het symbool past bij de filosofie van het project, naar eigen zeggen althans. Net als een boom groeit Kubernetes ring voor ring, gevormd door een wereldwijde gemeenschap van contributors. De release benadrukt die groei; hieronder de belangrijkste vernieuwingen.
In-place updates voor Pod-resources
De belangrijkste nieuwe stable feature is de mogelijkheid om CPU- en geheugenresources van draaiende Pods aan te passen zonder deze te hoeven herstarten. Voorheen moesten beheerders Pods volledig opnieuw aanmaken voor resource-wijzigingen, wat verstoringen veroorzaakte bij stateful applicaties. De nieuwe functionaliteit maakt het op- en afschalen van workloads mogelijk zonder downtime, een stevige verbetering.
Eerdere Kubernetes-versies lieten toe om alleen infrastructuurinstellingen te wijzigen voor bestaande Pods. Met v1.35 kunnen beheerders nu direct ingrijpen bij resource-tekorten of overschotten. Recente releases richten zich sowieso al op meer lifecyclebeheer-mogelijkheden, zoals ook te zien was in versie 1.33. Die trend zet zich dus voort.
Native Pod-certificaten voor workload-identiteit
Een andere opvallende beta-feature is de native ondersteuning voor Pod-certificaten. Tot nu toe vereiste het leveren van certificaten aan Pods externe controllers zoals cert-manager of SPIFFE/SPIRE, plus complexe CRD-orkestratie en beheer van secrets. Kubernetes v1.35 integreert deze functionaliteit direct in het platform. Hoewel Kubernetes niet een ‘by default’ veilige technologie is (het heeft altijd meer security nodig dan het zelf inbouwt), schelen zulke verbeteringen wel kopzorgen voor IT-teams.
De kubelet (lees: de node agent) genereert nu zelfstandig sleutels, vraagt certificaten aan via PodCertificateRequest en schrijft credential bundles direct naar het bestandssysteem van de Pod. De kube-apiserver handhaaft node-restricties bij toekenning, waardoor veelvoorkomende fouten bij third-party signers worden voorkomen. Het is met oudere versies van Kubernetes namelijk voor de hand liggend dat node-restricties niet meer gehandhaaft worden en dus leiden tot ongewenst gedrag, zoals nodes die identiteiten claimen voor workloads die daar niet draaien.
Node-features declareren voor betere scheduling
Als alpha-feature introduceert v1.35 een framework waarmee nodes hun ondersteunde Kubernetes-features kunnen declareren. Dit lost een praktisch probleem op waarbij control planes nieuwe features inschakelen maar nodes nog oude versies draaien, waardoor de scheduler Pods op incompatibele nodes plaatst.
Nodes rapporteren voortaan welke features ze wel en niet ondersteunen via een nieuw .status.declaredFeatures veld. De kube-scheduler, admission controllers en third-party componenten gebruiken deze informatie om Pods alleen op compatibele nodes te schedulen.
Het einde van de Ingress NGINX-controller
Naast nieuwe features brengt v1.35 ook afscheid van legacy-componenten. De Ingress NGINX controller, jarenlang de standaard voor als verkeersbegeleider van Kubernetes-workloads, wordt definitief uitgefaseerd. Het project kampt met een tekort aan maintainers en oplopende technische schuld. Tot maart 2026 volgt best-effort maintenance, daarna wordt het gearchiveerd. Securityproblemen rondom dit component kwamen dit jaar al op pijnlijke wijze aan het licht.
De aanbevolen migratieroute loopt via de Gateway API, die modernere en uitbreidbaardere traffic management biedt. Voor organisaties die zwaar leunen op Ingress NGINX is dit een vrij grote wijziging die planning vereist en wellicht tot wat technische onvolkomendheden leidt.
Daarnaast verdwijnt ondersteuning voor cgroup v1 volledig. Kubernetes introduceerde cgroup v2-support al in 2022 met versie 1.25 vanwege betere resource-isolatie en een schonere hiërarchie. Beheerders die nog nodes draaien op oude Linux-distributies zonder cgroup v2 moeten migreren, anders start de kubelet niet meer.
Ook de ipvs-modus in kube-proxy gaat op den duur verdwijnen. Hoewel de modus beschikbaar blijft, toont kube-proxy nu een waarschuwing bij gebruik. Voor Linux-nodes is nftables de aanbevolen vervanging. De wijziging komt door onderhoudslast en de wens om te focussen op moderne standaarden. Het lijkt erop dat het Kubernetes-team dit probleem over de gehele linie heeft bekeken en legacy dus wegwerkt waar mogelijk.
Verbeteringen aan Dynamic Resource Allocation
Dynamic Resource Allocation (DRA) bereikte stable status in v1.34 en blijft in v1.35 altijd ingeschakeld. Verschillende alpha-features binnen DRA zijn significant verbeterd, waaronder extended resource requests, device taints en tolerations, en partitionable devices.
DRA maakt het mogelijk om gespecialiseerde hardware zoals GPU’s flexibeler toe te wijzen aan workloads. De verbeteringen richten zich op edge-cases die voorheen niet goed werkten, zoals het hergebruik van apparatuur in init containers en het rapporteren van problemen zonder directe impact op scheduling.