GKE Agent Sandbox について

Google Kubernetes Engine（GKE）Agent Sandbox を使用すると、GKE 上で分離されたステートフルな単一レプリカ ワークロードを管理できます。これは、信頼できない LLM 生成コードを安全でパフォーマンスの高い環境で実行する必要がある AI エージェント ランタイムなどのユースケース向けに最適化されています。

GKE Agent Sandbox アドオンは、オープンソースの Agent Sandbox コントローラ プロジェクトに基づいており、そのリリース サイクルに沿っています。マネージド GKE アドオンとして、Google は自動アップグレードやセキュリティ パッチなど、コントローラのライフサイクル全体を管理します。

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

GKE Agent Sandbox を使用する理由

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

  • カーネルレベルの分離: GKE Sandbox などの組み込みの GKE 機能を使用して、信頼できない LLM 生成コードに対して強力なカーネルレベルの分離を提供します。Agent Sandbox は、オープンソースの Kata Containers ソフトウェアもサポートしています。

  • 1 秒未満のプロビジョニング: 標準の Kubernetes Pod スケジューリングよりも大幅に高速にサンドボックスを提供するメカニズムをすぐに利用できます（通常は 1 秒未満）。

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

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

エージェント サンドボックスの一般的なユースケース

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

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

GKE Agent Sandbox の仕組み

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

コア アーキテクチャ

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

クレーム モデル

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

Claim Model は SandboxClaim CRD と SandboxTemplate CRD を使用して管理され、次のように動作します。

  1. ユーザーまたはアプリケーションは、SandboxTemplate を参照する SandboxClaim を作成して、サンドボックスをリクエストします。
  2. コントローラは、クレームから実際の Sandbox インスタンスへのマッピングを処理し、柔軟なバックエンド管理を実現します。これにより、システムは既存のサンドボックスを再利用するか、プールから割り当てることができます。

Warm プール

ウォーム プール機能は、インタラクティブ AI エージェントのシナリオで重要な起動レイテンシを最小限に抑えるように設計されています。この機能により、Agent Sandbox は 1 秒未満で実行環境を提供できます。これは、一般的な Pod スケジューリングよりも大幅に高速です。この機能は SandboxWarmPool CRD を使用して管理され、次のように動作します。

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

ネットワーク分離

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

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

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

制限事項と要件

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

  • クラスタ バージョン: スナップショットを含むすべての機能をサポートするには、GKE バージョン 1.35.2-gke.1269000 以降が必要です。
  • インフラストラクチャ要件: 特定のノード構成（N2 マシンタイプなど）用に最適化されており、クラスタに Agent Sandbox コントローラをインストールして構成する必要があります。
  • 分離ランタイム: 複数のランタイムをサポートしていますが、主に gVisor などのセキュリティ強化ランタイムで使用することを目的としています。
  • 基盤となる機能の可用性: GKE Pod スナップショットなどの基盤となる機能の一部は、プレビュー版であるか、特定の地域でのみ利用可能である可能性があります。

次のステップ