DevZero setzt auf Checkpoint-Restore für Kubernetes-Rightsizing ohne Neustarts

Stellen Sie sich die Kubernetes-Kapazitätsplanung wie einen Pub am Freitagabend vor: Der Wirt bestellt immer zu viele Fässer, weil einmal trocken zu laufen teurer ist als unverkauftes Bier. Genau so provisionieren die meisten Plattform-Teams ihre Cluster. DevZero hat jetzt ein Tool eingeführt, das die Fässer angeblich leise umschichten kann, während die Band noch spielt – ganz ohne Sperrstunde.

Was passiert ist

Wie IT Brief UK am Donnerstag berichtete, hat das in Seattle ansässige Unternehmen DevZero eine autonome Infrastruktur-Optimierungsplattform für Kubernetes-Workloads eingeführt, die Ressourcen in Echtzeit ohne Neustarts anpasst. Das Versprechen ist klar: Überbereitstellung stoppen, Kosten für Leerlauf eliminieren – und das alles ohne Pod-Neustarts.

Das Unternehmen wurde 2022 von den ehemaligen Uber-Ingenieuren Debo Ray und Rob Fletcher gegründet, ursprünglich rund um eine Cloud-Entwicklungsplattform zur Verbesserung der Softwareentwicklungsproduktivität. Die Gründer betrieben diesen Dienst selbst auf Kubernetes, stießen auf dieselben Ineffizienzen wie alle anderen und entwickelten Tools, um damit umzugehen. Diese Tools sind inzwischen das Hauptprodukt geworden.

Damit gerät DevZero auf Kollisionskurs mit Cast.ai und ScaleOps, den zwei Namen, die die meisten Plattform-Verantwortlichen bereits auf ihrer Anbieterliste haben, wenn der CFO unbequeme Fragen zu EC2-Ausgaben stellt. Das Differenzierungsmerkmal, auf das DevZero setzt, ist die Checkpoint-Restore-Technologie, die nach eigenen Angaben die Live-Migration von Workloads bei Lastwechseln oder Infrastrukturausfällen ermöglicht.

Zu den veröffentlichten Kunden zählen DataBahn, Dentira, Starburst, OpenObserve und Outerbounds – eine auffällig KI- und Datenplattform-lastige Liste. Zu den Investoren gehören Anthos Capital, Foundation Capital und Madrona.

DevZero gibt an, dass seine durchschnittlichen Kunden vor der Einführung der Plattform 53 % zu viel für Compute ausgaben und dass Nutzer ihre Compute-Rechnungen typischerweise um 30 bis 60 % senken. Das Unternehmen weist selbst darauf hin, dass diese Einsparungszahlen nicht unabhängig verifiziert wurden – was zumindest ehrlich ist. Der Grund, warum sie den Markt für bereit halten: Eine Umfrage der Cloud Native Computing Foundation ergab, dass 66 % der Organisationen, die generative KI-Modelle betreiben, Kubernetes zur Verwaltung einiger oder aller ihrer Inferenz-Workloads nutzen, und Datadog-Forschung zeigt, dass 83 % der Container-Kosten auf inaktive Ressourcen entfallen, davon 54 % auf überprovisionierte Cluster-Infrastruktur.

Technische Architektur

Das Interessante ist der Mechanismus, nicht das Dashboard. DevZero arbeitet auf Cluster-, Node- und Workload-Ebene, erstellt Profile der Ressourcennachfrage und passt CPU-, Memory- und GPU-Zuteilung an, wenn sich die Nutzung verändert. Das ist Standard. Cast.ai und ScaleOps machen ähnliche Dinge. Der langweilige Teil ist bei allen Anbietern gleich: Metriken sammeln, Nachfrage modellieren, Instanztypen auswählen, planen.

Interessant wird es beim Checkpoint-Restore. Wer schon einmal versucht hat, einen Stateful-Pod auf Standard-Kubernetes vertikal zu skalieren, kennt das Spiel: In-Place-Ressourcenänderung ist noch nicht ausgereift, der VerticalPodAutoscaler wollte den Pod historisch gesehen evakuieren, und „Pod evakuieren" ist Ingenieurssprache für „Workload neu starten und hoffen, dass der Connection Pool sich wieder verbindet". Checkpoint-Restore (dieselbe Technologie-Familie wie CRIU, um die CNCF-Projekte seit Jahren kreisen) macht einen Snapshot des laufenden Prozesszustands und setzt ihn woanders fort. Kein Cold Start. Kein JVM-Warm-up-Aufwand. Kein verlorener In-Memory-Cache.

Das ist an zwei konkreten Stellen wichtig. Erstens bei KI-Inferenz: Ein großes Modell, das in den GPU-Speicher geladen wurde, ist teuer zu evakuieren. Wenn man es live auf einen passend dimensionierten GPU-Node migrieren kann, vermeidet man sowohl die Cold-Start-Latenz als auch die Versuchung, GPU-Kapazität „auf Vorrat" zu überprovisionieren. Zweitens bei Availability-Zone-Ausfällen. Mihir Nair, Head of Architecture bei DataBahn, sagte: „Während eines kürzlichen Availability-Zone-Ausfalls hat DevZero unsere Workloads transparent live migriert, ohne dass ein einziger Neustart oder ein operativer Eingriff unseres Teams erforderlich war."

Die Plattform läuft zudem auf AWS, Azure, GCP, OCI und OpenShift, und DevZero gibt an, mehr als 3.000 Instanztypen, 69.000 Preispunkte, 23 GPU-Modelle und mehr als 80 Regionen zu analysieren, um zu entscheiden, wo Workloads landen sollen. Der kombinatorische Raum der Cloud-SKUs ist seit Jahren eine stille Katastrophe für Plattform-Teams, und diese Entscheidung an einen Solver auszulagern ist ehrlich gesagt der einzig vernünftige Schritt. Die schwierigere technische Frage ist, ob der Live-Migrations-Anspruch bei wirklich komplexen Workloads standhält: TCP-Sessions, GPU-Memory-Mapped-Buffer, Kernel-Modul-Abhängigkeiten. Das Marketing sagt ja. Der 3-Uhr-Pager wird das letzte Wort haben.

Wer unter Druck gerät

Cast.ai und ScaleOps sind die offensichtlichen Platzhirsche, die diesem Launch gegenüberstehen. Beide haben starke Storys rund um K8s-Kostenoptimierung aufgebaut und müssen nun begründen, warum ihr Rightsizing-Ansatz – der in der Regel Pod-Ersatz beinhaltet – für KI-Inferenz und langlebige Stateful-Services akzeptabel ist. Erwarten Sie Feature-Seiten mit Erwähnung von Checkpoint-Restore innerhalb eines Quartals. So bewegt sich dieser Markt.

Die größere Gruppe, die unter Druck gerät, ist die schweigende Mehrheit der Plattform-Teams, die in den letzten zwei Jahren interne Confluence-Seiten mit dem Titel „Kubernetes Cost Optimisation Roadmap" geschrieben haben – ohne ein einziges ausgeliefertes Ergebnis. Ihr CFO hat jetzt die Datadog-Statistik gelesen, dass 83 % der Container-Kosten auf inaktive Ressourcen entfallen. Die Schonfrist für „wir prüfen gerade Karpenter und HPA-Tuning" schließt sich schnell.

Die KI-Inferenz-Gruppe ist auf andere Weise exponiert. Wer LLM-Inferenz auf reservierter GPU-Kapazität betreibt, die für Spitzenlast dimensioniert ist, hat still und leise schlechte Unit Economics. Das CNCF-Umfrageergebnis von 66 % Kubernetes-für-Inferenz zeigt, dass das Substrat standardisiert genug ist, damit Anbieter wie DevZero es direkt adressieren können. Teams, die maßgeschneiderte Inferenz-Stacks auf nativem EC2 gebaut haben, werden bald feststellen, dass ihre Kostengeschichte schlechter ist als bei den K8s-nativen Shops, über die sie sich früher lustig gemacht haben.

Schließlich trifft es auch die Cloud-Anbieter selbst, wenn auch nur leicht. Jeder Dollar, den eine Rightsizing-Plattform einem Kunden spart, ist ein Dollar weniger auf einer AWS-, Azure- oder GCP-Rechnung. Hyperscaler tolerieren das, weil die Alternative (Kunden verlieren) schlimmer ist, aber man beachte, dass ihre eigenen nativen Tools (Compute Optimizer, Azure Advisor) praktischerweise vor aggressivem Live-Rightsizing haltmachen. Wie praktisch.

Handlungsempfehlungen für Engineering-Teams

Wer eine Kubernetes-Plattform betreibt, sollte diese Woche drei Dinge tun. Erstens: Messen Sie tatsächlich Ihre Leerlaufquote. Vergleichen Sie Container-CPU- und Memory-Anfragen mit der tatsächlichen Nutzung über ein 14-tägiges Fenster. Wenn Sie sich in der Nähe der 83-%-Leerlauf-Zahl bewegen, haben Sie eine Kostengeschichte auf Vorstandsebene – ob Sie wollen oder nicht. OpenTelemetry-Metriken, die in Ihre bestehenden Tools fließen, reichen aus; Sie brauchen keinen neuen Anbieter, um festzustellen, dass Sie ein Problem haben.

Zweitens: Trennen Sie Workloads, die Eviction tolerieren können, von denen, die das nicht können. Zustandslose HTTP-Services: kein Problem, HPA und VPA erledigen den größten Teil der Arbeit. Stateful Services, langlebige gRPC-Streams, GPU-geladene Inferenz-Pods, alles mit einem nennenswerten Warm-up – das sind die Workloads, bei denen Checkpoint-Restore wirklich seinen Wert beweist. Wer seinen Split kennt, kann DevZero, Cast.ai, ScaleOps oder eine eigene Lösung auf ehrlicher Grundlage evaluieren.

Drittens: Pilotieren Sie auf einem nicht-kritischen Cluster, bevor Sie einer 30-bis-60-%-Einsparungszahl glauben. DevZero selbst weist darauf hin, dass diese Zahlen nicht unabhängig verifiziert wurden, und Ihr Workload-Mix entspricht nicht dem Durchschnitt. Führen Sie einen vierwöchigen Vergleichstest mit echtem produktionsähnlichem Traffic durch. Messen Sie nicht nur die Kostendifferenz, sondern auch p99-Latenz, Neustart-Anzahlen und Operator-Eingriffe. Rays eigene Formulierung war „autonome Optimierung, der sie um 3 Uhr morgens vertrauen können". Testen Sie es um 3 Uhr. An einem Sonntag. Mit einem synthetischen AZ-Ausfall. Wenn es das übersteht, haben Sie etwas Brauchbares. Wenn nicht, haben Sie ein sehr teures Dashboard.

Wichtigste Erkenntnisse

• DevZeros Launch stellt Checkpoint-Restore in den Mittelpunkt der K8s-FinOps-Diskussion und zwingt Cast.ai und ScaleOps, die Live-Migrations-Frage zu beantworten.
• Die Zahl von 83 % Leerlauf-Container-Kosten aus Datadog plus 66 % GenAI-Inferenz auf K8s bedeutet, dass Rightsizing nun ein CFO-sichtbarer Budgetposten ist, kein Hobby des Plattform-Teams.
• KI-Inferenz und Stateful-Workloads sind dort, wo evictionsbasierte Autoscaler versagen und wo Live-Migration die Wirtschaftlichkeit verändert.
• DevZeros Einsparungsbehauptung von 30 bis 60 % stammt vom Unternehmen selbst und ist unverifiziert; behandeln Sie sie als Hypothese zum Testen, nicht als Zahl für eine Vorstandspräsentation.
• Zurück zum Pub: Der Wirt, der Fässer mitten im Betrieb umschichten kann, ohne einen Tropfen zu verschütten, gewinnt. Alle anderen horten weiter. Das ist die Wette, die DevZero macht – und sie ist durchaus vernünftig.