当前位置：首页 > news >正文

Cube v0.5.0发布：自动暂停 · ARM 支持· 一键集群部署，把沙箱送进生产

news 2026/7/5 2:13:15

如果说 Cube Sandbox v0.3.0 解决的是"快"（毫秒级的快照 / 克隆 / 回滚），v0.4.0 解决的是"治理"（L7 出站管控 + 可观测性 + 集群一致性），那么 v0.5.0 想解决的是——"稳、省、广"。

◆省：Agent 沙箱大部分时间是在"等"，等用户输入、等回调、等下一轮 rollout。解决这些"空跑"占用沙箱的 CPU 和内存。

◆广：AI 时代的算力基座正在从 x86 独大走向 x86 / ARM 双轨。解决沙箱能原生跑在 ARM 上。

◆稳：解决用户从单机 Demo 到云上集群部署，提供一个生产环境一键部署的架构示例。

◆一、AutoPause / AutoResume：让沙箱学会自己"睡觉"◆

Agent 的世界里，沙箱大部分时间都在闲置：等用户下一条指令、等长任务回调、等 Agentic RL 的下一轮 rollout。在日均运行成千上万个沙箱的生产环境，这就是在给白白燃烧的服务器预算买单。

v0.5.0 版本中的第一个核心特性就是让沙箱学会自动暂停（AutoPause）与唤醒（AutoResume），且把这个做成了平台侧承担的、per-sandbox 的能力。在 SDK 侧，lifecycle 变成了 Sandbox.create 的标准参数，语义与 E2B 完全对齐：

◆ 当沙箱闲置超时，控制面会自动将沙箱的运行状态（文件系统 + 内存）整体快照到磁盘，并瞬间关停底层的沙箱。此时，它在宿主机上占用的物理资源会被完全释放。

◆ 一旦有新的网络请求到达，数据面的 CubeProxy 会自动拦截，在几十毫秒内原地唤醒沙箱，无缝接管后续流量。

这套状态机的切换完全由平台自动调度。由于目前的暂停恢复还是单机行为，为了防止单机资源的过载，我们引入了一个节点级配置：host.quota.paused_resource_release_ratio（暂停资源按比例释放）。

◆ 如果设为 0，暂停不释放调度配额；

◆ 如果设为1，暂停资源的调度配额全部释放，节点调度密度直接拉满。

当节点上一大批沙箱同时被唤醒，单节点无法承载时，控制面会返回异常，并给出具体的配额数字。

当前，用户需要在可用性和高利用率之间做出权衡，进行合理的配置，后续我们会让恢复能力突破单机的界限，可以让沙箱的恢复在集群内自由漂移，最大化提高整集群的利用率，让自动暂停恢复真正做到生产级可用。

◆Arm 原生支持，正式开启“双轨架构”时代◆

在 v0.5.0 中，Arm 工程团队与 Cube 项目团队展开了深度联合研发。从代码适配、运行环境、镜像构建到基础功能验证，Cube Sandbox 已经具备在 Arm64 平台上原生部署、编译、启动和运行典型沙箱工作负载的能力，项目状态也从早期可行性验证推进到了正式 Enablement 阶段。

为了在"Agent 原生指标"上拿到极致的结果，双方重点解决了 x86 绑定依赖、hypervisor 差异、Multi-Arch 镜像、Guest Kernel 启动路径和构建验证流程等关键问题，例如：

1. 消灭 x86 绑定与硬编码假设：清理了历史遗留的 x86 架构假设与构建依赖。

2. 跨越 Hypervisor 的底层架构鸿沟

◆I/O 系统的架构跨越：我们将 Guest 对 Host 的控制通知通道从原来的PIO 改写为了 MMIO；

◆引导路径重构：x86 机器依靠轻量化 SeaBIOS 启动；针对 ARM 架构，我们改造了启动逻辑，现在可以正常使用 UEFI 固件开机；

◆Seccomp 沙盒对齐：针对 x86 与 ARM64 的系统调用号差异，重写了过滤规则。

这使得 Cube Sandbox 能够在 Arm 平台完成部署、编译和基本功能验证。更重要的是，双方将优化目标从传统 CPU benchmark 转向 Agent 场景真正关心的启动、Snapshot、Rollback、高并发和部署密度等指标，帮助用户获得更可用、更易用、更贴近生产需求的 Arm 原生沙箱能力。

关于 Cube Sandbox Arm 版本更详细的信息，请持续关注 Cube 公众号下周发布专题报道。

◆腾讯云 Terraform 集群化部署：从"能跑"到"能上生产"◆

v0.5.0 带来了官方研发的腾讯云 Terraform 集群化 deployer。

你只需要一份 release bundle，执行 create.sh 作为唯一入口，剩下的事全部交给受管的 IaC 流程。它会为你自动规划和拉起：

◆受管控制面：在腾讯云 TKE（容器服务）上拉起 cubemaster、cube-api、cubeproxy（替代旧版的路由层）和 cube-webui 等组件。为了贴合不同的业务规模与成本预期，控制面副本采用了更科学的容灾设计：

◇默认 POC 模式：控制面组件默认配置为 1 副本，轻量无额外开销，方便快速验证；

◇cubeproxy 默认保持单副本：受限于现阶段的生命周期实现，多副本会影响自动暂停/恢复的判定可靠性。为保障自动休眠唤醒功能的绝对稳定，当前版本强烈建议将其保持为 1 副本，后续版本我们会将生命周期管理从cubeproxy解耦出来，cubeproxy可以多副本高可用运行；

◇cubemaster 结合 CFS 镜像共享：如果需要对 cubemaster 做多副本容灾，只需一键开启腾讯云文件存储 CFS（共享存储）（TENCENTCLOUD_USE_CFS=true），多副本控制面即可通过 ReadWriteMany NFS 共享挂载同一个底层镜像库（/data/CubeMaster/storage），优雅实现多机无感灾备。

◆高可用中间件：后端自动外接云数据库 MySQL 和云缓存 Redis，将元数据和状态持久化在受管云服务中，彻底告别单机容器挂载的隐患。

◆弹性计算节点：在私有 VPC 内，可弹性配置一台或多台 CVM PVM 实例或裸金属实例，作为沙箱计算节点。

同时， --mode upgrade（在线升级流）在这一版正式合入一键安装器。它在检测到既有安装后，会自动执行三路 .env 配置文件合并——既能保留你的自定义修改，又能把新的默认配置平滑合入，并在升级前对磁盘空间、semver 兼容性和网络 CIDR 冲突进行 fail-fast 预检。

从v 0.5.0 开始，Cube 的升级和集群扩容，变成了一个可预测、可重入的标准动作。

◆四、网络增强：入方向支持访问沙箱鉴权，出方向支持策略路由◆

Agent 沙箱的网络，必须做到入向极度安全，出向极度可控。v0.5.0 针对数据面网络通信提供了两项关键补丁：

◆入向——Per-sandbox 流量访问令牌：此前，只要沙箱网络打通，其入口流量近乎“裸奔”。现在，以 network.allow_public_traffic=false 创建的受限沙箱会分配到一个唯一的 traffic_access_token。CubeProxy强制拦截任何未携带该令牌的入站请求，直接返回 403。

◆出向——支持策略路由：此前，沙箱所有的出流量都会被转发至宿主机的主网卡出去，即使节点上有多张网卡配置了不同的路由或者各种隧道设备。新版本支持策略路由，流量通过一个虚拟网卡 cube-router，节点管理员可按需配置策略路由，无缝对接已有的网络基础设施，典型场景是宿主机内外网分离，以及通过隧道共享公网网关。