KubeVirt 很容易被简化成一个口号：Kubernetes 里的虚拟机。这个说法足以开启第一次讨论，却遮住了更有用的架构主张。KubeVirt 并没有把 VM 改造成容器。它让 Kubernetes 学会容纳一个 VM 形态的对象，再让常规集群机制调度、观测、保护并连接这个对象，同时不假定 guest operating system 已经消失。[1][2]
这个区分很重要，因为许多组织仍有尚未准备好变成容器的 workload：旧内核、打包 appliance、Windows guest、与许可证绑定的机器身份、网络 appliance，以及升级节奏慢于平台团队 Kubernetes 兴趣的系统。KubeVirt 的价值并不来自对 VM 的怀旧。它提供的是一种控制平面折衷：让 VM 留在 workload 需要的位置，同时把它的生命周期移入运维人员已经熟悉的 Kubernetes API 表面。[4]
VMI 是摩擦的基本单位
KubeVirt 的基本运行时对象是 VirtualMachineInstance，即 VMI。官方架构指南把 KubeVirt 描述为叠加在 Kubernetes 之上的附加 API 类型、集群级控制器和节点专属 daemon；调度、网络和存储交给 Kubernetes，KubeVirt 则提供虚拟化行为。[1] 这就是核心分界。Kubernetes 决定工作落到哪里。KubeVirt 让落下来的工作成为真正的 guest machine。
较早的 Kubernetes 项目概览仍然很好地说明了组件分工。virt-controller 在集群层面监听 VM 对象，并创建 VM 将要运行的 pod。pod 被调度到某个节点后，virt-handler 接手节点本地的 reconciliation。随后，virt-launcher 为 VM 进程提供 cgroups 和 namespaces，本地 libvirt 路径启动并监控 domain。[2] 这些移动部件听起来熟悉，因为它们借用了 Kubernetes 的 reconciliation 风格；只是被 reconciliation 的对象已经超出无状态 pod 副本，它是一套带磁盘、固件预期、guest agent、关机语义，有时还带着机器身份许可证绑定的操作系统。
这也是 VMI 之上需要 VirtualMachine 包装层的原因。VMI 是正在运行的实例。VirtualMachine 给运维人员一个持续存在的管理对象：启动和停止行为、重启行为、状态，以及应当跨 VMI 重建保留下来的配置。KubeVirt 文档把固件 UUID 稳定性列为一个例子，因为有些软件仍然会把意义绑定到它认为自己正在运行的那台机器上。[1] 这是一个小细节，却有很大的运行后果。如果平台在 guest 每次重启时都重写身份，VM workload 实际上没有被平台吸收，调试难度反而被抬高。
Pod 是边界，伪装不是它的角色
最容易出现的心智捷径，是说 KubeVirt VM “运行在 pod 里”。更精确的说法是：virt-launcher pod 为 VM 进程提供由 Kubernetes 拥有的外壳。这层外壳有用，因为集群可以把资源计量、调度、网络、存储和生命周期控制附着在这里。若运维人员忘记 guest 有自己的故障模式，这层外壳也会带来风险。
例如，在测试 namespace 里，Kubernetes pod 经常被随手删除。承载数据库、appliance 或有状态 Windows service 的 VM，不能按同一种方式处理。KubeVirt 自己的文档警告说，强制重启会造成数据损坏，这类句子正好把虚拟化平台和容器演示区分开来。[1] 控制平面可以呈现熟悉的动词，后果仍然落在 guest 身上。
这里也能看出 KubeVirt 的设计取向。架构指南描述了一个常被称作 KubeVirt Razor 的项目原则：如果某项能力对 pod 普遍有帮助，KubeVirt 不应为它建出只服务 VM 的孤岛。[1] 网络就是最明显的例子。KubeVirt 没有为每个 VM interface 发明一个私有宇宙，而是在长期更合适的位置上靠向 Kubernetes 和生态原语，例如 CNI 与 Multus。收益是复用。代价是集群本身已经要具备真实的存储、网络、节点策略和安全纪律。
热迁移是架构考试
到热迁移这里，架构停止停留在抽象层面。KubeVirt 指南把它定义为：在 guest workload 持续运行且保持可访问的同时，把正在运行的 VMI 移到另一台计算节点上。[3] 在经典虚拟化栈里，运维人员会预期这类操作内置于平台。在 Kubernetes 里，它变成一次跨层测试：API 能否表达迁移，源节点与目标节点能否满足 workload，存储能否跟随或共享，网络能否保持可达，VM 的 dirty memory 增长是否足够慢，能让迁移收敛完成。
文档列出的限制把真实分界显露出来。使用 PVC 的 VMI 需要共享的 ReadWriteMany 访问模式才能热迁移。不允许使用 bridge pod network binding。virt-launcher pod 中必须开放特定迁移端口，post-copy migration 还会要求额外的节点级权限。[3] 这些约束的价值在于提醒。它们告诉平台团队，KubeVirt 不是套在任意集群之上的魔法适配器。它是一套架构，只有当底层集群能够兑现 VM 级存储、网络和节点契约时，才会正常工作。
这就是采用上的主要教训。一个团队的问题不能停在“我们能用 KubeVirt 运行这个 VM 吗？”它还要问：“我们的 Kubernetes 平台能否解释这个 VM 的存储模式、网络附着、迁移策略、CPU 和内存形态、关机行为以及安全边界，同时不生成一套平行运维手册？”如果答案是否定的，KubeVirt 仍可成为正确目的地；第一项工程应当是平台就绪，随后才是 workload onboarding。
为什么 2026 年信号重要
CNCF 将 KubeVirt 列为孵化项目；该项目于 2019 年 9 月被 CNCF 接纳，并在 2022 年 4 月进入孵化状态。[4] 这条时间线很重要，因为 KubeVirt 已经不再只是一个精巧证明，用来说明 Kubernetes 可以容纳 VM 抽象。对希望为容器 workload 和 VM workload 提供同一运维表面的组织来说，它正在成为 cloud-native 基础设施菜单的一部分。
2026 年的版本背景也指向同一方向。InfoQ 对 KubeVirt v1.8 的报道强调了与 Kubernetes v1.35 对齐、旨在打开 KVM-only 假设之外空间的 Hypervisor Abstraction Layer，以及 Intel TDX attestation support 这类 confidential-computing 工作。[5] 这些内容更适合作为方向信号，不宜成为立即追逐每个功能的理由。更大的信息是，KubeVirt 正从“这能工作吗？”走向“哪些企业虚拟化要求必须由 Kubernetes 表达，同时保留原有含义？”
这也解释了 KubeVirt 为什么不是通用简化器。只有在团队愿意让 Kubernetes 承担 VM 调度、访问、策略、可观测性和故障处理时，它才会减少控制平面的数量。它仍然要求团队理解 hypervisor、guest operating system、RWX storage、节点容量和迁移行为。在一些组织里，保留专用虚拟化平台会更简单。在另一些组织里，尤其是在平台团队已经把 Kubernetes 运行得很好、而 legacy VM estates 又阻塞现代化时，KubeVirt 可以把“永远单独一套集群”变成分阶段迁移路径。
因此，对 KubeVirt 最好的阅读方式是架构性的，不是宣传性的。在声明、放置、策略、生命周期和共享运维工具这些位置，它把 VM 变成 Kubernetes 对象，因为这确实有帮助。在 guest 状态、设备预期、迁移约束、存储语义和关机风险这些位置，它仍然让 VM 保持为 VM，因为假装这些现实不存在会破坏系统。当运维人员同时尊重这两部分时，这个项目的力量最清楚。
来源
- KubeVirt, "Architecture," KubeVirt User Guide.
- Jason Brooks and Kaitlyn Barnard, "Getting to Know KubeVirt," Kubernetes Blog, May 22, 2018.
- KubeVirt, "Live Migration," KubeVirt User Guide.
- Cloud Native Computing Foundation, "KubeVirt" project page.
- Matt Saunders, "KubeVirt v1.8 Brings Multi-Hypervisor Support and Confidential Computing to Kubernetes," InfoQ, March 31, 2026.
- Abigor, "Servers in a Rack.jpg," Wikimedia Commons, photograph dated February 2, 2011.