GKE 上の Agent Substrate について

GKE 上の Agent Substrate は、Kubernetes クラスタ上でエージェント ワークロードを大規模に実行します。これは、一般的なリソースの非効率性に対処するものです。インタラクティブ エージェント（パーソナル アシスタントやコーディング エージェントなど）は、ほとんどの時間をユーザー入力や外部トリガーの待機に費やします。これらの非アクティブなエージェントを継続的に実行すると、アクティブなワークロードに割り当てられるはずの CPU とメモリが使用されます。

GKE の Agent Substrate は、アイドル状態のエージェントを一時停止し、エージェントのアクティブ メモリ（RAM）とローカル ファイルのスナップショットを取得することで、この問題を解決します。一時停止されたエージェントが再度動作する必要がある場合、システムはエージェントの状態を 1 秒未満で利用可能なサンドボックスに復元します。

GKE 上の Agent Substrate は、GKE 上の Agent Sandbox の機能をベースに構築されており、標準の Kubernetes コントロール プレーンのボトルネックを回避することで、GKE 上の Agent Sandbox を改善しています。その結果、マシンあたりの同時実行エージェント数が大幅に増加し、エージェントの起動時間が大幅に短縮されます。

標準の Kubernetes デプロイ（GKE の Agent Sandbox を含む）では、各エージェント ワークロードが専用の Pod に関連付けられます。Kubernetes はスケーラビリティに優れていますが、Pod のスケジューリング スループットと起動レイテンシによって制約を受けます。また、Kubernetes は Pod の休止をサポートしていません。クラスタ内に数百万のアイドル状態のエージェントを保持すると、Pod の上限とコントロール プレーンのメモリが枯渇します。アイドル状態のコンピューティングに対して料金を支払うことを避けるには、Pod をシャットダウンし、外部ストレージでエージェントの状態を管理する必要があります。GKE の Agent Substrate は、エージェントの状態を基盤となる Pod から切り離すことで、これらのスケーリングの制約を解決します。数百万の一時停止されたエージェント スナップショットをストレージに保存し、オンデマンドでウォーム ワーカーの共有プールに復元します。

GKE の Agent Substrate は、独自の GKE Standard クラスタに直接デプロイするオープンソース システムです。コア プロジェクトはオープンソースの Agent Substrate リポジトリで開発されていますが、Google は、対象となる Google Cloud のお客様向けに、GKE に最適化されたデプロイ ツールとスクリプトを substrate-gke リポジトリで提供しています。

GKE 上の Agent Substrate のメリット

GKE の Agent Substrate を使用すると、次の目標を達成できます。

  • 信頼できないコードを安全に実行する: GKE の Agent Substrate はカーネルとネットワークの分離を適用するため、より広範なインフラストラクチャを危険にさらすことなく、AI 生成コードを実行できます。
  • 長時間実行されるステートフル エージェントを構築する: エージェントのワーキング メモリとファイルは、セッション間で保持されます。エージェントは、一時停止した時点から再開します。
  • リクエストにリアルタイムで応答する: 新しいリクエストによって一時停止中のエージェントがトリガーされると、システムはエージェントの状態を 1 秒未満で復元します。
  • コンピューティング費用を削減する: すべてのエージェントでワーカー サンドボックスのプールを共有することで、より少ないマシンでより多くのエージェントを実行できます。アイドル状態のエージェントは一時停止され、CPU とメモリを使用しないため、エージェントがタスクをアクティブに処理している場合にのみコンピューティング料金が発生します。

ユースケース

GKE 上の Agent Substrate は、数十から数百万の同時実行エージェントまで、あらゆる規模でエージェントを実行できるように設計されています。以下に、3 つのワークロードの例を示します。

  • 生産性エージェント: 数週間にわたってコンテキストを維持する長期的なバックグラウンド アシスタント。これらのアシスタントは、ほとんどの時間をトリガーの待機に費やすため、使用していないときにワークロードを一時停止すると、コンピューティング費用を削減できます。
  • エフェメラル サンドボックス: 信頼できない LLM 生成コードの実行、ツール呼び出しの実行、データの分析を行うためのオンデマンドの分離環境。サンドボックスは 1 秒未満で復元されるため、システムは短時間のタスクに使い捨て環境を提供し、実行が終了するとリソースを解放できます。
  • コーディング エージェント: 開発者とリアルタイムで会話してコードの作成、ビルド、テストを行う AI アシスタント。エージェントは、ターミナル コマンドを実行し、サンドボックス内のファイルを変更します。エージェントがアイドル状態になると、デベロッパーが別のプロンプトを送信するまで、システムはエージェントを一時停止します。

GKE での Agent Substrate の仕組み

GKE の Agent Substrate は Kubernetes 上に構築されていますが、Kubernetes の知識がなくても使用できます。GKE の Agent Substrate の主なコンセプトは次のとおりです。

  • アクター: エージェントの単一の実行インスタンス。
  • ActorTemplate: Actor のインスタンス化に使用される構成ブループリント（コンテナ イメージ、環境変数、コンピューティング リソースを定義）。
  • ワーカー: アクティブなアクターが実行される安全なサンドボックス。
  • WorkerPool: 事前に起動されたアイドル状態のワーカーのグループ。アクターを受け取る準備が整っています。

アクターは特定のワーカーに関連付けられていないため、システムはアイドル状態のエージェントを一時停止し、解放されたコンピューティングを再利用できます。このアーキテクチャにより、システムは限られた数のマシンで数百万のエージェントを実行できます。

一般的なエージェントのライフサイクルは次の手順に沿って行われます。

  1. ルーティング: アプリケーションからの各受信 API リクエストは、ターゲット アクターを指定します。たとえば、ユーザーがチャット インターフェースに新しいプロンプトを入力すると、アプリケーションは、ユーザーのセッションを管理する特定のアクターにリクエストを送信します。
  2. 再開: リクエストが一時停止中の Actor に対するものである場合、システムは WorkerPool からウォーム Worker を要求し、その Worker に Actor のスナップショットを復元します。
  3. 実行中: システムはリクエストをこの新しくアクティブになったワーカーにルーティングし、アクターがタスクを処理します。
  4. 一時停止: Actor が処理を完了してアイドル状態になると、システムは Actor のメモリとファイルの新しいスナップショットを取得し、スナップショットをストレージに保存して、空の Worker をプールに戻します。

ワークロードの分離と GKE Sandbox

GKE の Agent Substrate は、gVisor または Cloud Hypervisor を使用して、アプリケーション コードをホストカーネルから分離するサンドボックスで各ワークロードを実行します。GKE への Agent Substrate のインストールには、Worker 用の gVisor ランタイムが含まれているため、基盤となる GKE ノードで GKE Sandbox を構成する必要はありません。

制限事項と要件

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

  • クラスタ バージョンとベータ版 API: GKE の Agent Substrate は、バージョン 1.36（ベータ版フラグが有効）またはバージョン 1.37 以降を実行している GKE Standard クラスタでサポートされています。1.36 より前のバージョンはサポートされていません。また、GKE にはベータ版 API（podcertificaterequests と clustertrustbundles）が必要です。バージョン 1.36 を実行する既存のクラスタでこれらの API を有効にする場合は、既存のノードを置き換えて、Pod 証明書のプロジェクションを有効にする必要があります。バージョン 1.37 以降では、既存のノードを置き換える必要はありません。
  • Workload Identity Federation for GKE: GKE クラスタで Workload Identity Federation for GKE を有効にする必要があります。GKE 上の Agent Substrate は、Workload Identity Federation for GKE を使用して、エージェント スナップショットを保存するための Cloud Storage などの Google Cloud API に対する認証を行います。
  • VM ファミリー:
    • 混合 CPU アーキテクチャ: GKE の Agent Substrate は、gVisor の既知の問題により、混合 CPU アーキテクチャ（E2 マシンタイプなど）で実行される汎用マシンシリーズをサポートしていません。
    • アクター テンプレートごとに均一な VM タイプ: 単一の ActorTemplate（アクターの作成に使用される構成ブループリント）内で VM タイプを混在させることはサポートされていません。たとえば、クラスタに C4 VM と N2 VM を使用する 2 つのノードプールがある場合、ActorTemplate には、そのテンプレートのアクターが異なるマシンタイプに分割されないように、単一の VM タイプ（C4 など）を指定するノードセレクタを含める必要があります。
  • GPU のサポート: Actor コンテナへの GPU デバイスのパススルーはサポートされていません。nvidia.com/gpu を指定すると、Pod は GPU 対応ノードにのみ配置されますが、GPU デバイスは Actor コンテナに渡されません。また、gVisor はライブ CUDA コンテキストのスナップショットを作成できません。
  • ネットワーキング:
    • 下り（外向き）ポリシー: EgressPolicy ルール（ホスト名と IP アドレスによるネットワーク制御）はサポートされていません。これには、次の機能が含まれます。
      • デフォルトの拒否ルール
      • ホスト名ベースのルール
      • 認証情報の挿入
    • オープン接続: エージェントが一時停止すると、オープン ネットワーク接続（データベース セッションや MCP サーバーへの接続など）は保持されません。エージェント コードは、エージェントが再開したときに外部サービスへの再接続を処理する必要があります。
  • オブザーバビリティとマネージド OpenTelemetry: GKE 用マネージド OpenTelemetry には次の制限があります。
    • コレクタ コネクタはサポートされていません。テレメトリーのベンチマークには外部プロキシ メーターを使用する必要があります。
    • コレクタのデプロイでは、大規模なクラスタ内の Pod の数に比例してメモリ キャッシュのオーバーヘッドが発生します。
    • GKE 用マネージド OpenTelemetry では TLS はサポートされていません。
  • ストレージ: エージェントのスナップショットを保存するには、Cloud Storage が必要です。
  • インストール環境: Cloud Shell の GKE に Agent Substrate をインストールすることはできません。Cloud Shell には 5 GB の永続ディスク ストレージの上限があり、インストールに十分なディスク容量がありません。GKE に Agent Substrate をインストールするには、十分なディスク容量があるローカル ワークステーションまたは仮想マシン（VM）からインストールする必要があります。

次のステップ