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

扒源码 | Cube Sandbox 的微虚机、容器镜像、可写层，是怎么串到一起的

news 2026/7/5 2:03:10

本文作者洪志国，原文发布于个人技术博客。作者基于 Cube Sandbox v0.1.1 测试环境对其存储架构进行了一次深度拆解，公众号经作者同意，对原文做了少量适配性编辑。

如果你已经在用 Cube Sandbox，可能会想过几个问题：

◆ 我跑一个沙箱，容器镜像到底放在宿主机上还是微虚机里？

◆ 我同时拉起 10 个一样的沙箱，会不会浪费 10 倍内存去缓存同一份镜像？

◆ 我对沙箱里的文件做的修改，最终落到了哪一块磁盘上？

◆ Cube 号称"几十毫秒起一台沙箱"，这件事在存储层是怎么做到的？

◆ “从快照启动"和"从镜像启动”——名字差不多，底层走的是同一套存储路径吗？

这些问题不影响你"用"Cube，但会影响你信任它、调优它，或者真的把它跑到生产。我自己最近想搞清楚这些，就在一个 v0.1.1 的测试环境里把存储这条链路从头到尾扒了一遍。

整个过程比想象中要曲折，还顺手扒出了一个我觉得可能有问题的设计（先卖个关子，文末讲）。这篇就把我看到的东西整理出来，希望对你有用。

◆一、先看一台沙箱启动时，到底都准备了什么◆

Cube Sandbox 的运行时模型是“宿主机 → 微虚机 (MVM) → 容器”这样一个三层夹心。要看清存储架构，最方便的入口是微虚机的配置文件 vm.info。

以一个 sandbox（id 取头一段 4d656bd3...）为例，可以通过一条命令拿到它的完整 vm.info：

curl --unix-socket /run/vc/vm/4d656bd3.../chapi \http://localhost/api/v1/vm.info | jq

vm.info 里包含了这台微虚机的所有秘密——内核启动参数、虚拟块设备清单、virtiofs 挂载、网络配置等等。后面的所有分析，都是从这个文件里反推出来的。

另外，Cube 启动一台沙箱有两种入口：

◆从镜像创建—— 直接拉一个 Docker 镜像跑

◆从快照恢复—— 从一个预先打好的模板（template）恢复

这两条路径在"存储"这一块走的不是同一条流水线。下面分开讲。

◆从镜像创建：四块磁盘各司其职◆

从镜像创建 sandbox 的存储架构总览图

2.1 一个最小化的启动请求长什么样

{"volumes": [{ "name": "rootfs-wlayer", "volume_source": { "empty_dir": { "SizeLimit": "1Gi" } } },{ "name": "tmp", "volume_source": { "empty_dir": { "SizeLimit": "2Gi" } } }],"containers": [{"name": "nginx","image": { "image": "nginx:latest" },"command": ["sleep"], "args": ["1000000"],"volume_mounts": [{ "name": "rootfs-wlayer", "container_path": "/" },{ "name": "tmp", "container_path": "/mnt1" }],"resources": { "cpu": "500m", "mem": "512Mi" },"security_context": { "readonly_rootfs": false }}]}

注意两个 empty_dir：一个挂到容器根目录 /（其实是当作可写层用），另一个挂到 /mnt1（类似 k8s 的 emptyDir 临时卷）。后面会看到它俩在虚机里其实是两块 virtio-blk 磁盘。

执行 cubecli cubebox create req.json，沙箱起来了。下面开始一块一块磁盘看进去。

2.2 微虚机的系统盘：只读的 pmem，没有 page cache 开销

从 vm.info 的 .config.payload.cmdline 字段可以看到：

root=/dev/pmem0 rootflags=dax,errors=remount-ro ro rootfstype=ext4

这说明微虚机的根文件系统挂在/dev/pmem0上，只读、启用DAX。

进一步从 .config.pmem[0].file 找到这个 pmem 的真身——宿主机上的一个 raw image 文件：

/usr/local/services/cubetoolbox/cube-image/cube-guest-image-cpu.img

可以手动 loop 挂载验证，里面就是一个标准的 ext4 文件系统。

这里 Cube 做了两件挺聪明的事：

◆用 pmem 而不是 virtio-blk—— 微虚机里的 ext4 访问数据时不走 block I/O 请求路径，直接当内存读；

◆挂载时加 dax=always—— 微虚机内绕过 page cache，避免每台沙箱都给自己复制一份系统盘缓存。

如果你在一台宿主机上跑十几个沙箱，这一条直接省下十几份系统盘缓存的内存开销。

💡小结：微虚机系统盘 = 宿主机上的一个 raw image + pmem + DAX 只读挂载。多沙箱共享，零 page cache。

2.3 容器镜像：宿主机 containerd 解压 + virtiofs 透传

容器镜像这一块走的是相对"传统"的路线：

镜像先被 cubelet 下载到宿主机，并按 containerd 的 overlayfs snapshotter 展开：

/data/cubelet/root/io.containerd.snapshotter.v1.overlayfs/refs/default├── f68a8bcb.../{fs,work}├── cbf2c778.../{fs,work}├── 894f3fad.../{fs,work}└── a464c54f.../{fs,work}

每个子目录是镜像的一个 layer。然后 Cube 通过virtiofs把这些 layer 目录透传给微虚机——vm.info 的 .config.fs 部分里能看到 4 个 layer 全部 mount 了进来，tag 统一是 cubeShared。

但注意 virtiofs 的一个关键参数：backendfs_config.cache = 2。

cache 值	策略	一致性 vs 性能
0 (none)	Guest 不缓存，每次走 Host	一致性最好，性能最差
1 (auto)	元数据缓存 1s，close-to-open	默认推荐
2 (always)	所有内容永久缓存	性能最好，一致性最差

Cube 选了最激进的 always。这意味着：镜像内容会在微虚机里产生 page cache。如果同一台宿主机上 10 个沙箱用同一个镜像，会产生 10 份重复的 page cache——这个跟系统盘 pmem 的"零 cache"形成了一个有意思的反差。

不过考虑到容器镜像在沙箱里是高频读取的、且 Cube 这里追求的是"启动快"，这个权衡是说得通的。

💡小结：容器镜像 = 宿主机 containerd 解压成 layer + virtiofs 透传给微虚机。性能优先，会有重复 page cache。

2.4 容器的可写层：reflink + 预热池，两层启动加速

这一节是 Cube 工程细节最密、也最值得拆出来讲的部分。

◆2.4.1 宿主机上的空磁盘文件长什么样

vm.info 里有两个 virtio-blk 磁盘（vda、vdb），对应宿主机上 /data/cubelet/storage/io.cubelet.internal.v1.storage/emptydir/ 目录下的两个 raw image 文件：

emptydir/├── 1Gi/│ ├── 0/{16ab39..., 7cdb97..., base.raw}│ └── 1/{0c8cfd..., 0ebae4..., base.raw}├── cubebox/└── othersv2/├── 0/base.raw└── 1/{4b4302..., base.raw}

每个 UUID 文件就是一个微虚机 virtio-blk 设备的后端，初始内容是一个空的 ext2 文件系统。1Gi 的放 1Gi/ 下，其他容量的放 othersv2/。

那么问题来了——沙箱启动那一刻，这些"空磁盘"是从哪冒出来的？格式化一个 ext 文件系统不是瞬间能完成的事，为什么 Cube 能做到几十毫秒起一个沙箱？

答案是两层优化叠加：reflink + 预热池。

◆2.4.2 第一层：reflink，让"复制磁盘"几乎不消耗磁盘空间

reflink（Copy-on-Write Link）是支持 CoW 的文件系统提供的高效文件克隆能力。

◆ 普通 cp：复制 inode + 复制所有数据块，时间和空间都跟原文件大小成正比；

◆cp --reflink：只复制 inode，两个文件共享底层数据块；只有被修改的块才会真正复制——典型的写时复制。

对 Cube 这个场景来说，这等于：一个 1GiB 的 base.raw 可以瞬间"复制"出一堆派生文件，磁盘几乎不占额外空间，IO 也几乎为零。

但 reflink 有一个硬性前提——底层文件系统必须支持它。目前 ext 系列不支持，xfs 和 btrfs 支持。所以官方建议 /data/cubelet 用 xfs；cubelet 启动时 plugin.go 的 checkPoolType() 会自动探测，不支持 reflink 就回退到普通拷贝——能跑，但启动会慢一些。

如果你在生产里跑 Cube，这是一个一定要确认的部署细节。

◆2.4.3 第二层：预热池，把 reflink 也提前做好

光有 reflink 还不够——cubelet 把这条优化又往前推了一步：连 reflink 这一步本身都提前做掉。

配置项 PoolDefaultFormatSizeList（默认 ["1Gi"]）声明了要为哪些容量做预热。以 1Gi 为例：

◆ 在 emptydir/1Gi/ 下预先创建0 ~ 99 共 100 个子目录；

◆ 每个子目录里预先生成一个 base.raw；

◆ 然后从这个 base.raw 通过 reflink预先克隆出一批可直接拿走的 raw 文件——这就是上面目录树里那些 UUID 文件。

base.raw 本身的创建逻辑在 newExt4BaseRaw() 函数里，流程是：

touch → truncate → mkfs.ext4 → mount → mkdir → umount

这是一次性的、相对耗时的"格式化 + 初始化目录结构"。但只要做一次，后续所有需要 1Gi 可写层的沙箱都能直接"拎走一个"。

◆2.4.4 不常见容量怎么办：othersv2 走即时创建路径

如果请求的可写层容量经过 normalizeRootfsSizes 规整化后没有落在预热池里（比如 2Gi、5Gi），就会走 othersv2/ 路径。

othersv2/ 也有 100 个预创建子目录、每个里面也有 base.raw，但不预先 reflink。当请求来了，cubelet 现场做：

reflink(base.raw → new.raw) → truncate → e2fsck → resize2fs

—— 把基础镜像 reflink 出来，再 truncate 到目标大小，跑 e2fsck 修一下文件系统，最后 resize2fs 把文件系统真正撑到指定容量。

这条路径比预热池慢，但比"从零格式化"还是快得多。

💡小结：Cube 把"几十毫秒起一个沙箱"做到的关键秘诀之一，是把磁盘准备的成本拆成两层往前移——base 文件系统预先 mkfs 好，常见容量的 reflink 副本也预先做好；沙箱真正启动时，只需要从池子里"拎走一个 inode"。

📌作者注：这块逻辑在后续新版本中发生了巨大变化，后面有空专门再梳理一下。本文基于 v0.1.1，仅作为参考。

2.5 微虚机里：怎么把这一堆磁盘拼成容器的根目录？

登进微虚机看一眼挂载：

bash-5.2# mount/dev/pmem0 on / type ext4 (ro,relatime,errors=remount-ro,dax=always)/dev/vda on /run/blk-cube/vda type ext4 (rw,relatime)/dev/vdb on /run/blk-cube/vdb type ext4 (rw,relatime)cubeShared on /run/cube-containers/shared/containers type virtiofs (ro,relatime)overlay2 on /run/cube-containers/b48b9c8.../rootfs type overlay(rw,lowerdir=/run/cube-containers/shared/containers/{f68a8bcb..,cbf2c778..,894f3fad..,a464c54f..}/fs,upperdir=/run/blk-cube/vda/disk/b48b9c8.../upper,workdir =/run/blk-cube/vda/disk/b48b9c8.../work)

最后那条 overlayfs 挂载，就是容器真正的 rootfs。逻辑很清晰：

◆lowerdir= virtiofs 透传进来的 4 个镜像 layer（只读）

◆upperdir= virtio-blk vda 上的子目录（可写）

◆挂载点= /run/cube-containers/<sandbox-id>/rootfs，这个就是容器进程看到的根目录

至于 vdb，对应 req.json 里那个挂到 /mnt1 的 emptyDir——通过 bind mount 暴露到容器里就行了。

到这里，从镜像启动的整条存储链路就串完了：

宿主机 raw image (pmem 只读根) + 宿主机 containerd layer (virtiofs 透传) + 宿主机预制空磁盘 (virtio-blk 可写层) → 微虚机 overlayfs 合并 → 容器 rootfs

◆三、从快照启动：另一条路径，主要差在镜像怎么走◆

如果你用的是 E2B 协议，那 sandbox 必须从模板（快照）创建。这条路径跟前面主要差在"容器镜像怎么从宿主机进到微虚机"这一步。

从快照创建 sandbox 的存储架构总览图

3.1 快照里到底存了什么

快照包含三部分，分别落在两个目录下：

/usr/local/services/cubetoolbox/├── cubebox_os_image/│ └── rfs-32b1e04a.../│ ├── rfs-32b1e04a....ext4 ← 容器镜像合并视图，打包成 ext4 raw image│ ├── rfs-32b1e04a....vm ← 微虚机内核二进制│ └── version└── cube-snapshot/cubebox/└── tpl-kvm-1/2C4096M/├── metadata.json└── snapshot/├── config.json├── memory-ranges ← 内存快照└── state.json ← CPU 状态

注意 .ext4 文件——这是 Cube 启动加速的关键设计：把容器镜像所有 layer 合并叠加之后的视图，整体打包成一个 ext4 文件系统。这样从快照启动时，不需要再走 containerd 的解压流程，一个文件直接挂上去就能用。

3.2 微虚机里看到的差异

进微虚机看：

/dev/pmem0 on / type ext4 (ro, dax=always)/dev/pmem1 on /run/cube-containers/sandbox/pmem-cube/pmem1 type ext4 (ro, dax=always) ← 新增/dev/vda on /run/blk-cube/vda type ext4 (rw)

多了一个/dev/pmem1——就是上面那个 .ext4 镜像合并视图，以 pmem + DAX 方式挂载。

然后 overlayfs 就用 pmem1 作 lowerdir，vda 作 upperdir，跟从镜像启动的拼装方式一样。

3.3 关键差异：从 virtiofs 走到了 pmem

把两种方式对照一下就一目了然了：

	从镜像创建	从快照创建
宿主机上镜像形态	每个 layer 一个子目录（containerd 默认）	layer 合并后打包成一个 ext4 raw image
镜像怎么进微虚机	virtiofs（cache=always）	pmem 块设备 + DAX
微虚机内 page cache	会产生重复 page cache	零 page cache 开销
启动速度	较慢（要先解压 + virtiofs 拉起）	快（一个文件挂上去就行）