8 Min. Lesezeit
Kubernetes 1.36 ist am 22. April 2026 GA gegangen. Zwei Änderungen stehen im Mittelpunkt: das endgültige cgroup-v1-Removal und die General-Availability von Dynamic Resource Allocation (DRA). Für Enterprise-Ops-Teams bedeutet das konkrete To-dos in den nächsten 60 Tagen – bevor Upstream-Support und Security-Patches für ältere Cluster-Versionen auslaufen. Eine Migrations-Checkliste ohne Theorie-Overhead.
Das Wichtigste in Kürze
- Kubernetes 1.36 GA 22.04.2026: cgroup-v1-Support entfernt, DRA wird General Available
- Wer noch auf cgroup-v1 läuft (erkennbar an –cgroup-driver=cgroupfs), muss vor Upgrade auf containerd + cgroup-v2 migrieren
- DRA-GA: Ressourcentreiberinstallation und NodeFeature-CRDs jetzt Pflicht für GPU/FPGA-Workloads
- Mindestanforderung containerd: 1.7.x für 1.36-Support, 2.0 empfohlen
- Zeitfenster: Kubernetes 1.33 End-of-Life Oktober 2026 – wer noch auf 1.33 läuft muss jetzt upgraden
VerwandtEdge Computing 2026: ThinkEdge SE60n Gen 2 im Praxischeck / FinOps 2026: Enterprise Cloud-Kosten im Griff
Was ist Kubernetes 1.36 und warum ist dieses Release migrationskritisch?
Was ist Kubernetes 1.36? Kubernetes 1.36 ist das am 22. April 2026 veröffentlichte Release des Open-Source-Container-Orchestrierungssystems und markiert das endgültige Removal von cgroup-v1-Support sowie die General Availability von Dynamic Resource Allocation (DRA) für Hardware-Ressourcen wie GPUs und FPGAs.
Kubernetes 1.36 ist das erste Release, das cgroup-v1 vollständig entfernt. cgroup v1 (Control Groups version 1) war die klassische Linux-Kernel-Schnittstelle für Ressourcenisolierung – RAM-Limits, CPU-Quoten, Prozess-Hierarchien. Seit Kubernetes 1.25 war cgroup-v2 der Standardpfad. Mit 1.36 ist cgroup-v1 nicht mehr optional deprecated, sondern weg.
Das bedeutet: Wer einen Node noch mit dem cgroupfs-Treiber unter cgroup-v1 betreibt, kann nach einem Upgrade auf 1.36 nicht mehr starten. Der Kubelet wirft einen Fehler beim Initialisierungscheck. Das ist kein weicher Übergang – das ist ein harter Stopp.
Zahlen zur Migration
23%
der Enterprise-Cluster liefen laut CNCF-Survey Q1 2026 noch auf cgroup-v1 oder haben unklaren Status
Oct 2026
K8s 1.33 End-of-Life – wer noch auf 1.33 läuft hat 5 Monate
containerd 2.0
Empfohlene Version für K8s 1.36 – 1.7.x ist Minimum, 2.0 ist supportierter Pfad
Schritt 1: Cluster-Status prüfen (cgroup-Version und containerd)
Bevor irgendjemand upgradet, braucht jeder Node eine Bestandsaufnahme. Zwei Checks, beide können remote über kubectl ausgeführt werden:
cgroup-Version pro Node:
xargs -I{} kubectl describe node {} | grep „Container Runtime“
# Oder direkt auf Node:
stat -fc %T /sys/fs/cgroup
# Ausgabe „tmpfs“ = cgroup-v1, „cgroup2fs“ = cgroup-v2
containerd-Version und Konfiguration:
# Min: 1.7.x | Empfohlen: 2.0.x
# containerd-cgroup-driver prüfen:
grep -i cgroup /etc/containerd/config.toml
# Sollte „SystemdCgroup = true“ zeigen (cgroup-v2)
Wer SystemdCgroup = false oder keinen Eintrag sieht, läuft noch im cgroupfs-Modus. Das ist der Hauptblocker für das 1.36-Upgrade.
Schritt 2: cgroup-v2-Migration auf Node-Ebene
Die Node-Migration von cgroup-v1 auf cgroup-v2 erfordert einen Kernel-Parameter-Change und einen Node-Drain-Restart-Zyklus. Kein Rolling-Upgrade möglich – jeder Node muss drainiert werden.
1. Kernel-Bootparameter anpassen (GRUB oder systemd-boot je nach OS):
GRUB_CMDLINE_LINUX=“systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all“
update-grub && reboot
2. containerd-Konfiguration updaten:
[plugins.“io.containerd.grpc.v1.cri“.containerd.runtimes.runc.options]
SystemdCgroup = true
3. Kubelet-Konfiguration anpassen:
cgroupDriver: systemd
# Restart-Sequenz:
kubectl drain <node> –ignore-daemonsets
systemctl restart containerd kubelet
kubectl uncordon <node>
„Ein Node der nach dem Drain nicht sauber rebooted – das ist der Moment wo die Planung auf die Realität trifft. Plan für 45 Minuten pro Node, nicht für 15.“
– Alec Chizhik, cloudmagazin
Schritt 3: DRA – Dynamic Resource Allocation einrichten
DRA ist in 1.36 General Available. Was bedeutet das für Teams mit GPU- oder FPGA-Workloads? DRA ersetzt den alten Device-Plugin-Mechanismus für Hardware-Ressourcen. Wer NVIDIA-GPUs über das NVIDIA-Device-Plugin betreibt, muss prüfen ob der Hersteller-Treiber bereits DRA-kompatibel ist.
DRA-Pflicht-Checks für GPU-Umgebungen:
kubectl get –raw /api/v1 | grep -i „dynamic“
# ResourceSlice und DeviceClass CRDs prüfen:
kubectl get crd | grep resource.k8s.io
# Erwartete Ausgabe:
# deviceclasses.resource.k8s.io
# resourceclaims.resource.k8s.io
# resourceslices.resource.k8s.io
NVIDIA hat mit NVIDIA-GPU-Operator 25.x DRA-Support eingeführt. AMD ROCm DRA-Support ist ab 2026-Q2 angekündigt. Wer Intel-GPUs (Gaudi, Arc) einsetzt muss separat prüfen – Intel-Extensions for Kubernetes haben einen eigenen Release-Zyklus.
Pros und Cons: Direkt auf 1.36 vs. Zwischenschritt über 1.35
Direkt auf 1.36 spricht
- Eine Migration statt zwei (keine Zwischenversion)
- DRA-GA sofort nutzbar
- Längerer Support-Horizont (1.36 EOL: ~April 2027)
- Ein Downtime-Fenster statt zwei
Zwischenschritt über 1.35 spricht
- cgroup-v2-Migration in 1.35 vorbereitbar ohne 1.36-Änderungen
- DRA noch beta in 1.35 – weniger Überraschungen wenn kein GPU-Workload
- Risiko-Splitting: Infrastruktur-Migration + API-Upgrade getrennt
Häufige Fragen
Muss ich cgroup-v2 aktivieren bevor ich auf K8s 1.36 upgrade?
Ja, das ist eine harte Anforderung. K8s 1.36 startet nicht auf Nodes die noch im cgroup-v1-Modus laufen. Die Migration muss vor dem Kubernetes-Upgrade auf Node-Ebene abgeschlossen sein (GRUB-Parameter + containerd-Konfiguration + Kubelet-Config).
Welche containerd-Version brauche ich für Kubernetes 1.36?
Minimum ist containerd 1.7.x. Empfohlen ist containerd 2.0.x für vollständigen Support. containerd 1.6.x ist nicht mehr kompatibel. Prüfen mit containerd –version.
Ist DRA ein Ersatz für NVIDIA Device Plugin?
Mittelfristig ja, kurzfristig beides parallel. DRA ist ab K8s 1.36 GA, aber Hersteller-Treiber haben eigene Roadmaps. NVIDIA GPU Operator unterstützt DRA ab 25.x. Das Device Plugin läuft parallel weiter bis Hersteller offiziell auf DRA-only umstellen.
Was passiert mit meinen bestehenden Resource-Quotas nach der cgroup-v2-Migration?
Memory-Limits und CPU-Limits bleiben semantisch identisch unter cgroup-v2. Der Unterschied: cgroup-v2 setzt Limits präziser durch, insbesondere bei Memory-Overcommit-Szenarien. In seltenen Fällen können Workloads die unter cgroup-v1 an den Grenzen liefen unter cgroup-v2 OOM-Signale früher bekommen.
Wie prüfe ich ob mein Managed-Kubernetes-Dienst (EKS, GKE, AKS) schon auf cgroup-v2 ist?
EKS: Amazon Linux 2023 ist standardmäßig cgroup-v2. Amazon Linux 2 ist noch cgroup-v1. GKE: Alle Nodes mit Container-Optimized OS seit 2023 sind cgroup-v2. AKS: Standard-Ubuntu-Nodes sind ab AKS 1.25 auf cgroup-v2. Prüfen mit stat -fc %T /sys/fs/cgroup auf einem Node.
Netzwerk
Industrie 5.0: Was CIOs jetzt entscheiden müssen (Digital Chiefs) | Nearshoring 2026: Entscheidungsrahmen (MyBusinessFuture)
Quelle Titelbild: Pexels / cottonbro studio (px:6804597)
