隔离边界决定攻击面#

容器依赖共享内核的 namespace、cgroup 和权限机制；gVisor 增加用户态系统调用边界；microVM 使用独立 Guest Kernel；Wasm 从显式能力集合开始。

这个选择先决定逃逸后果与 Linux 兼容范围。只有威胁模型允许的方案，才有继续比较启动时间和成本的意义。

构造方式决定启动与弹性#

共享宿主内核的容器主要创建进程与文件层，资源限额也能运行时调整。microVM 需要虚拟硬件、Guest Kernel 和设备状态，通常通过快照、CoW 与 Warm Pool 摊薄启动成本。

同一差异又出现在镜像上：OCI 原生文件分层，microVM 需要自行组织 RootFS、块级差异或文件共享。启动优化不是独立技巧，而是为所选隔离边界支付成本的方式。

状态位置决定调度与恢复#

实例状态只在本地时，调度必须找到持有镜像、快照或 Workspace 的节点；状态外置后，迁移更容易，但会增加网络与一致性成本。

网络也遵循相同边界：引擎隔离网络栈，域名出口策略仍需独立协议层。观测则要跨越控制面、宿主、VMM 和 Guest 才能还原完整生命周期。

因此资源、存储、网络与调度都在回答同一问题：哪些事实属于实例内部，哪些必须由平台在外部持有。

我的决策链#

我会按以下顺序选型：

1
威胁模型与兼容要求
2
→ 隔离引擎
3
→ 启动与资源保证
4
→ Workspace 与镜像供给
5
→ 网络、调度和观测合同
6
→ 在真实负载上验证成本

这个顺序不能完全反转。先按启动数字选择引擎，再补安全和状态边界，通常会把不可接受的限制留到最后才发现。

Facade 可以统一 Create、Execute 和 Destroy 等上层操作，但不能隐藏 KVM、共享内核、持久挂载和出口策略等本质差异。平台应统一业务合同，同时保留会改变安全与运营成本的能力声明。