Pünktlich zum Ende von 2025 wurde der neueste Kubernetes Release veröffentlicht. Wir konnten das neue Jahr also mit den üblichen ausführlichen Release Notes einläuten.
Wie für jede Kubernetes-Version hat sich das Release-Team auch dieses Mal wieder einen Namen und ein Release-Motto ausgesucht. Kubernetes v1.35 heißt Timbernetes, und der World Tree Release fügt dem Projektbaum einen weiteren Jahresring hinzu. Timbernetes ist allen Maintainern und Nutzern gewidmet, die erneut an der Ausarbeitung mitgearbeitet haben: Insgesamt enthält Version 1.35 17 Stable, 19 Beta und 22 Alpha-Features.
Auf die wichtigsten bzw. interessantesten wollen wir in diesem Release Review einen Blick werfen.
Stable Features: In-Place Ressource Updates, Update Tracking für Pods und neues Service-Routing
Das wohl wichtigste Feature hatten wir bereits in unserem Artikel zu Kubernetes v1.34 erwähnt. In-Place Updates von Pod-Ressourcen erreichen in diesem Kubernetes Release General Availability (GA). So können jetzt alle Nutzer die CPU- und Memory-Ansprüche bzw. Limits von Pods und Containern im laufenden Betrieb anpassen. Hierdurch wird vertikale Skalierung einfacher, besonders für Anwendungen und Jobs, die nicht einmal so eben neugestartet werden können.
Mehr Informationen findest du in KEP #1287.
Update Tracking für Pods ist ein weiteres Feature, das in diesem Kubernetes Release GA wird. In der Vergangenheit besaßen Pod-Ressourcen anders als bspw. Deployments kein Feld metadata.generation. Dadurch konnten Drittanwendungen und Nutzer nicht verlässlich bestimmen, ob der Kubelet veranlasste Änderungen an Pods verarbeitet hat oder nicht.
Mit v1.35 erhalten Pods nun die neuen Felder metadata.generation, das bei jeder Änderung der Pod-Ressource inkrementiert wird, und metadata.observedGeneration, das die zuletzt vom Kubelet gesehene und verarbeitete Generation enthält.
Mehr Informationen findest du in KEP #5067.
Das letzte stable Feature, das wir an dieser Stelle erwähnen wollen, ist die neue trafficDistribution Option PreferSameNode für Services. Mit dieser Einstellung priorisieren Services beim Routing von Netzwerkanfragen Endpoints auf dem lokalen Nodes. Gleichzeitig wurde die Option PreferClose in PreferSameZone umbenannt, um ihre Bedeuting expliziter zu machen.
Mehr Informationen findest du in KEP #3015.
Beta Features: mTLS für Pods, OCI Volumes und abfragbare Node-Topologie
Beim Lesen der Kubernetes Release Notes hatten wir das Gefühl, dass dieses Mal Pods im Mittelpunkt standen. Auch unter den wichtigsten Beta-Features finden sich viele Neuerungen, von denen die „kleinsten“ Kubernetes-Ressourcen unmittelbar profitieren.
So kann der kubelet nun Schlüssel erstellen, Zertifikate als PodCertificateRequests anfragen und die resultierenden Credentials direkt in den Dateisysteme von Pods hinterlegen. Auf diese Weise kann Kubernetes in Zukunft nativ Workload-Identitäten etablieren und Zertifikate rotieren, ohne auf Dritttools wie cert-manager oder SPIFFE/SPIRE angewiesen zu sein.
Mehr Informationen findest du in KEP #4317.
Informationen über die Topologie von Nodes, wie bspw. Zonen- und Regionszugehörigkeit, mussten in der Vergangenheit über die Kubernetes-API abgefragt werden. Die sogenannte Downward API, mit deren Hilfe man gewisse Informationen abfragen und in Containern als Umgebungsvariablen oder Volumes verfügbar machen konnte, unterstützte diese Informationen nicht.
Mit dem Kubernetes Release Timbernetes kann der Kubelet nun verschiedene Topologie-Labels an Nodes über die Downward API für Container in Pods verfügbar machen. Hierdurch können Anwendungen präziser auf die topologischen Gegebenheiten des Clusters abgestimmt und entsprechend konfiguriert werden.
Mehr Informationen findest du in KEP #4742.
Das dritte Beta Feature, das wir erwähnenswert finden, sind OCI Volumes. Gerade in Zeiten von Machine Learning und LLMs kommt es immer häufiger vor, dass große Datenmengen von Trainingsjobs oder Anwendungen heruntergeladen und initialisiert werden müssen. Traditionell hat man das in Kubernetes bisher mit Sidecars und Init-Containern gelöst.
Mit dem neuesten Kubernetes Release gibt es nun die Möglichkeit, OCI Container Image Artefakte herunterzuladen, zu entpacken und als Volumes in Pods zu mounten. So lassen sich Daten und Konfiguration nun vollständig von deinen containerisierten Anwendungen separieren. Aufwändige Init-Scripte und -Container können so vermieden werden. Voraussetzung für die Nutzung dieses Features ist eine kompatible Container Runtime, bspw. containerd v2.1+.
Mehr Informationen findest du in KEP #4639.
Alpha Features: Die neuesten Features im Kubernetes Release v1.35
Wie anfangs erwähnt, bilden Alpha Features die größte Gruppe im neuesten Kubernetes Release. Von den 22 brandneuen Funktionen sprechen uns Gang Scheduling und eingeschränkte Impersonation am aufregendsten.
Gang Scheduling führt nativen Support für ein „Alles oder Nichts“-Verhalten des Kubernetes Schedulers ein. Das ist besonders nützlich für AI-/ML-Training oder HPC-Anwendungen, die oft aus mehreren voneinander abhängigen Pods bestehen.
Bisher konnte es vorkommen, dass ein Teil dieser Pods gescheduled wurde, während ein anderer Teil aufgrund von Ressourcenmangel, Node- oder Pod-Affinity „festhing“. Das Resultat war in solchen Fällen ein Stillstand der gesamten Anwendung.
Mit dem neuen Kubernetes Release können solche Anwendungen nun mithilfe der neuen Workload-API und des PodGroup-Konzepts gruppiert gescheduled werden, was zu mehr Verlässlichkeit bei Deployments führt.
Mehr Informationen findest du in KEP #4671.
Dank eingeschränkter Impersonation ist es ab Kubernetes v1.35 z.B. möglich, Support-Mitarbeitern die Möglichkeit geben, sich als Clusteradmin auszugeben, um ausschließlich Podlogs auslesen zu können. Bisher war eine so granulare Berechtigung nicht möglich: Hatte ein User die RBAC-Berechtigungen für impersonate, galt das für alle Berechtigungen des Nutzers, für den man sich ausgab.
Ist das neue Feature Gate ConstrainedImpersonation aktiviert, prüft der Kubernetes API-Server nun neben den impersonate Berechtigungen zusätzlich impersonate-on Berechtigungen, um eingeschränkte Impersonation zu ermöglichen.
Mehr Informationen findest du in KEP #5284.
Adé Ingress NGINX: Deprecations in Kubernetes v1.35
Neben den vielen Neuerungen gibt es natürlich auch wieder einige Funktionen, Unterprojekte und Einstellungen, die mit dem Kubernetes Release Timbernetes abgekündigt wurden.
Am wichtigsten ist hierbei vermutlich die Abkündigung von Ingress NGINX. Bei dem beliebten, vom Kubernetes-Projekt verwalteten Ingress Controller gehen die Lichter aus. Grund dafür sind fehlende Maintainer: Zuletzt hatten nurnoch zwei Nutzer in ihrer privaten Zeit an dem Projekt entwickelt.
Die offizielle Empfehlung ist ein Umstieg von Ingress auf die neuere GatewayAPI, mehr Informationen sowie die Hintergründe der Abkündigung finden sich auch noch einmal in diesem offiziellen Blogpost.
Neben Ingress NGINX verschwinden auch cgroups v1 aus der Welt von Kubernetes. Bereits seit Version 1.25 unterstützt Kubernetes cgroups v2, mit dem neuesten Kubernetes Release sind cgroups v1 nun endgültig nicht mehr unterstützt. Solltest du noch Clusternodes betreiben, die die neueren cgroups v2 nicht unterstützen, startet der Kubelet nach einem Update auf Kubernetes v1.35 nicht mehr. Ein Update wäre also angebracht.
Mehr Informationen findest du in KEP #5573.
Eine weitere Abkündigung tief im Containergefüge kündigt sich mit Kubernetes v1.35 an: Der aktuelle Kubernetes Release wird die letzte Version mit Support für containerd 1.x sein. Auch hier gilt es also, zeitnah auf eine aktuelle, unterstützte Version zu upgraden.
Mehr Informationen findest du in KEP #4033.
Unser Fazit: Verbesserte Sicherheit und Pod-Management mit einer Prise Upgradezwang
Der Kubernetes Release Timbernetes bietet unserer Meinung nach wieder einen guten Mix an Features, bei denen für jeden Nutzer und Administrator etwas dabei sein dürfte.
Dieses Mal war ein gewisser Fokus auf Pods zu spüren. Ressourcenupdates ohne Neustarts, OCI-Volumes für die Einbindung von Daten und Konfiguration und mehr Möglichkeiten was Scheduling und externe Kontrolle angeht machen die Handhabe von komplexen Anwendungen in Zukunft sicherlich etwas einfacher.
Auch Sicherheit war ein größerer Posten in diesem Release. Eingeschränkte Impersonation bietet neue Möglichkeiten für Teams, ihre Strukturen und Prozesse besser in Kubernetes RBAC abzubilden, der eingestellte Support für cgroups v1 sorgt für eine Modernisierung veralteter Umgebungen, und natives mTLS für Pods bietet die Möglichkeit, Service Meshes und andere externe Lösungen zu ersetzen.
Wir werden nun Kubernetes v1.35 möglichst schnell in NETWAYS Managed Kubernetes® verfügbar machen, sodass du es zeitnah auch in MyNWS nutzen kannst. Solltest du in der Zwischenzeit Fragen zum neuen Kubernetes Release, dem Upgrade, oder Kubernetes allgemein haben, kontaktiere uns gerne jederzeit.
0 Kommentare