KubeVirt 是红帽在 2016 年发起的项目，出发点很直接：让 Kubernetes 在跑容器的同时也能跑虚拟机。目标是把遗留工作负载和现代化应用放在同一个平台上。这件事到今天仍然是它的本职，但从 v1.0 之后，情况有了变化——其他项目已经证明，它们可以在 KubeVirt 之上继续搭建，把它整合进更大的生态。
先看已经长出来的东西。Open Sovereign AI Cloud（OSAC）用它提供虚拟机、集群和裸金属服务；Cluster API Provider KubeVirt（CAPK）把 KubeVirt 的虚拟机当作 Kubernetes 节点来用；Flight Control 则在边缘跑 virt-launcher，不需要完整的 KubeVirt 控制平面。这些用法说明 KubeVirt 不再只是一个"在 K8s 里跑 VM"的工具，而是成了别人搭东西的地基。
社区规模也在变。KubeVirt 现在是 CNCF 的孵化项目，贡献者来自 Nvidia、微软、AMD、英特尔、SUSE 等公司，社区正在推动它从孵化阶段毕业。从 v1.6 到 v1.10，增强提案的队列从一小批条目涨到了超过一百条，v1.9 一个版本就包含了几十个新提案。队列变长，核心怎么保持稳定？靠的是 KubeVirt 增强提案（VEP）流程：先设计后写代码，一个统一的追踪器，由各个特别兴趣小组（SIG）负责归属。
接下来几个版本的工作，大致落在几个方向上。
设备与 DRA
虚拟机上的 GPU 已经可以通过 Kubernetes 的动态资源分配（DRA）来申请，不必再走设备插件，这个功能在 v1.9 是 beta。同一套申请模型正在扩展到通用主机设备、SR-IOV 这类网络设备，以及 CPU。不久的将来，一台虚拟机可以同时申请 GPU、网卡和 CPU，由 Kubernetes 把它们作为一组协调分配。还有一项工作在推进：让 KubeVirt 根据虚拟机规格和厂商策略的输入自动构建这些申请，而不是要求每个用户手写 ResourceClaim 对象。
这延续了项目从第一天起的设计原则——优先采用 Kubernetes 原生的方案和机制，而不是另建一套孤立的虚拟化绕行方案。DRA 让设备和 CPU 分配的粒度更细。类似的做法还有不少：Kubernetes 里的 Swap、ImageVolumes、volume populators 等，都让 KubeVirt 得以删掉一条只属于自己的路径，改用集群已经具备的能力。
硬件方面，包括 Nvidia 工程师在内的贡献者一直在让 KubeVirt 支持更新的 Nvidia 硬件，比如 Grace Hopper、Grace Blackwell 和 Vera Rubin 系统。这部分工作先在加速基础设施赋能工作组里开发，目前正在向上游推进。
机密虚拟机与可信执行
用户越来越希望在共享基础设施上跑敏感应用和 AI 负载，同时在执行过程中保护数据和模型。机密计算用硬件支撑的可信执行环境提供隔离，在平台的威胁模型内，连特权主机软件也被挡在外面。远程认证则让负载所有者先评估环境证据，再决定是否交出密钥。KubeVirt 正在扩大对机密虚拟机的支持，并探索与认证、密钥释放服务的集成，包括机密容器项目的 Trustee。
KubeVirt 的 AIE 与机密计算工作组联合负责人 Fan Zhang 解释了这条边界："对 AI 来说，信任边界应该贯穿整个执行路径——CPU、加速器，以及它们之间的互连。负载所有者需要通过认证核实环境，然后才能释放敏感数据或模型密钥。KubeVirt 提供了一个机会，把机密虚拟机、受保护的加速器和认证通过熟悉的 Kubernetes 工作流结合起来。与机密容器、Trustee 这类项目合作，可以让这些保护更容易获得，同时帮助负载所有者控制对其数据和模型的访问。"
这块工作横跨多个硬件方案：英特尔 TDX、AMD 安全加密虚拟化（包括 SEV-SNP）、IBM Secure Execution，以及正在推进的 Arm 机密计算架构（CCA）。在 KubeVirt v1.9 中，覆盖 AMD SEV 和 SEV-SNP 的特性门已升到 beta，英特尔 TDX 支持仍是 alpha，IBM Secure Execution 支持达到正式可用（GA），Arm CCA 的支持还在开发中。
往前看，贡献者在探索跨集群节点更一致地发现可信执行环境能力，帮助 Kubernetes 把机密虚拟机放到合适的基础设施上。其他提案涉及认证初始化数据、证据处理，以及与 Trustee 这类外部验证和密钥释放服务的集成。能力发现决定一台虚拟机能在哪里跑，认证则决定负载所有者是否信任它跑的那个环境。
对加速负载来说，目标还包括机密设备分配，以及 CPU 与加速器之间的受保护通信。这些能力需要硬件、固件、虚拟化栈、客户机软件和认证服务协同支持。相关工作处在讨论和实现的不同阶段，能否进入未来版本，取决于社区评审、集成和测试。
不靠膨胀核心来扩展
KubeVirt 是个成熟项目，核心是被刻意保护起来的。一个特性要进入 kubevirt/kubevirt，前提是我们愿意为所有人长期支持它，并且不破坏已经在跑的集群。这需要时间。有时候社区并不认为某个特性该进核心，但这不该拦住别人去做它。
项目遵循 Kubernetes 的可扩展性思路：用户应该能在核心之外写出完整特性，同时仍然拿到 KubeVirt 的 API 保证。结构化插件就是这条路。插件是集群级对象，分域钩子、节点钩子和准入三类。域变更可以是一个 CEL 表达式，当钩子需要外部状态时也可以是一个 sidecar。管理员能看到它，也能控制它。这个功能在 v1.9 是 alpha。
可插拔的虚拟化栈
另一半是虚拟化栈本身。libvirt、QEMU 和 KVM 在 KubeVirt 中处于中心位置，这仍是默认选择，也是当初正确的默认。v1.8 里加入了树内的 Hypervisor 抽象层，以及微软的 MSHV 后端（Alpha）。但目标是让虚拟化栈可插拔，用户能扩展 KubeVirt，让 Cloud Hypervisor、OpenVMM 或 Firecracker 在树外运行，而不必分叉 KubeVirt。这项工作仍在进行。
微软高级软件工程师 Harshit Gupta 说："KubeVirt 让客户把 Kubernetes 的编排、存储和网络带给虚拟机，从而现代化 VM 工作流。把这些好处扩展到基于其他栈构建的虚拟化方案上，增加了用户的灵活性。我们的提案建立在支持替代 hypervisor 的工作之上，目标是通过可插拔虚拟化框架，把 KubeVirt 与底层虚拟化栈彻底解耦。这符合 KubeVirt 走向更强定制化和灵活性的方向。我很兴奋参与其中，因为它有潜力扩大 KubeVirt 在各组织中的采用。"
可插拔意味着要重构 KubeVirt，用插件框架来选择具体的虚拟机监视器和 hypervisor，初期实现工作已经开始。KubeVirt 增强提案 #82 勾勒了可插拔性的主要工作。除了接入其他虚拟化平台，把后端作为插件维护，还可能带来更好的测试和更轻松的维护。
十年前，这个项目从一个简单的焦点开始：帮组织把遗留 VM 工作负载迁到 Kubernetes 上。今天，使命已经演变为让团队部署现代化的下一代平台。从 AI 推理、边缘部署，到加固的多租户环境和新兴架构，社区仍在推进虚拟机在这个平台上原生能做到的事。最初那个用 Kubernetes 编排 VM 的雄心实验，已经扩展成一整个生态。下一个十年会是什么样，取决于贡献者如何把这些提案变成稳定的能力。
热门跟贴