Kubernetes 1.38: Vorschau auf das Dezember-Release 2026

Der Release-Zug von Kubernetes fährt im Drei-Monats-Takt — und pünktlich zum Jahresende steht am 16. Dezember 2026 die nächste Version an: Kubernetes 1.38. Während 1.37 „Garhwal" mit Gang Scheduling Beta, HPA Scale-to-Zero und Pod-Zertifikaten die AI- und Security-Wende einleitete, zeichnet sich für 1.38 ein Release ab, das diese Entwicklungen in den Stable-Status überführt und die Plattform für moderne Workloads weiter konsolidiert. Wer seine Cluster-Plattform strategisch plant, sollte jetzt den Fahrplan kennen.

Der aktuelle Stand: Beta.0 ist draußen, Code Freeze naht

Der Entwicklungszyklus von Kubernetes 1.38 begann am 31. August 2026. Am 29. September passierte der Enhancement Freeze — danach durften keine neuen KEPs mehr für das Release eingebracht werden. Seit dem 4. November 2026 ist v1.38.0-beta.0 verfügbar, und am 16. November 2026 (AoE) folgt der Code Freeze: Ab dann werden nur noch kritische Bugfixes akzeptiert. Der Fahrplan der SIG Release sieht folgende Meilensteine vor:

Mit Code Freeze und dem geplanten Deprecations-Blog Ende November wird die Feature-Liste bis zur GA zementiert. Stand Ende Oktober waren 87 KEPs für das Milestone getrackt (15 Stable, 27 Beta, 42 Alpha, 3 ohne Stage-Label) — ein Umfang, der 1.38 zum stärksten Release des Jahres macht.

Gang Scheduling und Workload-Aware Preemption werden GA

Das wichtigste Feature aus Produktionssicht: Gang Scheduling (KEP-4671) und Workload-Aware Preemption (KEP-5710) visieren den Stable-Status an. Gang Scheduling war in 1.37 als Beta (standardmäßig deaktiviert, Feature Gate GenericWorkload) eingeführt worden. Es löst ein klassisches Problem verteilter AI/ML/HPC-Workloads: Verteilt ein Scheduler Pods einer Trainingseinheit über mehrere Nodes, blockiert der langsamste Pod den gesamten Job — GPU-Zyklen verfallen. Gang Scheduling stellt sicher, dass eine Pod-Gruppe nur gemeinsam terminiert wird („Alles-oder-Nichts").

Die Kombination mit Workload-Aware Preemption in 1.38 erlaubt es, priorisierte KI-Jobs auf Kosten niederpriorer Batch-Läufe durchzusetzen. Beide Features kommunizieren über die Workload API und das PodGroup-Konzept, das Kubernetes seit 1.37 bereitstellt. Für Betreiber von GPU-Clustern und CI-Farmen ist das die produktiv relevante Verbesserung — der Wegfall von Deadlocks im verteilten Training spart direkt Infrastrukturkosten.

DRA wird erwachsen: Device Binding, Partitionierung und Capacity-Management

Die Dynamic Resource Allocation (DRA) ging in 1.34 in den GA-Status. In 1.38 werden gleich drei Follow-up-KEPs auf Stable-Kurs gebracht:

• Device Binding Conditions (KEP-5007): Pods können an konkrete Geräteinstanzen (GPU-UUID, NPU-Seriennummer) gebunden werden — Voraussetzung für lizenzgebundene KI-Hardware und deterministic Device Assignment.
• Partitionable Devices (KEP-4815): Ein physisches Gerät (z. B. eine NVIDIA H200) kann in Partitionen aufgeteilt werden, sodass mehrere Pods ein Gerät teilen, ohne sich gegenseitig zu stören.
• Consumable Capacity (KEP-5075): Ressourcen wie VRAM werden als verbrauchbare Kontingente modelliert, nicht als binäre „vorhanden/nicht vorhanden"-Flags.

Diese drei KEPs machen DRA erst richtig alltagstauglich — sie schließen die Lücke zwischen „GPU als Zahl" und „GPU als verwaltbarem Gerät mit Teilbarkeit und Bindung".

Platform-Verbesserungen und Komfort

Neben den großen AI-Themen bringt 1.38 mehrere Verbesserungen für den täglichen Betrieb:

• kuberc (KEP-3104) wird Stable: Nach sieben Jahren Alpha/Beta-Status erhalten kubectl-Benutzer endlich eine stabile Konfigurationsdatei (~/.kube/kuberc) für Aliase, Default-Flags und Credential-Plugin-Policy. Das ersetzt Workarounds mit Shell-Aliasen.
• Pod-Level Resources als Stable (KEP-2837/5419): CPU- und Memory-Angaben auf Pod-Ebene werden stabil — inklusive In-Place-Resize ohne Pod-Neuerstellung (bisher nur auf Container-Ebene stabil). Das ermöglicht vertikales Autoscaling ohne Pod-Churn.
• SPDY → WebSockets (KEP-4006): kubectl exec, attach und port-forward wechseln von SPDY auf WebSockets — ein Infrastruktur-Wechsel, der vor allem Cluster mit modernen Load-Balancern und Firewalls betrifft.
• Hermetic Network-Isolated Pods und In-Place Container Probe Updates sind als Kandidaten auf dem Tracking Board, ihr Status entscheidet sich mit dem Code Freeze.

Was bleibt: cgroup v1, IPVS und die Langzeit-Aufräumarbeiten

Der Deprecations-Blog für 1.38 erscheint planmäßig am 23. November 2026, sodass die finale Liste der Streichungen erst dann feststeht. Klar ist: Die bereits in 1.35–1.37 eingeleiteten Langzeit-Migrationen laufen weiter:

• cgroup v1: failCgroupV1 defaultet bereits seit 1.35 auf true (kubelet startet nicht auf cgroup-v1-Hosts). Der Code-Entfernung in einem künftigen Release (KEP-5573) ist beschlossen, 1.38 setzt hier keinen neuen Termin, aber der Druck auf Betreiber alter Node-Images steigt.
• IPVS → nftables: Der IPVS-Modus der Kubelet-Proxy-Ebene ist auf dem Rückzug. Wer noch IPVS in seinen Platform-Templates hartkodiert hat, sollte den Wechsel zu nftables in die Upgrade-Planung aufnehmen.
• Support-Ende für 1.35: Wenn 1.38 erscheint, verlässt Kubernetes 1.35 den Drei-Branch-Support-Zyklus und erhält nur noch kritische Security-Patches.

Fazit

Kubernetes 1.38 wird kein „großes Release" mit einem einzelnen neuen Feature, sondern der Stabilisierungslauf für die AI- und Platform-Wende, die mit 1.35 begann. Gang Scheduling, Workload-Aware Preemption und DRA-Follow-ups machen Kubernetes fit für GPU-Workloads und deterministisches Device-Management — genau das, was Plattform-Teams für den produktiven KI-Betrieb brauchen. Parallel werden langjährige Baustellen wie kuberc und Pod-Level-Resources endlich abgeräumt.

Für Cluster-Betreiber gilt: Nicht auf die GA warten, sondern jetzt die Node-Basis auf cgroup v2 und containerd 2.x migrieren. Wer auf 1.35 unterwegs ist, sollte den Upgrade-Pfad über 1.36 → 1.37 → 1.38 planen — und sich den 16. Dezember 2026 im Kalender markieren.

Quellen

• Kubernetes v1.38 Release Information (offiziell, SIG Release) — Release-Zyklus, Meilensteine, Team
• Kubernetes 1.38: Release Date, Schedule and Features (kubernetesinterviewquestions.com, Stand 29.10.2026) — 87 KEPs im Tracking, Feature-Details: Gang Scheduling GA, kuberc Stable, DRA Follow-ons
• Kubernetes 1.35 to 1.38: What Actually Changes in Production (Aleksei Aleinikov, 22.09.2026) — Kandidaten-Analyse für 1.38, Hermetic Pods, In-Place Probe Updates
• Kubernetes Releases (offiziell) — Release-Historie, EOL-Termine, Patch-Releases