OCI 原生提供文件级分层#

OCI 镜像由内容寻址的只读层组成。相同摘要的基础层在本地只保存一份，容器运行时通过 OverlayFS 叠加多个只读下层和一个实例独占写层。

共享、去重、拉取和挂载都由镜像格式与运行时共同完成。代价是首次修改下层文件时需要 Copy-up，大文件的小改动也可能复制整个文件。

Firecracker 只看到完整块设备#

Firecracker 接收 RootFS 块设备，不理解 OCI 文件层。要获得“共享基线 + 私有差异”，平台需要另外选择：

• Guest 内使用 OverlayFS；
• 宿主侧使用 qcow2 或块级 CoW；
• 从快照恢复共享内存与磁盘基线；
• 通过文件共享协议接入外部内容。

这些方案的并发只读、写层回收和一致性都由平台负责。microVM 的隔离优势不会自动带来容器式镜像管理体验。

Kata 选择两条供给路径#

Kata 的思路更接近：通用 Guest 系统镜像单独维护，容器内容通过 virtio-fs 等方式从宿主共享进入 Guest。它没有强求把所有内容塞入一个可分层磁盘格式。

这种拆分说明，稳定系统与高频变化内容可以采用不同分发机制。系统镜像关注启动和安全更新，任务内容关注共享、挂载和租户隔离。

我的选择：按变化频率拆分内容#

容器工作负载直接使用 OCI 分层。Firecracker 场景下，我会把稳定 RootFS、运行时快照和用户 Workspace 分开管理，而不是自行复制一套完整 OCI 语义。

代价是供应链和回收路径更多，但每层职责清晰。若 workload 需要频繁切换大量现有容器镜像，Kata 式共享更适合；若环境固定且隔离优先，预构建 RootFS 与快照更简单。分层是否“原生”，决定的是平台需要补多少工程，不决定隔离强度。