Agent Substrate on GKE 简介

GKE 上的 Agent Substrate 可在 Kubernetes 集群中大规模运行智能体工作负载。它解决了常见的资源效率低下的问题：交互式智能体（例如个人助理和编码智能体）通常大部分时间都在等待用户输入或外部触发器。让这些处于闲置状态的智能体持续运行会占用 CPU 和内存，而这些资源原本可以分配给活跃的工作负载。

GKE 上的 Agent Substrate 通过暂停闲置智能体并拍摄智能体活跃内存 (RAM) 和本地文件的快照来解决此问题。当暂停的智能体需要再次执行操作时，系统会在不到一秒的时间内将智能体的状态恢复到可用的沙盒中。

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 会在 substrate-gke 代码库中为 符合条件的 Google Cloud 客户提供针对 GKE 优化的部署工具和脚本。

GKE 上的 Agent Substrate 的优势

您可以使用 GKE 上的 Agent Substrate 实现以下目标：

  • 安全运行不受信任的代码：GKE 上的 Agent Substrate 会强制执行内核和网络隔离，以便您执行 AI 生成的代码，而不会给更广泛的基础架构带来风险。
  • 构建长时间运行的有状态智能体：智能体的工作内存和文件 会在会话之间保留。智能体会从暂停的确切位置恢复。
  • 实时响应请求：当新请求触发 暂停的智能体时，系统会在极短的时间内恢复智能体的状态。
  • 降低计算费用：您可以通过 在所有智能体之间共享工作器沙盒池，在更少的机器上运行更多智能体。由于闲置智能体会暂停且不使用 CPU 和内存，因此只有当智能体主动处理任务时，您才需要支付计算费用。

使用场景

GKE 上的 Agent Substrate 旨在运行任何规模的智能体，从数十个到数百万个并发智能体。以下是三个示例工作负载：

  • 生产力智能体：长期后台助理，可在数周内保持 上下文。由于这些助理大部分时间都在等待触发器，因此在不使用时暂停工作负载可以降低计算费用。
  • 临时沙盒：按需隔离的环境，用于执行 不受信任的 LLM 生成的代码、运行工具调用或分析数据。 由于沙盒会在不到一秒的时间内恢复，因此系统可以为短期任务提供一次性环境，并在执行完成后释放资源。
  • 编码智能体：AI 助理，可与 开发者进行实时对话，以编写、构建和测试代码。智能体在沙盒内运行终端命令并修改文件。当智能体处于闲置状态时，系统会暂停它，直到开发者发送另一个提示。

GKE 上的 Agent Substrate 的工作原理

GKE 上的 Agent Substrate 基于 Kubernetes 构建，但您无需了解 Kubernetes 即可使用它。GKE 上的 Agent Substrate 的核心概念如下：

  • Actor：智能体的单个运行实例。
  • ActorTemplate：用于实例化 Actor 的配置蓝图（定义容器映像、 环境变量和计算资源）。
  • 工作器：活跃 Actor 在其中运行的安全沙盒。
  • WorkerPool：一组预先启动的闲置工作器，它们随时准备 接收 Actor。

由于 Actor 不与特定工作器绑定，因此系统可以暂停闲置智能体并重复使用释放的计算资源。借助此架构，系统可以在有限数量的机器上运行数百万个智能体。

典型的智能体生命周期遵循以下步骤：

  1. 路由：来自应用的每个传入 API 请求都会指定其 目标 Actor。例如，当用户在聊天界面中输入新提示时，您的应用会向管理用户会话的特定 Actor 发送请求。
  2. 恢复：如果请求是针对暂停的 Actor，系统会从工作器池中声明一个 暖工作器，并将 Actor 的快照恢复到该 工作器上。
  3. 执行：系统会将请求路由到这个新活跃的工作器， Actor 会处理该任务。
  4. 暂停：当 Actor 完成工作并处于闲置状态时， 系统会拍摄 Actor 的内存和文件的新快照，将 快照保存到存储空间，并将空工作器释放回池中。

工作负载隔离和 GKE Sandbox

GKE 上的 Agent Substrate 使用 gVisor 或 Cloud Hypervisor 在 沙盒中运行每个工作负载，该沙盒会将应用代码与宿主机内核隔离。GKE 上的 Agent Substrate 安装包含工作器的 gVisor 运行时，因此您无需在 底层 GKE 节点上配置 GKE Sandbox。

限制和要求

GKE 上的 Agent Substrate 有以下限制和要求：

  • 集群版本和 Beta 版 API：GKE 上的 Agent Substrate 受运行版本 1.36（已启用 Beta 版标志）或版本 1.37 或更高版本的 GKE Standard 集群支持。不支持低于 1.36 的版本。此外，GKE 需要 Beta 版 API（podcertificaterequests 和 clustertrustbundles）。如果您在运行版本 1.36 的现有集群上启用这些 API，还必须替换现有节点，以便在这些节点上启用 Pod 证书投影。在版本 1.37 或更高版本上，无需替换现有节点。
  • Workload Identity Federation for GKE：GKE 集群必须启用 Workload Identity Federation for GKE 。GKE 上的 Agent Substrate 使用 适用于 GKE 的工作负载身份联合向 Google Cloud API 进行身份验证，例如 Cloud Storage（用于保存智能体快照）。
  • 虚拟机系列:
    • 混合 CPU 架构：由于 gVisor 存在已知问题，GKE 上的 Agent Substrate 不支持在混合 CPU 架构（例如 E2 机器类型）上运行的通用机器系列。
    • 每个 Actor 模板的虚拟机类型一致：不支持在单个 ActorTemplate（用于创建 Actor 的配置蓝图）中混合使用虚拟机类型。例如，如果您的集群有两个使用 C4 和 N2 虚拟机的节点池，则 ActorTemplate 必须包含一个节点选择器，用于指定单个虚拟机类型（例如 C4），以防止该模板的 Actor 分散到不同的机器类型中。
  • GPU 支持：不支持将 GPU 设备直通到 Actor 容器中 。指定 nvidia.com/gpu 仅会将 Pod 放置在启用 GPU 的节点上，但不会将 GPU 设备传递到 Actor 容器中。此外，gVisor 无法拍摄活跃 CUDA 上下文的快照。
  • 网络：
    • 出站政策：EgressPolicy 规则（按 主机名和 IP 地址进行网络控制）不受支持，包括以下 功能：
      • 默认拒绝规则
      • 基于主机名的规则
      • 凭据注入
    • 打开的连接：当智能体 暂停时，不会保留打开的网络连接（例如数据库 会话或与 MCP 服务器的连接）。您的智能体代码必须在智能体恢复时处理与外部服务的重新连接。
  • 可观测性和托管式 OpenTelemetry：GKE 的 托管式 OpenTelemetry具有 以下限制：
    • GKE 的托管式 OpenTelemetry 处于预览版阶段。
    • 不支持收集器连接器，这需要使用外部代理计量器进行遥测基准评测。
    • 收集器部署会产生内存缓存开销，该开销在大型集群中与 Pod 数量呈线性关系。
    • GKE 的托管式 OpenTelemetry 不支持 TLS。
  • 存储空间：系统需要Cloud Storage来保存智能体的 快照。
  • 安装环境：您无法在 Cloud Shell 中安装 GKE 上的 Agent Substrate。Cloud Shell 的永久性磁盘存储空间限制为 5 GB，这无法为安装提供足够的磁盘可用空间。您必须从具有足够磁盘可用空间的本地工作站或虚拟机 (VM) 安装 GKE 上的 Agent Substrate。

后续步骤