關於 GKE 的 Agent Sandbox

Google Kubernetes Engine (GKE) 的 Agent Sandbox 可讓您在專屬 Kubernetes Pod 中，執行獨立的代理程式工作負載。AI 代理執行 LLM 生成的不信任程式碼時，隔離機制至關重要。對於大多數代理工作負載，建議改用 GKE 上的 Agent Substrate，因為它可以在相同節點上執行更多代理。如果每個代理都需要專屬 Pod、GPU 或 TPU、完整的 Kubernetes PodSpec 或 GKE Autopilot 叢集，請使用 GKE 的 Agent Sandbox。如要比較 GKE 上的 Agent Sandbox 與 GKE 上的 Agent Substrate，並選擇適合 AI 代理工作負載的架構，請參閱「規劃 GKE 上的 AI 代理工作負載架構」。

Agent Sandbox 是 Kubernetes SIG Apps 下的開放原始碼專案。如要在 GKE 使用 Agent Sandbox，請在叢集安裝 Agent Sandbox 控制器。您必須自行升級控制器。如需操作說明，請參閱「在 GKE 上安裝 Agent Sandbox」。

本文件概略說明 GKE 上的 Agent Sandbox。

在 GKE 使用 Agent Sandbox 的優點

GKE 的 Agent Sandbox 會為每個代理提供專屬的核心隔離 Pod，您可以使用標準 Kubernetes API 管理。主要優點如下：

  • 核心層級隔離：使用 GKE Sandbox 搭配 gVisor 或 microVM，將不受信任、由 LLM 生成的程式碼與節點核心隔離。GKE 的 Agent Sandbox 也支援自行管理的開放原始碼 Kata Containers，您可以將其安裝在節點上，而非 GKE Sandbox。如需在 GKE 上搭配使用開放原始碼 Kata Containers 和 Agent Sandbox 的教學課程，請參閱「在 GKE 上啟用 Kata Containers」。

  • 不到一秒即可佈建：為代理程式提供預熱的 Pod，通常不到一秒即可完成，不必等待標準 Kubernetes Pod 排程和啟動。

  • 雲端原生擴充性：運用 Kubernetes 範式的強大功能和 GKE 的代管基礎架構。

GKE 的 Agent Sandbox 提供宣告式標準化 API，可提供單一容器體驗，具備與虛擬機器 (VM) 類似的隔離和持久性特性，完全以 Kubernetes 原語建構。

GKE Agent Sandbox 的常見用途

如果工作負載需要隔離、永久性和穩定身分，請在 GKE 上使用 Agent Sandbox。用途範例如下：

  • AI 代理執行階段：在 Pod 中執行不受信任的程式碼，並使用 gVisor 或 microVMs 將程式碼與節點核心隔離。
  • 開發環境：為開發人員提供永久、隔離的雲端式程式設計環境。
  • 筆記本和研究工具：為 Jupyter Notebook 等互動式工具託管單一容器工作階段。
  • 有狀態的單一 Pod 服務：執行需要穩定身分和儲存空間的應用程式，不必處理複雜的 StatefulSet。
  • 程式輔助環境管理：使用提供的用戶端程式庫 SDK (例如 Agent Sandbox Python SDK)，直接從應用程式邏輯要求及管理 Sandbox 資源，無須管理 Kubernetes YAML。

Agent Sandbox on GKE 的運作方式

GKE 的 Agent Sandbox 使用自訂控制器和多個 Kubernetes 自訂資源定義 (CRD)，管理 Sandbox 資源的生命週期。

核心架構

  • Sandbox 自訂資源：代表單一有狀態 Pod 的主要資源。這項資源會管理穩定的主機名稱、網路身分和永久儲存空間。如要暫停閒置的代理，請將其 Sandbox 資源的 spec.operatingMode 欄位設為 Suspended。控制器會刪除 Pod，但保留沙箱資源及其永久磁碟區。除非您先建立 Pod 快照，否則記憶體內資料和容器檔案系統變更都會遺失。如要恢復代理，請將欄位設回 Running。GKE 上的 Agent Sandbox 不會偵測閒置的代理，而是由應用程式決定何時暫停。
  • 沙箱路由器：這個元件提供穩定的端點，並將流量傳送至執行代理的 Pod，抽象化底層網路的複雜性。
  • 與 Pod 快照整合：GKE 的 Agent Sandbox 與 GKE Pod 快照功能整合，可儲存及還原容器的完整狀態，藉此暫停和恢復工作負載。

著作權聲明模型

宣告模型是一項重要功能，可將使用者對環境的要求與特定實作詳細資料區隔開來，例如工作負載的佈建位置和方式。與標準 Kubernetes StatefulSet 不同，要求模型可讓您要求 Sandbox 資源，不必直接管理基礎 Pod 或儲存空間設定。

要求模型會使用 SandboxClaim、SandboxWarmPool 和 SandboxTemplate 自訂資源，運作方式如下：

  1. 使用者或應用程式建立參照 SandboxWarmPool 資源的 SandboxClaim 資源，藉此要求沙箱資源。暖集區會參照定義 Pod 設定的 SandboxTemplate 資源。
  2. 控制器會從暖集區中，將準備就緒的沙箱資源 (及其執行中的 Pod) 指派給要求。如果集區中沒有可用的沙箱資源，控制器會根據範本為宣告建立新的沙箱資源。

預建集區

暖集區功能旨在盡可能縮短互動式 AI 代理情境的啟動延遲時間。透過暖集區，GKE 上的 Agent Sandbox 可以在一秒內提供執行環境。這項功能會使用 SandboxWarmPool 自訂資源，運作方式如下：

  1. SandboxWarmPool 資源會維護預建沙箱資源集區，其中的 Pod 處於就緒狀態。
  2. 建立 SandboxClaim 資源時，控制器會從集區指派已就緒的 Sandbox 資源及其執行中的 Pod，而不是等待新的 Pod 提取映像檔並啟動。
  3. 與 Pod 快照搭配使用時，暖集區可從預先設定的狀態還原 Pod，而非從頭啟動。

網路隔離

GKE 上的 Agent Sandbox 會針對控制器從 SandboxTemplate 資源建立的 Pod，實施預設拒絕網路政策。針對每個 SandboxTemplate 資源，控制器會建立 NetworkPolicy 資源，防止 Pod 內不受信任的程式碼存取未經授權的內部網路或 GKE 控制層。您可以在 SandboxTemplate 資源中，定義特定網路限制和允許的輸出或輸入規則，控管代理工作負載的網路存取權。

控制器不會為您直接建立的 Sandbox 資源建立 NetworkPolicy 資源。如要限制這些 Sandbox 資源的 Pod 網路存取權，請自行建立 NetworkPolicy 資源。

使用 SDK 透過程式輔助方式存取

AI 工程師可以使用提供的用戶端程式庫，以程式輔助方式在 GKE 資源上使用 Agent Sandbox。舉例來說，Python SDK 提供高階介面，可為您建立基礎 SandboxClaim 資源。該要求會參照您建立的 SandboxWarmPool 資源。您可以透過這個介面，直接從 LangChain 或 Vertex AI Agentic SDK 等 Python 代理框架，建立及與隔離環境互動。

限制與需求

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，不適用於 microVM。如未指定 GKE Sandbox 執行階段 (gVisor 或 microVM)，Pod 執行時就不會隔離核心，因此請勿用於執行不受信任的程式碼。
  • 硬體加速器：GPU 和 TPU 僅適用於支援的 GPU 模型和 TPU 版本上的 gVisor 執行階段，不支援 microVM。此外，Pod 快照不支援 TPU。
  • 基礎功能可用性：部分基礎功能 (例如 GKE Pod 快照) 可能處於預先發布階段，或僅在特定區域提供。

後續步驟