From bf1d104c4982232d9d1297b1adae0af2fff4243c Mon Sep 17 00:00:00 2001 From: rkoster Date: Thu, 2 Jul 2026 12:13:35 +0200 Subject: [PATCH 1/2] Add research note: Kubernetes Agent Sandbox (k8s-sigs) --- research/k8s-agent-sandbox.md | 48 +++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 research/k8s-agent-sandbox.md diff --git a/research/k8s-agent-sandbox.md b/research/k8s-agent-sandbox.md new file mode 100644 index 0000000..0b53dff --- /dev/null +++ b/research/k8s-agent-sandbox.md @@ -0,0 +1,48 @@ +--- +title: "Kubernetes Agent Sandbox (k8s-sigs)" +author: Ruben Koster (@rkoster) +date: 2026-07-02 +tags: [sandboxing-isolation, runtime-lifecycle, ecosystem-survey] +cf_areas: [diego, garden-runc] +status: draft +sources: + - https://github.com/kubernetes-sigs/agent-sandbox +--- + +## Summary + +A Kubernetes SIG project providing a native sandbox control plane for AI agents. It offers +stable identity, persistence, and warm pools for agent workloads running on Kubernetes +clusters. It represents the cloud-native community's answer to "how should container +orchestrators support AI agent execution?" + +## Key findings + +- **K8s-native CRDs**: Defines Kubernetes custom resources for agent sandboxes — declarative + specification of agent execution environments. +- **Stable identity**: Each agent sandbox gets a persistent identity (analogous to StatefulSet + pod identity) that survives restarts. Critical for agents that need consistent credentials + and state references. +- **Warm pools**: Pre-provisioned sandbox instances ready for immediate use, eliminating + cold-start latency. Pool size managed declaratively. +- **Persistence**: Sandbox state persists across executions. Agents can resume work without + rebuilding context from scratch. +- **Control plane separation**: The sandbox control plane manages lifecycle independently + from the workload orchestrator — sandboxes are managed resources, not just pods. + +## CF relevance + +The project shows how the cloud-native community is extending a general-purpose container +orchestrator with agent-specific primitives. Stable sandbox identity maps to workload +identity patterns (e.g., SPIFFE/SVIDs). Warm pools address the cold-start latency problem +that affects interactive agent workloads. The control-plane-separated architecture — a +sandbox controller alongside the scheduler — is one model for how a platform could add agent +lifecycle management without replacing its core scheduling layer. + +## Open questions + +- What is the warm pool implementation — pre-created pods, or paused containers? +- How does stable identity interact with horizontal scaling (multiple instances of the same + agent)? +- What persistence backend does it use (PVCs, external stores)? +- How does the project handle multi-tenancy? From 02b952cfee0a6f18a37a5ba95cd977c279d70567 Mon Sep 17 00:00:00 2001 From: rkoster Date: Thu, 2 Jul 2026 12:39:08 +0200 Subject: [PATCH 2/2] Expand k8s-agent-sandbox note: answer open questions from upstream research --- research/k8s-agent-sandbox.md | 59 ++++++++++++++++++++++------------- 1 file changed, 38 insertions(+), 21 deletions(-) diff --git a/research/k8s-agent-sandbox.md b/research/k8s-agent-sandbox.md index 0b53dff..536737d 100644 --- a/research/k8s-agent-sandbox.md +++ b/research/k8s-agent-sandbox.md @@ -7,6 +7,7 @@ cf_areas: [diego, garden-runc] status: draft sources: - https://github.com/kubernetes-sigs/agent-sandbox + - https://agent-sandbox.sigs.k8s.io/docs --- ## Summary @@ -18,31 +19,47 @@ orchestrators support AI agent execution?" ## Key findings -- **K8s-native CRDs**: Defines Kubernetes custom resources for agent sandboxes — declarative - specification of agent execution environments. -- **Stable identity**: Each agent sandbox gets a persistent identity (analogous to StatefulSet - pod identity) that survives restarts. Critical for agents that need consistent credentials - and state references. -- **Warm pools**: Pre-provisioned sandbox instances ready for immediate use, eliminating - cold-start latency. Pool size managed declaratively. -- **Persistence**: Sandbox state persists across executions. Agents can resume work without - rebuilding context from scratch. -- **Control plane separation**: The sandbox control plane manages lifecycle independently - from the workload orchestrator — sandboxes are managed resources, not just pods. +- **K8s-native CRDs**: Core `Sandbox` CRD plus three extensions — `SandboxTemplate` + (reusable runtime config), `SandboxClaim` (user-facing allocation abstraction), and + `SandboxWarmPool` (pre-warmed pools). Together these give a declarative API without + hand-stitching StatefulSets, Services, and PVCs. +- **Stable identity — singleton model**: Each Sandbox has a stable hostname and network + identity. Sandboxes are explicitly *singleton* (one pod per object), designed for + workloads that don't fit the replicated model of Deployments or the numbered model of + StatefulSets. Horizontal "scaling" means creating multiple independent Sandbox objects, + each with its own identity — not replicas sharing one. +- **Warm pools — pre-created running pods**: `SandboxWarmPool` maintains a pool of fully + provisioned, running pods ready to be claimed in milliseconds. Pods are pre-created and + live (not paused or frozen), then adopted by a `SandboxClaim` on demand. Pool size is + managed declaratively. +- **Persistence via PVCs**: Persistent storage uses standard Kubernetes + `volumeClaimTemplates` — identical semantics to StatefulSet. Each Sandbox gets its own + dynamically provisioned PVC backed by the cluster's StorageClass. GKE clusters running + gVisor additionally support pod snapshots: full memory-state freeze to persistent storage + for cost-efficient suspend/resume between agent turns. +- **Multi-tenancy via K8s primitives**: Standard K8s RBAC, namespaces, network policies, + and resource quotas apply as usual. Isolation depth is a runtime choice: gVisor for + kernel-level sandboxing, or Kata Containers for VM-grade isolation with a dedicated + kernel per sandbox. The API is decoupled from the isolation mechanism. +- **Lifecycle management**: The controller handles creation, scheduled deletion, + hibernation (pause to free compute), and automatic resume on incoming network activity — + sandboxes are managed resources, not just pods. ## CF relevance The project shows how the cloud-native community is extending a general-purpose container -orchestrator with agent-specific primitives. Stable sandbox identity maps to workload -identity patterns (e.g., SPIFFE/SVIDs). Warm pools address the cold-start latency problem -that affects interactive agent workloads. The control-plane-separated architecture — a -sandbox controller alongside the scheduler — is one model for how a platform could add agent -lifecycle management without replacing its core scheduling layer. +orchestrator with agent-specific primitives. The singleton + stable-identity model contrasts +with the replicated-stateless model that most PaaS platforms optimize for. Warm pools +(pre-created pods assigned on claim) are a concrete answer to cold-start latency for +interactive agent workloads. The multi-tenancy model — standard K8s RBAC plus pluggable +runtime isolation — separates policy enforcement from isolation mechanism, treating isolation +depth as a deployment choice rather than a fixed platform guarantee. ## Open questions -- What is the warm pool implementation — pre-created pods, or paused containers? -- How does stable identity interact with horizontal scaling (multiple instances of the same - agent)? -- What persistence backend does it use (PVCs, external stores)? -- How does the project handle multi-tenancy? +- Can warm pool pods be pre-loaded with large model artifacts or dependency caches, or does + storage provisioning happen separately from pod pre-warming? +- How does scheduling work on mixed-runtime clusters (some nodes with gVisor, others with + Kata Containers) — is runtime selection per Sandbox spec or per namespace? +- What is the story for direct agent-to-agent communication across Sandboxes within a + namespace — direct pod networking, or routed through a service?