Broadcom宣布将其 Kubernetes 原生备份、恢复和迁移项目 Velero 贡献给云原生计算基金会(CNCF)作为沙箱项目。Velero 在 Kubernetes API 层运行，通过自定义资源定义(CRDs)捕获集群状态，而不是通过 hypervisor 或存储层快照。该公告在阿姆斯特丹举行的 KubeCon + CloudNativeCon Europe 2026 上发布。
Velero 的起源可以追溯到 Heptio，这是一家由前谷歌工程师 Joe Beda 和 Craig McLuckie 创立的 Kubernetes 公司，VMware 于 2019 年收购了该公司。此后，该项目一直由 VMware 以及后来的 Broadcom 管理。平台团队使用它来备份命名空间定义、持久卷声明、RBAC 策略和其他资源配置，作为可移植的 Kubernetes 对象，这些对象理论上可以恢复到与备份来源不同的集群或发行版。它在 GitHub 上有近 9900 个星标。
"随着组织扩展其云原生工作负载，重点正在从简单的编排转向长期韧性和数据管理。Velero 为备份和灾难恢复提供了一个重要的层，确保有状态应用程序能够得到保护。通过加入 CNCF 沙箱项目，Velero 获得了一个供应商中立的托管方，以促进社区协作和增长。"
-- Chris Aniszczyk, CTO, CNCF
Broadcom VCF 部门高级工程总监 Dilpreet Bindra 在 KubeCon 上表示，该公司将这一贡献视为投资而非剥离：“我们不仅是 Kubernetes 的用户，还是构建者，我们让 Kubernetes 更容易运行，而不是更难。”Bindra 也坦率地谈到了这一举措背后的信任问题。在 KubeCon 后与 Pete Flecha 和 John Nicholson 的采访中，他承认一些观察者可能会将这一贡献解读为 Broadcom 放弃了一个不再相信的项目，并直接反驳了这一解读，他说，该公司打算将 Velero 作为 VKS 和 IaaS 故事的一部分，是需要继续投资的工具。
Rack2Cloud 架构博客在 KubeCon 大会结束后不久，发布了一篇针对此次公告的深度分析文章，文中认为，这次治理架构调整既是开源机制层面的变动，同样也是一次信任修复之举。文章指出，Broadcom 在大会上的官方表态，尤其不希望用户将 Velero 视作“VMware 的专属项目”，释放出了明确的信号：此次将 Velero 纳入 CNCF 管理，首要目标群体正是那些因 Velero 长期归属单一厂商、而迟迟不愿将其纳入企业标准化技术栈的各类机构。该博客严谨区分了两个概念：CNCF 所能提供的厂商中立治理，以及 CNCF 无法做到的完全脱离厂商运营。同时强调，本次治理架构变更并不会改变 Velero 原有的运行时依赖，包括对外部对象存储、IAM 凭证链以及可用目标集群的依赖关系均保持不变。
"我们认为，这款工具无论是在我们整体 VKS 布局还是整体 IaaS 布局中，都将带来巨大的价值，我们也会持续对其投入研发。"
-- Dilpreet Bindra, Broadcom VMware Cloud Foundation 部门高级工程总监
据科技媒体Machine Herald报道，目前 Velero 项目维护者名单包含 Broadcom、红帽与微软，且项目的现行治理模式已契合云原生计算基金会（CNCF）的准则，包括采用绝对多数投票的共识决策机制，以及为期五天的延迟共识评审周期。Machine Herald 提出一个尚存的疑问，那就是，随着社区治理逐步落地，项目维护者构成是否会发生变动；同时鉴于 Velero 已在大量生产环境落地，该项目能否从沙箱项目快速进入孵化阶段，并最终完成 CNCF 毕业认证。
业界社区对此次公告整体反响比较积极。云原生计算基金会大使、前 Velero 贡献者及社区经理Orlin Vasilev在 LinkedIn 发文：“这件事花了好几年才顺理成章走到这一步，但终究还是实现了…… 作为 Velero 前贡献者和社区经理，我由衷感到欣喜，这件事意义重大！” 参与联合提交沙箱入驻申请的项目维护者之一、红帽工程师Shubham Pampattiwar，也于今年 2 月在 LinkedIn 谈及了此项提议。KubeCon 大会结束后发布的一期 DevTools Radio 播客节目中，主持人援引 Bindra 对业界反响的评价，称 Velero 项目捐赠消息公布后，社区反馈都非常积极，业内普遍认为“此举完全合乎情理”。
在官宣 Velero 移交社区治理的同时，Broadcom 还公布了多项其他的上游开源贡献。VMware 官方博客表示，团队正与 etcd 贡献者社区并行研发诊断与故障恢复工具，已开源至github.com/vmware/etcd-diagnosis和github.com/vmware/etcd-recovery，旨在帮助 Kubernetes 运维人员更清晰地掌握控制平面健康状态，同时简化故障恢复流程。Broadcom 还提及，将持续与集群 API（CAPI）社区协作，推进集群配置、升级编排及节点生命周期管理相关工作。RedMonk 咨询分析师 James Governor 在 KubeCon 现场与 Bindra、Zach Shepherd 的访谈中评价，Broadcom 长期向 CNCF 贡献开源项目，堪称行业里最被低估的事。
Velero 正式纳入 CNCF 后，进一步丰富了基金会旗下与 Kubernetes 运维相关的数据平面及可观测性工具矩阵。早在本次治理架构调整之前，CNCF 就已发布基于 Velero 的 Kubernetes备份与迁移策略指南，涵盖跨云厂商集群迁移的实操方案。Velero 的官方文档说明，项目以对象存储作为唯一可信数据源，会持续比对集群内的备份资源与存储桶中的备份内容并自动同步。基于这一设计，只要有权限访问同一个存储地址，在某一集群创建的备份就可以被另一集群的 Velero 实例识别并恢复，这一特性也是其承载业务负载迁移场景的核心优势。
techbytes.app 对此公告的分析认为，Velero 未来路线图或将纳入多项规划：搭建集中式控制平面以统一管理多集群备份策略；深化与 CSI 数据管理规范的集成，支持快照前静默应用、实现应用感知型备份；借助 Sigstore 为备份制品提供签名校验。以上均为行业预期发展方向，并非官方确定的承诺。值得注意的是，项目短期路线图今后将由全体维护者社区共同制定，不再由 Broadcom 单方面主导。
对于正在评估此次变更的平台团队而言，Rack2Cloud 博客给出了另一视角：此前因 Veler 归属 VMware 单一厂商背景、不愿将其纳入企业技术标准的机构，如今已不再有治理层面的顾虑。而项目的运维架构保持不变，依旧依赖可访问的外部对象存储、有效的 IAM 凭证及可用的恢复目标集群。无论治理主体如何变更，所需的运维投入与架构适配要求均和此前一致。
原文链接：
Broadcom Donates Velero to CNCF, Shifting Kubernetes Backup to Community Governance