Google Kubernetes Engine（GKE）には、カーネル分離サンドボックス内で AI エージェントを実行するための 2 つのオーケストレーション モデルが用意されています（Cloud Hypervisor マイクロ VM または gVisor を使用）。
- GKE の Agent Substrate（アクターベース、推奨）: ほとんどの AI エージェント ワークロード（特に、頻繁に一時停止と再開を行うステートフルな CPU ベースのエージェント）にこのモデルを使用します。アクティブなエージェント セッション（アクター）は、ウォーム ワーカー Pod のプールを共有し、1 秒未満で Cloud Storage から復元できます。
- GKE 上の Agent Sandbox（Pod ベース）: 各エージェントに専用の Kubernetes Pod が必要な場合は、このモデルを使用します。継続的にアクティブなエージェントや、完全な Kubernetes PodSpec（サイドカーなど）、GPU または TPU、Arm ノード、GKE Autopilot クラスタを必要とするワークロードの場合は、このオプションを選択します。
2 つのオーケストレーション モデルの比較については、Agent Substrate と Agent Sandbox の比較をご覧ください。
このドキュメントでは、GKE クラスタをプロビジョニングする前に、オーケストレーション モデル、サンドボックス ランタイム、分離制御、ストレージ オプションを選択する方法について説明します。このドキュメントは、GKE で AI エージェントの実行環境を設計するソリューション アーキテクト、AI デベロッパー、プラットフォーム管理者、オペレーターを対象としています。
GKE での AI エージェント ワークロードのアーキテクチャ要件
GKE で AI エージェント ワークロードを実行すると、分離されたエージェント実行環境を、サポートする Kubernetes Service と同じクラスタとネットワーク境界に配置し、GKE を使用してノードの自動プロビジョニング、バースト スケーリング、ライフサイクル管理を行うことができます。
継続的にアクティブなマイクロサービスとは異なり、AI エージェント ワークロードには次のアーキテクチャ要件があります。
- 信頼できないコード実行: コードやシェルコマンドを生成して実行するエージェントには、セッション間でカーネル、認証情報、ネットワークの分離が必要です。どちらのオーケストレーション モデルも、microVM または gVisor を使用してエージェント セッションをホストカーネルから分離し、Agent Substrate の認証情報とネットワーク下り（外向き）または Agent Sandbox の認証情報とネットワーク ポリシーを制限できます。
- 高いアイドル率: インタラクティブなコーディング支援アシスタントとバックグラウンドの生産性エージェントは、ライフサイクルのほとんどを人間の入力、モデルの推論、ツールのレスポンスを待つことに費やします。Agent Substrate と Agent Sandbox の両方で、アクティブなエージェントは、アプリケーションが一時停止するまでコンピューティング リソースを保持します。
- 環境の急速なチャーン: エージェント プラットフォームは、多数の環境を頻繁に作成、一時停止、再開、停止します。Agent Substrate の WorkerPool Pod や Agent Sandbox の SandboxWarmPool Pod のバーストに備えてノード容量を確保するには、GKE のカスタム ComputeClass を使用してノードを自動プロビジョニングし、容量バッファを使用してスタンバイ容量を予約します。
- 高速な状態の一時停止と再開: ステートフル エージェントは、環境をゼロから再構築することなく、ワーキング メモリ（RAM）とワークスペース ファイルのチェックポイントを作成して復元する必要があります。GKE は、Cloud Storage、Filestore、Google Cloud Hyperdisk と統合されており、Agent Substrate のセッション チェックポイントとワークスペース ストレージ、Agent Sandbox の Pod スナップショットと永続ストレージをサポートしています。
アクターベースのモデル: GKE 上の Agent Substrate（推奨）
GKE の Agent Substrate は、エージェント セッション（アクター）を基盤となる Kubernetes Pod から切り離す実行ランタイムです。アクティブなアクターは、アクター テンプレート（ActorTemplate リソース）間で、事前にウォームアップされたワーカー Pod（WorkerPool リソース）のプールを共有します。アプリケーションがアイドル状態のアクターを一時停止すると、Agent Substrate はアクターの状態を Cloud Storage にチェックポイントし、ワーカー容量を解放して、他のアクターがノードを使用できるようにします。新しいリクエストが届くと、Agent Substrate は 1 秒未満でアクターを使用可能なワーカーに復元します。
次のようなユースケースを含む、CPU ベースのエージェント ワークロードのデフォルト アーキテクチャとして Agent Substrate を使用します。
- インタラクティブなコーディング エージェント: 開発者との会話中にターミナル コマンドの実行、コードのビルド、ファイルの編集を行い、プロンプト間で一時停止する AI アシスタント。
- 長時間実行される生産性エージェント: 数日から数週間にわたってコンテキストを維持し、ほとんどの時間をユーザー入力や外部トリガーの待機に費やすバックグラウンド アシスタント。
- エフェメラル コードとブラウザ サンドボックス: LLM 生成コード、ヘッドレス ブラウザ、ツール呼び出しを実行するためのオンデマンド環境。1 秒未満で復元され、実行後にコンピューティングを解放します。
Agent Substrate には、x86 CPU ワーカーノードを備えた GKE Standard クラスタ（コントロール プレーンとノードプールの両方でバージョン 1.37 以降）が必要です。GKE Autopilot はサポートされていません。Agent Substrate ノード エージェント（atelet）が特権 DaemonSet として実行され、microVM ワーカープールにはネストされた仮想化またはベアメタル ノードが必要なためです。GPU と TPU はサポートされていません。
ID、認証情報、ネットワーク下り（外向き）
Agent Substrate は、各アクターに一意の SPIFFE X.509 証明書と JSON ウェブトークン（JWT）をプロビジョニングし、個々のセッションからのリクエストを認証して監査します。複数のアクターがワーカー Pod を共有するため、Pod レベルの Workload Identity Federation for GKE はワーカー インフラストラクチャ タスクにのみ使用します。
API キーとトークンをサンドボックスの外部に保持するため、組み込みの下り（外向き）ゲートウェイは、転送中の送信リクエストに認証情報を挿入します。シークレットは、Kubernetes Secret オブジェクトまたは Secret Manager に保存します。アウトバウンド HTTP または HTTPS リクエストが Egress ルールに一致すると、ゲートウェイはアクターの mTLS トンネルを認証し、プレースホルダ ヘッダーを取得したシークレットまたはアクター JWT に置き換えます。詳細については、オープンソースの Agent Substrate 下り（外向き）認証情報の挿入に関するドキュメントをご覧ください。
デフォルトでは、Agent Substrate は、他のアクター、Kubernetes コントロール プレーン、Compute Engine メタデータ サーバー、インターネットへのすべてのアウトバウンド トラフィックをブロックします。DNS 以外の UDP、任意の未加工 TCP 接続、HTTP WebSocket のアップグレードはブロックされ、DNS はアクターの EgressPolicy リソースで許可されているホスト名のみを解決します。アウトバウンド接続を許可するには、完全修飾ドメイン名（FQDN）またはワイルドカード ホスト名を使用して、EgressPolicy リソースに HTTP、HTTPS、または TLS パススルールールを定義します。IP アドレスと CIDR の範囲はサポートされていません。詳細については、オープンソースの Agent Substrate の下り（外向き）トラフィックとセキュリティのドキュメントをご覧ください。
セッション チェックポイントとワークスペース ストレージ
アプリケーションがアクターを一時停止すると（gVisor または microVM のいずれか）、Agent Substrate はアクティブ メモリ、ルート ファイル システムの変更、永続ディレクトリ（ボリューム レイヤ）の 3 つのレイヤにわたってスナップショットを Cloud Storage に保存します。アタッチされた外部 CSI ボリュームは、スナップショットの外部のバッキング ストレージに保持され、再開時に再アタッチされます。
一時停止されたアクターが再開されると、Agent Substrate はターゲット環境に一致する最上位のスナップショット レイヤを復元します。
- メモリ、ルート ファイル システム、ボリューム: アクターが同じハードウェア、サンドボックス ランタイム、コンテナ イメージで再開されると、1 秒未満で復元されます。
- ルート ファイル システムとボリューム: ノード ハードウェアまたはサンドボックス ランタイムが変更されると復元されます。アクターは、ルート ファイル システムの変更と永続ディレクトリを保持しながら、プロセスを再起動します。
- ボリュームのみ: アクターが一時停止している間に ActorTemplate リソースのコンテナ イメージを更新すると、復元されます。次の再開では、更新されたイメージからコンテナが起動され、永続ディレクトリと外部ボリュームが復元されます。イメージの更新後も保持する必要があるデータは、永続ディレクトリまたは外部ストレージに書き込みます。
一時停止と再開のレイテンシは、スナップショットのサイズに応じてスケールします。アクターが別のノードで再開するときに高速なクロスノード再アタッチが必要な大規模なワークスペースの場合は、スナップショット内にデータを保存するのではなく、外部の Filestore エージェント ボリュームを使用します。ActorTemplate リソース内の各外部 CSI ボリューム（プレビュー）は、単一のアクター専用にプロビジョニングされ（アクター間で共有されません）、そのアクターとともに削除されます。Filestore エージェント ボリュームのプロダクション サポートは、アクセス リクエストが必要な限定的な GA プログラムを通じて提供されます。
ブロック ストレージ（Hyperdisk など）は、アクターごとの CSI ボリュームではなく、ノードのブートディスクとローカル スナップショット キャッシュに使用されます。これは、ノード間のブロックの切断と接続のレイテンシにより、アクターの再開が遅くなるためです。詳細については、オープンソースの Agent Substrate CSI ボリュームのドキュメントをご覧ください。
Pod ベースのモデル: GKE 上の Agent Sandbox
GKE 上の Agent Sandbox は、Kubernetes カスタム リソース（Sandbox、SandboxClaim、SandboxTemplate、SandboxWarmPool）を介して管理される専用のステートフルな Kubernetes Pod で各エージェントを実行します。SandboxWarmPool リソースは、特定の SandboxTemplate リソースに対して実行中の Pod を含む事前にウォームアップされた Sandbox リソースを維持します。これにより、コントローラは準備完了の Sandbox リソースとその実行中の Pod を 1 秒未満でクレームに割り当てることができます。
各エージェントに専用の Pod が必要な場合や、ワークロードに次のいずれかの要件がある場合は、Agent Sandbox を選択します。
- 継続的にアクティブなエージェントと単一 Pod サービス: 頻繁なアイドル期間のないワークロード、または StatefulSet の複雑さなしに安定したホスト名とストレージを必要とする永続セッション（クラウド開発環境や Jupyter Notebook など）。
- ハードウェア アクセラレータ（GPU または TPU）: サンドボックス内の GPU または TPU に直接アクセスする必要があるエージェント。アクセラレータは、サポートされている GPU モデルと TPU バージョンの gVisor ランタイムでのみ動作します。MicroVM は GPU または TPU をサポートしていません。
- 完全な Kubernetes PodSpec、Arm ノード、または GKE Autopilot: カスタム サイドカーまたは init コンテナ、標準の Kubernetes API とツール（
kubectlコマンド、ロールベース アクセス制御、既存のコントローラなど）、Arm CPU、または GKE Autopilot クラスタを必要とするワークロード。
ID、認証情報、ネットワーク ポリシー
各エージェントは専用の Pod で実行されるため、Workload Identity Federation for GKE または Agent Identity（プレビュー）を使用して、Pod に Google CloudIdentity and Access Management（IAM）権限を付与できます。どちらのオプションでも、Pod の作成時に ID が Pod の Kubernetes ServiceAccount にバインドされるため、SandboxWarmPool リソース内のすべての事前ウォームアップされた Pod が同じ ID を共有します。エージェントまたはテナントごとに ID を分離するには、ID ごとに個別の SandboxWarmPool リソースを維持するか、ウォームプールなしでオンデマンドで Sandbox リソースを作成します。
標準の Kubernetes Secret オブジェクトまたは CSI ボリュームを使用して、Secret を Pod にマウントします。Agent Sandbox には、サンドボックス外の認証情報の挿入用のゲートウェイは含まれていません。転送中に認証情報を挿入するには、独自の外部プロキシをデプロイします。
コントローラは、SandboxTemplate リソースごとにデフォルト拒否の NetworkPolicy オブジェクトを作成します。テンプレートを使用せずに直接作成する Sandbox リソースの場合は、独自の NetworkPolicy オブジェクトを作成します。トラフィックを制限するには、標準の GKE ネットワーク制御を使用します。
- レイヤ 4: GKE ネットワーク ポリシー（NetworkPolicy オブジェクト）を使用して、Pod 間のトラフィックと IP トラフィックを制限します。
- レイヤ 7: FQDN ネットワーク ポリシー（FQDNNetworkPolicy オブジェクト）を使用して、承認済みドメインへのアウトバウンド接続を制限します。
アイドル状態の停止、Pod スナップショット、ストレージ
アイドル状態のエージェントの Pod は、アプリケーションが spec.operatingMode フィールドを Suspended に設定して Sandbox リソースを一時停止するまで、予約済みの CPU とメモリを保持します。Sandbox リソースを一時停止すると、永続ボリュームを保持したまま Pod が削除されます。Pod を削除すると、メモリ内データとコンテナ ファイル システムの変更が消去されます。その状態を Cloud Storage に保存して復元するには、エージェントを一時停止する前に GKE Pod スナップショットを取得します。Pod スナップショットには gVisor ランタイムが必要です。マイクロ VM や TPU はサポートされていません。スナップショットから Pod を復元するには、約 3 ～ 5 秒かかります。
Pod スナップショット以外の永続ストレージについては、次のオプションから選択します。
- Filestore: 共同作業スペース用に、複数のサンドボックス Pod に共有
ReadWriteMany（RWX）PersistentVolumeClaim（PVC）をマウントします。詳細については、AI エージェント ワークロードのストレージを選択するをご覧ください。 - Hyperdisk: 分離された Pod ディスクには Google Cloud Hyperdisk Balanced（
ReadWriteOnceアクセスモード）を使用し、読み取り専用のデータセットまたはモデルの重みをノード間で共有するには Google Cloud Hyperdisk ML（ReadOnlyManyアクセスモード）を使用します。詳細については、AI エージェント ワークロード用のストレージを選択すると GKE 用 Hyperdisk についてをご覧ください。
Agent Substrate と Agent Sandbox の比較
次の表に、GKE 上の Agent Substrate と GKE 上の Agent Sandbox のアーキテクチャの違いをまとめます。
| ディメンション | GKE 上の Agent Substrate（アクターベース） | GKE 上の Agent Sandbox（Pod ベース） |
|---|---|---|
| 推奨される AI エージェント ワークロード | 頻繁に一時停止と再開を行う、ほとんどのステートフルな CPU ベースのエージェント | 継続的にアクティブなエージェント、GPU または TPU ワークロード、カスタム PodSpec、Arm ノード、GKE Autopilot |
| スケジュール設定単位 | 複数のアクターがウォーム Pod のプール（WorkerPool）を共有する | エージェントごとに 1 つの専用 Pod（サンドボックス） |
| サンドボックス ランタイム | gVisor と Cloud Hypervisor のマイクロ VM（WorkerPool Pod 内で管理） | GKE Standard の gVisor とマイクロ VM（ノードプールまたは ComputeClass で GKE Sandbox が有効になっている場合）、または GKE Autopilot の gVisor（デフォルトで有効） |
| ウォーム プーリング | アクター テンプレートとコンテナ イメージ間で共有される WorkerPool リソース | テンプレートとコンテナ イメージごとに 1 つの SandboxWarmPool リソース |
| コントロール プレーンのパス |
kube-apiserver コンポーネント外の専用コントロール プレーンとデータベース |
標準の Kubernetes コントローラ、kube-apiserver、etcd |
| アイドル状態のリソースの処理 | アイドル状態のアクターを一時停止すると、ワーカーの CPU とメモリが解放されます。 | アイドル状態の Sandbox リソースを一時停止すると、Pod が削除され、永続ボリュームが保持されます。 |
| 状態チェックポイント | gVisor と microVM に組み込まれた Cloud Storage スナップショット。1 秒未満で復元 | GKE Pod スナップショット（gVisor でのみサポート）、3 ～ 5 秒で復元 |
| サポートされているクラスタモード | GKE Standard（バージョン 1.37 以降、x86 ノード） | GKE Standard と GKE Autopilot |
| ハードウェア アクセラレータ | サポート対象外（CPU のみのワーカーノード） | GPU と TPU は gVisor ランタイムでのみサポートされます |
| Kubernetes PodSpec のサポート | ActorTemplate リソースと WorkerPool リソースに分割されたサブセット | 完全な PodSpec（サイドカーと init コンテナを含む） |
| ネットワーキング | アクターごとの mTLS トンネルを備えた組み込みの Envoy Ingress ゲートウェイと Egress ゲートウェイ | Kubernetes Service、NetworkPolicy、FQDNNetworkPolicy |
| 身分証明用モデル | アクターごとの SPIFFE X.509 証明書と JWT | Workload Identity Federation for GKE または Agent Identity（プレビュー）を使用する Pod ServiceAccount。ウォームプール間で共有されます。 |
| Secret Manager | Egress ゲートウェイでアウトバウンド リクエストに挿入される | Kubernetes Secret オブジェクトまたは CSI ボリュームを使用して Pod にマウントされる |
サンドボックス ランタイムを選択する
Agent Substrate と Agent Sandbox はどちらも、Cloud Hypervisor microVM または gVisor を使用して、信頼できないコードをホストノードから分離しますが、ランタイムの構成はモデルごとに異なります。
- エージェント基盤: WorkerPool リソースのランタイムを選択します。Agent Substrate は、ノードレベルの GKE Sandbox 機能を使用するのではなく、WorkerPool Pod 内で独自の microVM ランタイムと gVisor ランタイムを管理します。Agent Substrate ワーカーノード プールで GKE Sandbox を有効にしないでください。
sandbox.gke.io/runtimeノード taint により、WorkerPool Pod のスケジューリングが妨げられます。 - Agent Sandbox: SandboxTemplate リソースの Pod テンプレートで
runtimeClassNameフィールドをgvisorまたはmicrovmに設定します。GKE Standard では、ノードプールまたはカスタム ComputeClass で GKE Sandbox を有効にします。GKE Autopilot では、gVisor はデフォルトで使用可能であり、マイクロ VM はサポートされていません。
どちらのランタイムも、信頼できないコードとヘッドレス ブラウザを実行します。
- MicroVMs: 各サンドボックスは、専用のゲスト Linux カーネルを備えた軽量の仮想マシンで実行されます。VM レベルの分離、完全な Linux システムコール互換性、またはマルチコンテナ アクター内のコンテナごとの CPU とメモリの制限が必要な場合は、microVM を選択します。
- gVisor: 各サンドボックスは、Linux syscall をインターセプトしてフィルタするユーザー空間カーネルで実行されます。コールド スタートの高速化、メモリ オーバーヘッドの削減、Compute Engine マシンのサポートの拡大（GPU、TPU、Arm ノード、Agent Sandbox の GKE Autopilot など）が必要な場合は、gVisor を選択します。
次の表は、GKE での microVM と gVisor を比較したものです。
| 機能 | MicroVMs | gVisor |
|---|---|---|
| カーネルへのアクセス | 完全な Linux カーネル | Linux カーネルのシステムコールのサブセット |
| 分離レベル | 専用のゲストカーネルを使用したハードウェア仮想化 | ユーザー空間カーネルでのシステムコールのインターセプト |
| CPU とメモリのオーバーヘッド | Agent Substrate のアクターごとの VMM メモリ。GKE Sandbox で Pod あたり 250 mCPU と 130 MiB に固定。 | ベースメモリが少ない動的オーバーヘッド |
| 開始時刻 | 1 ～ 2 秒 | 100 ミリ秒未満 |
| GKE ノード構成 | ネストされた仮想化を備えた GKE Standard ノード（両方のモデル）、または x86 ベアメタル ノード（Agent Substrate のみ） | GKE Standard ノードプール（両方のモデル）、または GKE Autopilot ノード（Agent Sandbox のみ） |
| ノードイメージのサポート |
Agent Substrate の Container-Optimized OS（cos_containerd）。Container-Optimized OS（cos_containerd）または GKE Sandbox の Ubuntu。 |
Container-Optimized OS（cos_containerd）のみ |
| マシンタイプの互換性 | ネストされた仮想化をサポートする x86 マシンシリーズと x86 ベアメタル（E2 または Arm ではサポートされていません） | Agent Substrate の非混合 CPU x86 シリーズ。Agent Sandbox のほとんどの x86、Arm、アクセラレータ シリーズ。 |
| アクセラレータのサポート | 非対応 | サポートされている GPU モデルと TPU バージョン（Agent Sandbox のみ） |
| サンプル ユースケース |
|
|
これらの分離テクノロジーの詳細については、GKE Sandbox をご覧ください。
次のステップ
- アクターのライフサイクルの詳細については、GKE の Agent Substrate についてをご覧ください。
- GKE に Agent Substrate をインストールする。
- GKE で Agent Substrate のインフラストラクチャを設計する方法を確認する。
- Pod ベースのサンドボックスの詳細については、GKE の Agent Sandbox の概要をご覧ください。
- GKE に Agent Sandbox をインストールする。