In-Place-Pod-Restarts: Effizienzsteigerung und Workload-Zuverlässigkeit in Kubernetes v1.35 und v1.36

🔄 Update — 20. Juni 2026: Neue Cloud-Features und Optimierungsstrategien für Kubernetes-Ressourcen

Die fortlaufenden Verbesserungen der Ausfallsicherheit und Effizienz von Kubernetes spiegeln sich in aktuellen Entwicklungen führender Cloud-Plattformen wider. Neue Automatisierungs- und Lifecycle-Features von Oracle OKE und Qovery sowie neue Best Practices zur Ressourcen-Optimierung verdeutlichen den Fokus auf optimierte Node-Nutzung und reduzierte Ausfallzeiten.

Was ist neu?

Oracle OKE Host-Gruppen & Quick Recycle: OCI unterstützt nun Compute Host-Gruppen für verwaltete OKE-Worker-Nodes, inklusive der „Quick Recycle“-Funktion, die Ausfallzeiten bei Node-Wartungen und -Ersetzungen drastisch minimiert.
Qovery Provision-Feature: Die automatisierte Cluster-Bereitstellung von Qovery vereinfacht das Aufsetzen von Kubernetes-Infrastrukturen (Netzwerk, IAM, Autoscaling) und erleichtert die Erstellung temporärer Umgebungen.
Dash0-Leitfaden für Requests vs. Limits: Dash0 hebt hervor, wie wichtig das präzise Tuning von Ressourcen-Requests und -Limits ist, um unnötige Cluster-Autoscaling-Kosten und OOM-Fehler (Out of Memory) zu vermeiden.

Warum es den Artikel ergänzt

Diese Entwicklungen zeigen, wie wichtig effizientes Ressourcenmanagement in der Praxis ist: Während in-place Pod-Restarts die Container-Wiederherstellung beschleunigen, minimieren Features wie OKE Quick Recycle die Node-Ausfallzeit, und Dash0-Metriken ermöglichen die optimale Dimensionierung der genutzten Kapazitäten.

Zusammenfassung

In Kubernetes v1.35 wurde das Feature “Restart All Containers on Container Exits” (KEP-5532) als Alpha-Version eingeführt und in Version 1.36 in die Beta-Phase überführt, wo es standardmäßig aktiviert ist. Diese Funktion ermöglicht es, bei einem Container-Absturz alle Container eines Pods inline auf demselben Node neu zu starten, ohne das Pod-Objekt selbst zu löschen und neu zu erstellen. Dadurch bleibt die Netzwerkidentität, die Speicher-Mounts und die Zuweisung von Hardware-Beschleunigern (wie GPUs/TPUs) vollständig erhalten, was die Effizienz und Wiederherstellungsgeschwindigkeit drastisch verbessert.

Was ist passiert?

Historisch gesehen führte ein kritischer Fehler in einem Container dazu, dass Administratoren oder Automatisierungstools das gesamte Pod-Objekt löschen und neu erstellen mussten, wenn eine saubere Neuinitialisierung erforderlich war. Mit der Einführung der Aktion RestartAllContainers (unterstützt durch das Feature-Gate RestartAllContainersOnContainerExits sowie die Abhängigkeiten ContainerRestartRules und NodeDeclaredFeatures) können Entwickler nun in den restartPolicyRules eines Containers festlegen, dass ein bestimmter Exit-Code (z. B. Code 88 eines Watchers) einen Neustart aller Container im Pod auslöst. Die Kubelet-Komponente stoppt dabei alle Container, hält die Pod-Sandbox jedoch intakt, behält IP-Adressen und Volumes bei und führt anschließend die Init-Container (einschließlich Sidecars) erneut in der korrekten Reihenfolge aus.

Warum es wichtig ist

Für den Betrieb von großen, verteilten Systemen – insbesondere bei AI/ML-Modelltraining oder komplexen Batch-Workloads – bietet das in-place Neustarten erhebliche Vorteile:

Reduzierung der Control-Plane-Last: Das Löschen und Neuerstellen tausender Pods bei einem Ausfall führte bisher zu massivem Druck auf die Kubernetes-Control-Plane und die etcd-Datenbank (“Thundering Herd”-Problem).
Beibehalt der Hardware-Bindung: GPUs und TPUs müssen nicht neu zugewiesen oder rescheduled werden, was teure Idle-Zeiten minimiert.
Erhalt lokaler Caches: Da der Pod auf demselben Node verbleibt, können neu gestartete Container direkt auf warme lokale Daten- und Modell-Caches zugreifen.
Vermeidung von Race Conditions: Bei Ressourcenknappheit wird verhindert, dass andere ausstehende Pods die Ressourcen eines kurzzeitig fehlerhaften Pods stehlen.

Beweise

Die Funktionalität ist in der offiziellen Kubernetes-Dokumentation verankert und wurde in KEP-5532 ausführlich spezifiziert. Im Google Open Source Blog wurde die Implementierung detailliert beschrieben, insbesondere wie die Wiederherstellungszeiten bei JobSet (einem Kubernetes-Projekt zur Orchestrierung von Batch-Jobs) durch dieses Feature von Minuten auf Sekunden verkürzt werden konnten. Zudem wurde der neue Pod-Status AllContainersRestarting eingeführt, der verhindert, dass Monitoring-Systeme oder Autoscaler während des Neustarts fälschlicherweise Alerts auslösen.

Analyse

Dieses Feature schließt eine langjährige Lücke in der Ausfallsicherheit von Multi-Container-Pods. Bisherige Workarounds mit individuellen Container-Neustarts führten oft zu inkonsistenten Zuständen (z. B. wenn eine Hauptanwendung nach dem Neustart einer Datenbank-Sidecar auf veralteten/toten Verbindungen hängen blieb). Die Re-Initialisierung über die erneute Ausführung der Init-Container im selben Sandbox-Kontext löst dieses Problem elegant. Die Architektur zeigt Googles Beitrag zur CNCF-Community, bei dem Best Practices aus dem Betrieb interner Mega-Systeme in den Open-Source-Standard einfließen.

Praktische Erkenntnisse

Für Entwickler und SREs ergeben sich folgende Kernpunkte zur Nutzung:

Idempotenz erzwingen: Da das Kubelet die Ausführung von Init-Containers nach dem Prinzip “mindestens einmal” garantiert, müssen alle Init-Skripte und Setup-Schritte absolut reentrant (idempotent) sein.
Termination Handling beachten: In-place Restarts unterstützen keine grazilen preStop-Hooks. Container erhalten fast augenblicklich ein SIGKILL, weshalb Anwendungen auf plötzliche Beendigungen vorbereitet sein müssen.
Tooling anpassen: CI/CD-Pipelines und externe Observability-Tools müssen so konfiguriert werden, dass sie neu startende Init-Container innerhalb derselben Sandbox nicht als neue Bereitstellung (Deployment) interpretieren.

Offene Fragen

Wie verhalten sich komplexe Service-Meshes, wenn die Netzwerkidentität zwar erhalten bleibt, aber alle Anwendungscontainer und Proxys abrupt per SIGKILL neu gestartet werden?
Gibt es spezifische Szenarien im Bereich hochsensibler Sicherheits-Workloads, in denen das Beibehalten der Sandbox trotz schwerer Container-Fehler ein Sicherheitsrisiko darstellen könnte?