Kubernetes 沙箱管理方案洞察

K8s Agent Sandbox

开发中项目，为AI隔离运行环境提供简单的管理能力，提供一系列沙箱相关CRD及其对应的控制器，Sandbox CRD是核心，主要功能点在于：

• 稳定身份: Sandbox的主机与网络身份标识符能够保持不变
• 持久化存储: 为沙箱配置强绑定、不受重启影响的持久化存储
• 生命周期管理: 控制器能够管理Pod的增删与启停

用户可以直接通过Sandbox CRD创建Sandbox实例；也可以先创建SandboxTemplate，再创建SandboxClaim，由Reconciler创建实际的Sandbox实例。此外，用户可以提前创建SandboxWarmPool，维护一个沙箱预热池，当SandboxClaim创建时，可以直接从池中分配，减少启动延迟。

除了SandboxClaim资源用于申领Sandbox，并用于相关业务外；官方还提供了k8s-agent-sandbox SDK，用户便可通过代码方式申领并在沙箱中执行任务。需要在集群中额外部署一个sandbox-router服务，并配置forward-port或gateway暴露该服务。

OpenKruise

与沙箱管理基本无关

OpenKruise 是一个基于 Kubernetes 的扩展套件，提供云原生应用自动化的增强：

• 包含了一系列增强版本的工作负载，支持类原生工作负载功能的基础上，提供了如原地升级、可配置的扩缩容/发布策略、并发操作等增强功能。
• 高级运维功能，如镜像预拉取，容器重启等
• 高可用性防护，防止Kubernetes资源受级联删除机制的干扰

架构如下：

• Kruise-manager：提供控制器与webhook。前者用于管理各类增强工作负载的CRD，后者作为Kruise提供准入控制。
• Kruise-daemon：部署在节点上的守护进程，直接与容器运行时交互，提供镜像预热、容器重启等功能。

Kruise Agents

OpenKruise Agents在OpenKruise的在AI Agent场景的子项目，提供高层次的沙箱管理 API，实现高效的资源供给、用户管理和流量路由。针对AI Agent工作负载场景提供增强的管理能力。

• 提供沙箱资源池化与动态调整
• 沙箱休眠与检查点
• 用户身份与会话管理
• K8s CRD API+E2B API

Kruise Agents当前与K8s Agent Sandbox的相互独立的，但是在设计上保持接近，以确保Agent Sandbox项目可用时，能使Kruise Agents快速实现与其的兼容。

架构如下：

• Kruise Agents依赖于OpenKruise的部分功能，需要先安装OpenKruise核心组件。
• Sandbox controller：提供OpenKruise CRD的控制器逻辑。
• Sandbox manager：提包含控制器和Envoy代理，内置了E2B API服务。

用户可以直接通过SandBox CR创建沙箱；也可以先创建SandboxSet CR沙箱预热池，拉起一系列沙箱，再创建SandboxClaim CR或通过E2B SDK编码方式获取、使用沙箱。

Kruise Agents并非使用E2B作为底座，而是在Sandbox Manager直接内置了E2B服务器，对外提供一致的API接口，对内管理集群中的沙箱相关资源。推测是希望能够使现有基于E2B服务的业务能够平滑接入Kruise Agent。

另外内置了一套路由层，由manager负责管理，负责传递Envoy代理与沙箱实例之之间的流量，减少对Service的依赖。

选型分析

Kruise：

• Agent Sandbox仍在开发中，不稳定，不适合商用；Kruise Agents依托OpenKruise社区，是正式运营的项目，有明确的版本规划与社区支持。此外，待Agent Sandbox稳定后，Kruise Agents会进行兼容，切换成本低。
• 对于原本依赖E2B服务的业务，可以支持其向K8s生态的平滑切换。

关键技术能力

Agent Sandbox与Kruise Agents在关键能力上保持一致

• 提供Sandbox高阶抽象API，实现沙箱对象稳定身份标识、持久化存储
• 提供Manager组件，实现沙箱的生命周期管理
• 提供预热池机制，允许沙箱快速拉起
• 对外提供API接口，支持SDK方式进行沙箱生命周期管理与任务下发

CRD资源设计一致，能力相似

• Sandbox实时的创建实例
• SandboxTemplate存储沙箱模板
• SandboxWarmPool/SandboxSet创建沙箱预热池
• SandboxClaim申领沙箱资源

Agent Sandbox是K8s社区官方项目，Kruise Agents会在前者可用后保证兼容性。

生态兼容性

• 容器运行时

作为沙箱管理体系，Agent Sandbox与Kruise Agents本身并不直接依赖具体的容器运行时。它们通过调用API Server创建和管理沙箱资源，而沙箱的实际运行载体仍然是Pod。因此，底层依然复用K8s的容器运行时机制，可以通过原生方式（RuntimeClass）来指定运行时环境。只要能够接入K8s生态的容器运行时，无论是否是安全容器运行时，应当都可以被Agent Sandbox与Kruise Agents使用。

• 存储

沙箱需要持久化存储，可能需要存储能力作为支撑。对于基础的持久化存储创建、删除等，直接用K8s本身的存储机制（SC、PV、PVC等）。Agent Sandbox暂无其他存储相关能力，因此没有明确的存储类要求；Kruise Agents依赖ACS服务存储实现Checkpoint管理能力。

结构扩展性

• 网关

如果需要使用SDK管理、使用沙箱，需要安装额外的网关控制器，从而将接口对外暴露。Agent Sandbox作为K8s官方社区项目，使用Gateway作为对外暴露方式，Kruise Agents则依然使用Ingress。两者在安装包中均只提供了Gateway/Ingress资源，没有内置安装包含所需的控制器。

Agent Sandbox默认使用GKE Gateway，由于Gateway API本身接口设计与具体实现无关，也能切换到其他Gateway控制器。Kruise Agents默认使用ingress nginx，但没有用到Nginx特有能力，因此也能够切换为其他Ingress控制器。

• cert-manager

针对对外暴露的API服务，尤其是生产环境，需要挂载证书。Kruise Agents社区提供了证书挂载的最佳实践，可以手动挂载自签名证书，也提供cert-manager的自动签发支持。Agent Sandbox由于还在开发中，没有涉及证书配置。

运行时、内核能力协同

• containerd/iSula + Kata

iSula作为OpenEuler提供的通用容器引擎，提供CRI接口，支持和Kubernetes的对接。沙箱管理层对引擎的选择不感知。

Kata是云原生主流安全容器，containd/iSula均支持接入，可以通过K8s原生的RuntimeClass方式，在Pod声明时选择容器运行时，沙箱管理层对运行时的选择不感知。

• StratoVirt

StratoVirt作为OpenEuler提供的hyperviosr/vmm，支持对处于暂停状态（suspend）的虚拟机制作快照，并且支持虚拟机以快照文件为虚拟机模板批量创建新的虚拟机。可以对标ACS Agent Sandbox商业版的Checkpoint管理能力。Kruise Agents与StratoVirt层不直接相关。iS ula + kata + StratoVirt是openEuler社区验证过的技术栈，需要确认快照能力在该链路上是否打通，containerd + Kata + StratoVirt理论上也可行。

结论 AI Agent沙箱并不是“运行AI运行时”沙箱，而是旨在为AI Agent使用场景下频繁地不可信代码执行等任务提供的代码、轻量工作负载运行时沙箱，实际上也用在作为云开发环境、轻量有状态负载等场景。 K8s语境下的Sandbox对Pod、Servic以及可选的PVC等资源的高阶抽象，本质上还是用Pod运行目标实例。沙箱隔离的核心能力由底层容器运行时提供，配置遵从K8s配置运行时的最佳实践，与沙箱管理层无关。上述项目都是提供沙箱生命周期管理等能力增强，使得K8s上能够更好的运行有状态、单实例、长生命周期、需要安全隔离的工作负载。