KubeVirt 核心架构解析：3 层组件如何协同运转虚拟机

背景

如果你做过 VMware 或 OpenStack 运维，你一定有个疑问：K8s 这套东西是为容器设计的，虚拟机和容器的资源模型差这么远，真的能在 K8s 上跑 VM 吗？

答案是：可以，而且生产可用。KubeVirt 就是那个把虚拟机变成 K8s 一等公民的项目。本文带你拆解它的架构------从一个 kubectl create vm 命令，到 QEMU 进程真正跑起来，中间到底经历了什么。

为什么需要 KubeVirt

现实情况是，很多企业的工作负载无法容器化：遗留系统依赖特定内核、Windows 授权绑硬件、GPU 直通应用......但基础设施团队又希望用统一的 K8s 控制面管理所有资源。

KubeVirt 的目标很清晰：在不改变 K8s 架构的前提下，让虚拟机像 Pod 一样被调度和管理。

核心概念：三个 CRD

在看组件之前，先理解 KubeVirt 的资源模型：

CRD	对应 OpenStack 概念	说明
`VirtualMachine (VM)`	Instance（持久化）	描述期望状态，负责 VM 生命周期
`VirtualMachineInstance (VMI)`	Instance（运行中）	代表一个正在运行的 VM
`DataVolume`	Cinder Volume	管理虚拟机磁盘的生命周期

简单理解：VM 是你写的配置，VMI 是真正在跑的实例，就像 Deployment 和 Pod 的关系。

组件架构全景

KubeVirt 由 3 层组件构成，按职责清晰分工：
节点层
控制面
kubectl apply VM yaml
Watch VM/VMI
Watch VMI
Admission + Subresource
创建并监控
libvirt XML
启动
kubectl
K8s API Server
virt-controller

负责 VM 到 VMI 生命周期
virt-handler

每个节点一个，同步 VMI 到本节点
virt-api

Admission + virtctl 代理
virt-launcher Pod

每个 VMI 一个 Pod
libvirt daemon

管理 QEMU 进程
QEMU/KVM 进程

实际运行虚拟机

3 层分工：

API 层 （virt-api）：Admission Webhook + virtctl 命令代理（vnc/console/migrate）
控制层 （virt-controller）：Watch VM 对象，创建/删除对应的 VMI；Watch VMI，创建/删除对应的 virt-launcher Pod
节点层 （virt-handler + virt-launcher）：virt-handler 是 DaemonSet，负责将 VMI 规格同步到节点；virt-launcher 是每个 VMI 独占的 Pod，里面运行 libvirt 和 QEMU

VM 启动的完整流程

知道了组件，再看一个 VM 从创建到运行的完整时序：
QEMU 进程 virt-launcher Pod virt-handler virt-controller K8s APIServer 用户 QEMU 进程 virt-launcher Pod virt-handler virt-controller K8s APIServer 用户 kubectl apply -f vm.yaml VM 对象创建事件创建 VMI 对象 VMI 创建事件创建 virt-launcher Pod Pod 调度到节点，VMI 事件同步 VMI 规格 libvirt 启动 QEMU 进程 VM 开始运行更新 VMI 状态 = Running kubectl get vmi 显示 Running

整个链路的关键点：每一层都是 Watch-Reconcile 模式，和原生 K8s 控制器完全一致，这就是为什么 KubeVirt 能无缝融入 K8s 生态。

网络与存储接入

网络：KubeVirt 支持 3 种模式：

bridge：VM 和 Pod 共享同一个网络命名空间（适合需要固定 MAC 的场景）
masquerade：VM 流量通过 NAT 转发（默认，最安全）
SR-IOV：直通物理网卡（高性能场景，需要硬件支持）

存储：通过 CDI（Containerized Data Importer）管理：

DataVolume → 自动从镜像源（HTTP/S3/PVC）导入磁盘
底层是 PVC，支持所有 K8s StorageClass（Ceph RBD、NFS、本地存储）

总结

KubeVirt 的架构可以用一句话概括：用 K8s 原生的 CRD + 控制器模式，把 libvirt/QEMU 包进 Pod 里。

3 个关键设计理念值得记住：

非侵入式：不修改 K8s 任何核心组件，纯扩展
VMI = Pod 的包装 ：每个虚拟机都有一个专属的 virt-launcher Pod，调度、资源限制、网络全部复用 K8s 机制
控制面和数据面分离 ：virt-controller 不碰节点，virt-handler 不管集群级别状态