# Running Agents on Kubernetes with Agent Sandbox Kubernetes 公式ブログの記事。SIG Apps 主導で開発中の新プロジェクト [[Agent Sandbox]](`kubernetes-sigs/agent-sandbox`)を紹介する。AI エージェントという新しいワークロードの性質が既存の Kubernetes プリミティブとどう噛み合わないかを整理したうえで、それを埋めるための宣言的 API を提案する導入記事である。(Source: 本ページ) ## 背景: AIワークロードの世代交代 生成 AI との対話は当初、50 ミリ秒程度で起動・実行・終了するステートレスな関数呼び出しとして扱われていた。現在は「AI v2 が AI v1 を食う」形で、複数のエージェントが協調しながら常時稼働し、文脈を維持し、外部ツールを使い、コードを書いて実行し、互いに通信するという長時間稼働のパターンへ移行している。プラットフォームエンジニアリングチームがこの新しい AI ワークロードのホスト基盤を探すとき、[[Kubernetes]] が自然な選択肢として浮上する一方、これらのユニークなエージェントワークロードを既存の Kubernetes プリミティブへ写像するには新しい抽象化が必要になる。(Source: 本ページ) ## Kubernetesの強みと抽象化のギャップ Kubernetes がクラウドネイティブアプリケーションのオーケストレーションのデファクトスタンダードである理由は、拡張性・堅牢なネットワーキング・成熟したエコシステムを解決している点にある。しかし AI が短命な推論リクエストから長命で自律的なエージェントへ進化するにつれ、新しい運用パターンが立ち現れている。AI エージェントは典型的には**孤立・ステートフル・シングルトン**なワークロードであり、LLM のためのデジタルワークスペースまたは実行環境として振る舞う。エージェントは永続的なアイデンティティと、(しばしば未信頼な)コードを書いて実行するためのセキュアなスクラッチパッドを必要とする。決定的に重要な点として、これらの長命エージェントは短いバースト活動の合間はほとんどアイドル状態であることが期待されるため、サスペンドと高速再開のようなメカニズムをサポートするライフサイクルを必要とする。理論上は StatefulSet(サイズ1)・headless Service・PersistentVolumeClaim を エージェントごとに組み合わせることでこれを近似できるが、大規模に運用すると運用上の悪夢になる。(Source: 本ページ) ## Kubernetes Agent Sandboxの紹介 このギャップを埋めるため、SIG Apps は [[Agent Sandbox]](`kubernetes-sigs/agent-sandbox`)を開発している。このプロジェクトは、AI エージェントランタイムのようなシングルトン・ステートフルワークロード向けに特化して調整された、宣言的で標準化された API を導入する。中核にあるのは **Sandbox CRD** であり、Kubernetes プリミティブのみで構築された軽量・単一コンテナ環境として、以下を提供する。(Source: 本ページ) - **未信頼コード実行のための強い隔離**: AI エージェントが自律的にコードを生成・実行する場合、セキュリティが最重要となる。Sandbox カスタムリソースは [[gVisor]] や [[Kata Containers]] のような異なるランタイムをネイティブにサポートし、マルチテナントかつ未信頼な実行に必要なカーネル・ネットワーク隔離を提供する。 - **ライフサイクル管理**: 定常的なステートレストラフィック向けに最適化された従来の Web サーバとは異なり、AI エージェントはタスク間で数時間アイドルになりうるステートフルなワークスペースとして動作する。Agent Sandbox はこうしたアイドル環境をゼロへスケールしてリソースを節約しつつ、中断した箇所から正確に再開できることを保証する。 - **安定したアイデンティティ**: 協調するマルチエージェントシステムは安定したネットワーキングを必要とする。各 Sandbox には安定したホスト名とネットワークアイデンティティが与えられ、異なるエージェント同士がシームレスに互いを発見・通信できる。 ## Extensionsによるスケーリング AI 領域の変化が非常に速いため、Agent Sandbox はさらに高速な反復・開発を可能にする Extensions API 層を備えて構築されている。Pod の新規起動は約1秒のオーバーヘッドを追加する。マイクロサービスの新バージョンをデプロイする分には全く問題ないが、アイドル状態から再起動されたエージェントにとって、1秒のコールドスタートは対話の連続性を壊す。ユーザまたはオーケストレーションサービスは、モデルが思考・行動を開始する前に環境のプロビジョニングを待たされることになる。**SandboxWarmPool** はこの問題を、事前プロビジョニング済みの Sandbox Pod のプールを維持することで解決し、コールドスタートを事実上排除する。ユーザまたはオーケストレーションサービスは `SandboxTemplate` に対して `SandboxClaim` を発行するだけでよく、コントローラは事前ウォームアップ済みの完全に隔離された環境を即座にエージェントへ引き渡す。(Source: 本ページ) ## クイックスタート Agent Sandbox のコアコンポーネントと拡張機能は、[GitHub リリース](https://github.com/kubernetes-sigs/agent-sandbox/releases)のマニフェストから任意の学習・サンドボックスクラスタへ直接インストールできる。プロジェクトは急速に進化しているため最新リリースの利用が推奨される。 ```bash export VERSION="vX.Y.Z" # コアコンポーネントのインストール kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/${VERSION}/manifest.yaml # 拡張コンポーネントのインストール(任意) kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/${VERSION}/extensions.yaml # Python SDKのインストール(任意) python3 -m venv .venv source .venv/bin/activate pip install k8s-agent-sandbox ``` インストール後は AI エージェント向けの Python SDK や、[example 集](https://github.com/kubernetes-sigs/agent-sandbox/tree/main/examples)を用いて、隔離されたエージェント環境を立ち上げる体験を試せる。(Source: 本ページ) ## エージェントの未来はクラウドネイティブである 50 ミリ秒のステートレスなタスクであれ、数週間にわたるほとんどアイドルな協調プロセスであれ、孤立したステートフルなシングルトン向けに特化して設計されたプリミティブで Kubernetes を拡張することで、クラウドネイティブエコシステムの堅牢な恩恵をすべて活用できる。Agent Sandbox はオープンソースかつコミュニティ主導のプロジェクトであり、Kubernetes Slack の `#sig-apps` および `#agent-sandbox` チャンネルで議論に参加できる。(Source: 本ページ) ## 関連 - エンティティ: [[Agent Sandbox]] / [[Kubernetes]] / [[gVisor]] / [[Kata Containers]] / [[LeaderWorkerSet]] / [[Agent Substrate]](対照的な非 Kubernetes 解)