DRA-Stabilität zwingt GPU-Workloads zum Umdenken
Kubernetes 1.36 „Haru“ ist seit dem 22. April 2026 GA und bringt zwei Änderungen die für DACH-Enterprise-Cluster sofortigen Handlungsbedarf bedeuten: cgroup v1 ist nicht deprecated sondern vollständig entfernt – Dynamic Resource Allocation…
6 Min. Lesezeit
Kubernetes 1.36 „Haru“ ist seit dem 22. April 2026 GA und bringt zwei Änderungen die für DACH-Enterprise-Cluster sofortigen Handlungsbedarf bedeuten: cgroup v1 ist nicht deprecated sondern vollständig entfernt – Dynamic Resource Allocation für GPU-Workloads ist jetzt stable. Wer noch auf cgroup v1 läuft, kann nach diesem Release keinen Upgrade mehr durchführen ohne vorher zu migrieren.
Das Wichtigste in Kürze
- Kubernetes 1.36 „Haru“ GA seit 22. April 2026: cgroup v1 vollständig entfernt, kein Pfad zurück nach Upgrade
- cgroup v2 Pflicht: alle Nodes müssen vor dem Upgrade auf cgroup v2 migriert sein – RHEL 9+, Ubuntu 22.04+ und SLES 15 SP5+ haben es als Default aktiviert
- Dynamic Resource Allocation (DRA) stable: strukturiertes GPU/FPGA-Scheduling ohne Device-Plugin-Workarounds ist jetzt production-ready
- Job API: sukzessive Parallelitätskontrolle stable – Max-in-flight-Management für Batch-Workloads deutlich verbessert
- Empfehlung: Upgrade-Freeze aufheben erst nach cgroup-v2-Validierung auf allen Worker-Nodes aller Cluster
Verwandt: S3 Files vs. EFS vs. FSx: AWS-Dateisystemdienste im Vergleich 2026
Was ist cgroup v2? Control Groups Version 2 (cgroup v2) ist der Linux-Kernel-Mechanismus zur Ressourcensteuerung von Prozessen und Containern. Im Gegensatz zu cgroup v1 arbeitet cgroup v2 mit einer einheitlichen Hierarchie statt mehrerer paralleler Subsystem-Hierarchien – das vereinfacht Ressourcen-Accounting und ermöglicht präzisere Memory-OOM-Steuerung, Pressure-Signaling und I/O-Latenz-Kontrolle für Container-Workloads.
cgroup v1 ist weg – nicht deprecated, sondern entfernt
Der wichtigste Unterschied zu früheren Ankündigungen: Das Kubernetes-Projekt hat cgroup v1 nicht in den deprecated-Status gesetzt, sondern direkt entfernt. Es gibt keine „deprecation grace period“ mehr für 1.36. Wer upgradet ohne vorher alle Nodes auf cgroup v2 zu migrieren, wird beim Upgrade scheitern.
Konkret: kubelet und die Container-Runtime (containerd, CRI-O) erwarten auf jedem Node cgroup v2 als aktive Kernel-Feature. Auf Nodes die noch im cgroup v1-Modus laufen wird kubelet nach dem Upgrade nicht mehr starten. Das betrifft besonders Organisationen die noch auf älteren RHEL 8 oder Ubuntu 20.04-Nodes betreiben – beide Systeme nutzen cgroup v1 als Default.
Migration-Status nach Distro
| Distribution | cgroup v2 Default ab | Handlungsbedarf |
|---|---|---|
| RHEL 9 / Rocky 9 / Alma 9 | ab Release (2022) | Keiner – bereits cgroup v2 |
| RHEL 8 / CentOS 8 | Nicht default | OS-Upgrade auf RHEL 9 oder manuell aktivieren |
| Ubuntu 22.04 LTS | ab Release (2022) | Keiner – bereits cgroup v2 |
| Ubuntu 20.04 LTS | Nicht default | systemd-Kernel-Parameter setzen oder auf 22.04 upgraden |
| SLES 15 SP5+ | ab SP5 | Keiner ab SP5 – ältere SPs prüfen |
Dynamic Resource Allocation (DRA) stable: Was das für GPU-Workloads bedeutet
Dynamic Resource Allocation ist in 1.36 aus dem Beta-Status in Stable übergegangen. DRA löst ein fundamentales Problem bei GPU- und Accelerator-Workloads: Device Plugins wie der NVIDIA-Device-Plugin haben bisher eine statische 1:1-Zuordnung von GPU-Slots zu Pods umgesetzt. Mehrere Pods konnten sich eine GPU nicht strukturiert teilen. Mit DRA können Cluster-Administratoren GPU-Ressourcen über ResourceClasses und ResourceClaims granular aufteilen – ein GPU-Slice für einen Inference-Pod, ein anderer für ein Training-Job.
DRA Vorteile für Enterprise
- GPU-Sharing ohne NVIDIA MIG-Hardware-Anforderungen
- ResourceClaims sind namespaced – Multi-Tenant-fähig
- Bessere Auslastung von teurer Accelerator-Hardware
- Declarative Konfiguration statt Device-Plugin-Hacks
Umstieg erfordert
- Bestehende Device Plugins müssen auf DRA-API migriert werden
- NVIDIA-Device-Plugin v0.17+ für DRA-Kompatibilität nötig
- Scheduler und kubelet müssen DRA-Feature-Gate aktiviert haben
- Kein automatischer Migrationspfad von alten Device-Plugin-Deployments
Was Enterprise-Teams in DACH jetzt prüfen müssen
Kubernetes 1.36 Upgrade-Checkliste
- Alle Worker-Nodes auf cgroup v2 prüfen: stat -fc %T /sys/fs/cgroup/ muss cgroup2fs zurückgeben
- Container-Runtime-Version prüfen: containerd 1.7+ und CRI-O 1.28+ unterstützen cgroup v2 nativ
- Managed Cluster prüfen: EKS, GKE und AKS migrieren Nodes automatisch bei Kubernetes-Version-Upgrade
- Self-managed Cluster: vor Upgrade alle Nodes rotieren oder manuell migrieren
- NVIDIA-Device-Plugin Version prüfen falls GPU-Workloads im Einsatz
Quelle Fakten: Kubernetes Blog, Kubernetes 1.36 Release Notes, CNCF TAG-Runtime, NVIDIA Blog April 2026.
Häufige Fragen
Kann ich cgroup v1 unter Kubernetes 1.36 noch aktivieren?
Nein. Mit Kubernetes 1.36 ist der cgroup v1-Code vollständig aus kubelet und den Kubernetes-internen Libraries entfernt. Es gibt kein Feature-Gate das cgroup v1 reaktivieren würde. Wer auf 1.35 oder älter bleibt, kann cgroup v1 weiterhin nutzen, aber ein Upgrade auf 1.36+ erfordert zwingend cgroup v2 auf allen Nodes.
Wie kann ich prüfen ob meine Nodes schon cgroup v2 nutzen?
Auf jedem Node: stat -fc %T /sys/fs/cgroup/. Gibt cgroup2fs zurück bedeutet cgroup v2 aktiv. Gibt tmpfs zurück bedeutet noch cgroup v1. Alternativ: cat /proc/1/cgroup – wenn alle Einträge in eine einzelne Zeile mit 0::/ zusammenlaufen, nutzt das System cgroup v2 unified.
Betrifft der cgroup v1-Removal auch Managed Kubernetes auf AWS/GCP/Azure?
Bei EKS, GKE und AKS wird die Node-Migration zu cgroup v2 vom Cloud-Provider beim Kubernetes-Versions-Upgrade automatisch durchgeführt – neue Node-Pools oder Managed Node Groups rotieren auf cgroup-v2-fähige Basis-Images. Problematisch sind self-managed Node-Gruppen oder Spot-Instanz-Pools mit custom AMIs die noch auf Ubuntu 20.04 oder Amazon Linux 2 (ohne cgroup v2-Konfiguration) laufen.
Wann sollte ich mit dem Upgrade auf 1.36 beginnen?
Erst nach vollständiger cgroup-v2-Validierung aller Worker-Nodes im Cluster. Der empfohlene Pfad: Staging-Cluster upgraden, alle Workloads 2 Wochen beobachten, dann Rolling-Upgrade der Production-Cluster node-by-node. Auf managed Cluster mit Auto-Upgrade: Auto-Upgrade-Window erst nach validierter Node-Kompatibilität öffnen.
Was ändert sich für Teams die GPU-Workloads mit NVIDIA-Device-Plugin betreiben?
Das klassische NVIDIA-Device-Plugin funktioniert weiterhin in Kubernetes 1.36 – es nutzt die Device-Plugin-API nicht DRA. Wer von Device-Plugin auf DRA migrieren will, benötigt NVIDIA-Device-Plugin v0.17+ und muss ResourceClasses und ResourceClaims für seine GPU-Workloads neu definieren. Die Migration ist optional aber empfohlen für Multi-Tenant-GPU-Cluster die sich Accelerator-Hardware teilen müssen.
Quelle Titelbild: Pexels | Faktengrundlage: Kubernetes Blog, CNCF, NVIDIA Developer Blog
