Systemd und Kubernetes 1.36: Was sich für Bare-Metal-Cluster jetzt ändert

Kubernetes 1.36 macht Schluss mit Kompromissen: cgroup-v1 ist raus, systemd ist Pflicht, und wer auf Bare Metal betreibt, muss jetzt seine Node-Konfiguration grundlegend überdenken. Was das konkret bedeutet – von der Kubelet-Unit bis zur Container Runtime.

Der Bruch mit cgroup-v1: Was sich mit Kubernetes 1.36 ändert

Kubernetes 1.36 erschien im April 2026 und bringt eine Änderung mit, die in vielen Betriebsumgebungen sofort zuschlägt: Nodes, die noch mit dem cgroupfs-Treiber unter cgroup-v1 laufen, starten nach einem Upgrade auf 1.36 nicht mehr. Das ist kein Deprecation-Warning, kein Feature-Flag, keine sanfte Warnung – das ist ein harter Schnitt. Wer upgradet, ohne seinen Host vorzubereiten, hat danach einen nicht-bootenden Node.

Das trifft vor allem Bare-Metal-Setups, die über Jahre gewachsen sind: Ubuntu 20.04, CentOS 7, ältere Debian-Versionen – Systeme, auf denen cgroup-v1 noch Standard war und niemand aktiv migriert hat. In Cloud-VMs hat der Anbieter das oft still erledigt. Auf eigenen Servern nicht.

Die technische Konsequenz ist eindeutig: cgroup v2 plus passender cgroup-Driver in der Container Runtime ist ab 1.36 Pflicht. Containerd braucht SystemdCgroup = true in seiner Konfiguration, CRI-O die entsprechende Option im TOML. Ohne das läuft nichts. Der Grund dafür ist nicht Ideologie, sondern Konsistenz: Ressourcen-Limits, PSI-Metriken und DRA-Features bauen strukturell auf cgroup-v2-Hierarchien auf.

Wer also auf Debian 13 (Trixie), Ubuntu 26.04 oder Fedora 42 neu aufsetzt, hat cgroup v2 von Haus aus aktiv. Wer ältere Systeme betreibt, muss vorher prüfen: stat -fc %T /sys/fs/cgroup liefert cgroup2fs bei v2 und tmpfs bei v1. Kein Fund, kein Upgrade. So einfach ist die Entscheidungslogik.

Systemd als Pflicht-Init: Architekturentscheidung oder Pragmatismus?

Ich halte die Debatte um systemd oft für vergeudet. Was Kubernetes 1.36 hier tut, ist nicht religiös motiviert – es ist eine Engineering-Entscheidung. Das Init-System ist auf Linux-Nodes de facto systemd, und die neue Integration nutzt das aus, statt dagegen anzukämpfen.

Wer auf Bare Metal noch mit OpenRC, runit oder gar SysV-Init arbeitet: Es gibt keine offiziellen Roadmaps, keine Kubernetes-Testinfrastruktur, keine Support-Aussagen für diese Setups in 1.36. Experimente sind möglich, aber wer produktiv läuft, trägt das Risiko allein. Das ist keine böse Absicht, das ist schlicht Realität.

Der interessante Punkt ist ein anderer: Kubernetes delegiert in 1.36 aktiv Host-Level-Lifecycle-Management an systemd zurück. Das ist eine konzeptuelle Verschiebung. Früher haben Teams eigene Watchdog-Skripte gebaut, Healthcheck-Pods auf Node-Ebene eingesetzt oder externe Supervisoren konfiguriert. Jetzt übernimmt systemd diese Rolle direkt – offiziell, dokumentiert, mit expliziter API.

Das reduziert tatsächlich Betriebsaufwand. Nicht dramatisch, aber messbar: Weniger Custom-Ops-Skripte, weniger externe Abhängigkeiten, weniger Debugging in exotischen Supervisor-Konfigurationen. Dafür steigt die Erwartung an saubere systemd-Unit-Konfiguration auf jedem Node.

Kubelet Systemd Watchdog: Konfiguration und praktische Konsequenzen

Das neue Feature in Kubernetes 1.36 ist der Kubelet Systemd Watchdog. Es ist nicht standardmäßig aktiv – das ist ein häufiges Missverständnis. Ohne explizite Konfiguration passiert nichts. Aktiviert wird er ausschließlich über die systemd-Unit des Kubelet.

Die Mechanik ist geradlinig: Das Kubelet sendet periodisch sd_notify()-Signale mit WATCHDOG=1 an systemd. Fehlen diese Signale länger als der konfigurierte WatchdogSec-Wert, markiert systemd den Dienst als unresponsiv und beendet ihn. Was danach passiert, steuert die Restart=-Policy.

Eine typische Kubelet-Unit mit aktiviertem Watchdog sieht so aus:

[Service]
WatchdogSec=30s
Restart=on-watchdog
RestartSec=5s

Die offizielle Kubernetes-Dokumentation zum Kubelet Systemd Watchdog empfiehlt einen Wert von etwa 15 Sekunden, nennt 1 Sekunde als Minimum und rät explizit von Werten über 10 Minuten ab. Der Sinn: Zu kurze Intervalle produzieren falsche Positive bei kurzem CPU-Druck, zu lange Intervalle machen den Watchdog wertlos.

Was bringt das konkret? Hängt der Kubelet – etwa durch Deadlock, OOM-Situation oder Netzwerkproblem – wird das ohne Watchdog erst bemerkt, wenn externe Monitoring-Systeme anschlagen oder manuell jemand hinschaut. Mit Watchdog reagiert das System in konfigurierbaren Sekunden, vollautomatisch, ohne Cronjob, ohne Healthcheck-Pod. Das ist nützlich. Besonders auf Bare-Metal-Nodes, die keinen Cloud-Provider-Health-Check hinter sich haben.

Ein Detail, das in der Praxis relevant ist: Restart=on-watchdog und Restart=on-failure unterscheiden sich im Verhalten. on-watchdog greift nur bei Watchdog-Timeout, on-failure bei jedem nicht-sauberen Exit. Für den Kubelet empfiehlt sich in den meisten Bare-Metal-Setups Restart=always oder on-failure kombiniert mit WatchdogSec – damit sind sowohl Watchdog-Timeouts als auch normale Abstürze abgedeckt.

Container Runtimes und cgroup-v2: Was auf dem Node stimmen muss

Die Container Runtime ist das Bindeglied zwischen systemd, cgroup-Hierarchie und Kubernetes. Ohne saubere Integration auf dieser Ebene bringt der Rest nichts. Für Kubernetes 1.36 bedeutet das konkret: CRI-konforme Runtimes, explizit für systemd-cgroups konfiguriert.

Bei containerd sieht das in /etc/containerd/config.toml so aus:

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
  SystemdCgroup = true

Bei CRI-O ist die Option cgroup_manager = "systemd" in der Hauptkonfiguration zu setzen. Beide Runtimes unterstützen das auf aktuellen Debian 13-, Ubuntu 26.04- und Fedora 42-Systemen stabil out-of-the-box – vorausgesetzt, man verwendet Pakete aus den offiziellen Repositories oder die Kubernetes-eigenen Paketquellen, nicht irgendwelche selbst kompilierten Stände.

Was viele unterschätzen: Die Kombination aus cgroup-v2-Kernel, systemd als cgroup-Manager und einer CRI-konformen Runtime ist keine Selbstverständlichkeit auf altem Bare-Metal-Hardware. Auf Systemen mit älteren Kerneln (vor 5.8) fehlen teils cgroup-v2-Subsysteme. Prüfenswert: cat /proc/filesystems | grep cgroup2 und cat /sys/fs/cgroup/cgroup.controllers. Fehlen dort memory, cpu oder io, gibt es Probleme mit Ressourcen-Limits und PSI-Metriken.

PSI-Metriken und DRA: Warum cgroup-v2 mehr als nur Pflicht ist

Mit Kubernetes 1.36 erreichen PSI-Metriken (Pressure Stall Information) den GA-Status. Das bedeutet: Der Kubelet exponiert jetzt Kernel-Drucksignale – CPU-Pressure, Memory-Pressure, IO-Pressure – im Summary API als First-Class-Metriken. Das klingt nach einem Detail, ist aber für Bare-Metal-Betrieb relevant.

Warum? Weil CPU-Auslastung als alleinige Metrik lügt. Ein Node kann 60% CPU-Nutzung zeigen und trotzdem komplett überlastet sein – wenn Prozesse im Wartezustand auf Speicherzugriff oder IO stecken. PSI misst genau das: die Zeit, die Prozesse auf Ressourcen warten. Auf Basis dieser Signale kann Kubernetes Scheduling-Entscheidungen treffen, die näher an der Realität sind. Das ist unter der Haube direkt an cgroup-v2 gebunden – ohne v2 keine PSI.

Parallel dazu sind mehrere DRA-Features (Dynamic Resource Allocation) in 1.36 Beta und standardmäßig aktiv: Partitionable Devices, Consumable Capacity, Device Taints und Tolerations sowie Resource Health Status. Das ist vor allem für GPU-Nodes und High-IO-Setups interessant, also genau die Infrastruktur, die man typischerweise auf Bare Metal betreibt, weil Cloud-Instanzen für diese Hardware zu teuer oder zu inflexibel sind. ScaleOps hat die Resource-Management-Änderungen in 1.36 im Detail dokumentiert.

Logging-Integration: Von journalctl zu Cluster-Metriken

Ein Aspekt, der in Bare-Metal-Setups häufig stiefmütterlich behandelt wird: Logging-Integration zwischen systemd-Journal und Kubernetes-Monitoring. Mit 1.36 wird das durch feiner granulare Kubelet-RBAC-Subresources adressierbar.

Konkret: Die Subresources nodes/metrics, nodes/stats und nodes/log erlauben es, Monitoring- und Logging-Komponenten präzise zu berechtigen, ohne das breite nodes/proxy-Recht zu vergeben. Das ist sicherheitstechnisch wichtig. Wer bisher Prometheus-Node-Exporter oder Log-Agents mit nodes/proxy berechtigt hat, sollte das vor dem 1.36-Upgrade überprüfen und auf die spezifischen Subresources umbauen.

Praktisch bedeutet das für Self-Hosting-Cluster: journalctl -u kubelet -f auf dem Node und strukturierte Logs aus dem Kubelet-Summary-API im Cluster können jetzt über klar getrennte Berechtigungspfade zusammengeführt werden. Das ist kein glamouröses Feature, aber genau die Art von Betriebsverbesserung, die auf Bare Metal den Unterschied macht zwischen „wir suchen 2 Stunden nach dem Problem“ und „wir sehen es sofort“.

Für Self-Hosting-Setups auf Debian 13 gilt zudem: Der systemd-Journal exportiert mit --output=json strukturierte Logs, die direkt in Loki oder ähnliche Backends passen. Kombiniert mit den neuen Kubelet-Subresource-Permissions entsteht ein nachvollziehbarer Pfad von Host-Logs zu Cluster-Observability – ohne proprietäre Agenten oder Cloud-Lock-in.

Häufige Fehlerquellen und wie man sie vermeidet

Wer Bare-Metal-Cluster in der Praxis betreut, kennt die Situationen: Ein Upgrade läuft durch, der Node startet, aber Pods bleiben im Status ContainerCreating hängen. In vielen dieser Fälle liegt die Ursache nicht im Kubernetes-Upgrade selbst, sondern in inkonsistenten Konfigurationszuständen, die erst unter 1.36 sichtbar werden.

Ein häufiges Szenario: Die Container Runtime wurde auf SystemdCgroup = true umgestellt, aber der Kubelet selbst läuft noch mit dem alten cgroupfs-Driver-Parameter in seiner Konfigurationsdatei (/var/lib/kubelet/config.yaml, Feld cgroupDriver). Das Ergebnis ist ein Mismatch, der sich in kryptischen Fehlermeldungen im Kubelet-Log äußert. Lösung: beide Seiten konsistent konfigurieren und dann in der richtigen Reihenfolge neu starten – Runtime zuerst, Kubelet danach.

Ein weiteres typisches Problem betrifft Nodes, die via kubeadm provisioniert wurden und deren kubeadm-generierte systemd-Unit-Override-Dateien nicht angepasst wurden. Der Watchdog-Parameter landet dann nicht in der tatsächlich aktiven Unit, sondern in einer Datei, die von einem neueren Override überschrieben wird. Prüfbar mit systemctl cat kubelet – das zeigt die vollständige, zusammengeführte Unit-Konfiguration inklusive aller Drop-in-Dateien.

Wer mehrere Nodes parallel upgradet, sollte zudem auf den Node-Drain-Status achten. Nodes, die während des Upgrades plötzlich nicht mehr starten, blockieren im schlimmsten Fall laufende Workloads auf verbleibenden Nodes. Eine bewährte Praxis ist das sequenzielle Upgrade mit explizitem kubectl drain vor dem Upgrade und kubectl uncordon danach – auch wenn kubeadm das prinzipiell automatisiert, gibt manuelles Vorgehen mehr Kontrolle über Zeitpunkt und Reihenfolge.

Langfristige Konsequenzen für die Infrastrukturplanung

Die Änderungen in Kubernetes 1.36 sind kein Einzelereignis. Sie markieren eine Richtungsentscheidung, die sich in den nächsten Releases fortsetzen wird: Tighter Integration zwischen Host-Betriebssystem und Kubernetes, weniger Abstraktion auf Kosten von Portabilität, mehr explizite Konfigurationsanforderungen auf Node-Ebene. Wer das verstanden hat, plant Infrastruktur heute anders.

Konkret bedeutet das für Teams, die neue Bare-Metal-Cluster aufbauen: Der Betriebssystem-Auswahlprozess ist kein nachgelagertes Detail mehr. Die Entscheidung zwischen Debian 13, Ubuntu 26.04 und Fedora 42 hat direkte Auswirkungen auf den Support-Aufwand, die Paketversionen der Container Runtime und die cgroup-Konfiguration. Wer das frühzeitig in seine Beschaffungs- und Betriebsplanung für Serverinfrastruktur einbezieht, vermeidet kostspielige Nachrüstarbeiten später.

Für bestehende Cluster mit heterogener Node-Landschaft – ein Mix aus unterschiedlichen Distributionen und Kernelversionen – ist jetzt der richtige Zeitpunkt, eine Inventur zu machen. Welche Nodes sind cgroup-v2-bereit? Welche Runtimes laufen in welcher Version? Gibt es Nodes, die noch auf Kernel-Versionen vor 5.8 laufen? Diese Fragen lassen sich mit wenigen Befehlen beantworten, aber sie müssen gestellt werden, bevor das Upgrade läuft – nicht danach.

Die engere Verzahnung von systemd und Kubernetes ist letztlich auch eine Chance: Sie macht das Verhalten von Nodes vorhersehbarer, reduziert die Zahl der Moving Parts und erleichtert das Debugging. Wer die Investition in saubere systemd-Unit-Konfiguration und aktuelle Kernel heute macht, profitiert nicht nur von Kubernetes 1.36, sondern legt das Fundament für alle kommenden Releases, die diesen Weg konsequent weitergehen werden.

Migrationspfad: Was vor dem Upgrade auf 1.36 zu tun ist

Konkret und ohne Umschweife: Was muss auf einem Bare-Metal-Node vor dem Upgrade geprüft und geändert werden?

1. cgroup-Version prüfen:stat -fc %T /sys/fs/cgroup. Ergebnis muss cgroup2fs sein. Wenn nicht: Distribution upgraden oder Kernel-Bootparameter anpassen (systemd.unified_cgroup_hierarchy=1 für ältere Systeme, aber besser sauber migrieren).

2. Container-Runtime-Konfiguration anpassen:SystemdCgroup = true bei containerd, cgroup_manager = "systemd" bei CRI-O. Danach Runtime und Kubelet neu starten. Prüfen mit crictl info | grep cgroupDriver.

3. Kubelet-Unit für Watchdog konfigurieren:WatchdogSec in /etc/systemd/system/kubelet.service.d/10-kubeadm.conf oder der entsprechenden Override-Datei setzen. Wert zwischen 15 und 60 Sekunden ist in den meisten Umgebungen sinnvoll.

4. RBAC-ClusterRoles überprüfen:kubectl get clusterrolebindings -o json | jq '... nodes/proxy ...' – alle Einträge mit nodes/proxy identifizieren und auf spezifische Subresources migrieren.

5. Verteilungsunterstützung sicherstellen: Fedora 42 und Ubuntu 26.04 liefern aktuelle Kubernetes-kompatible Kernel und Runtimes mit. Debian 13 (Trixie) ist im Freeze-Prozess und sollte produktiv auf stabilen Backports-Paketen laufen. Die Enterprise-Migrationscheckliste für Kubernetes 1.36 auf Cloudmagazin listet die Schritte für verschiedene Distributionen im Detail.

Was bleibt nach diesem Upgrade? Der Node ist enger an das Host-Init-System gebunden als je zuvor. Das ist keine Schwächung – es ist eine Klärung. Systemd macht, was systemd kann: Prozesse überwachen, Ressourcen verwalten, Failures behandeln. Kubernetes macht, was Kubernetes kann: Workloads planen, APIs anbieten, Cluster-State deklarativ verwalten. Die Frage ist nicht ob diese Architektur sinnvoll ist – die Frage ist, ob Ihre Bare-Metal-Infrastruktur bereit dafür ist.