KubeVirt 维护者：GPU 调度与机密计算将走 Kubernetes 原生路径

KubeVirt 维护者 Vladik Romanovsky 在 2026 年 10 月发表的项目路线说明中，将一条贯穿十年的设计原则重新摆到台前：优先采用 Kubernetes 原生解决方案和机制，而不是构建孤立的虚拟化专用变通路径。这条原则在 AI 工作负载进入 KubeVirt 的场景下有了具体含义——GPU 调度、机密计算、虚拟机作为沙箱以及可扩展性都正在从 KubeVirt 自有实现迁移到 Kubernetes 集群已有的 API 和控制器体系中。

在 GPU 资源分配方面，KubeVirt v1.9 已将虚拟机通过 Kubernetes 动态资源分配（DRA）声明 GPU 的功能推进到 beta 阶段。此前，GPU 分配依赖 device-plugin 机制，KubeVirt 需要自行处理虚拟化层面的设备热插拔。Romanovsky 表示，同一声明模型正在扩展到通用主机设备、SR-IOV 网络设备和 CPU；近期目标是让一台虚拟机能够同时请求 GPU、网卡和 CPU，由 Kubernetes 作为一组协调资源统一分配。此外，项目还在探索让 KubeVirt 根据虚拟机规格和厂商策略自动生成 ResourceClaim 对象，而不是要求每个用户手写。Romanovsky 还列举了 Swap in Kubernetes、ImageVolumes、volume populators 等案例，说明这些机制使团队得以删除 KubeVirt 专用路径、直接复用集群已有能力。Nvidia 工程师也参与了将 KubeVirt 适配到 Grace Hopper、Grace Blackwell 和 Vera Rubin 等新硬件的工作，相关功能先在加速基础设施使能工作组中开发，再逐步合入上游。

机密计算是另一条正在落地的原生路径。用户希望在共享基础设施上运行敏感 AI 应用和模型，同时在执行期间保护数据和模型权重。KubeVirt 正在扩展对机密虚拟机的支持，并探索与远程证明和密钥释放服务（包括 Confidential Containers 项目中的 Trustee）的集成。KubeVirt AIE 和机密计算工作组联合负责人 Fan Zhang 指出，对 AI 而言，信任边界应覆盖完整执行路径——CPU、加速器和它们之间的互联；工作负载所有者需要通过证明验证环境后才能释放敏感数据或模型密钥。在 v1.9 中，AMD SEV 和 SEV-SNP 的功能门控已毕业到 beta，Intel TDX 支持仍为 alpha，IBM Secure Execution 达到通用可用（GA），Arm CCA 仍在开发中。

在架构层面，Romanovsky 解释了为什么 KubeVirt 核心被刻意保护：一个功能不会进入 kubevirt/kubevirt 仓库，除非社区愿意为所有人长期支持它且不破坏已运行的集群。结构化插件是遵循 Kubernetes 可扩展性理念的解法——用户可以在核心之外编写完整功能，同时获得 KubeVirt API 保证。插件是集群作用域对象，包含域钩子、节点钩子和准入控制；域变更可以用 CEL 表达式实现，当钩子需要外部状态时则使用 sidecar。管理员可以查看和控制。这一机制在 v1.9 中处于 alpha 阶段。

可插拔虚拟化栈是更深层的架构变化。libvirt、QEMU 和 KVM 仍是 KubeVirt 的默认栈，v1.8 已加入树内 Hypervisor 抽象层和微软 MSHV 后端（alpha）。微软高级工程师 Harshit Gupta 表示，其提案旨在通过可插拔虚拟化框架将 KubeVirt 与底层虚拟化栈完全解耦，使 Cloud Hypervisor、OpenVMM 或 Firecracker 无需 fork KubeVirt 即可作为外部后端运行。该工作对应 KubeVirt Enhancement Proposal #82，目前仍在进行中。

Romanovsky 明确标注了这些路线图的边界：各项功能处于不同讨论和实现阶段，能否进入未来版本取决于社区评审、集成和测试。他同时指出，CNCF 赞助了本文发布。

对 AI 基础设施团队而言，这条路线的实际意义在于：如果 DRA、机密计算和结构化插件按预期成熟，GPU 协调分配、模型密钥保护和定制虚拟化后端将统一在 Kubernetes 原生 API 下管理，而不是散落在 KubeVirt 专用变通路径中。这减少了运维复杂度，但也意味着团队需要接受各功能从 alpha 到 GA 的渐进过程，以及社区治理节奏对交付时间的影响。