Kubernetes 1.35 veröffentlicht: Updates für Cloud-Native-Teams

Kubernetes 1.35 wurde am 17. Dezember 2025 veröffentlicht und liefert ein Paket aus neuen Stable-, Beta- und Alpha-Funktionen sowie einigen klaren Deprecations.

Insgesamt nennt das Projekt 60 Enhancements, darunter 17 stable, 19 beta und 22 alpha. Besonders relevant für Plattformteams sind GA für In-Place-Updates von Pod-Ressourcen, Beta für Pod-Zertifikate als Baustein für Workload Identity und ein neues Alpha-Framework, mit dem Nodes vor dem Scheduling unterstützte Features deklarieren.

Parallel dazu werden alte Pfade aktiv zurückgebaut, etwa cgroup v1, ipvs in kube-proxy, containerd v1.X und Ingress NGINX mit einem festen Enddatum.

What happened

Am 17. Dezember 2025 veröffentlichte das Kubernetes-Projekt die Release-Ankündigung zu Kubernetes v1.35 ("Timbernetes"). Darin beschreibt das Release-Team, dass v1.35 insgesamt 60 Enhancements umfasst, aufgeteilt in 17 stable, 19 beta und 22 alpha Features.

Bereits am 26. November 2025 hatte das Projekt in einem "v1.35 Sneak Peek" die wichtigsten geplanten Deprecations und möglichen Highlights skizziert. Dieser Hinweis war explizit als vorläufig markiert, weil sich Inhalte bis zum finalen Release noch ändern können.

Ein separates, aber für viele Teams unmittelbar relevantes Thema kam am 11. November 2025: Die Kubernetes-Community kündigte an, den Ingress NGINX Controller in den Ruhestand zu schicken. In der v1.35 Release-Ankündigung wird das nochmals hervorgehoben, inklusive Zeitplans Best-effort Maintenance bis März 2026, danach Archivierung ohne weitere Updates und die Empfehlung, in Richtung Gateway API zu migrieren.

Für den Betrieb und die Lebensdauerplanung sind außerdem die Upstream-Supportdaten wichtig. LaKubernetes-Patch-Releases-Seite ist für 1.35 der nächste Patch 1.35.1, v1.35 geht am 28. Dezember 2026 in den Maintenance Mode und erreicht am 28. Februar 2027 das End of Life.

Why it matters

Der größte Produktivitätsgewinn für viele Teams steckt in einer Funktion, die sich nach dem Alltag anfühlt: In-Place Updates von Pod-Ressourcen sind in Kubernetes 1.35 auf General Availability. CPU- und Memory-Anforderungen lassen sich damit anpassen, ohne Pods oder Container neu zu starten. Das reduziert Ausfallrisiken beim vertikalen Skalieren und ist besonders nützlich für stateful und batch Workloads, bei denen ein Neustart teuer oder riskant ist.

Pod-Zertifikate in Beta zielen auf ein häufiges Security- und Plattformproblem: Workloads brauchen eine starke Identität für mTLS, aber der Weg dahin war oft ein Mix aus externen Controllern, CRDs, Secret-Management und Sidecars für Rotation. In Kubernetes 1.35 beschreibt das Projekt einen nativen Ansatz, bei dem der kubelet Schlüssel erzeugt, Zertifikate per PodCertificateRequest anfordert und die Bundles direkt in das Dateisystem des Pods schreibt, inklusive automatischer Rotation. Für Teams, die Service Meshes oder Zero-Trust-Patterns einsetzen, ist das ein Schritt zu weniger beweglichen Teilen.

Das Alpha-Feature "Node declared features" ist weniger glamourös, dafür relevant für Upgrade-Sicherheit. Kubernetes erlaubt Versions-Skew zwischen Control Plane und Nodes. Wenn die Control Plane neue Features aktiviert, Nodes aber noch hinterherhinken, kann Scheduling auf inkompatible Nodes zu Laufzeitfehlern führen. Mit dem Framework können Nodes unterstützte Features melden und diese Information über ein neues Feld .status.declaredFeatures an die Control Plane übergeben. Das gibt dem Scheduler und den Admission-Mechanismen eine bessere Grundlage, Fehlplatzierungen zu vermeiden.

Genauso wichtig wie neue Features sind die harten Kanten im Upgrade-Pfad. In 1.35 wird cgroup v1 entfernt. Wer noch Nodes auf alten Linux-Distributionen ohne cgroup v2 betreibt, muss vor dem Upgrade migrieren, sonst kann der kubelet auf diesen Nodes nicht starten. Zusätzlich deprecates Kubernetes in 1.35 den kube-proxy ipvs Modus und empfiehlt für Linux nftables. Und: 1.35 ist laut Release-Ankündigung das letzte Kubernetes-Release mit Support für die containerd v1.X Serie (inklusive containerd 1.7). Wer auf containerd 1.X ist, muss vor dem nächsten Minor-Upgrade auf containerd 2.0 oder neuer wechseln.

Key numbers

• Release-Datum: Kubernetes 1.35.0 wurde am 17. Dezember 2025 veröffentlicht.
• Umfang: 60 Enhancements (17 stable, 19 beta, 22 alpha).
• Stable-Promotions: Das Release-Team listet 15 Enhancements, die in 1.35 zu stable/GA befördert wurden, darunter "In-Place Update of Pod Resources" und der "Job API managed-by mechanism".
• Release-Zyklus: 14 Wochen, von 15. September 2025 bis 17. Dezember 2025.
• Community-Beiträge: bis zu 85 Unternehmen und 419 Individuen im v1.35 Zyklus; im weiteren Cloud-Native-Ökosystem 281 Unternehmen und 1769 Contributors.
• Ingress NGINX: Best-effort Maintenance bis März 2026, danach keine Updates mehr.
• containerd: Kubernetes 1.35 ist die letzte Version mit Support für containerd v1.X; vor dem Upgrade auf die nächste Kubernetes-Version ist containerd 2.0 oder neuer erforderlich.
• Supportfenster: Kubernetes 1.35 geht am 28. Dezember 2026 in den Maintenance Mode und erreicht am 28. Februar 2027 End of Life.
• Release-Webinar: 14. Januar 2026, 17:00 Uhr (UTC).

Context

Kubernetes 1.35 kommt in einer Phase, in der sich viele Plattformteams stärker auf zwei Dinge konzentrieren: planbare Upgrades und weniger Sonderpfade im Clusterbetrieb. Die Release-Ankündigung selbst spiegelt das wider. Neben neuen Features steht ein klarer Block "Deprecations and removals" mit konkreten Konsequenzen, etwa "kubelet startet nicht" bei cgroup v1 oder Warnungen, wenn kube-proxy auf ipvs konfiguriert ist.

Auch die Networking-Landschaft verschiebt sich sichtbar. Ingress bleibt als API bekannt, aber das Ende von Ingress NGINX zwingt viele Teams, ihren Controller-Stack zu überdenken. Die Kubernetes-Community empfiehlt in ihrer Release-Kommunikation ausdrücklich die Gateway API als modernen Standard für Traffic-Management.

Ein weiterer Kontextpunkt ist die Operationalisierung von Batch- und ML-Workloads. Kubernetes 1.35 betont neben Pod-Resizing auch Verbesserungen rund um Jobs. Beispielsweise wird der managedBy-Mechanismus für Jobs in 1.35 zu GA, um externe Controller sauber für Job-Reconciliation einzubinden. Wer Multi-Cluster-Dispatch oder spezialisierte Job-Controller nutzt, bekommt damit einen offizielleren Integrationspfad.

What’s next

Upgrade-Checkliste für Nodes: Vor dem Upgrade auf 1.35 prüfen, ob alle Linux-Nodes cgroup v2 aktiv haben. Falls nicht, OS- und Kernel-Setup anpassen und erst dann upgraden, damit der kubelet zuverlässig startet.

kube-proxy Mode prüfen: Wer ipvs nutzt, sollte einen Migrationsplan auf nftables erstellen und das Verhalten im Staging testen. Ab 1.35 ist ipvs deprecated und kube-proxy kann Warnungen ausgeben.

Container Runtime inventarisieren: Wenn im Cluster containerd 1.X läuft, Upgrade auf containerd 2.0 oder neuer einplanen, bevor die nächste Kubernetes-Minor-Version ansteht. Das Release nennt außerdem die Metrik kubelet_cri_losing_support, um betroffene Nodes zu erkennen.

Ingress Roadmap aktualisieren: Falls Ingress NGINX im Einsatz ist, spätestens bis März 2026 die Migration auf Gateway API oder einen aktiv gepflegten Alternativ-Controller abschließen. Sinnvoll ist ein parallelbetriebener Übergang mit klaren Rollback-Pfaden.

Neue Features gezielt pilotieren: In-Place Pod Resizing eignet sich für einen Pilot mit ausgewählten stateful und batch Workloads, inklusive Monitoring der Resource- und Performance-Charakteristik. Pod-Zertifikate sollten zuerst in einem begrenzten Namespace getestet werden, bevor sie als Identitätsstandard ausgerollt werden.

How to go deeper

Webentwicklung-Bootcamp von Code Labs Academy für Grundlagen zu modernen Deployments und APIs, die häufig auf Kubernetes laufen.

Cybersecurity-Bootcamp von Code Labs Academy für Security-Grundlagen rund um Identitäten, mTLS und sichere Plattform-Defaults.

Data Science und KI Bootcamp von Code Labs Academy für Teams, die Batch- und ML-Workloads auf Container-Plattformen betreiben.

UX/UI Design Bootcamp von Code Labs Academy, falls ihr Developer Tools oder Plattform-Portale baut und die Developer Experience verbessern wollt.