Kubernetes Agent Sandboxはstateful singletonをSandbox CRDにする
Kubernetes SIG AppsのAgent Sandboxは、AIエージェントのような長寿命・stateful・singletonなworkloadを扱うための専用APIを提供するプロジェクトである。
通常のPodやDeploymentは、stateless serviceやreplicated workloadを前提に使われることが多い。一方、agent execution environmentは次のような性質を持つ。
- 1つのworkspaceを長時間保持する
- 数時間idleになることがある
- 外部toolやcode executionを使う
- suspend/resumeしたい
- userやtask単位で1つの環境を割り当てたい
Agent Sandboxはこの差を埋めるため、Sandbox CRDを中心にしたAPIを導入する。
2026年の実装では、gVisorやKata ContainersのようなRuntimeClassを選べるため、Agent Sandbox自身が新しい低レベルsandbox技術というより、sandbox lifecycleをKubernetes上で標準化するcontrol-plane abstractionと見る方が正確である。
さらにextensionsとして、次のprimitiveがある。
SandboxTemplate: sandboxのtemplateSandboxWarmPool: 起動済みsandboxを事前に用意するpoolSandboxClaim: poolからsandboxを払い出してもらうclaim
2026年8月時点ではこれらのAPIはv1beta1へ移行している。WarmPoolではpre-warmed Podを保持し、Claim作成時に既存Podをadoptすることでcold startを避ける。公式quickstartでは、WarmPool利用時のallocationをsub-2 second、poolなしを10–30 secondsと例示しているが、この値は環境依存の参考値として扱うべきである。
この設計の重要な点は、security boundaryとlifecycle abstractionを分離していることにある。
例えば同じSandbox APIでも、RuntimeClassを変えることで gVisorはユーザー空間カーネルでhost kernel syscall面を減らす や Kata Containers 4.0はOCI UXのままVM境界を使う を下層に置ける。上位側は「sandboxを確保する、使う、suspendする、捨てる」といったlifecycleだけを見ることができる。
大量の短命sandboxだけでなく、長時間保持するagent workspaceを扱うplatformでは、このような抽象化が今後重要になりそうである。
隔離方式そのものの比較は Linuxサンドボックスの隔離境界をどう捉えるか を参照。