规划在 GKE 上运行 AI 智能体工作负载的架构

Google Kubernetes Engine (GKE) 提供了两种编排模型，用于在内核隔离的沙盒中运行 AI 智能体（使用 Cloud Hypervisor 微虚拟机或 gVisor）：

  • GKE 上的 Agent Substrate（基于 actor，推荐）：此模型适用于大多数 AI 智能体工作负载，尤其是频繁暂停和恢复的有状态、基于 CPU 的智能体。活跃智能体会话（执行者）共享一个温工作器 Pod 池，并且可以在不到一秒的时间内从 Cloud Storage 恢复。
  • GKE 上的 Agent Sandbox（基于 Pod）：当每个智能体都需要一个专用 Kubernetes Pod 时，请使用此模型。如果代理或工作负载持续处于活跃状态，或者需要完整的 Kubernetes PodSpec（例如边车）、GPU 或 TPU、Arm 节点或 GKE Autopilot 集群，请选择此选项。

如需查看这两种编排模型的对照摘要，请参阅比较 Agent Substrate 和 Agent Sandbox。

在预配 GKE 集群之前，请阅读本文档，选择编排模型、沙盒运行时、隔离控制和存储选项。本文档适用于在 GKE 上为 AI 智能体设计执行环境的解决方案架构师、AI 开发者以及平台管理员和运维人员。

GKE 上 AI 智能体工作负载的架构要求

在 GKE 上运行 AI 智能体工作负载，您可以将隔离的智能体执行环境与支持的 Kubernetes 服务放置在同一集群和网络边界内，并使用 GKE 进行节点自动预配、突发伸缩和生命周期管理。

与持续活跃的微服务不同，AI 智能体工作负载具有以下架构要求：

基于 Actor 的模型：GKE 上的 Agent Substrate（推荐）

GKE 上的 Agent Substrate 是一个执行运行时，可将智能体会话（执行者）与底层 Kubernetes Pod 分离。活跃 Actor 会跨 Actor 模板（ActorTemplate 资源）共享预热工作器 Pod 池（WorkerPool 资源）。当应用暂停空闲智能体时，Agent Substrate 会将智能体的状态检查点保存到 Cloud Storage，并释放其工作器容量，以便其他智能体可以使用该节点。当新请求到达时，Agent Substrate 会在不到一秒的时间内将 actor 恢复到可用的工作器上。

将 Agent Substrate 用作基于 CPU 的智能体工作负载的默认架构，包括以下用例：

  • 交互式编码智能体：AI 助理，可在开发者对话期间运行终端命令、构建代码和编辑文件，并在提示之间暂停。
  • 长时间运行的生产力智能体：在几天或几周内保持上下文的后台助理，大部分时间都在等待用户输入或外部触发器。
  • 临时代码和浏览器沙盒：按需环境，用于运行 LLM 生成的代码、无头浏览器或工具调用，可在 1 秒内恢复，并在执行后释放计算资源。

Agent Substrate 需要使用 GKE Standard 集群（控制平面和节点池均需使用 1.37 或更高版本），且工作器节点需配备 x86 CPU。不支持 GKE Autopilot，因为 Agent Substrate 节点代理 (atelet) 作为特权 DaemonSet 运行，并且 microVM 工作器池需要嵌套虚拟化或裸机节点。不支持 GPU 和 TPU。

身份、凭据和网络出站流量

Agent Substrate 为每个 actor 预配唯一的 SPIFFE X.509 证书和 JSON Web 令牌 (JWT)，以便对来自各个会话的请求进行身份验证和审核。由于多个执行组件会随着时间的推移共享工作器 Pod，因此请仅将 Pod 级 Workload Identity Federation for GKE 用于工作器基础架构任务。

为了将 API 密钥和令牌保留在沙盒之外，内置出站网关会在传输过程中将凭据注入出站请求。您可以将 Secret 存储在 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 出站流量和安全文档。

会话检查点和工作区存储空间

当您的应用暂停 actor（在 gVisor 或 microVM 上）时，Agent Substrate 会将快照保存到 Cloud Storage，快照涵盖三个层：活跃内存、根文件系统更改和持久目录（卷层）。任何挂接的外部 CSI 卷都会保留在快照之外的后备存储空间中，并在恢复时重新挂接。

当暂停的 actor 恢复时，Agent Substrate 会恢复与目标环境匹配的最高快照层：

  • 内存、根文件系统和卷：当 actor 使用相同的硬件、沙盒运行时和容器映像恢复时，可在不到一秒的时间内恢复。
  • 根文件系统和卷：在节点硬件或沙盒运行时发生更改时恢复。Actor 会重启其进程，同时保留根文件系统更改和持久目录。
  • 仅限卷：在 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 自定义资源（Sandbox、SandboxClaim、SandboxTemplate 和 SandboxWarmPool）管理的专用有状态 Kubernetes Pod 中运行每个智能体。SandboxWarmPool 资源会为特定 SandboxTemplate 资源维护具有正在运行的 Pod 的预热 Sandbox 资源，以便控制器可以在不到一秒的时间内将就绪的 Sandbox 资源及其正在运行的 Pod 分配给声明。

如果每个智能体都需要一个专用 Pod，或者您的工作负载具有以下任一要求，请选择 Agent Sandbox：

  • 持续活跃的代理和单 Pod 服务：没有频繁空闲期的工作负载，或需要稳定主机名和存储空间且没有 StatefulSet 复杂性的持久会话（例如云开发环境或 Jupyter 笔记本）。
  • 硬件加速器（GPU 或 TPU）：需要在沙盒内直接访问 GPU 或 TPU 的代理。加速器仅适用于受支持的 GPU 模型和 TPU 版本上的 gVisor 运行时。MicroVM 不支持 GPU 或 TPU。
  • 完整的 Kubernetes PodSpec、Arm 节点或 GKE Autopilot：需要自定义边车或初始化容器、标准 Kubernetes API 和工具（例如 kubectl 命令、基于角色的访问权限控制和现有控制器）、Arm CPU 或 GKE Autopilot 集群的工作负载。

身份、凭据和网络政策

由于每个代理都在专用 Pod 中运行，因此您可以使用 Workload Identity Federation for GKE 或代理身份（预览版）向 Pod 授予 Google CloudIdentity and Access Management (IAM) 权限。这两种方法都会在创建 Pod 时将身份绑定到 Pod 的 Kubernetes ServiceAccount，因此 SandboxWarmPool 资源中的所有预热 Pod 都共享同一身份。如需按代理或租户隔离身份，请为每个身份维护一个单独的 SandboxWarmPool 资源，或按需创建 Sandbox 资源，而不使用预热池。

您可以使用标准 Kubernetes Secret 对象或 CSI 卷将 Secret 装载到 Pod 中。Agent Sandbox 不包含用于在沙盒外注入凭证的网关。如需在传输过程中注入凭据，请部署您自己的外部代理。

控制器会为每个 SandboxTemplate 资源创建一个默认拒绝的 NetworkPolicy 对象。对于您直接创建（不使用模板）的沙盒资源，请创建您自己的 NetworkPolicy 对象。您可以使用标准 GKE 网络控制来限制流量：

  • 第 4 层：使用 GKE 网络政策（NetworkPolicy 对象）限制 Pod 到 Pod 的流量和 IP 流量。
  • 第 7 层：使用 FQDN 网络政策（FQDNNetworkPolicy 对象）将出站连接限制为已获批准的网域。

空闲暂停、Pod 快照和存储

空闲代理的 Pod 会保留其预留的 CPU 和内存，直到您的应用通过将其 spec.operatingMode 字段设置为 Suspended 来暂停 Sandbox 资源。暂停 Sandbox 资源会删除 Pod，但会保留其永久性卷。删除 Pod 会清除内存中的数据和容器文件系统更改。如需从 Cloud Storage 保存和恢复该状态，请在暂停代理之前创建 GKE Pod 快照。Pod 快照需要 gVisor 运行时，不支持微型虚拟机或 TPU。从快照恢复 Pod 大约需要 3 到 5 秒。

如需在 Pod 快照之外使用永久性存储，请从以下选项中进行选择：

比较 Agent Substrate 和 Agent Sandbox

下表总结了 GKE 上的 Agent Substrate 与 GKE 上的 Agent Sandbox 之间的架构差异：

维度 GKE 上的 Agent Substrate（基于 actor） GKE 上的 Agent Sandbox（基于 Pod）
推荐的 AI 智能体工作负载 大多数基于 CPU 的有状态智能体，这些智能体经常暂停和恢复 持续活跃的代理、GPU 或 TPU 工作负载、自定义 PodSpec、Arm 节点或 GKE Autopilot
调度单元 多个 actor 共享一个预热 Pod 池 (WorkerPool) 每个智能体一个专用 Pod（沙盒）
沙盒运行时 gVisor 和 Cloud Hypervisor 微虚拟机（在 WorkerPool Pod 中管理） GKE Standard 上的 gVisor 和微虚拟机（在节点池或 ComputeClass 上启用了 GKE Sandbox），或 GKE Autopilot 上的 gVisor（默认启用）
预热池 跨 actor 模板和容器映像共享 WorkerPool 资源 每个模板和容器映像一个 SandboxWarmPool 资源
控制平面路径 kube-apiserver 组件外部的专用控制平面和数据库 标准 Kubernetes 控制器、kube-apiserver 和 etcd
空闲资源处理 暂停闲置 actor 会释放其工作器 CPU 和内存 暂停空闲的 Sandbox 资源会删除其 Pod 并保留永久性卷
状态检查点 gVisor 和微型虚拟机上的内置 Cloud Storage 快照，可在不到一秒的时间内恢复 GKE Pod 快照（仅在 gVisor 上受支持），可在 3-5 秒内恢复
支持的集群模式 GKE Standard（1.37 版或更高版本，x86 节点） GKE Standard 和 GKE Autopilot
硬件加速器 不支持（仅限 CPU 的工作器节点） 仅支持 gVisor 运行时的 GPU 和 TPU
Kubernetes PodSpec 支持 在 ActorTemplate 和 WorkerPool 资源之间拆分子集 完整的 PodSpec，包括边车和 init 容器
网络 内置 Envoy 入站和出站网关，具有按 actor 分配的 mTLS 隧道 Kubernetes 服务、NetworkPolicy 和 FQDNNetworkPolicy
身份模型 每个参与者的 SPIFFE X.509 证书和 JWT 使用 Workload Identity Federation for GKE 或代理身份（预览版）的 Pod ServiceAccount，在温池中共享
Secret 管理 在出站流量网关处注入到出站请求中 使用 Kubernetes Secret 对象或 CSI 卷装载到 Pod 中

选择沙盒运行时

Agent Substrate 和 Agent Sandbox 都会使用 Cloud Hypervisor 微虚拟机或 gVisor 将不受信任的代码与主机节点隔离，但您在每个模型中配置运行时的方式不同：

  • Agent Substrate：在 WorkerPool 资源上选择运行时。Agent Substrate 在其 WorkerPool Pod 中管理自己的 microVM 和 gVisor 运行时，而不是使用节点级 GKE Sandbox 功能。请勿在 Agent Substrate 工作器节点池上启用 GKE Sandbox，因为 sandbox.gke.io/runtime 节点污点会阻止 WorkerPool Pod 调度。
  • Agent Sandbox：在 SandboxTemplate 资源的 Pod 模板中，将 runtimeClassName 字段设置为 gvisor 或 microvm。在 GKE Standard 上，还需在节点池或自定义 ComputeClass 中启用 GKE Sandbox。在 GKE Autopilot 上，gVisor 默认可用，并且不支持微型虚拟机。

这两种运行时都会运行不受信任的代码和无头浏览器：

  • MicroVMs：每个沙盒都在具有专用客机 Linux 内核的轻量级虚拟机中运行。如果您需要虚拟机级隔离、完整的 Linux 系统调用兼容性，或多容器 actor 中每个容器的 CPU 和内存限制，请选择微虚拟机。
  • gVisor：每个沙盒都在用户空间内核中运行，该内核会拦截和过滤 Linux 系统调用。选择 gVisor 可实现更快的冷启动、更低的内存开销或更广泛的 Compute Engine 机器支持（包括 Agent Sandbox 中的 GPU、TPU、Arm 节点和 GKE Autopilot）。

下表比较了 GKE 上的微型虚拟机和 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)。GKE Sandbox 中的 Container-Optimized OS (cos_containerd) 或 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 推理和代码执行沙盒
  • Web 前端、缓存和代理

如需详细了解这些隔离技术，请参阅 GKE Sandbox。

后续步骤