60ms 启动一个安全沙箱：深入解析腾讯云 CubeSandbox 的架构设计

当 AI Agent 需要执行用户代码时，安全问题就像一颗定时炸弹。Docker 共享内核的隔离模型在 LLM 生成代码面前几乎形同虚设，而传统虚拟机的启动速度又让实时交互成为奢望。CubeSandbox 用 Rust + KVM + eBPF 给出了一个漂亮的答案：60ms 冷启动、5MB 内存开销、硬件级隔离。

1. 为什么 Docker 在 AI Agent 场景下不够安全

在聊 CubeSandbox 之前，先说一个很多人不愿意面对的事实：Docker 的 Namespace 隔离本质上是共享内核的软隔离。

当 LLM 生成一段代码并交给 Docker 容器执行时，这段代码运行在和宿主机相同的内核上。Namespace 只是做了资源视图的限制，但如果内核存在漏洞，或者代码调用了某些未被 seccomp 过滤的 syscall，容器逃逸就是分分钟的事。

css 复制代码

┌─────────────────────────────────────────┐
│              Host Kernel                │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐ │
│  │Container│  │Container│  │Container│ │
│  │  A      │  │  B      │  │  C (恶意)│ │
│  └────┬────┘  └────┬────┘  └────┬────┘ │
│       └────────────┼────────────┘       │
│            共享内核 (风险!)              │
└─────────────────────────────────────────┘

这个问题在传统微服务场景下还可以通过严格的镜像审计来缓解，但在 AI Agent 场景下完全不可控------你永远不知道 LLM 会生成什么样的代码。

CubeSandbox 的解决方案很直接：每个沙箱一个独立内核，通过 KVM 实现硬件级隔离。即使沙箱内的代码利用了内核漏洞，崩溃的也只是沙箱自己的 Guest 内核，宿主机毫发无损。

scss 复制代码

┌──────────────────────────────────────────────┐
│               Host Kernel + KVM              │
│  ┌────────────┐ ┌────────────┐ ┌────────────┐│
│  │ Guest OS 1 │ │ Guest OS 2 │ │ Guest OS 3 ││
│  │ (Agent A)  │ │ (Agent B)  │ │ (Agent C)  ││
│  │ 独立内核   │ │ 独立内核   │ │ 独立内核   ││
│  └────────────┘ └────────────┘ └────────────┘│
│       硬件级隔离 (安全!)                      │
└──────────────────────────────────────────────┘

2. 架构全景：六层组件如何协同

CubeSandbox 的架构分为六个核心组件，每个组件各司其职：

scss 复制代码

┌──────────────────────────────────────────────────────────┐
│                    SDK (E2B Compatible)                   │
├──────────────────────────────────────────────────────────┤
│              CubeAPI (Rust REST Gateway)                  │
├──────────────────────────────────────────────────────────┤
│           CubeMaster (Cluster Orchestrator)               │
├──────────────────────────────────────────────────────────┤
│              CubeProxy (Reverse Proxy)                    │
├──────────────────────────────────────────────────────────┤
│     Cubelet (Node Lifecycle Manager)                     │
│     ┌─────────────────────────────────────────────┐      │
│     │  CubeShim (containerd Shim v2)              │      │
│     │  CubeHypervisor (KVM MicroVM)               │      │
│     │  CubeVS (eBPF Network Isolation)            │      │
│     └─────────────────────────────────────────────┘      │
└──────────────────────────────────────────────────────────┘

CubeAPI 是整个系统的入口，用 Rust 编写的高并发 REST API 网关。它完全兼容 E2B SDK 的接口规范，这意味着如果你之前用的是 E2B 的云服务，只需要改一个环境变量 URL 就能无缝迁移到 CubeSandbox：

python 复制代码

import os
from e2b_code_interpreter import Sandbox

# 从 E2B 迁移到 CubeSandbox，只需要改这一行
os.environ["E2B_API_URL"] = "http://your-cubesandbox:3000"
os.environ["E2B_API_KEY"] = "dummy"

with Sandbox.create(template="your-template-id") as sandbox:
    result = sandbox.run_code("print('Hello from CubeSandbox!')")
    print(result)

CubeMaster 是集群调度器，负责接收 API 请求并分发到对应的 Cubelet 节点。它管理着整个集群的资源状态和调度策略。

CubeProxy 是反向代理，通过解析 Host header 中的 <port>-<sandbox_id>.<domain> 格式，将 SDK 客户端的请求路由到正确的沙箱实例。

Cubelet 是节点本地的调度组件，管理单个节点上所有沙箱实例的完整生命周期。它的下面是三个核心的底层组件：

CubeShim：实现 containerd Shim v2 API，让沙箱能融入容器运行时生态
CubeHypervisor：管理 KVM MicroVM，基于 Cloud Hypervisor 定制
CubeVS：基于 eBPF 的虚拟交换机，提供内核级网络隔离

3. 60ms 冷启动的秘密：资源池预分配 + 快照克隆

传统虚拟机启动慢的根源在于要走完整的 BIOS → Bootloader → Kernel → Init 流程。CubeSandbox 用了两个关键技术把这个时间压到了 60ms 以内。

3.1 资源池预分配

CubeSandbox 不是等请求来了才创建沙箱，而是提前维护一个资源池。当请求到达时，直接从池中取出一个已经初始化好的 MicroVM 实例：

scss 复制代码

请求到达 → 查找可用预分配实例 → 克隆快照 → 配置网络 → 挂载文件系统 → 就绪
            (O(1) 查表)        (CoW 拷贝)   (eBPF 注入)  (virtiofs)

这个设计的核心思想是：把串行的初始化过程变成并行的后台任务。资源池会根据历史请求模式动态调整预分配的数量。

3.2 快照克隆 (Snapshot Cloning)

预分配的实例不是一个完整的运行中的虚拟机，而是一个快照。当需要创建新沙箱时，通过 Copy-on-Write (CoW) 技术克隆快照，只复制元数据，实际的内存页在首次写入时才真正拷贝。

这就是为什么每个沙箱的额外内存开销不到 5MB------大部分内存页都是通过 CoW 共享的。

scss 复制代码

                    ┌─────────────┐
                    │ Base Snapshot│
                    │  (只读共享)  │
                    └──────┬──────┘
              ┌────────────┼────────────┐
              ▼            ▼            ▼
        ┌──────────┐ ┌──────────┐ ┌──────────┐
        │ Sandbox 1│ │ Sandbox 2│ │ Sandbox 3│
        │ (CoW页)  │ │ (CoW页)  │ │ (CoW页)  │
        │ 仅差异页 │ │ 仅差异页 │ │ 仅差异页 │
        └──────────┘ └──────────┘ └──────────┘
        内存开销: <5MB  <5MB       <5MB

4. eBPF 驱动的网络隔离：CubeVS

传统的容器网络隔离依赖 iptables 规则或者 CNI 插件，这些方案要么性能差，要么配置复杂。CubeSandbox 选择了 eBPF 这个更底层、更高效的方案。

CubeVS 是一个基于 eBPF 的虚拟交换机，它在内核态完成数据包的转发和过滤，避免了用户态和内核态之间的频繁切换：

c 复制代码

// CubeVS eBPF 程序的核心逻辑 (简化示意)
SEC("xdp")
int cubevs_ingress(struct xdp_md *ctx) {
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;
    
    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end)
        return XDP_PASS;
    
    // 解析 IP 头
    struct iphdr *iph = (void *)(eth + 1);
    if ((void *)(iph + 1) > data_end)
        return XDP_PASS;
    
    // 查找沙箱 ID 对应的网络策略
    __u32 sandbox_id = get_sandbox_id(ctx->ingress_ifindex);
    struct network_policy *policy = bpf_map_lookup_elem(&policy_map, &sandbox_id);
    
    if (!policy)
        return XDP_DROP;  // 无策略默认拒绝
    
    // 检查目标端口是否允许
    if (iph->protocol == IPPROTO_TCP) {
        struct tcphdr *tcp = (void *)iph + (iph->ihl * 4);
        if ((void *)(tcp + 1) > data_end)
            return XDP_DROP;
        
        __u16 dport = ntohs(tcp->dest);
        if (!is_port_allowed(policy, dport))
            return XDP_DROP;
    }
    
    return XDP_PASS;
}

CubeVS 提供了三个层面的隔离保障：

沙箱间隔离：不同沙箱之间的网络流量完全隔离，无法直接通信
出站流量过滤：可以精细控制沙箱能访问哪些外部地址和端口
内核级性能：XDP (eXpress Data Path) 在网络栈的最早期就介入，性能远超 iptables

5. 虚拟化层：从 Cloud Hypervisor 到 CubeHypervisor

CubeSandbox 的虚拟化层基于 Cloud Hypervisor 定制，这是一个由 Intel 主导的轻量级 VMM (Virtual Machine Monitor)。相比 QEMU，Cloud Hypervisor 的代码量小得多，攻击面也更小。

CubeHypervisor 在 Cloud Hypervisor 的基础上做了几个关键定制：

5.1 快速启动优化

裁剪了不必要的设备模拟，只保留 AI Agent 场景需要的最小设备集：

javascript 复制代码

标准 Cloud Hypervisor 设备:          CubeHypervisor 裁剪后:
├── CPU (vCPU)                       ├── CPU (vCPU)
├── Memory                           ├── Memory  
├── virtio-blk (磁盘)               ├── virtio-blk (磁盘)
├── virtio-net (网络)                ├── virtio-net (网络)
├── virtio-fs (文件系统)             ├── virtio-fs (文件系统)
├── virtio-console (控制台)          ├── virtio-console (控制台)
├── virtio-rng (随机数)              └── (移除其他非必要设备)
├── USB 控制器
├── PCI 桥接器
├── TPM 设备
└── ...

5.2 containerd 集成：CubeShim

CubeShim 实现了 containerd Shim v2 接口，这让 CubeSandbox 的沙箱可以像普通容器一样被 Kubernetes 管理：

rust 复制代码

// CubeShim 核心接口实现 (简化)
impl Task for CubeShim {
    async fn create(&self, req: CreateTaskRequest) -> Result<CreateTaskResponse> {
        // 1. 解析沙箱配置
        let config = SandboxConfig::from_bundle(&req.bundle)?;
        
        // 2. 从资源池获取预分配的 MicroVM
        let vm = self.resource_pool.acquire(config.template_id).await?;
        
        // 3. 克隆快照并配置
        let sandbox = vm.snapshot_clone(SnapshotConfig {
            memory_limit: config.memory_limit,
            cpu_count: config.cpu_count,
            disk_size: config.disk_size,
        }).await?;
        
        // 4. 配置网络 (CubeVS)
        self.network_agent.assign_ip(&sandbox).await?;
        
        // 5. 启动沙箱
        sandbox.start().await?;
        
        Ok(CreateTaskResponse {
            pid: sandbox.pid(),
            ..Default::default()
        })
    }
    
    async fn start(&self, req: StartRequest) -> Result<StartResponse> {
        // 启动沙箱内的进程
        let sandbox = self.get_sandbox(&req.id)?;
        sandbox.exec(&req.exec_id).await?;
        Ok(StartResponse::default())
    }
    
    async fn delete(&self, req: DeleteRequest) -> Result<DeleteResponse> {
        // 清理沙箱资源，归还到资源池
        let sandbox = self.remove_sandbox(&req.id)?;
        sandbox.destroy().await?;
        self.resource_pool.recycle(sandbox.base_snapshot()).await;
        Ok(DeleteResponse::default())
    }
}

6. 实战：在 60ms 内启动一个代码执行沙箱

说了这么多架构，来点实际的。下面展示如何在本地部署 CubeSandbox 并执行代码。

6.1 环境准备

bash 复制代码

# 克隆项目
git clone https://github.com/tencentcloud/CubeSandbox.git
cd CubeSandbox

# 准备开发环境 (需要 KVM 支持)
cd dev-env
./prepare_image.sh  # 下载运行时镜像
./run_vm.sh         # 启动开发环境 VM

# 在新终端登录
./login.sh

6.2 一键部署

bash 复制代码

# 在开发环境内执行
curl -sL https://github.com/tencentcloud/CubeSandbox/raw/master/deploy/one-click/online-install.sh | bash

6.3 创建沙箱模板

bash 复制代码

# 创建代码执行模板
cubemastercli tpl create-from-image \
  --image cube-sandbox-int.tencentcloudcr.com/cube-sandbox/sandbox-code:latest \
  --writable-layer-size 1G \
  --expose-port 49999 \
  --expose-port 49983 \
  --probe 49999

# 监控构建进度
cubemastercli tpl watch --job-id <job_id>

6.4 Python SDK 调用

python 复制代码

import os
import time
from e2b_code_interpreter import Sandbox

# 配置 CubeSandbox 端点
os.environ["E2B_API_URL"] = "http://127.0.0.1:3000"
os.environ["E2B_API_KEY"] = "dummy"
os.environ["CUBE_TEMPLATE_ID"] = "<your-template-id>"

# 测量启动时间
start = time.time()
with Sandbox.create(template=os.environ["CUBE_TEMPLATE_ID"]) as sandbox:
    startup_ms = (time.time() - start) * 1000
    print(f"沙箱启动耗时: {startup_ms:.1f}ms")
    
    # 在隔离环境中执行代码
    execution = sandbox.run_code("""
import sys
print(f"Python version: {sys.version}")
print("Hello from CubeSandbox!")

# 这段代码运行在独立的 Guest OS 内核中
# 即使执行 rm -rf / 也只会影响沙箱本身
import os
print(f"PID: {os.getpid()}")
print(f"Hostname: {os.uname().nodename}")
""")
    
    print(execution.text)

6.5 网络策略配置

python 复制代码

from e2b_code_interpreter import Sandbox

# 创建沙箱时指定网络策略
sandbox = Sandbox.create(
    template="your-template-id",
    # 只允许访问特定域名
    allowed_domains=["api.openai.com", "github.com"],
    # 禁止沙箱间通信
    enable_internet=True,
)

7. 性能对比：CubeSandbox vs Docker vs 传统 VM

在 AI Agent 代码执行的场景下，三个方案的对比非常直观：

指标	Docker	传统 VM	CubeSandbox
隔离级别	低 (共享内核 Namespace)	高 (独立内核)	极高 (独立内核 + eBPF)
启动速度	~200ms	数秒	<60ms
内存开销	低 (共享内核)	高 (完整 OS)	极低 (<5MB)
部署密度	高	低	极高 (单节点数千)
E2B 兼容	❌	❌	✅ 原生兼容

关键数据（在裸金属服务器上测试）：

单并发创建：平均 60ms
50 并发创建：平均 67ms，P95 90ms，P99 137ms
内存开销：32GB 规格沙箱的基础开销 < 5MB

8. 踩坑记录

在实际使用 CubeSandbox 的过程中，遇到了几个值得注意的问题：

8.1 KVM 依赖问题

CubeSandbox 需要 KVM 支持，在云服务器上可能需要额外配置。如果没有裸金属服务器，可以通过 PVM (Paravirtual Machine) 方案在普通云 VM 上启用 KVM：

bash 复制代码

# 检查 KVM 是否可用
ls /dev/kvm
# 如果不存在，需要安装 PVM Host Kernel
# 参考 docs/guide/pvm-deploy.md

8.2 镜像拉取超时

沙箱模板的镜像比较大（包含完整的 Python 环境），首次拉取可能需要较长时间。建议：

bash 复制代码

# 使用国内镜像加速
cubemastercli tpl create-from-image \
  --image cube-sandbox-cn.tencentcloudcr.com/cube-sandbox/sandbox-code:latest \
  --writable-layer-size 1G

8.3 WSL 2 环境下的嵌套虚拟化

在 Windows 的 WSL 2 中运行 CubeSandbox 需要开启嵌套虚拟化，这需要在 BIOS 中开启 VT-x，并在 WSL 配置中启用：

ini 复制代码

# %UserProfile%\.wslconfig
[wsl2]
nestedVirtualization=true

9. 适用场景与不适用场景

适合使用 CubeSandbox 的场景：

AI Agent 代码执行：最核心的场景，LLM 生成的代码需要在安全隔离的环境中运行
在线编程教育平台：学生提交的代码需要隔离执行
CI/CD 安全构建：不可信代码的构建和测试
RL 训练环境：强化学习 Agent 需要大量隔离的执行环境

不太适合的场景：

纯微服务部署：如果代码是可信的，Docker 就够了，不需要硬件级隔离
GPU 密集型任务：当前版本主要面向 CPU 场景，GPU 直通支持还在开发中
极低延迟要求（<10ms）：虽然 60ms 已经很快，但某些场景可能需要更快

10. 总结

CubeSandbox 做对了几件事：

精准的场景定位：不是要做一个通用的容器替代品，而是专门为 AI Agent 代码执行场景优化
兼容性优先：E2B SDK 兼容让迁移成本降到最低
Rust 全栈：从 API 网关到虚拟化层全部用 Rust 实现，内存安全和性能兼得
eBPF 网络隔离：比 iptables 更高效的内核级网络策略

如果你在做 AI Agent 相关的开发，需要一个安全、快速、低成本的代码执行沙箱，CubeSandbox 值得认真考虑。它已经在腾讯云的生产环境中经过了大规模验证，开源版本也保持了相当高的完成度。

项目地址：github.com/TencentClou...

参考资料

Cloud Hypervisor: A Virtual Machine Monitor for Modern Cloud Workloads - Cloud Hypervisor 的设计论文
RustVMM: A Rust-based Virtual Machine Monitor - RustVMM 项目
eBPF: The Future of Networking? - eBPF 官方文档
E2B SDK Documentation - E2B SDK 文档（CubeSandbox 兼容接口）
Copy-on-Write in Operating Systems - CoW 技术原理
XDP: eXpress Data Path - XDP 高性能网络技术