AI
Why Standard Kubernetes Pods Cannot Run Agent Sandboxes
AI agents that debug and run user code face three problems that Kubernetes pods do not solve on their own. First, user code is an asset and must stay isolated — malicious prompts can generate harmful code like destructive commands or host-escape attempts. Second, every tool call spawns its own sandbox, so agent counts grow exponentially. Third, sandbox lifetimes range from minutes to days, and keeping them running while agents wait for input burns money. These three constraints drove the OpenKruise Agent design.
OpenKruise Agent: A Higher-Level Sandbox Abstraction
OpenKruise Agent adds a custom resource called Sandbox to Kubernetes. It does not replace pods. It extends pod lifecycle with checkpoint, restore, pause, and resume. The project started in 2019, comes out of Alibaba’s large-scale container practice, and is widely used in the community. The first open-source version supports four lifecycle states: pending, running, paused, and complete. Two integration paths are available: the E2B SDK for AI scientists who want to skip Kubernetes details, and standard custom resources (SandboxClaim, SandboxSet) for platform engineers.
Session-Aware MCP and the Sandbox Gateway
The MCP API surface hides sandbox IDs entirely and exposes sessions instead. Each new user gets a session. When the session expires, the controller cleans up the underlying sandbox automatically. Tools exposed over MCP include code running, command running, and file operations. A sandbox gateway, powered by Envoy filters, sits in front of all sandboxes and enforces network policy so that only traffic routed through the gateway reaches a container. The gateway resolves sandbox IDs directly to IP addresses with no service mesh overhead.
Warm Pools: From 200 ms Cold Starts to 20 ms Assignments
Kata Containers give each sandbox its own kernel, so booting one takes time. Even Firecracker micro-VMs cannot break the 200-millisecond barrier for pod creation. A warm pool of pre-started sandboxes solves this. Load tests at 2,000-sandbox pool size hit an average assignment latency of 20 milliseconds and handled roughly 50,000 sandbox claim operations per second, creating around 10,000 sandboxes. In-place image updates let a small pool serve requests that need different container images. Dynamic storage mounting handles different NAS or object storage requirements at claim time.
Pause, Resume, and Checkpoint for Cost and Safety
When a sandbox goes idle, the controller deletes the pod and persists its state, including the memory filesystem, to shared storage. On resume, it restores from that snapshot. The idle OpenClaw agent use case shows the payoff: without this, an idle agent eats CPU continuously. With auto-suspend, cost drops to near zero between user prompts. Checkpoint goes further, snapshotting root filesystem and memory so a sandbox can branch into multiple training paths or roll back after a failed upgrade. A corresponding custom resource controls whether the sandbox keeps running after the checkpoint completes.
Notable Quotes
attacker could generate and run malicious code like delete or try to break down to the host and do another uh bad stuff. Mingshan Zhao · ▶ 03:05
even the most uh efficient micro VM such as uh firecracker just doesn’t doesn’t have enough speed to cross the boundary of like 200 milliseconds of this uh port generation. Zhen Zhang · ▶ 23:57
with the sandbox uh samples warm pool actuallying our our load test uh we can reach for uh like average latency of 20 milliseconds uh which is which is very crucial for our for for the agent serving uh use cases. Zhen Zhang · ▶ 24:13
can just sit idle and just eat all your CPU CPU resources so in this case when the open core is is is idle we can just automatically suspend the symbol boxes Zhen Zhang · ▶ 20:07
Key Takeaways
- Kata Container cold starts exceed 200 ms; a warm pool cuts assignment latency to 20 ms.
- MCP sessions abstract sandbox IDs, so cleanup is automatic when a session expires.
- Pause and resume delete the pod but persist memory state, cutting idle compute cost to near zero.
About the Speaker(s)
Mingshan Zhao is a Senior R&D Engineer at Alibaba Cloud and a maintainer of the OpenKruise community. He has worked on cloud native, containers, and scheduling, and is a core member of Alibaba’s one-million-container scheduling system.
Zhen Zhang is a Staff Engineer at Alibaba Group driving cloud native innovation with a focus on application management. He is one of the main maintainers of the OpenKruise project, which started in 2019 and grew out of Alibaba’s large-scale container operations.