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 或微型虚拟机搭配使用，将 LLM 生成的不受信任的代码与节点的内核隔离开来。GKE 上的 Agent Sandbox 还可与您在节点上安装的自行管理的开源 Kata Containers（而非 GKE Sandbox）搭配使用。如需查看有关在 GKE 上将开源 Kata Containers 与 Agent Sandbox 搭配使用的教程，请参阅在 GKE 上启用 Kata Containers。

  • 亚秒级预配：为您的智能体提供预热 Pod，通常在不到一秒的时间内完成，而无需等待标准 Kubernetes Pod 调度和启动。

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

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

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

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

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

GKE 上的 Agent Sandbox 的工作原理

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

核心架构

  • 沙盒自定义资源：表示单个有状态 Pod 的主要资源。该资源管理稳定的主机名、网络身份和永久性存储。如需暂停空闲代理，请将其 Sandbox 资源的 spec.operatingMode 字段设置为 Suspended。控制器会删除 Pod，但会保留沙盒资源及其永久性卷。除非您先创建 Pod 快照，否则内存中的数据和容器文件系统更改都会丢失。如需恢复代理，请将该字段重新设置为 Running。GKE 上的 Agent Sandbox 不会检测空闲智能体；您的应用会决定何时暂停它们。
  • 沙盒路由器：一个提供稳定端点并将流量通过隧道传输到运行智能体的 Pod 的组件，可抽象化底层网络复杂性。
  • 与 Pod 快照集成：GKE 上的 Agent Sandbox 与 GKE Pod 快照功能集成，可通过保存和恢复容器的完整状态来暂停和恢复工作负载。

版权主张模式

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

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

  1. 用户或应用通过创建引用 SandboxWarmPool 资源的 SandboxClaim 资源来请求 Sandbox 资源。温池会引用定义 Pod 配置的 SandboxTemplate 资源。
  2. 控制器会将温池中已就绪的 Sandbox 资源（及其正在运行的 Pod）分配给声明。如果池中没有 Sandbox 资源准备就绪，控制器会根据模板为声明创建新的 Sandbox 资源。

预热池

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

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

网络隔离

GKE 上的 Agent Sandbox 为控制器从 SandboxTemplate 资源创建的 Pod 实现默认拒绝网络政策。对于每个 SandboxTemplate 资源，控制器都会创建一个 NetworkPolicy 资源，以帮助防止 Pod 内的不受信任代码访问未经授权的内部网络或 GKE 控制平面。您可以在 SandboxTemplate 资源中定义特定的网络限制以及允许的出站流量或入站流量规则，以控制智能体工作负载的网络访问权限。

控制器不会为您直接创建的 Sandbox 资源创建 NetworkPolicy 资源。如需限制这些沙盒资源的 Pod 的网络访问权限，请创建您自己的 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 Sandbox 运行时（gVisor 或 microVM），则 Pod 会在没有内核隔离的情况下运行，因此请勿使用它们运行不受信任的代码。
  • 硬件加速器：GPU 和 TPU 仅适用于受支持的 GPU 模型和 TPU 版本上的 gVisor 运行时，不支持微虚拟机。此外，Pod 快照不支持 TPU。
  • 底层功能可用性：某些底层功能（例如 GKE Pod 快照）可能处于预览版阶段或仅在特定区域可用。

后续步骤