規劃 GKE AI 代理工作負載的架構

Google Kubernetes Engine (GKE) 提供兩種自動化調度管理模型，可在核心隔離的沙箱中執行 AI 代理 (使用 Cloud Hypervisor 微型 VM 或 gVisor)：

  • GKE 上的 Agent Substrate (以執行者為基礎，建議使用)：這個模型適用於大多數 AI 代理工作負載，尤其是經常暫停和恢復的有狀態 CPU 代理。活躍的代理工作階段 (執行者) 會共用暖啟動 worker Pod 集區，並可在不到一秒內從 Cloud Storage 還原。
  • GKE 上的 Agent Sandbox (以 Pod 為基礎)：如果每個代理都需要專屬的 Kubernetes Pod，請使用這個模型。如果代理程式持續運作，或工作負載需要完整的 Kubernetes PodSpec (例如 sidecar)、GPU 或 TPU、Arm 節點或 GKE Autopilot 叢集，請選擇這個選項。

如要並排比較這兩種自動化調度管理模式，請參閱「比較 Agent Substrate 和 Agent Sandbox」。

請參閱這份文件，選擇自動化調度管理模型、沙箱執行階段、隔離控制項和儲存空間選項，然後再佈建 GKE 叢集。本文適用對象為解決方案架構師、AI 開發人員，以及平台管理員和操作人員，負責在 GKE 上設計 AI 代理的執行環境。

在 GKE 執行 AI 代理工作負載的架構需求

在 GKE 執行 AI 代理工作負載，即可將獨立的代理執行環境，放在與支援 Kubernetes 服務相同的叢集和網路邊界，並使用 GKE 自動佈建節點、突發資源調度及管理生命週期。

與持續運作的微服務不同，AI 代理工作負載有下列架構需求：

Actor 模式：GKE 上的 Agent Substrate (建議)

GKE 上的 Agent Substrate 是執行階段，可將代理工作階段 (執行者) 與基礎 Kubernetes Pod 分離。活躍的 actor 會在 actor 範本 (ActorTemplate 資源) 之間，共用預熱 worker Pod 集區 (WorkerPool 資源)。當應用程式暫停閒置的代理時，Agent Substrate 會將代理的狀態檢查點儲存至 Cloud Storage，並釋出 worker 容量，讓其他代理使用節點。收到新要求時，Agent Substrate 會在一秒內將 actor 還原至可用的 worker。

使用 Agent Substrate 做為 CPU 型代理工作負載的預設架構，包括下列用途：

  • 互動式程式碼代理：AI 助理，可在開發人員對話期間執行終端機指令、建構程式碼及編輯檔案，並在提示之間暫停。
  • 長時間執行的效率提升代理：背景助理，可保留數天或數週的背景資訊，大部分時間都在等待使用者輸入或外部觸發條件。
  • 暫時性程式碼和瀏覽器沙箱：隨選環境，用於執行 LLM 生成的程式碼、無頭瀏覽器或工具呼叫，可在 1 秒內還原，並在執行後釋出運算資源。

Agent Substrate 必須使用 GKE Standard 叢集 (控制層和節點集區皆為 1.37 以上版本)，並搭配 x86 CPU worker 節點。不支援 GKE Autopilot，因為 Agent Substrate 節點代理程式 (atelet) 會以具特殊權限的 DaemonSet 形式執行，且 microVM worker 集區需要巢狀虛擬化或裸機節點。不支援 GPU 和 TPU。

身分、憑證和網路輸出

Agent Substrate 會為每個執行者佈建專屬的 SPIFFE X.509 憑證和 JSON Web Token (JWT)，以便驗證及稽核個別工作階段的要求。由於多個執行者會共用 worker Pod，因此請僅將 Pod 層級的 Workload Identity Federation for GKE 用於 worker 基礎架構工作。

為避免 API 金鑰和權杖出現在沙箱外，內建的輸出閘道會在傳輸過程中，將憑證插入傳出要求。密鑰會儲存在 Kubernetes Secret 物件或 Secret Manager 中。當傳出 HTTP 或 HTTPS 要求符合輸出規則時，閘道會驗證執行者的 mTLS 通道，並將預留位置標頭替換為擷取的密鑰或執行者 JWT。詳情請參閱開放原始碼 Agent Substrate 輸出憑證插入說明文件。

根據預設，Agent Substrate 會封鎖所有傳至其他 actor、Kubernetes 控制層、Compute Engine 中繼資料伺服器和網際網路的傳出流量。非 DNS UDP、任意原始 TCP 連線和 HTTP WebSocket 升級都會遭到封鎖，且 DNS 只會解析執行者 EgressPolicy 資源允許的主機名稱。如要允許傳出連線，請使用完整網域名稱 (FQDN) 或萬用字元主機名稱，在 EgressPolicy 資源中定義 HTTP、HTTPS 或 TLS 傳遞規則。不支援 IP 位址和 CIDR 範圍。詳情請參閱開放原始碼 Agent Substrate 的輸出流量和安全性說明文件。

工作階段檢查點和工作區儲存空間

當應用程式暫停執行者 (在 gVisor 或 microVM 上) 時，Agent Substrate 會將快照儲存至 Cloud Storage，涵蓋三個層級：使用中記憶體、根檔案系統變更和永久目錄 (磁碟區層)。任何附加的外部 CSI 磁碟區都會保留在快照以外的備份儲存空間中，並在恢復時重新附加。

暫停的 actor 恢復運作時，Agent Substrate 會還原與目標環境相符的最高快照層：

  • 記憶體、根檔案系統和磁碟區：當執行者使用相同的硬體、沙箱執行階段和容器映像檔繼續執行時，可在不到一秒內還原。
  • 根檔案系統和磁碟區：節點硬體或沙箱執行階段變更時，系統會還原這些項目。執行者會重新啟動程序，同時保留根檔案系統變更和永久目錄。
  • 僅限磁碟區：在 Actor 暫停期間，更新 ActorTemplate 資源中的容器映像檔時，系統會還原磁碟區。下次繼續執行時，系統會從更新後的映像檔啟動容器，並還原永久目錄和外部磁碟區。將必須在映像檔更新後保留的資料，寫入永久目錄或外部儲存空間。

暫停和繼續作業的延遲時間會隨著快照大小而改變。如果工作區較大，且需要在 actor 於其他節點繼續執行時，快速重新附加跨節點，請使用外部 Filestore 代理磁碟區，而非將資料儲存在快照中。ActorTemplate 資源中的每個外部 CSI 磁碟區 (預先發布版) 都是專為單一 actor 佈建 (不會在 actor 之間共用)，並會與該 actor 一併刪除。Filestore 代理磁碟區的進階支援服務，是透過有限的正式發布版計畫提供，必須提出存取要求。

區塊儲存空間 (例如 Hyperdisk) 用於節點開機磁碟和本機快照快取，而非個別 actor 的 CSI 磁碟區，因為跨節點區塊卸載和連接延遲會減緩 actor 恢復速度。詳情請參閱開放原始碼 Agent Substrate CSI 磁碟區說明文件。

Pod 模式：GKE 上的 Agent Sandbox

GKE 的 Agent Sandbox 會在專屬的有狀態 Kubernetes Pod 中執行每個代理，並透過 Kubernetes 自訂資源 (Sandbox、SandboxClaim、SandboxTemplate 和 SandboxWarmPool) 管理。SandboxWarmPool 資源會維護預熱的 Sandbox 資源，並為特定 SandboxTemplate 資源執行 Pod，讓控制器能在不到一秒的時間內，將準備就緒的 Sandbox 資源及其執行中的 Pod 指派給要求。

如果每個代理都需要專屬 Pod，或工作負載符合下列任一條件，請選擇 Agent Sandbox：

  • 持續運作的代理和單一 Pod 服務：沒有頻繁閒置期的工作負載，或需要穩定主機名稱和儲存空間，但不需要 StatefulSet 複雜性的永久工作階段 (例如雲端開發環境或 Jupyter Notebook)。
  • 硬體加速器 (GPU 或 TPU)：需要在沙箱中直接存取 GPU 或 TPU 的代理。加速器僅適用於支援的 GPU 模型和 TPU 版本上的 gVisor 執行階段。MicroVM 不支援 GPU 或 TPU。
  • 完整的 Kubernetes PodSpec、Arm 節點或 GKE Autopilot：需要自訂 sidecar 或 init 容器、標準 Kubernetes API 和工具 (例如 kubectl 指令、角色式存取控管和現有控制器)、Arm CPU 或 GKE Autopilot 叢集的工作負載。

身分、憑證和網路政策

由於每個代理都在專屬 Pod 中執行，您可以使用 Workload Identity Federation for GKE 或代理身分 (預先發布版)，將 Google CloudIdentity and Access Management (IAM) 權限授予 Pod。這兩種選項都會在建立 Pod 時，將身分繫結至 Pod 的 Kubernetes ServiceAccount，因此 SandboxWarmPool 資源中所有預先暖機的 Pod 都會共用相同身分。如要依代理或租戶隔離身分，請為每個身分維護獨立的 SandboxWarmPool 資源，或視需要建立 Sandbox 資源，不使用暖集區。

您可以使用標準 Kubernetes Secret 物件或 CSI 磁碟區，將 Secret 掛接至 Pod。Agent Sandbox 不含用於沙箱外憑證插入的閘道。如要在傳輸過程中插入憑證，請部署自己的外部 Proxy。

控制器會為每個 SandboxTemplate 資源建立預設拒絕的 NetworkPolicy 物件。如要直接建立沙箱資源，而不使用範本，請自行建立 NetworkPolicy 物件。您可以使用標準 GKE 網路控制項限制流量：

  • 第 4 層：使用 GKE 網路政策 (NetworkPolicy 物件) 限制 Pod 對 Pod 和 IP 流量。
  • 第 7 層：使用 FQDN 網路政策 (FQDNNetworkPolicy 物件)，限制傳出連線至已核准的網域。

閒置暫停、Pod 快照和儲存空間

閒置代理程式的 Pod 會保留預留的 CPU 和記憶體，直到應用程式將 Sandbox 資源的 spec.operatingMode 欄位設為 Suspended，暫停該資源為止。暫停 Sandbox 資源會刪除 Pod，但保留其永久磁碟區。刪除 Pod 會清除記憶體內資料和容器檔案系統變更。如要從 Cloud Storage 儲存及還原該狀態，請在暫停代理程式前建立 GKE Pod 快照。Pod 快照需要 gVisor 執行階段，不支援微型 VM 或 TPU。從快照還原 Pod 大約需要三到五秒。

如要使用 Pod 快照以外的永久儲存空間，請選擇下列選項：

比較 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
排程單位 多個 Actor 共用暖機 Pod 集區 (WorkerPool) 每個代理一個專屬 Pod (沙箱)
沙箱執行階段 gVisor 和 Cloud Hypervisor microVM (在 WorkerPool Pod 內管理) GKE Standard 上的 gVisor 和 microVM (在節點集區或 ComputeClass 上啟用 GKE Sandbox)，或 GKE Autopilot 上的 gVisor (預設啟用)
預建集區 在執行者範本和容器映像檔之間共用 WorkerPool 資源 每個範本和容器映像檔只能有一個 SandboxWarmPool 資源
控制層路徑 kube-apiserver 元件外的專屬控制層和資料庫 標準 Kubernetes 控制器、kube-apiserver 和 etcd
閒置資源處理 暫停閒置的 actor 會釋出 worker CPU 和記憶體 暫停閒置的沙箱資源會刪除其 Pod，並保留永久磁碟區
狀態查核點 gVisor 和 microVM 內建 Cloud Storage 快照，可在 1 秒內還原 GKE Pod 快照 (僅支援 gVisor)，可在 3 到 5 秒內還原
支援的叢集模式 GKE Standard (1.37 以上版本，x86 節點) GKE Standard 和 GKE Autopilot
硬體加速器 不支援 (僅限 CPU 的 worker 節點) 僅支援 gVisor 執行階段的 GPU 和 TPU
Kubernetes PodSpec 支援 子集分散在 ActorTemplate 和 WorkerPool 資源中 完整的 PodSpec，包括 sidecar 和 init 容器
網路 內建 Envoy 輸入和輸出閘道，並為每個執行者提供 mTLS 通道 Kubernetes 服務、NetworkPolicy 和 FQDNNetworkPolicy
身分模型 每個執行者的 SPIFFE X.509 憑證和 JWT Pod ServiceAccount 使用 Workload Identity Federation for GKE 或代理程式身分 (預先發布版)，在暖集區中共用
Secret 管理 在輸出閘道插入傳出要求 使用 Kubernetes Secret 物件或 CSI 磁碟區掛接至 Pod

選取沙箱執行階段

Agent Substrate 和 Agent Sandbox 都會使用 Cloud Hypervisor microVM 或 gVisor，將不受信任的程式碼與主機節點隔離，但您在各模型中設定執行階段的方式不同：

  • Agent Substrate：選取 WorkerPool 資源的執行階段。Agent Substrate 會在 WorkerPool Pod 內管理自己的 microVM 和 gVisor 執行階段，而非使用節點層級的 GKE Sandbox 功能。請勿在 Agent Substrate worker 節點集區啟用 GKE Sandbox，因為 sandbox.gke.io/runtime 節點 taint 會阻止 WorkerPool Pod 排程。
  • Agent Sandbox：在 SandboxTemplate 資源的 Pod 範本中，將 runtimeClassName 欄位設為 gvisor 或 microvm。在 GKE Standard，也請在節點集區或自訂 ComputeClass 啟用 GKE Sandbox。在 GKE Autopilot 中，gVisor 預設為可用，且不支援 microVM。

這兩個執行階段都會執行不受信任的程式碼和無頭瀏覽器：

  • MicroVMs：每個沙箱都在輕量虛擬機器中執行，並有專屬的訪客 Linux 核心。如需 VM 層級隔離、完整的 Linux syscall 相容性，或多容器 actor 內每個容器的 CPU 和記憶體限制，請選擇 microVM。
  • gVisor：每個沙箱都在使用者空間核心中執行，可攔截及篩選 Linux 系統呼叫。如要加快冷啟動速度、降低記憶體負擔，或支援更多 Compute Engine 機器 (包括 GPU、TPU、Arm 節點和 Agent Sandbox 中的 GKE Autopilot)，請選擇 gVisor。

下表比較 GKE 上的微型 VM 和 gVisor：

功能 MicroVMs gVisor
核心存取權 完整 Linux 核心 Linux 核心系統呼叫的子集
隔離等級 硬體虛擬化，搭配專屬客體核心 在使用者空間核心中攔截系統呼叫
CPU 和記憶體負擔 Agent Substrate 中每個 actor 的 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)
應用實例
  • 自主式程式設計和瀏覽器代理
  • 需要完整 Linux 核心相容性的工作負載
  • 高 I/O 工作負載，且系統呼叫頻繁
  • Python、Node.js、Go、Java 或 Rust 中的不受信任應用程式
  • CPU、GPU 或 TPU 推論和程式碼執行沙箱
  • 網頁前端、快取和 Proxy

如要進一步瞭解這些隔離技術，請參閱「GKE Sandbox」。

後續步驟