第一眼看到 KubeVirt 这个词，对技术有些理解的人根本都会晓得，Kube 代表了 Kubernetes 容器化平台，而 Virt 则是以 OpenStack 为代表的虚拟化平台及虚拟化的缩写。近几年 Kubernetes 的大热，相随同的是 OpenStack 虚拟化平台的落寞，KubeVirt 的呈现，仿佛有一种重整旧山河，王者归来的霸气。
前几年 Kubernetes 与 OpenStack 各自大行其道时，鉴于容器的安全性、网络隔离等问题，有很多计划在探讨如何在虚拟机上运行容器，典型的如 Magnum，能够通过成熟的多租户以及网络虚拟化来更好地管制容器的生命周期。而 KubeVirt 反其道而行，用 Kubernetes 平台来治理虚拟机。
01 KubeVirt 是什么？
KubeVirt 是一个 Kubernetes 插件，由 Redhat 开源，在调度容器之余也能够调度传统的虚拟机。它通过应用自定义资源（CRD）和其它 Kubernetes 性能来无缝扩大现有的集群，以提供一组可用于治理虚拟机的 API。
KubeVirt 并不是虚拟化平台的替代品，它只是利用 Kubernetes 的整体框架以及 CRD 来治理 VM，底层调用的仍旧是基于 libvirt 的机制，类比为 OpenStack 中的 Nova，并不波及网络、存储等相干内容。
除了 KubeVirt，近几年来也涌现出不少相似的技术，例如 Virtlet，Kata 等。Virtlet 是将 POD、VM 两个并不齐全匹配的概念映射在了一起，后果导致在 virtlet 中并不存在迁徙等概念，所以也就不是一个规范的 VM；Kata 则有着更快的速度以及更好的安全性，但仍旧不是一个残缺的 VM 治理计划。
K8S 容器平台是将来业务容器化平台的支流方向，但虚拟机 VM 仍然会长期存在，对于那些因为历史代码、操作系统老旧等问题而无奈迁徙到容器平台的业务，KubeVirt 给出了完满的解决方案，有了 KubeVirt，虚拟机能够与容器无缝地连接在一起。Rancher 还基于 K8S、KubeVirt 公布了开源的超交融基础架构软件 Harvester。
至此，容器与 IaaS 必由之路。
| 列项 | KubeVirt | Kata-container | virtlet |
|---|---|---|---|
| 反对虚拟机零碎 | Linux, windows | Linux | 社区曾经不沉闷 |
| 平安水平 | 虚拟机平安 | 虚拟机平安 | |
| 启动速度 | 虚拟机启动速度 | 靠近容器启动速度 | |
| 虚拟机残缺性能 | 反对 | 不反对 |
性能比照图
02 KubeVirt 构造
KubeVirt 次要包含 4 个组件 irt-api、Virt-controller、Virt-handler、Virt-launcher，并且利用 CRD 的性能，定义了若干种资源对象。
- VirtualMachineInstance（VMI）：相似于 Kubernetes Pod，是治理虚拟机的最小资源。一个 VirtualMachineInstance 对象即示意一台正在运行的虚拟机实例，蕴含一个虚拟机所须要的各种配置。
- VirtualMachine（VM）：为群集内的 VirtualMachineInstance 提供治理性能，例如开机 / 关机 / 重启虚拟机，确保虚拟机实例的启动状态，与虚拟机实例是 1:1 的关系，相似与 spec.replica 为 1 的 StatefulSet。
- VirtualMachineInstanceMigrations：提供虚拟机迁徙的能力，尽管并不会指定具体迁徙的目标节点，但要求提供的存储反对 RWX 读写模式。
- VirtualMachineInstanceReplicaSet：相似 ReplicaSet，能够启动指定数量的 VirtualMachineInstance，并且保障指定数量的 VirtualMachineInstance 运行，能够配置 HPA。
| 组件 | 性能 |
|---|---|
| virt-api | 相似于 kube-api , 提供 http restful，虚拟化操作的入口，包含惯例的 CRD 更新验证以及 vm start、stop。 |
| virt-controlller | 是 Kubernetes 的控制器，用于治理集群中的 VM 生命周期，会依据 VMI CRD，生成对应的 virt-launcher pod，并保护 CRD 的状态。 |
| virt-handler | Virt-handler 会以 Daemonset 模式部署在每个节点上，负责监控节点上每个虚拟机实例状态变动，一旦检测到状态变动，会进行响应并确保相应操作能达到所需（现实）状态。Virt-handler 放弃集群级 VMI Spec 与相应 libvirt 域之间的同步，报告 Libvirt 域状态和集群 Spec 的变动，调用以节点为核心的插件以满足 VMI Spec 定义的网络和存储要求。 |
| virt-launcher | 每个 virt-launcher pod 对应着一个 VMI，kubelet 只是负责 virt-launcher pod 运行状态，不会去关怀 VMI 创立状况。virt-handler 会依据 CRD 参数配置去告诉 virt-launcher 应用本地 libvirtd 实例来启动 VMI，pod 生命周期完结，virt-launcher 也会去告诉 VMI 去终止。每个 virt-launcher pod 对应一个 libvirtd，virt-launcher 通过 libvirtd 去治理 VM 的生命周期，不再是以前虚拟机的做法，一个 libvirtd 去治理多个 VM。 |
KubeVirt 构造各组件性能
03 KubeVirt 存储
KubeVirt 中提供多种形式的虚拟机磁盘，磁盘应用形式非常灵活。以下列出几种比拟罕用的：
- CloudInitNoCloud/CloudInitConfigDrive：用于提供 cloud-init 初始化所须要的 user-data，应用 configmap 作为数据源。
- PersistentVolumeClain：应用 PVC 作为后端存储，实用于数据长久化；PV 类型能够为块存储或者文件系统（filesystem），应用 filesystem 时，会应用 PVC 上的 /disk.img，格局为 RAW 的文件作为硬盘。
- ContainerDisk：镜像中蕴含虚拟机启动须要的所有内容，能够将它们推送到 registry，应用时拉取镜像，间接应用 containerDisk 作为 VMI 的磁盘，但数据无奈长久化。
04 KubeVirt With YRCloudFile
首先在一个 Working 的 K8S + YRCloudFile CSI 的环境上，咱们来装置 KubeVirt。
有了以上的根底内容，咱们就能够用 ISO 来装一个虚拟机了，咱们以 CentOS 为例，首先将 ISO 上传到 PVC 供后续装置应用。
在上述文件中，咱们利用 YRCloudFile PV 来承载 CDROM ISO 以及虚拟机的系统盘。随后应用上述 yaml 文件创建虚拟机：
装置完重启后，咱们能够登录到虚拟机内，残缺的虚拟机即可出现在眼前。
那么虚拟机是如何被创立进去的呢？咱们能够到对应的 virt-launcher POD 内一探到底，首先察看一下 virt-launcher 的日志：
进入到 virt-launcher 进一步深挖，咱们看到每个 virt-launcher 创立了一个虚拟机，虚拟机定义文件内所配置的 disk 门路即为在 launcher 容器内挂载的 YRCloudFile PVC 内对应的磁盘文件。
到这里，咱们独特见证了 KubeVirt 与 YRCloudFile 完满联合的过程，而这完满的联合也胜利的使用到了理论的案例场景中。
日前，秒云与焱融科技强强联手胜利落地电力设计行业云原生超交融虚拟化场景，秒云容器云平台的云原生虚拟化性能是基于 Kubernetes+Kubevirt 等云原生开源组件，可在一套平台上同时治理容器和虚拟机，联合焱融 YRCloudFile 云原生分布式文件系统，实现了基于云原生技术的 GPU 云桌面超交融部署计划，为用户提供了高性能的基于容器的 GPU 云桌面平台，升高投入老本，实现了存储资源的自动化调度和应用。
KubeVirt + YRCloudFile 联结解决方案对电网、能源等行业的设计规划业务是一次重要的翻新，解决了用户对 GPU 设计平台更高效利用，以及高性能数据拜访的理论问题。