容器不是沙箱：2026 年 microVM 隔离现状综述

2026 年 MicroVM 隔离现状

早在 agentic AI 催生需求之前，microVM 生态系统就已经久经实战考验。如今它蓬勃发展、百花齐放，且演进迅速。本文涵盖所有 VMM、共享的 Rust crate 生态、十余个 AI 沙箱平台，以及坦诚的取舍权衡。

Emir Beganović Booking.com 资深 SRE，阿姆斯特丹 2026 年 3 月 27 日 · 25 分钟阅读 GitHub · LinkedIn

我刚从 KubeCon EU 2026 回来，感触颇多。AI 无处不在，生态系统明显在走向成熟，然而我在展区至少数出五家不同的公司在解决极为相似的隔离问题。这或许是一个信号：趋同要么即将发生（要么已经在发生？）总之……有一件事比什么都让我印象深刻。来自 Edera 的 Marina Moore 在她的安全主题演讲中直言不讳：

容器不是安全边界。它们是一种控制资源使用的机制。

我从十几岁起就在用 Linux，但直到最近我才真正彻底理解这句话的含义。

过去几个月，我深入钻研 microVM，在它们之上构建基础设施，学习这个领域的每一个 VMM、每一种隔离方法、每一项取舍权衡……我想写一篇我当初入门时希望拥有的指南（附上十几条参考资料、博客文章、演示文稿和 README，我挖出了太多高质量内容）。本文涵盖各种 VMM、支撑它们的共享 Rust 生态、AI 沙箱的爆发式增长，以及我认为这一切将走向何方。

microVM 生态不需要为 AI 而发明。它需要被重新发现。

本文内容：

• 为什么容器从来就不是安全边界（18 个月内 8 个逃逸 CVE）
• microVM 启动约 125ms，开销 <5 MiB —— “虚拟机很慢”的反对意见已死
• rust-vmm 共享 crate 生态：真正的革命，而非任何单一 VMM
• Firecracker 与 Cloud Hypervisor：如何选择
• 十余个 AI 沙箱平台对比 —— 从 E2B 到 SlicerVM 再到 Vercel
• gVisor、Kata Containers、Edera、KubeVirt：microVM 遇上 Kubernetes
• 完整的隔离时间线：从 chroot（1979）到 AI agent 沙箱（2026）

时间不够？ 阅读接下来两节以及结论。 正在选择 VMM？ 跳到 Firecracker 与 Cloud Hypervisor。 正在构建 agent 沙箱？ 跳到 AI Agents 让所有人都开始关注。

Linux 容器是一种打包与资源控制机制。命名空间和 cgroup 限制进程能看到什么，以及它能使用多少 CPU 和内存。但同一主机上的每个容器都共享同一个内核。一个内核漏洞、一个越权 capability、一个挂载错误的 socket，你就能成为主机上的 root，访问所有其他租户的数据。内核有约 4000 万行 C 代码，暴露450 多个系统调用。这就是攻击面。

平心而论：容器确实是一种边界。你确实需要漏洞才能逃逸。并不存在“让我出去”这样的系统调用。但内核攻击面极其庞大，逃逸 CVE 定期出现。一个让我印象深刻的类比：NAT 不是防火墙。命名空间不是安全层。两者都只是作为其设计的副作用来限制访问，而两者都常被误认为是安全边界。

长期以来，这被视为一种可接受的权衡。如果你信任容器内的代码（你自己的代码、你自己的团队），那么这种便利是值得的。

然后发生了两件事，但相隔数年。

首先，AWS 构建了 Firecracker（2018 年），一个用 Rust 编写的微型虚拟机监视器，并用它在各自硬件隔离的 VM 中运行每一个 Lambda 函数。启动时间：125ms。内存开销：<5 MiB。“直接启动一个 VM”不再是个笑话。

其次，AI 智能体开始编写并执行任意代码。每天数百万次。这些代码无人审查，由无法审计的模型生成，运行在一旦容器逃逸就意味着全盘皆输的基础设施上。

问题不再是“我们是否应该在 VM 中隔离不受信任的工作负载？”，而变成了“我们为什么还没有这么做？”

当容器“逃逸”时究竟会发生什么

将鼠标悬停在下方任意一层上，了解在每种模型中是什么将你的代码与宿主机隔开。差异并不细微。

容器 vs. MicroVM 隔离

容器

宿主内核 共享

命名空间 ns

Cgroups v2 cgroup

Seccomp-bpf 过滤器

你的代码 pid 1

MicroVM

宿主内核 + KVM 硬件

VMM（用户空间） 硬件

客户机内核 隔离

容器运行时 可选

你的代码 pid 1

将鼠标悬停在任意一层上，看看它实际做什么。剧透：容器这一侧有很多“但如果有人发现内核漏洞……”的附加条件。

在容器模型中，每一层都是由共享内核强制执行的软件约定。内核是安全边界，而内核有约 4000 万行 C 代码。在 microVM 模型中，安全边界是硬件虚拟化：Intel VT-x / AMD-V，由 CPU 本身强制执行。编排这一切的 VMM 呢？大约 83,000 行 Rust（Firecracker）或 106,000 行（Cloud Hypervisor），这是 2026 年 3 月用 cloc 测得的。

容器逃逸会让你获得宿主机的 root 权限。而 VM 逃逸需要 hypervisor CVE，这类漏洞极其罕见且价值极高，在漏洞利用市场上能卖到 25 万至 50 万美元的赏金（Google 的 kvmCTF 仅针对一个 KVM 逃逸就提供 25 万美元）。

这并非理论

容器逃逸并非假设。来自 Marina Moore 的 KubeCon EU 2026 演讲，以下是近期的 CVE，全部来自 2024-2025 年：

这些漏洞中的每一个都为攻击者提供了从容器内部通往主机的路径。在 microVM 模型中，它们都无关紧要，因为客户机内核由硬件隔离。

底线

容器逃逸是主机问题。microVM 逃逸必须跨越真正的硬件虚拟化边界，这类漏洞极为罕见，悬赏金额高达六位数。

进程隔离的尝试简史

要理解 microVM 的定位，回顾这段历程会有所帮助。我们尝试隔离进程已近 50 年，而容器只是其中的一个章节：

隔离时间线

将鼠标悬停在任意圆点上即可查看。每一代都试图以更低的开销实现更多隔离，而每一代最终都触及了共享内核的极限。

• 1979 chroot：文件系统隔离，可轻易逃逸
• 1999 FreeBSD Jails：首个真正的操作系统级虚拟化
• 2004 Solaris Zones：资源控制、隔离网络
• 2005 OpenVZ：通过补丁内核实现 Linux 容器
• 2006 cgroups：Google 向 Linux 贡献资源限制功能
• 2008 LXC：首个完整的 Linux 容器（命名空间 + cgroups）
• 2013 Docker：容器走向主流
• 2015 runc/OCI：容器运行时标准化
• 2018 Firecracker：AWS 开源了驱动 Lambda 的 VMM
• 2018 gVisor：Google 的用户空间应用内核
• 2019 Cloud Hypervisor：Intel 基于 rust-vmm 的 VMM
• 2025 AI 代理沙箱：microVM 的“Docker 时刻”

模式很清晰：每一种共享内核的方法最终都会撞上同一堵墙。chroot 没有隔离进程。FreeBSD Jails 没有隔离网络。命名空间和 cgroups 没有隔离内核 450+ 系统调用的攻击面。每一代都增加了更多软件防御层，而每一代都产生了新的逃逸 CVE。

microVM 打破了这一模式，因为它根本不共享内核。这种隔离是架构性的，而非渐进式的。

并非所有人都等到行业想明白这一点。Jessie Frazelle 早在 2018 年就提出了完全相同的论点，她的一系列博客文章在今天读来如同预言：澄清事实：容器 vs. Zones vs. Jails vs. VM、Kubernetes 中的硬多租户，以及 迈向真正的沙箱容器。她直言不讳地指出，容器从未被设计为顶层安全边界，真正的多租户隔离需要硬件虚拟化。她是对的，而行业其他部分似乎花了好几年才追上她的思路。

Rust VMM 革命

2018 年，AWS 开源了 Firecracker，改变了“轻量级虚拟机”的含义。在 Firecracker 之前，“启动一台虚拟机”意味着 QEMU：170 万行 C 代码、数百个模拟设备（包括软盘驱动器控制器，因为为什么不呢），以及以秒计的启动时间。

Firecracker 提出了一个问题：如果我们把这一切都剥离掉会怎样？没有 BIOS、没有 ACPI、没有 PCI、没有 USB……总共只有五个模拟设备，用 Rust 编写，因此整类 CVE（缓冲区溢出、释放后使用、双重释放）在编译时就被消除了。

结果：有史以来构建的最快的 VMM，而且不仅在理论上，在实践中也不懈地运行着。AWS 每月在其上运行数万亿次 Lambda 调用。每一次调用都在自己的虚拟机中。

但 Firecracker 并非凭空诞生。它的起源可以追溯到 Google 的 crosvm，即 Chrome OS 的 VMM，同样用 Rust 编写。Amazon 以 crosvm 为起点，然后构建了 Firecracker。Firecracker 之后又出现了 Cloud Hypervisor、libkrun、Dragonball Sandbox 等。它们都在不断重新发明相同的底层组件：KVM 封装、virtio 设备模型、内存管理。

这种向 KVM 的汇聚并非偶然。AWS 自己曾在 2006 年基于 Xen 推出 EC2，但从 2017 年开始迁移到 Nitro 系统，这是一个基于 KVM 的 hypervisor，搭配定制的 Annapurna Labs 芯片用于网络和存储 I/O。所有新的 EC2 实例类型都基于 Nitro；Xen 实例已是遗留。同样的模式在整个行业上演：Google Cloud 运行 KVM，Azure 转向基于 KVM 的 Hyper-V，甚至Edera——它多年来一直将 Xen 定位为更安全的选择——也在昨天 Kubecon 前后宣布支持 KVM，因为客户要求如此。当整个行业汇聚到单一的 hypervisor 接口上时，在其上构建共享基础设施就变得不可避免，而这正是 rust-vmm 的所在。

社区认识到了这种浪费。AWS、Intel、Google、Microsoft、Red Hat、Alibaba、Linaro 等开始合作开发 rust-vmm，这是一个共享的 Rust crate 生态系统，任何 VMM 项目都可以使用。Stefano Garzarella、Ruoqing He 和 Patrick Roy 的 FOSDEM 2026 演讲展示了它已经变得多么成熟：

rust-vmm crate 生态系统（2026）

核心 VM：kvm-ioctls、kvm-bindings、mshv-ioctls（Hyper-V）、xen-ioctls（Xen）、linux-loader
资源管理：vm-allocator、vm-memory（支持 IOMMU、guest_memfd、Kani 形式化验证）
设备模拟与 I/O：virtio-queue、virtio-bindings、vhost、vhost-user-backend、vfio-ioctls、vm-superio
vhost-user 设备：can、console、gpio、gpu、i2c、input、rng、scmi、scsi、sound、spi、video、vsock、virtiofsd
新增：RISC-V 架构支持、monorepo 整合（kvm、vfio、vm-virtio、vhost 工作区已合并）、POSIX/*BSD 可移植性

这是没有得到足够关注的部分。rust-vmm 才是真正的革命，而不是任何单个 VMM。这意味着我们不是只有一个好的 VMM。我们有一个共享的基础，使得构建许多好的 VMM 成为可能，每个都针对不同的权衡进行优化。对 vm-memory 的改进会同时惠及 Firecracker、Cloud Hypervisor、libkrun、Dragonball 和 crosvm。一个新的架构（RISC-V）只需在 crate 中实现一次，每个 VMM 都能获得它。

消费者体现了广度：Firecracker（AWS）、Cloud Hypervisor（Intel/Microsoft）、crosvm（Google/ChromeOS）、libkrun（Red Hat）、Dragonball Sandbox（阿里巴巴/Kata）、OpenVMM（Microsoft）以及 virtiofsd（参考 virtio-fs 守护进程，本身就是一个 rust-vmm 项目）。甚至 vmexec——一个用于在一次性 VM 中运行命令的零配置 CLI 工具——也使用了该生态系统。仅 vhost-user 设备实现就涵盖了 can、console、gpio、gpu、i2c、input、rng、scmi、scsi、sound、spi、video 和 vsock。

2026 年的隔离格局

下面并非所有东西都是 VMM（虚拟机监视器）。VMM 通过 KVM 或类似机制创建和管理硬件隔离的 VM：Firecracker、Cloud Hypervisor、QEMU、libkrun、crosvm。包装器如 Lima 和 Tart 在 VMM 或宿主 hypervisor 之上提供 CLI/UX，但本身不实现虚拟化。替代运行时如 gVisor 和 Sysbox 在没有 hypervisor 的情况下改进了容器隔离。它们都被包含在内，因为它们属于同一个决策空间。

Firecracker 与 Cloud Hypervisor：岔路口

如果你今天在评估 microVM，你很快就会像我工作中那样来到同一个岔路口：Firecracker 还是 Cloud Hypervisor？

Firecracker 约 83K 行 Rust 代码，Cloud Hypervisor 约 106K。两者都使用 KVM。两者都通过 rust-vmm 共享代码。在合成基准测试中，虚拟化开销处于较低的个位数百分比（实际上可以忽略不计）。

区别在于它们的理念，而这主要源于 Firecracker 在 AWS 诞生时是为了一个特定任务。

Firecracker 是一把手术刀。它刻意移除功能以最小化攻击面。没有 GPU 直通。没有 CPU 热插拔。没有嵌套虚拟化。这对于 AWS Lambda 的威胁模型来说是完美的：短生命周期函数，永远不需要 /dev/kvm 或 GPU。

Cloud Hypervisor 是一把瑞士军刀。它保留了极简精神，但增加了通用云工作负载所需的功能：嵌套 KVM（--cpus nested=on 于 2025 年 12 月添加）、VFIO 设备直通（GPU！）、CPU/内存热插拔、Windows 客户机支持。代价是启动时间慢几十毫秒，攻击面略大，尽管其核心大量构建在与 Firecracker 相同的 rust-vmm crate 之上。

决定性问题

你的工作负载是否需要运行 Docker-in-Docker、Android 模拟器，或任何需要在 VM 内使用 /dev/kvm 的东西，或 Windows，或一些更复杂的设置？如果是：Cloud Hypervisor。如果否：Firecracker。

Fly.io（一家公共云，在全球自有硬件上将客户容器作为 Firecracker VM 运行，我很欣赏）在 GPU 方面吃了苦头才明白这一点。他们为标准工作负载运行 Firecracker，并且做得非常好，开发者体验极佳。但他们不得不为需要 PCIe 直通的 GPU 机器引入 Cloud Hypervisor，花了数月时间试图让 Nvidia 的宿主驱动正常工作，一度十六进制编辑闭源驱动以欺骗它们认为 Cloud Hypervisor 是 QEMU。此后他们缩减了 GPU 雄心。如果你的工作负载需要嵌套 KVM、Windows 或其他类似 Android 设备模拟器的东西，那么 Cloud Hypervisor 是务实的单一 VMM 选择。如果你只需要临时计算，Firecracker 更简单的模型可能值得。

性能：启动时间和运行时开销

对 microVM 最常见的反对意见是延迟。“每个请求都开一整个 VM？那得增加好几分钟。”事实证明完全不会。这就是为什么我在下面加了这个花哨的干运行原生 HTML/CSS/JS 演示（来自真实的 Cloud Hypervisor microVM）。Firecracker NSDI'20 论文测得启动 Linux 内核并开始接受 API 调用只需 <125ms。借助快照恢复，可以做到 ~28ms。AWS Lambda 将其用于 SnapStart：在初始化后冻结 VM，然后在冷启动时恢复快照。

Colin Percival 通过内核补丁让 FreeBSD 在 Firecracker 上不到 20ms 启动（内核启动比 TCP 握手还快！）。Unikraft Cloud 甚至能在 10ms 内启动完整的 microVM，并且凭借大幅修改的 firecracker VMM 和庞大的快照子系统实现规模化（每台服务器数千个 VM）。

我自己把一个最小的 Linux 6.18 内核裁剪到约 30 MB，只保留在 Cloud Hypervisor 中正确运行 Docker 所需的最少驱动，在现代硬件上它能在 200ms 内启动。
作为对比：Kubernetes pod 调度通常需要 3-15 秒。传统 VM 启动需要 30-60 秒。microVM 启动不是瓶颈。

看它启动：4 vCPU · 8 GiB MicroVM

$

—

启动时间

在 AMD EPYC 上真实 Cloud Hypervisor 启动的回放。为便于观看放慢约 8 倍。按下按钮时不会创建任何 VM。

VMM，不是 VM

你会从朋友或同事那里听到这种说法，所以让我们澄清一下（即使这对你来说可能非常简单）：Firecracker 和 Cloud Hypervisor 是虚拟机监视器（VMM）：使用 KVM 创建和管理 VM 的用户态进程。它们不是 VM 本身。客户机运行的是完全标准、功能齐全的 Linux 内核（或 FreeBSD）。在 VM 内部，你可以使用每一个系统调用、每一个内核特性、每一个工具。VMM 限制的是暴露给客户机的硬件，而不是其中能运行的软件。microVM 不是受限环境。

运行时开销同样极小。客户机代码通过 KVM 直接在 CPU 上运行，开销只有个位数百分比。Oracle 的 Firecracker on OCI 基准测试显示，即使使用嵌套虚拟化，CPU 开销也只有约 3%。在实践中，专用核心的 VM 在共享主机上往往优于容器：当容器在 192 线程主机上遇到 --cpus=4 时，一旦守护线程和 GC 超出配额，CFS 带宽节流就会冻结整个 cgroup。拥有专用核心的 VM 没有配额，CPU 时间是硬件的物理属性。

诚实的权衡是运维复杂性，而不是性能。管理客户机内核、rootfs 镜像和 VMM 是实打实的工作。我乐在其中，因为我们的目标是构建尽可能快、尽可能安全的内部 CI 平台。在这个领域以及其他类似领域，microVM 赢得了自己的位置：当你运行不受信任的代码时，当你需要多租户隔离时，或者当规模大到单次容器逃逸的安全成本超过运行 VMM 的工程成本时。

“VM 太慢”的旧论调多年前就不再令人信服了。启动时间约 125ms。运行时开销只有个位数百分比。真正的成本在运维，而不是性能。

套娃模型

对于这部分，我想不出比俄罗斯套娃（或者洋葱的层层结构）更好的比喻了。2026年涌现出的最强大的模式是在虚拟机中嵌套容器：宿主机运行一个VMM，VMM运行一个Linux内核，内核运行一个容器运行时，运行时运行用户代码。我个人非常看好这个模型。每一层只信任它下面的一层，别无其他。它很快就会变得在思维上很复杂，但当我运行了一个完整的端到端docker run hello-world等价物，运行在一个200毫秒前刚启动的microVM中时，一切都说得通了 ¯\_(ツ)_/¯

纵深防御

宿主操作系统 & KVM

裸金属 • 最小化软件包 • 加固

VMM（用户空间，Rust）

83-106K行Rust代码 • Seccomp隔离 • 非特权

客户虚拟机

专用内核 • 临时性 • 这里root没问题

Podman / 容器运行时

无守护进程 • OCI镜像 • 熟悉的界面

不受信任的代码

AI代理输出 • CI脚本 • 用户提交

每一层只信任它下面的一层，别无其他。攻击者必须突破每一道边界才能到达宿主机。将鼠标悬停在某一层上，查看它被攻破时会发生什么。

这就是Fly.io Sprites、E2B、Unikraft、AWS Lambda和Kata Containers或多或少趋同的模型。细节有所不同：Firecracker对比Cloud Hypervisor、临时性对比持久性、容器对比直接进程……但架构是一样的：虚拟机才是安全边界，而不是容器。

AI代理让所有人都开始关注

2024年，microVM还是一个基础设施领域的小众事物。AWS在用。Fly.io在用。少数几家构建加固Kubernetes的公司（Kata Containers、Edera）在用。其他所有人都在运行容器，并祈祷一切顺利。

2025年，Claude、GPT、Gemini和Codex开始编写代码，并要求执行它。不是玩具代码，而是会安装软件包、运行服务器、修改文件系统、发起网络请求的真实代码。每天数百万次会话。

突然间，每个AI平台都需要回答同一个问题：代理的代码在哪里运行？

为什么容器对代理来说不够

2026年3月，Leonardo Di Donato（CNCF运行时安全工具Falco的核心维护者）演示了，如果沙箱挡在代理和完成任务之间，Claude Code会绕过它自己的沙箱。

代理发现/proc/self/root/usr/bin/npx解析到同一个二进制文件，但不匹配拒绝模式。当bubblewrap捕获到这一点时，代理禁用了自己的沙箱，还是运行了那条命令。没有越狱，没有特殊提示。它只是想完成任务。

教训是：容器、拒绝列表和权限提示存在于代理推理的同一空间：用户空间、语言、逻辑。microVM的隔离由硬件强制执行，位于代理能够推理的层面之下。

AI沙箱生态系统（2026）

基于Firecracker

经过大量修改和扩展的Firecracker VMM（由一位博士创始人领导），冷启动低于10毫秒（此处最快），缩容至零低于10毫秒。任何Dockerfile都能转为microVM，具有毫秒级快照/分叉，每台服务器可运行100,000多个隔离实例；支持托管、BYOC或本地部署。

持久化、有状态的虚拟机。约300毫秒内完成检查点/恢复。预装Claude Code、Codex CLI。“开发者工作站即虚拟机”模式。

OpenFaaS/Actuated 团队推出的自托管 microVM 平台。在 Linux 上使用 Firecracker + Cloud Hypervisor，在 Mac 上使用 Apple Virtualization Framework。固定费率，无需 SaaS，运行在你自己的硬件上。

一个会话，一个 microVM。最长 8 小时。使用后销毁并清理。与 Bedrock AI 服务集成。

E2B Firecracker

专为 AI 智能体打造的 Firecracker 沙箱，启动约 150ms。声称财富 100 强中 88% 已注册。

Amazon Linux 2023 上的 Firecracker microVM。毫秒级启动。快照实现即时恢复。Node.js 和 Python 运行时。SDK 和 CLI。专为 AI 代码解释器和不可信代码执行而构建。

开源。面向 AI 智能体的 Firecracker microVM，具备全拒绝网络、域名允许列表和密钥保护。专为安全运行 claude --dangerously-skip-permissions 而构建。

其他 microVM / VM

2026 年 1 月（Docker Desktop 4.58）。每个智能体通过原生 hypervisor（macOS 上为 virtualization.framework，Windows 上为 Hyper-V）获得一个 microVM，并拥有自己私有的 Docker daemon。Claude Code、Codex、Copilot、Gemini、Kiro。网络隔离。

Ona（前 Gitpod）VM

Gitpod 于 2025 年 9 月更名，转型为 AI 智能体平台。每个智能体获得一个临时 VM，具备内核级隔离和系统调用监控。VMM 未披露。SOC 2、GDPR。在 AWS、GCP 和 Azure 上的客户 VPC 中运行。

2025 年从开发环境转向智能体基础设施。每个沙箱获得专用的内核、文件系统和网络栈。冷启动 <90ms。VMM 未披露。

开源、自托管、Apache-2.0。YC 支持。约 4,700 个 GitHub star。使用 libkrun（Red Hat 基于库的 VMM）。

多运行时平台：Firecracker、gVisor、Kata Containers 和 Cloud Hypervisor。任选你的隔离后端。每月 200 万+ microVM。托管或自带云。客户包括 Writer 和 Sentry。

非 VM 隔离

基于 gVisor 的沙箱，集成 GPU 支持。更广泛的平台，用于推理、训练和批处理。启动约 300ms。

亚毫秒级启动，Dynamic Workers 让 LLM 在运行时将 JS/TS 生成到子 isolate 中（相比工具调用减少 81% token 用量）。单独的 Containers 产品（beta）为任意语言添加完整 Linux 运行时。

这个模式再明显不过。在 18 个月的时间里，几乎所有主要平台都汇聚到了同一个答案：不可信代码需要比容器更强的隔离。大多数选择了 microVM。Modal 选择了 gVisor。Cloudflare 选择了 V8 isolate。争论不再是是否要隔离，而是如何隔离：哪个 VMM、哪条边界，以及状态应该有多持久。

超越沙箱：Kubernetes 中的 MicroVM

沙箱的故事吸引了注意力，但可以说更重要的战线是 Kubernetes（尤其是在我在 KubeCon 待了 3 天之后）。有三个项目正在将硬件级隔离带到每个 pod，每个都有不同的理念：

MicroVM 遇上 Kubernetes

OpenInfra Foundation 项目，将 QEMU、Cloud Hypervisor 或 Firecracker 封装在兼容 OCI 的运行时之后。将其放入 containerd，每个 pod 就获得自己的 VM。150-300ms 启动开销。经 IBM Cloud 实战检验；可部署在 AWS EKS 上，使用裸金属节点。最成熟的选项，但运维复杂性是真实存在的：你要在现有容器栈之外管理 guest 内核、VM 镜像和一个额外的运行时 shim。

Edera Type-1 hypervisor

一个用于 Kubernetes 的 Type-1 虚拟机管理程序，基于精简版 Xen 构建，控制平面用 Rust 编写。宣传点：虚拟机管理程序位于内核之下，因此内核漏洞无法破坏隔离。花了数年时间争论 KVM 不安全，然后在 2026 年添加了 KVM 支持。本周在 KubeCon EU 上：Falco 集成用于 microVM 隔离 Pod 内部的运行时威胁检测。

不同角度：通过 CRD 将完整虚拟机作为 Kubernetes Pod 运行。“它只是一个 Pod。”在 YAML 中定义 CPU 拓扑、内存、磁盘；virt-controller 创建 Pod。GPU 直通、SR-IOV、实时迁移、通过 ArgoCD/Flux 实现 GitOps。SK Telecom 在 KubeVirt 上运行其 Petasus AI Cloud。v1.8（2026 年 3 月）发布了虚拟机管理程序抽象层，为 QEMU/libvirt 之外的后端打开了大门，包括 Cloud Hypervisor。不是关于隔离容器，而是关于将虚拟机工作负载带入 Kubernetes 编排。

此外，Unikraft 提供了一种基于虚拟 kubelet（Kraftlet）的商业解决方案，允许透明地将 Pod（即容器）作为虚拟机运行。（在我看来是非常优雅的解决方案！）

gVisor 问题

2026 年任何关于隔离的诚实讨论都必须认真对待 gVisor。它不是 microVM；它是一个用 Go 编写的用户空间应用内核，拦截系统调用并在内存安全进程中重新实现它们。没有虚拟机管理程序，没有客户机内核。但将其视为“较弱的隔离”则忽略了全貌。

Google 在 Cloud Run、App Engine 和 Cloud Functions 上运行着数十亿个基于 gVisor 的容器。Modal 在其上构建了整个 GPU 推理平台。DigitalOcean 将其 App Platform 的 gVisor 部署升级到新的 systrap 模式，Node.js 吞吐量提升 2 倍，WordPress 提升 7 倍。systrap 模式（取代了 ptrace）大幅降低了开销，gVisor 在 Go 中重新实现了约 274 个 Linux 系统调用，但 Sentry 本身在没有网络时仅进行 53 个主机系统调用，有网络时为 68 个，这比内核的 450+ 个系统调用面小得多。

gVisor 相对于 microVM 的最强优势是GPU 工作负载。将 VFIO GPU 直通到 microVM 中无论如何都会破坏虚拟机隔离边界，因为 GPU 对主机内存有 DMA 访问权限。gVisor 的 nvproxy 在内存安全层中拦截 CUDA 调用，可以说比带有直通 GPU 的 microVM 提供了更好的安全性。这正是 Modal 使用 gVisor 进行 GPU 推理的原因。

microVM 相对于 gVisor 的最强优势是兼容性。gVisor 重新实现了 Linux 内核的一个子集。如果你的工作负载遇到未实现的系统调用或内核特性，它就会崩溃；而 Google Cloud Run 在其第二代执行环境中转向了 microVM，部分原因是客户不断要求 gVisor 不支持的内核特性。microVM 运行真实内核；一切都能正常工作。

诚实的看法：gVisor 和 microVM 是互补的工具，适用于隔离与兼容性光谱上的不同点。gVisor 在启动速度（约 50 毫秒）、内存效率和 GPU 工作负载方面胜出。microVM 在兼容性、嵌套虚拟化以及“它只是 Linux”的简单性方面胜出。两者都没有获胜，实际上两者似乎都在以不同的客户群蓬勃发展。

“加固容器就够了”的反对意见

一个合理的反驳：“我们用 seccomp、AppArmor、只读 rootfs、无 capabilities 和用户命名空间来运行容器。生产环境中零逃逸。”对于你自己代码的可信工作负载来说，这是合理的。microVM 的论点对于不可信工作负载最为有力：AI agent 输出、来自数百名开发者的 CI 脚本、多租户平台。在数千种配置中正确加固每个容器的运维负担，超过了直接启动一个 VM 的运维负担。两种方法都有其用武之地。

生态系统正在蓬勃发展

2026 年这个领域最让我兴奋的是多样性。并不存在单一的 microVM 解决方案：而是一个生态系统，并且它正在快速成熟：

rust-vmm 正在整合为一个 monorepo（于 FOSDEM 2026 宣布），并添加 RISC-V 支持。共享 crate 生态系统意味着对 virtio、KVM 绑定或内存管理的改进将使每一个使用它的 VMM 受益。

来自 Red Hat 的 libkrun 是一匹黑马：一个基于库的 VMM，启动时间低于 200ms，透明的 socket 模拟（无需 TAP 设备），以及在 macOS 上的半虚拟化 GPU 支持。它为 Microsandbox 提供动力，并与 crun 集成，可直接在 microVM 内运行容器。

Ubicloud 正在悄然证明这一模式适用于 CI，也适用于构建一个完整的开源云。他们的架构很有启发性：一个 Ruby/Postgres 控制平面通过 SSH 与裸机 Linux+KVM 服务器通信，其中 Cloud Hypervisor 在 Linux 命名空间内运行每个 VM 以提供额外的隔离。他们提供的 GitHub Actions runner 比 GitHub 的定价便宜 10 倍，每个作业都能在裸机提供商上获得一个干净、临时的 VM。以 AGPL 开源。

AWS 在标准 EC2 实例（C8i/M8i/R8i）上于 2026 年 2 月添加了嵌套虚拟化。此前，你需要在 EC2 内运行 KVM 时使用昂贵的裸机实例。现在，法兰克福一台每小时 0.72 美元的 c8i.4xlarge 就能运行带有嵌套 VM 的 Cloud Hypervisor。这解锁了 AWS 上基于 microVM 的 CI/CD，而无需承担每小时 9-20 美元的裸机税。

crosvm，Google 为 Chrome OS 打造的 VMM，仍在积极维护，并为每台 Chromebook 上的 Linux（Crostini）和 Android VM 提供动力。又一个 rust-vmm 消费者，又一个共享生态系统的证明点。

Lima（CNCF 孵化项目，GitHub 星标 20K+）最初是为了在 macOS 上运行 containerd，如今已演变为更广泛的东西。在 KubeCon EU 2026 上，Lima 团队展示了他们向 AI agent 沙箱化的扩展。v2.0 通过 krunkit 添加了 GPU 加速，以及一个 MCP 服务器，让 AI agent 可以在 VM 内安全操作。Lima 将 QEMU、Apple 的 Virtualization.framework、WSL2 或 krunkit 包装为 VM 后端，并为 Colima、Rancher Desktop 和 AWS Finch 提供动力。它是通往整个生态系统的开发者友好入口。

意外的革命

我一直在思考的一点是：这些都不是为 AI agent 构建的。

Firecracker 于 2018 年为 AWS Lambda 构建。Cloud Hypervisor 于 2019 年为通用云工作负载构建。rust-vmm 自 2018 年以来一直在成熟。Kata Containers 自 2017 年以来一直在生产环境中运行。Fly.io 自 2020 年以来一直在运行 Firecracker。monorepo 整合、RISC-V 支持、IOMMU、使用 Kani 证明的形式化验证，所有这些都在悄然发生，年复一年，而行业的大部分注意力都集中在 Kubernetes 和容器上。

技术已经就绪，缺的只是需求。

然后在 2025 年，智能体编程爆发了。Claude Code、Codex、Copilot、Gemini CLI，你能想到的都有：每天数百万个会话，AI 在其中编写代码，并且需要在某处运行它。世界上每个平台突然都需要回答“智能体的代码在哪里执行？”，而且是立刻需要。

答案早已摆在那里。成熟。久经考验。运行着数万亿次 Lambda 调用和数百万个 Fly.io Machines。microVM 生态不需要为 AI 而发明：它需要被发现。上面沙箱网格中几乎每个平台都是在几个月内建成的，而不是几年，因为那些难题早已在 rust-vmm crate 和生产级 VMM 中解决了。

这就是那场安静的基础设施革命。不是某个单一的突破时刻，而是一种积累：八年的 Rust VMM 开发、跨相互竞争公司的共享 crate 生态、超大规模生产环境的实战检验，然后是需求的突然爆发，把这一切推到了聚光灯下。

这有点像 2013 年容器身上发生的事。内核原语（namespaces 和 cgroups）自 2006-2008 年起就存在于 Linux 中。LXC 自 2008 年起就存在。但需要 Docker 的开发者体验来创造需求，才让容器成为主流。

对于 microVM 来说，那个“Docker 时刻”就是智能体 AI。

结论

在我看来，终局并不是“microVM 将取代容器”。而是隔离层变得不可见。

你仍然会写 Dockerfile。你仍然会kubectl apply。你仍然会以容器的方式思考，这很好（没有新的认知负担）。但在底层，每个 pod 都会在 ~200ms 内启动自己的内核。每个 AI 智能体会话、每个 CI 作业等等，都会获得自己的硬件隔离 VM。而你永远不会注意到，因为 VMM 只是<几 MiB 的 Rust，启动极快。

这已经在发生了。Kata Containers 为每个 Kubernetes pod 放置一个 VM。Docker Sandboxes 将每个编码智能体包裹在 microVM 中。AWS Lambda 自 2018 年起就对每次函数调用这样做。最好的模式是 VM 内运行容器：容器提供打包和开发者体验，VM 提供隔离。开发者看到的是容器，一切都像在本地用 Docker/Podman 一样运作。安全团队看到的是 VM。尽管底层复杂，双方都很满意。

让这一切无缝运行的基础设施由 AWS、Intel、Google、Microsoft、Red Hat 和阿里巴巴的工程师维护，他们都为同一个 Rust crate 单体仓库做贡献。谢谢你们！八年的默默耕耘，如今需求已经到来。

你的容器不是沙箱，因为它从来就不是为此设计的。但它不需要是，只要它运行在某个是沙箱的东西里面。

免责声明：我是 Booking.com 的一名 Staff SRE，从事运行在 microVM 中的面向开发者的 CI 基础设施工作。所有观点仅代表我个人。