Daytona2 will die Lücke bei der Agenten-Laufzeitumgebung schließen, die Kubernetes offenlässt

Warum Kubernetes bei Agenten-Workloads an Grenzen stößt

Laut Daytona erweitern viele Teams ihre bestehende Kubernetes-Infrastruktur, um Agenten zu betreiben, weil darauf bereits ihre Produktivanwendungen laufen. Das funktioniere zunächst, gerate aber ins Wanken, sobald die Workloads wachsen. Die Teams setzten dann zusätzliche Systeme obendrauf, was Daytona als „a patchwork of workarounds and fragile dependencies“ beschreibt, also als Flickenteppich aus Notlösungen und fragilen Abhängigkeiten.

In dem Beitrag heißt es, Kubernetes sei zur Standard-Steuerungsebene geworden, weil es containerisierte Workloads zuverlässig ausführe. Sein Pod-basiertes Design eigne sich für langlebige Microservices und horizontal skalierte APIs, bei denen Instanzen austauschbar seien und der Zustand von der Rechenleistung entkoppelt sei. Agenten benötigten Daytona zufolge dagegen kurzlebige, aufgabenspezifische Umgebungen mit wechselnden Ausführungsmustern. Die Infrastruktur müsse sich in Echtzeit anpassen und zugleich Kontext über einzelne Schritte hinweg mitführen.

Daytona betont ausdrücklich, dass die Lösung nicht darin bestehe, Kubernetes aufzugeben. Dem Unternehmen zufolge fehlt dem Stack vielmehr eine Ausführungsumgebung, die auf das Verhalten von Agenten zugeschnitten ist.

Fünf Schwachpunkte, die Daytona benennt

Der Beitrag fasst die Probleme in fünf Bereichen zusammen.

• Orchestrierungskomplexität: Jede Agentenaufgabe braucht eine eigene Umgebung mit eigenem Dateisystem und eigenem Lebenszyklus. Bei Tausenden gleichzeitigen Aufgaben schreiben Teams Controller, um Sandboxes bereitzustellen, aktive zu verfolgen und anschließend aufzuräumen. Jeder zusätzliche Schritt bringe neue Fehlerquellen mit sich, darunter verwaiste Sandboxes, die Speicher belegen, den andere Workloads benötigen, so Daytona.
• Latenz bei der Bereitstellung: Ein Coding-Agent, der einen Produktionsfehler beheben soll, muss warten, bis Kubernetes Kapazität bereitstellt, den Pod einplant, das Image lädt und die Laufzeit initialisiert. Auch wenn jeder Schritt nur Sekunden dauere, summiere sich die Verzögerung über viele Aufgaben und begrenze den Durchsatz, sagt Daytona.
• Isolationsaufwand: Da Agenten Code erzeugen und Dateien verändern, braucht jede Umgebung eine starke Isolation, in der Regel gVisor oder Kata Containers plus CNI-Plugins wie Cilium oder Calico für Egress-Regeln. Laut Daytona erhöht Kata Containers den grundlegenden Ressourcenverbrauch erheblich, während Ansätze mit gemeinsamem Kernel wie gVisor die I/O-Leistung bremsen und mögliche Ausbruchspfade eröffnen.
• Wiederholte Rekonstruktion des Kontexts: Um den Zustand des Workspace zu erhalten, braucht es PersistentVolumeClaims, externe Speicher und CSI-basierte Snapshots. Wenn diese Eigenbauten nicht ausreichen, rekonstruieren Agenten ihren Kontext neu, und Umgebungen können zwischen einzelnen Ausführungen auseinanderdriften.
• Ineffiziente Ressourcennutzung: Die Nachfrage kann von null auf Hunderte oder Tausende Umgebungen springen. Daytona nennt als Beispiel, dass 500 vorgewärmte Sandboxes bedeuten können, 500 vCPUs und 1 TB Arbeitsspeicher zu reservieren, bevor die Agenten überhaupt anfangen. Ein kleinerer Pool führe dazu, dass Agenten bei Lastspitzen in der Warteschlange hängen.

Was Daytona anbietet

Daytona zufolge erspart die eigene Plattform den Aufbau dieser Schicht. Teams erhalten eine vollständig verwaltete Sandbox-Plattform und können die Laufzeitumgebung wahlweise auf eigenen Clustern betreiben, wobei Kubernetes die Steuerungsebene bleibt.

Der Orchestrator des Unternehmens nutzt einen Declarative Builder zur Definition der Umgebungen und stellt eigenständige Einzelinstanz-Sandboxes in Cloud-Infrastruktur, auf VMs und auf Bare-Metal-Servern bereit und verwaltet sie. Jede Sandbox habe eigene Ressourcen und einen eigenen Lebenszyklus, was Agenten laut Daytona unabhängig von der darunterliegenden Infrastruktur eine einheitliche Laufzeit biete.

Beim Tempo setzt Daytona nach eigenen Angaben darauf, Sandboxes bei Bedarf aus vorgewärmten Snapshot-Vorlagen bereitzustellen, statt einen ungenutzten Pool warmer Sandboxes vorzuhalten. Der Plattform zufolge dauert die Bereitstellung neuer Firecracker-microVMs weniger als 90 ms, wodurch interaktive Agenten-Workflows reaktionsschnell bleiben sollen.

Als Kundenbeispiel nennt Daytona Trajectory: Das Unternehmen spare monatlich mehr als 15 Stunden, die zuvor in das Zusammenbauen von Lösungen auf Kubernetes-Basis geflossen seien, und profitiere zudem von besser planbaren Infrastrukturabläufen. Diese Zahlen stammen aus Daytonas eigenem Beitrag.

Was das für Teams bedeutet, die Agenten entwickeln

Die Argumentation richtet sich an Entwicklungsteams, die Agenten bereits auf Kubernetes betreiben und Zeit in eigene Controller, Warm-Pools und Speicherschichten stecken. Daytonas Angebot lautet, dass eine dedizierte Laufzeitumgebung es diesen Teams erlaubt, sich auf das Verhalten der Agenten zu konzentrieren und neue Workflows schneller zu iterieren. Die Aussagen zu Leistung und Zeitersparnis stammen vom Unternehmen selbst, unabhängige Benchmarks enthält der zugrunde liegende Text nicht.