gVisor 被捐赠给 CNCF

2018 年，Google 以 Apache 2.0 许可证将 gVisor 开源。据其贡献者所知，此后它一直是仅次于 Linux 的第二成熟的 Linux 实现。

今年，gVisor 项目被捐赠给 CNCF，其治理模式也随之改变。

发生了什么？

Google 将 gVisor 项目（包括其名称和商标）捐赠给 云原生计算基金会（CNCF），后者是 Linux 基金会的下属机构。顾名思义，CNCF 专注于云原生计算，而它的诞生正是源于 Google 捐赠的 Kubernetes 项目。此后，Kubernetes 成长为容器编排领域的行业标准，并在其周围发展出一个庞大而活跃的生态。如今，gVisor 正走上同一条路。

你可以查看 gVisor 的 CNCF 申请与流程。

时间线是怎样的？

已经发生的事：

• 2026-09-07：Google 提交了 CNCF 捐赠申请。
• 2026-09-22：CNCF 审核了该申请。
• 2026-09-28：申请获批。
• 2026-10-02：本博客文章发布。

接下来几周：

• 项目将转入 CNCF“Sandbox”状态（对 gVisor 这样的项目来说，这个名字相当贴切）。
• gVisor 的构建与测试基础设施将迁移到 GitHub Actions 和 Buildkite。
• Google 内部的 gVisor 测试基础设施将不再阻塞 PR。
• gVisor 项目的治理模式将转为基于维护者的模式。
• 将新增非 Google 的维护者，并授予其合并权限。

接下来几个月：

• 项目将采取必要步骤，转入 CNCF“Incubation”状态。
• GitHub 仓库将迁出 google GitHub 组织。
• gVisor 项目的治理模式将转为长期模式，引入基于组织的投票，从而避免 Google 单方面控制治理决策。
• 成为正式 CNCF 项目的后续步骤将逐步推进。

为什么要捐赠？

在业界熟知的沙箱/安全格局里，gVisor 并不好归类。这个格局习惯把“原生容器”和“虚拟机”分开，中间只留一些灰色地带。gVisor 恰好横跨这片中间地带，提供实证意义上的同等安全性，却没有勾上那个熟悉的“虚拟化”选项——而安全审计人员、监管机构和安全从业者往往把这一项当作“安全”的一对一代名词。这给 gVisor 的发展带来了推广上的困难：面对习惯了这种虚假二分法的受众，很难讲清楚这个项目的价值。

gVisor 面临的另一个难题是性能认知问题。在 Google 内部（以及 Ant Group、Modal 等其他使用 gVisor 的公司），有一些 Linux 内核补丁能显著提升 gVisor 的性能。但对其他 gVisor 用户来说，开箱即用的性能在某些 I/O 密集型负载下往往出现下降。这让潜在采用者第一印象不佳。我们曾试图通过向上游提交提升性能的 Linux 内核补丁来解决这个问题，但内核维护者以 gVisor 是 Google 全资项目为由拒绝了。

最后，gVisor 作为一个项目，其潜力在仅由公司所有权驱动时很难被排上优先级。作为 Linux 的用户态实现，gVisor 有一些非商业用途的潜力，例如：

• gVisor-on-Mac：让 Linux 程序能在 macOS 上运行，体验类似于 Wine 让 Windows 程序在 macOS 上运行。
• 桌面 Linux 沙箱：让 gVisor 成为桌面 Linux 应用沙箱的实用选择，比当前最先进的做法（bubblewrap/flatpak/nsjail 等）安全得多，又比 Qubes OS 那类完整的虚拟化方案容易集成得多。我们在这方面已经取得了一些进展，推出了最近发布的 bwrap 直接替代方案，但 gVisor 能沙箱化的东西远不止这些。

从gVisor 目前的采用者名单中就能看出这些问题的端倪：这些采用者要么是有能力投入资源、按自身需求定制 gVisor 的大型科技公司（Google、Ant Group、OpenAI、Anthropic），要么是业务方向与 gVisor 的适用场景高度契合、值得把创业公司有限的资源专门投在让 gVisor 为己所用的初创企业（Modal、Tines）。哪些人不在这份名单上？

• 业余项目：即前面提到的那些非商业应用，gVisor 本可派上用场，但目前无人采用。
• 行业的“中间层”：这些个人和公司能从 gVisor 的安全性中获益，但他们要么不知道它的存在，要么因过去的印象问题而对其不屑一顾，要么没有资源专门投入安全，但如果自己的计算基础设施提供商已经广泛提供一种便宜、开箱即用的沙箱运行时，他们会乐于采用。
• Google 之外的其他超大规模厂商：几乎所有大型科技公司都在内部采用 gVisor 来满足自身大规模的沙箱需求（例如代码片段执行、RL），但只有一小部分（Google、DigitalOcean 和 Modal）直接向客户出售通用的、由 gVisor 驱动的算力。尽管 gVisor 的运营利润率很有竞争力，而且需求有目共睹——gVisor 仓库的 issue 报告显示，大量主体在非 Google 的超大规模厂商上自行安装 gVisor——情况依然如此。剩下的解释很可能是该项目（捐赠前）的治理风险。

把项目捐给 CNCF，正是为了解决上述所有问题。这样一来，gVisor 和应用内核将成为容器生态与安全行业的通用语言，让集成和采用不再局限于那些积极性高、技术强、资源充足的企业；同时也能把解决 gVisor 性能问题的 Linux 补丁上游化，惠及所有人。

为什么捐给 CNCF？

gVisor 是一个可直接替换的容器运行时，天然属于云原生容器生态。它直接与 Kubernetes、containerd 和 Agent Substrate 等 CNCF 技术集成。

从资源和效率的角度看，gVisor 的进程模型与容器类似，因此它比其他以安全为目标的容器运行时更云原生。这使它能够被高效、紧凑地配置，从而实现安全容器的装箱，其粒度和密度是虚拟机运行时无法企及的。它也不需要硬件虚拟化或嵌套虚拟化，因此只要 Linux 能跑的地方它就能跑。这让 gVisor 成为 CNCF 现有项目组合的良好补充。gVisor 目前已在各大云上可用，其中一些云将其作为原生服务提供，另一些云的用户可以（也确实会）自行安装。

Google 未来会剥离 gVisor 的开发吗？

过去几个月对安全行业、尤其是对安全沙箱来说至关重要。在廉价而安全的沙箱需求从未如此明确的时候，Google 放弃自己的沙箱技术毫无道理。恰恰相反，我们（Google 的 gVisor 贡献者）一直在内部推动这一举措，期望它能加速 gVisor 在 Google 内外的发展和采用，就像 Kubernetes 当年那样。

除 Google 外，还有谁加入 gVisor 的贡献者行列？

Google 正在联系可能感兴趣的各方。截至本文写作时，以下机构已承诺长期加入 gVisor 的维护者队伍：Ant Group、Modal 和 Tines。此外，包括 OpenAI、Tencent 和 NVIDIA 在内的其他公司将继续它们对 gVisor 的持续贡献。

这对我意味着什么？

• 短期：没什么变化。
• 中期：PR 贡献体验没那么痛苦。
• 长期：一个更自由的 gVisor，新贡献者的涌入会加速开发，更开放的治理流程将服务于用户。

接下来

部分 gVisor 贡献者将出席 KubeCon North America 2026。欢迎前来交流！