GKE 上の Agent Sandbox について

Google Kubernetes Engine（GKE）の Agent Sandbox を使用すると、各サンドボックスを専用の Kubernetes Pod で実行することで、分離されたステートフルな単一レプリカ ワークロードを管理できます。この Pod ベースのアーキテクチャは、信頼できない LLM 生成コードを分離された環境で実行する必要がある AI エージェント ランタイムなどのユースケースをサポートします。

Agent Sandbox は、Kubernetes SIG Apps のオープンソース プロジェクトです。GKE で Agent Sandbox を使用するには、クラスタに Agent Sandbox コントローラをインストールします。コントローラのアップグレードはお客様の責任で行う必要があります。手順については、GKE に Agent Sandbox をインストールするをご覧ください。

このドキュメントでは、GKE の Agent Sandbox の概要について説明します。

Pod ベースのアーキテクチャとアクターベースのアーキテクチャのどちらかを選択する

GKE には、AI エージェント ワークロードをオーケストレートするための 2 つのアーキテクチャが用意されています。

  • GKE 上の Agent Substrate（アクターベース）: ほとんどのエージェント ワークロード、特に頻繁に一時停止と再開を行うステートフル エージェントには、このアーキテクチャを使用します。アクティブなエージェントは、エージェントごとに専用の Pod を保持するのではなく、ウォーム Pod のプールを共有するため、より少ないノードでより多くのエージェントを実行できます。GKE の Agent Substrate は、アイドル状態のワークロードを自動的に一時停止して再開します。システムは、アイドル状態のエージェントのメモリとファイルをストレージに保存し、1 秒未満でエージェントを復元します。一方、GKE の Agent Sandbox では、手動で Pod のスナップショットを作成する必要があります。また、非アクティブを検出してエージェントの進行状況を保存するアプリケーション コードをビルドする必要があります。GKE 上の Agent Substrate には、GKE Standard クラスタが必要です。詳細については、GKE の Agent Substrate についてをご覧ください。
  • GKE 上の Agent Sandbox（Pod ベース）: 各エージェントに GKE Autopilot クラスタまたは Standard クラスタ上の専用の Kubernetes Pod が必要な場合は、このアーキテクチャを使用します。継続的にアクティブなエージェントや、次のいずれかを必要とするワークロードには、このオプションを選択します。
    • 宣言型 Kubernetes API（Sandbox カスタム リソースや SandboxClaim カスタム リソースなど）
    • カスタム サイドカーと init コンテナを含む、完全な Kubernetes PodSpec スキーマ
    • GPU や TPU などのハードウェア アクセラレータへの直接アクセス
    • GKE Autopilot クラスタ

GKE で Agent Sandbox を使用する理由

GKE の Agent Sandbox は、高度なスケーリング、拡張性、セキュリティを必要とするエージェント ワークロード向けに構築されています。主な利点は次のとおりです。

  • カーネルレベルの分離: 信頼できない LLM 生成コードに対して、強力なカーネルレベルの分離を提供します。GKE の Agent Sandbox は、オープンソースの Kata Containers でも動作します。GKE で Agent Sandbox とオープンソースの Kata Containers を使用するチュートリアルについては、GKE で Kata Containers を有効にするをご覧ください。

  • 1 秒未満のプロビジョニング: 標準の Kubernetes Pod のスケジューリングと起動を待つのではなく、通常は 1 秒未満でウォームプールからサンドボックスを提供します。

  • クラウドネイティブな拡張性: Kubernetes パラダイムのパワーと GKE のマネージド インフラストラクチャを活用します。

GKE の Agent Sandbox は、宣言型の標準化された API を提供することで、仮想マシン（VM）と同様の分離特性と永続性特性を備えた単一コンテナ エクスペリエンスを提供します。これは、Kubernetes プリミティブのみで構築されています。

GKE 上の Agent Sandbox の一般的なユースケース

分離、永続性、安定した ID を必要とするワークロードには、GKE で Agent Sandbox を使用します。たとえば、次のような場合があります。

  • AI エージェント ランタイム: gVisor などのセキュリティ重視のランタイムによって分離された環境で、信頼できないコードを安全に実行します。
  • 開発環境: デベロッパーに、永続的で分離されたクラウドベースのコーディング環境を提供します。
  • ノートブックとリサーチツール: Jupyter Notebook などのインタラクティブ ツール用に、単一コンテナ セッションをホストします。
  • ステートフルな単一 Pod サービス: StatefulSet の複雑さを伴わずに、安定した ID とストレージを必要とするアプリケーションを実行します。
  • プログラムによる環境管理: Agent Sandbox Python SDK などの提供されているクライアント ライブラリ SDK を使用して、Kubernetes YAML を管理することなく、アプリケーション ロジックから直接サンドボックスをリクエストして管理します。

GKE での Agent Sandbox の仕組み

GKE の Agent Sandbox は、カスタム コントローラと複数の Kubernetes カスタム リソース定義（CRD）を使用して、サンドボックス環境のライフサイクルを管理します。

コア アーキテクチャ

  • Sandbox カスタム リソース: 単一のステートフル Pod を表すプライマリ リソース。このリソースは、安定したホスト名、ネットワーク ID、永続ストレージを管理します。
  • サンドボックス ルーター: 安定したエンドポイントを提供し、トラフィックを適切なサンドボックス Pod にトンネリングするコンポーネント。基盤となるネットワークの複雑さを抽象化します。
  • Pod スナップショットとの統合: GKE の Agent Sandbox は GKE Pod スナップショット機能と統合されており、コンテナの完全な状態を保存して復元することで、ワークロードの一時停止と再開を可能にします。

申し立てモデル

クレームモデルは、ユーザーの環境リクエストを、ワークロードのプロビジョニング場所や方法などの特定の実施の詳細から分離する重要な機能です。標準の Kubernetes StatefulSet とは異なり、クレームモデルを使用すると、基盤となる Pod やストレージ構成を直接管理することなく、サンドボックスをリクエストできます。

クレームモデルは、SandboxClaim、SandboxWarmPool、SandboxTemplate のカスタム リソースを使用し、次のように動作します。

  1. ユーザーまたはアプリケーションは、SandboxWarmPool リソースを参照する SandboxClaim リソースを作成して、サンドボックスをリクエストします。ウォームプールは、サンドボックス構成を定義する SandboxTemplate リソースを参照します。
  2. コントローラは、ウォームプールから準備完了のサンドボックスをクレームに割り当てます。プール内のサンドボックスが準備できていない場合、コントローラはテンプレートからクレーム用の新しいサンドボックスを作成します。

ウォームプール

ウォームプール機能は、インタラクティブな AI エージェント シナリオの起動レイテンシを最小限に抑えるように設計されています。ウォームプールを使用することで、GKE の Agent Sandbox は 1 秒未満で実行環境を提供できます。この機能は SandboxWarmPool カスタム リソースを使用し、次のように動作します。

  1. SandboxWarmPool リソースは、事前にウォームアップされた Pod インスタンスのセットを準備完了状態で維持します。
  2. SandboxClaim リソースが作成されると、コントローラは、新しい Pod がイメージを pull して最初から起動するのを待つのではなく、プールから準備完了の Pod を割り当てます。
  3. Pod スナップショットと組み合わせると、ウォームプールは Pod を最初から起動するのではなく、事前構成された状態から復元できます。

ネットワーク分離

GKE の Agent Sandbox は、SandboxTemplate リソースから作成するサンドボックスにデフォルト拒否のネットワーク セキュリティ ポスチャーを実装します。コントローラは、SandboxTemplate リソースごとに NetworkPolicy リソースを作成します。これにより、サンドボックス内で実行される信頼できないコードが、デフォルトで未承認の内部ネットワークや GKE コントロール プレーンにアクセスできないようにします。SandboxTemplate リソース内で特定のネットワーク制限と許可された下り（外向き）ルールまたは上り（内向き）ルールを定義して、エージェント ワークロードにきめ細かいセキュリティを提供できます。

コントローラは、直接作成した Sandbox リソースの NetworkPolicy リソースを作成しません。これらのサンドボックスのネットワーク アクセスを制限するには、独自の NetworkPolicy リソースを作成します。

SDK を使用したプログラムによるアクセス

AI エンジニアは、提供されているクライアント ライブラリを使用して、GKE リソースで Agent Sandbox をプログラムで使用できます。たとえば、Python SDK には、基盤となる SandboxClaim リソースを作成する高レベルのインターフェースが用意されています。このクレームは、作成した SandboxWarmPool リソースを参照します。このインターフェースを使用すると、LangChain や Vertex AI Agentic SDK などの Python ベースの AI エージェント フレームワークから、分離された環境を直接作成して操作できます。

制限事項と要件

GKE 上の Agent Sandbox には、次の制限事項と要件があります。

  • クラスタ バージョン: GKE の Agent Sandbox は、サポートされている任意の GKE バージョンで実行されます。Pod スナップショットを使用するには、クラスタで GKE バージョン 1.35.3-gke.1234000 以降を実行する必要があります。
  • インフラストラクチャの要件: Agent Sandbox コントローラがクラスタにインストールされ、構成されている必要があります。GKE の Agent Sandbox には、特定のマシンタイプは必要ありません。たとえば、インストール ガイドでは e2-standard-2 ノードを使用します。ただし、Pod スナップショットは E2 マシンタイプをサポートしていません。Pod スナップショットを使用する場合は、N2 などの別のマシンシリーズを使用してください。
  • 分離ランタイム: GKE の Agent Sandbox は、分離ランタイムとして gVisor と microVMs をサポートしています。Pod スナップショットには gVisor が必要で、マイクロ VM では動作しません。サンドボックス ランタイムを指定しない場合、サンドボックスはカーネル分離なしで実行されます。これは、信頼できないコードにはおすすめしません。
  • 基盤となる機能の可用性: GKE Pod スナップショットなど、基盤となる機能の一部はプレビュー版であるか、特定のリージョンでのみ利用可能な場合があります。

次のステップ