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 は、高度なスケーリング、拡張性、セキュリティを必要とするエージェント ワークロード向けに構築されています。主な特典は次のとおりです。

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

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

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

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

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

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

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

GKE Agent Sandbox の仕組み

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

コア アーキテクチャ

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

クレームモデル

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

クレームモデルは SandboxClaimと SandboxTemplate CRD を使用して管理され、次のように動作します。

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

ウォームプール

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

  1. SandboxWarmPool は、事前ウォーミングされた Pod インスタンスのセットを準備完了状態で維持します。
  2. SandboxClaim が作成されると、コントローラは新しい Pod がイメージをプルして最初から起動するのを待つのではなく、プールから 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 スナップショットなど、一部の基盤となる機能はプレビュー版であるか、特定のリージョンでのみ利用可能である可能性があります。

次のステップ