Warum Kubernetes Live-Container-Migration immer noch nicht nativ unterstützt (und warum es das sollte)

Kubernetes hat bei der Orchestrierung containerisierter Workloads einen weiten Weg zurückgelegt, aber es gibt immer noch eine auffällige Lücke, die sich 2025 fast schon anachronistisch anfühlt: native Unterstützung für Live-Container-Migration.

Man könnte meinen, dass bei all den Fortschritten in der Container-Technologie – Serverless-Abstraktionen, Multi-Cloud-Scheduler, GPU-Orchestrierung und sogar Edge-Cluster – die Fähigkeit, einen Container zwischen Nodes zu verschieben, ohne ihn zu killen, mittlerweile Grundvoraussetzung wäre. Ist sie aber nicht. Und für eine Plattform, die um Resilienz und Skalierbarkeit herum gebaut ist, ist das … seltsam.

Kürzlich hat CAST AI ein Feature vorgestellt, das dieses Problem endlich anpackt: Container Live Migration für EKS. Mit CRIU (Checkpoint/Restore In Userspace) können Sie einen laufenden Container pausieren, seinen kompletten Zustand kopieren – inklusive Speicher und Prozessinformationen – und ihn auf einem anderen Node fortsetzen. Stellen Sie sich „Live-VM-Migration" vor, nur für Container. Die Reaktion? Zu gleichen Teilen Staunen, Skepsis und jede Menge Kopfkratzen.

Schauen wir es uns also genauer an – was Live-Container-Migration ist, warum Kubernetes sie immer noch nicht nativ unterstützt, und warum es höchste Zeit dafür wäre.

Was genau ist Live-Container-Migration eigentlich?

Einfach gesagt bedeutet Live-Migration, einen laufenden Container von einem Node auf einen anderen zu verschieben, ohne ihn zu stoppen oder neu zu starten.

Das unterscheidet sich grundlegend davon, wie Kubernetes heute funktioniert. Müssen Sie Ihre Workloads heute neu ausbalancieren (etwa wegen Wartungsarbeiten oder einer besseren Bin-Packing-Gelegenheit), wird der Pod gekillt und irgendwo anders neu erstellt. Für zustandslose Apps ist das kein Problem. Für alles Komplexere? Nicht so sehr.

Live-Migration würde bedeuten, dass Sie:

• einen Container, der eine lange Datenverarbeitungsaufgabe ausführt, auf einen anderen Node verschieben könnten, ohne den Job neu zu starten
• Pods nahtlos von einem Node wegverlagern könnten, der kurz vor der Terminierung steht (etwa eine Spot-Instanz)
• Downtime bei Stateful Workloads wie Gameservern oder PBX-Systemen vermeiden könnten
• Kosten senken könnten, indem Sie Workloads im Laufe der Zeit effizienter konsolidieren

Die Idee gibt es in der VM-Welt schon ewig. VMware hat sie. KubeVirt unterstützt sie sogar für VMs innerhalb von Kubernetes. Aber Container? Das ist ein anderes Kaliber.

Warum unterstützt Kubernetes das nicht schon längst?

Gute Frage. Ein paar Gründe:

1. Philosophische Wurzeln

Kubernetes wurde um die Annahme herum gebaut, dass Workloads vergänglich und fehlertolerant sein sollten. Man patcht oder verschiebt Dinge nicht – man ersetzt sie. Apps sind darauf ausgelegt, einen Neustart zu tolerieren. Es ist wieder mal „Vieh versus Haustiere".

Aber hier ist der Punkt: Die Welt hat sich verändert. Stateful Workloads sind überall – dank besserer Operatoren, Unterstützung für Persistent Volumes und ausgereifter Tools wie Longhorn und Rook. Wir betreiben nicht mehr nur Nginx und Redis. Wir betreiben massive Spark-Jobs, LLM-Inferenz, PostgreSQL-Cluster und Echtzeit-Multiplayer-Gameserver.

Diese alte Annahme wird zum Flaschenhals.

2. Es ist technisch schwierig

CRIU zu verwenden, um einen Container zu checkpointen und wiederherzustellen, klingt auf dem Papier einfach. In der Realität? Ein Minenfeld.

Sie speichern nicht nur den Arbeitsspeicher – Sie müssen bewahren:

• Offene File Descriptors
• Aktive Netzwerkverbindungen
• IP-Adressen und DNS-Konfigurationen
• Mounts und Volume-Zustände
• GPU- oder Device-Kontexte (falls vorhanden)
• CPU- und NUMA-Bindungen

Und dann müssen Sie all das auf einem anderen Node wieder aufbauen, idealerweise im selben Namespace, mit derselben IP und demselben Zustand, ohne Aussetzer. Das ist keine Kleinigkeit.

CAST AI hat Berichten zufolge ein ganzes Jahr gebraucht, um ihre Version zu bauen. Das sagt schon einiges.

3. Kubernetes hat keine nativen Primitiven dafür

Es gibt heute keine eingebaute API in Kubernetes, die sagt: „Verschiebe diesen Container von Node A zu Node B." Der Scheduler arbeitet auf Pod-Ebene, nicht auf Ebene des Container-Zustands.

KubeVirt umgeht das, indem es VMs in einer benutzerdefinierten CRD (Custom Resource Definition) betreibt, und weil VMs Live-Migration bereits auf Hypervisor-Ebene unterstützen, lässt sich leichter darauf aufbauen.

Für Container bräuchte Kubernetes neue APIs, Controller-Logik und möglicherweise eine Verschiebung darin, wie Container-Runtimes mit dem Kubelet zusammenspielen. Nicht unmöglich, aber auch nicht trivial.

Warum es unbedingt ein natives Feature sein sollte

Trotz alledem sind die Vorteile zu überzeugend, um sie zu ignorieren.

Besseres Bin Packing

Ist ein Node heute unterausgelastet, kann Kubernetes nicht einfach Container umherschieben, um Ressourcen zurückzugewinnen. Sie müssten Pods killen und hoffen, dass der Scheduler sie beim nächsten Mal besser platziert. Live-Migration würde intelligentere, störungsfreie Ressourcenoptimierung in Echtzeit ermöglichen.

Überlebensfähigkeit bei Spot-Instanzen

Bei AWS, GCP und Azure können Spot-/Preemptible-VMs mit wenig Vorwarnung verschwinden. Live-Migration würde es Ihnen erlauben, Workloads zu verschieben, bevor sie terminiert werden. Das bedeutet weniger Neustarts, weniger Fehler und bessere Uptime – besonders bei Workloads wie KI-Training, wo Neustartkosten hoch sind.

Unterstützung für lang laufende Stateful Workloads

Manche Jobs starten einfach nicht sauber neu. Denken Sie an einen Spark-Job, der 10 Stunden läuft, aber die meiste Zeit nur 50 % der CPU nutzt. Könnten Sie Teile davon verschieben, würden Sie Ressourcen sparen, ohne den gesamten Job neu zu starten. Das wäre ein gewaltiger Gewinn.

Neue Anwendungsfälle erschließen

Wollen Sie einen Echtzeit-Gameserver in Kubernetes betreiben? Oder einen Hochfrequenzhandel-Bot? Oder eine Telekom-Vermittlungsanwendung? All das liegt traditionell außerhalb von Kubernetes' Komfortzone, wegen der Empfindlichkeit gegenüber Neustarts. Live-Migration würde sie mit ins Boot holen.

Wie geht es also weiter?

Es gibt Anzeichen, dass sich die Dinge in diese Richtung bewegen.

Das Feature von CAST AI zeigt, was möglich ist, auch wenn es (noch) nicht Open Source ist.

KubeVirt beweist, dass Live-Migration innerhalb einer Kubernetes-nativen Umgebung funktionieren kann.

Die Checkpoint Restore Working Group innerhalb der Kubernetes-Community erforscht, wie sich diese Ideen Stück für Stück verwirklichen lassen.

Währenddessen experimentieren Projekte wie ZeroPod mit CRIU-basiertem Pausieren/Wiederherstellen von Containern für Edge- und Embedded-Systeme. Die Saat wird gelegt. Die Frage ist, ob der Kubernetes-Core sie irgendwann aufnehmen wird.

Und vielleicht sollte er das auch.

Denn am Ende des Tages hat sich Kubernetes weit über seine zustandslosen Microservice-Wurzeln hinaus entwickelt. Es ist zur De-facto-Control-Plane für moderne Infrastruktur geworden – und betreibt alles von Datenbanken bis zu ML-Pipelines. Die Anforderungen haben sich geändert, und das sollte auch die Plattform tun.

Zum Schluss

Live-Container-Migration ist nicht nur ein cooler Trick – sie ist ein fehlendes Puzzleteil. Und da Stateful Workloads zur Norm werden statt zur Ausnahme, wird Kubernetes aufholen müssen.

Native Unterstützung würde Workloads nicht nur widerstandsfähiger machen – sie würde eine ganz neue Klasse von Anwendungsfällen erschließen, für die Kubernetes nie gebaut war … bis jetzt.

Vielleicht geht es gar nicht darum, ob Kubernetes Live-Migration unterstützen sollte.

Vielleicht ist die bessere Frage: Wie lange kann es sich leisten, es nicht zu tun?