How OpenKruise Agents Enable Scalable AI Agent Sandboxes on Kubernetes

OpenKruise Agents (https://github.com/openkruise/agents) is an open‑source, container‑based infrastructure that provides secure, elastic sandbox environments for AI agents (AI Agents) in production.

Core Capabilities

Provides an E2B‑compatible agent‑apiserver exposing high‑level APIs such as create(), pause(), connect(), kill(), and run_code() for AI developers.

Manages the full sandbox lifecycle: creation from a template, pause, resume, and destroy.

Implements resource pooling and dynamic scaling to achieve sub‑second cold‑start times for sandbox instances.

Sandbox Lifecycle

A sandbox is created from a template (image, resources, optional checkpoint). The pod progresses through Pending → Running . When idle, it can be Paused (state saved with CRIU and Containerd snapshots). A Resume restores the sandbox to Running. Checkpoint and fork operations allow state duplication.

State Persistence

Checkpoint : captures both memory and filesystem layers, enabling instant restoration of a sandbox to a previous state. Useful for reinforcement‑learning (RL) where many parallel environments diverge from a common checkpoint.

Commit : persists only the filesystem layer, suitable for creating immutable images for downstream forks.

In RL training, after 1,000 steps a sandbox can be Commit ed to produce an image rl‑env‑checkpoint‑step1000 , which can then be forked into multiple new sandboxes for parallel policy exploration.

Integration Paths

For AI scientists and developers, the built‑in Agent‑APIServer can be called directly via the E2B protocol or the native Python SDK. For platform engineers, custom resources Sandbox CR and SandboxSet CRD enable declarative scaling, health‑checking, and automated resource reclamation.

Instance Management and Resource Pooling

Inactive sandboxes are paused using CRIU; snapshots are stored on cloud disks and restored on demand.

A pre‑warm pool, controlled by SandboxSet, maintains a configurable number of ready sandboxes. Elasticity rules (minAvailableRatio, maxAvailableRatio, cron‑based scaling) adjust pool size to workload patterns.

Sandbox creation can target Alibaba Cloud Container Service (ACK) pods or ACS Serverless Pods, providing elastic compute for bursty sessions and parallel RL training.

Practical Debugging Workflow Example

The agent invokes a large language model (LLM) to analyze the submitted code.

The code is executed inside an isolated sandbox, preventing destructive actions.

Historical code and review records are fetched (MCP‑style tool call) to understand the user's coding style.

A memory module retrieves past debugging interactions to maintain context.

The agent aggregates LLM analysis, sandbox execution results, and historical insights into a concrete debugging report with actionable suggestions.

User feedback is recorded to improve future model responses.

Security and Cost Controls

Data security: User code is isolated within the sandbox to prevent leakage.

Execution safety: Sandbox isolation mitigates risks from untrusted code (e.g., delete *).

Elastic compute: Rapid, second‑level scaling supports bursty agent workloads.

State persistence and cost control: Pause/resume and checkpoint mechanisms reduce resource waste for sandboxes that may remain idle for minutes to days.

Roadmap

Upcoming work includes advanced elastic scheduling, in‑place image updates, dynamic storage mounting, and expanded checkpoint/fork capabilities for large‑scale RL workloads.