kubernetes-sigs/agent-sandbox

What it is

Agent Sandbox is a Kubernetes SIG Apps project that adds a new custom resource – Sandbox – plus optional extensions. A Sandbox represents a single, stateful pod with a stable hostname, persistent storage and lifecycle controls (pause, resume, delete). The controller watches these CRs and creates the underlying pod, optionally using a hardened runtime such as gVisor or Kata Containers. Extensions add templating, warm‑pool pre‑warming, and claim‑based allocation.

Why it matters for AI/ML workloads

Many emerging AI workloads (LLM‑generated code, reinforcement‑learning loops, Jupyter notebooks, evaluation sandboxes) need an isolated, long‑running container that can be started quickly, kept alive across restarts, and run untrusted code safely. A plain Deployment or a size‑1 StatefulSet can approximate this, but they lack built‑in isolation, hibernation, and fast‑warm‑pool semantics. Agent Sandbox provides a declarative API that fits naturally into existing CI/CD and GitOps pipelines while giving you:

• Strong isolation – you can bind the pod to a RuntimeClass that uses gVisor, Kata, etc.
• Stable identity & networking – each sandbox gets a permanent hostname and Service‑like address.
• Persistent storage – PVCs survive pod restarts or hibernation.
• Warm‑pool provisioning – pre‑create sandboxes so claimers get an instant ready‑to‑run environment, which is valuable for high‑throughput RL training or evaluation.

These features let AI teams run many short‑lived, untrusted jobs at scale without sacrificing security or the convenience of Kubernetes.

How you would use it

1. Install the controller and CRDs (single kubectl apply -f …sandbox-with-extensions.yaml or separate core/extension manifests). Optionally install the optional Sandbox Router for HTTP routing.
2. Create a Sandbox (or a SandboxClaim that pulls from a warm pool) with a YAML that includes the pod spec you want to run.
3. The controller creates a pod that uses the chosen RuntimeClass (e.g., kata) and attaches any PVCs you defined.
4. Access the sandbox via its stable hostname (my‑sandbox) or through the Sandbox Router SDKs (Go/Python) which expose a client library for programmatic creation, claim, and lifecycle actions.
5. When finished, delete the Sandbox or let the controller hibernate it; the state is persisted for later resume.

Who should care

• AI platform engineers building services that need to run untrusted LLM‑generated code or RL agents safely.
• Data scientists who want reproducible, persistent notebook environments managed via GitOps.
• Kubernetes operators looking for a lightweight alternative to full VMs for single‑container workloads that still need strong isolation.
• Developers of CI/CD pipelines that need fast, isolated execution environments for each job.

Maturity & activity

• First stable release v1.0.2 (as of the README) – versioned CRDs and controller.
• Provides Go and Python SDKs for programmatic interaction.
• Active SIG Apps community, contribution guidelines, and a public roadmap.
• Security model documented (threat model, isolation via RuntimeClass).

Quick start snippet

# Install core + extensions
kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/latest/download/sandbox-with-extensions.yaml

# Create a sandbox
cat <<EOF | kubectl apply -f -
apiVersion: agents.x-k8s.io/v1beta1
kind: Sandbox
metadata:
  name: my-sandbox
spec:
  podTemplate:
    spec:
      containers:
      - name: app
        image: python:3.11-slim
        command: ["python", "-m", "http.server", "8080"]
EOF

# Verify
kubectl get sandbox my-sandbox -o yaml

Bottom line

Agent Sandbox is a genuine, production‑grade Kubernetes extension that fills a niche between stateless Deployments and full VMs. Its focus on isolated, stateful, singleton workloads makes it a natural fit for modern AI/ML workloads that need secure, quickly‑available execution environments.