GKE 上的 Agent Sandbox 简介

Google Kubernetes Engine (GKE) 上的 Agent Sandbox 可通过在专用 Kubernetes Pod 中运行每个沙盒，帮助您管理隔离、有状态和单副本工作负载。这种基于 Pod 的架构支持 AI 智能体运行时等用例，其中不受信任的 LLM 生成的代码必须在隔离的环境中运行。

Agent Sandbox 是 Kubernetes SIG Apps 下的一个开源项目。如需在 GKE 上使用 Agent Sandbox，您需要在集群上安装 Agent Sandbox 控制器。您负责升级控制器。如需查看相关说明，请参阅在 GKE 上安装 Agent Sandbox。

本文档从概念上简要介绍了 GKE 上的 Agent Sandbox。

在基于 Pod 的架构和基于 Actor 的架构之间进行选择

GKE 提供了两种架构来编排 AI 智能体工作负载：

  • GKE 上的 Agent Substrate（基于 actor）：对于大多数智能体工作负载，尤其是频繁暂停和恢复的有状态智能体，请使用此架构。活跃代理共享一个温 Pod 池，而不是每个代理保留一个专用 Pod，因此您可以在更少的节点上运行更多代理。Agent Substrate on GKE 可自动暂停和恢复空闲工作负载。系统会将每个空闲智能体的记忆和文件保存到存储空间，并在不到一秒的时间内恢复智能体。相比之下，GKE 上的 Agent Sandbox 需要手动执行 Pod 快照，并且您需要构建应用代码来检测不活动状态并保存智能体的进度。GKE 上的 Agent Substrate 需要 GKE Standard 集群。如需了解详情，请参阅 GKE 上的 Agent Substrate 简介。
  • GKE 上的 Agent Sandbox（基于 Pod）：当每个智能体都需要在 GKE Autopilot 或 Standard 集群上拥有专用 Kubernetes Pod 时，请使用此架构。如果代理或工作负载持续处于活跃状态，并且需要以下任一功能，请选择此选项：
    • 声明式 Kubernetes API，例如 Sandbox 和 SandboxClaim 自定义资源
    • 完整的 Kubernetes PodSpec 架构，包括自定义边车和初始化容器
    • 直接访问硬件加速器，例如 GPU 或 TPU
    • GKE Autopilot 集群

为何在 GKE 上使用 Agent Sandbox

GKE 上的 Agent Sandbox 专为需要高度可扩缩性、可扩展性和安全性的智能体工作负载而构建。主要优势包括以下各项：

  • 内核级隔离：为不受信任的 LLM 生成的代码提供强大的内核级隔离。GKE 上的 Agent Sandbox 还可与开源 Kata Containers 搭配使用。如需查看有关在 GKE 上将开源 Kata Containers 与 Agent Sandbox 搭配使用的教程，请参阅在 GKE 上启用 Kata Containers。

  • 亚秒级预配：从暖池中提供沙盒，通常用时不到一秒，而无需等待标准 Kubernetes Pod 调度和启动。

  • 云原生可扩展性：利用 Kubernetes 范式的强大功能和 GKE 的托管式基础设施。

通过提供声明式标准化 API，GKE 上的 Agent Sandbox 可提供单容器体验，该体验提供类似于虚拟机 (VM) 的隔离和持久性特征，完全基于 Kubernetes 原语构建。

GKE 上的 Agent Sandbox 的常见应用场景

对于需要隔离、持久性和稳定身份的工作负载，请在 GKE 上使用 Agent Sandbox。示例使用场景包括：

  • AI 智能体运行时：在由注重安全的运行时（例如 gVisor）隔离的环境中安全地执行不受信任的代码。
  • 开发环境：为开发者提供持久、隔离的云端编码环境。
  • Notebooks 和调查工具：为 Jupyter 笔记本等交互式工具托管单容器会话。
  • 有状态单 Pod 服务：运行需要稳定身份和存储空间的应用，而无需应对 StatefulSet 的复杂性。
  • 以编程方式管理环境：使用提供的客户端库 SDK（例如 Agent Sandbox Python SDK），直接从应用逻辑请求和管理沙盒，而无需管理 Kubernetes YAML。

GKE 上的 Agent Sandbox 的工作原理

GKE 上的 Agent Sandbox 使用自定义控制器和多个 Kubernetes 自定义资源定义 (CRD) 来管理沙盒化环境的生命周期。

核心架构

  • Sandbox 自定义资源：表示单个有状态 Pod 的主要资源。该资源管理稳定的主机名、网络身份和永久性存储。
  • 沙盒路由器：一个提供稳定端点并将流量通过隧道传输到相应沙盒 Pod 的组件，可抽象化底层网络的复杂性。
  • 与 Pod 快照集成：GKE 上的 Agent Sandbox 与 GKE Pod 快照功能集成，可通过保存和恢复容器的完整状态来暂停和恢复工作负载。

版权主张模式

声明模型是一项关键功能，可将用户对环境的请求与具体实现细节（例如工作负载的预配位置和方式）分离开来。与标准 Kubernetes StatefulSet 不同，声明模型可让您请求沙盒，而无需直接管理底层 Pod 或存储配置。

声明模型使用 SandboxClaim、SandboxWarmPool 和 SandboxTemplate 自定义资源，其工作原理如下：

  1. 用户或应用通过创建引用 SandboxWarmPool 资源的 SandboxClaim 资源来请求沙盒。温池引用定义沙盒配置的 SandboxTemplate 资源。
  2. 控制器会将温池中的就绪沙盒分配给声明。 如果池中没有沙盒准备就绪，控制器会根据模板为声明创建一个新沙盒。

预热池

温池功能旨在最大限度地缩短交互式 AI 智能体场景的启动延迟时间。通过使用温池，GKE 上的 Agent Sandbox 可以在不到一秒的时间内提供执行环境。该功能使用 SandboxWarmPool 自定义资源，其工作原理如下：

  1. SandboxWarmPool 资源会维护一组处于就绪状态的预热 Pod 实例。
  2. 创建 SandboxClaim 资源后，控制器会从池中分配一个就绪的 Pod，而不是等待新 Pod 拉取映像并从头开始。
  3. 与 Pod 快照结合使用时，温池可以从预配置状态恢复 Pod，而不是从头开始启动 Pod。

网络隔离

GKE 上的 Agent Sandbox 会为您通过 SandboxTemplate 资源创建的沙盒实现默认拒绝网络安全状况。对于每个 SandboxTemplate 资源，控制器都会创建一个 NetworkPolicy 资源，以帮助确保在沙盒内执行的不可信代码默认无法访问未经授权的内部网络或 GKE 控制平面。您可以在 SandboxTemplate 资源中定义特定的网络限制以及允许的出站流量或入站流量规则，从而为智能体工作负载提供精细的安全保障。

控制器不会为您直接创建的 Sandbox 资源创建 NetworkPolicy 资源。如需限制这些沙盒的网络访问权限，请创建您自己的 NetworkPolicy 资源。

使用 SDK 以编程方式访问

AI 工程师可以使用提供的客户端库，以编程方式在 GKE 资源上使用 Agent Sandbox。例如，Python SDK 提供了一个高级接口，可为您创建底层 SandboxClaim 资源。该声明引用您创建的 SandboxWarmPool 资源。借助此接口，您可以直接从基于 Python 的智能体框架（例如 LangChain 或 Vertex AI Agentic SDK）创建隔离环境并与之交互。

限制和要求

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，不适用于微型虚拟机。如果您未指定沙盒运行时，沙盒将在没有内核隔离的情况下运行，我们不建议对不受信任的代码使用此方法。
  • 底层功能可用性：某些底层功能（例如 GKE Pod 快照）可能处于预览版阶段或仅在特定区域可用。

后续步骤