共计 3241 个字符，预计需要花费 9 分钟才能阅读完成。
如何分析基于 K8s 的虚拟化技术 Kube-virt，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
根据 Garnter 的最新预测，到 2022 年将会有 75% 的生产应用全部跑在容器环境之上。基于这个预测，其实至少还有 25% 的架构由于技术原因或是认为原因都将仍然跑在旧的架构之上，这其中虚拟机又会占据其中的大部分份额。所以在容器技术尤其是 Kubernetes 诞生之初，就已经有开源的社区在为如何使用 Kubernetes 纳管虚拟机作为一个重要的功能在开发和贡献。
今天要介绍的主角就是 Kube-virt，那么使用 Kube-virt 主要会帮我们解决以下两个问题：
从技术层面，完全的虚拟机纳管，可以完美迁移因为内核版本过于陈旧以及语言问题而无法迁移到容器的部分应用
从管理和运维层面，符合传统的运维工作方式，以前的 SSH 等运维方式可以完美复用
架构
为什么 kube-virt 可以做到让虚拟机无缝的接入到 K8S？
首先，先给大家介绍一下它的整体架构。
virt-api
kubevirt 是以 CRD 形式去管理 vm pod，virt-api 就是所有虚拟化操作的入口，包括常规的 CRD 更新验证以及 vm start、stop
virt-controlller
virt-controller 会根据 vmi CRD，生成对应的 virt-lancher pod，并维护 CRD 的状态
virt-handler
Virt-handler 会以 Daemonset 形式部署在每个节点上，负责监控节点上每个虚拟机实例状态变化，一旦检测到状态变化，会进行响应并确保相应操作能达到所需（理想）状态。
Virt-handler 保持集群级 VMI Spec 与相应 libvirt 域之间的同步；报告 Libvirt 域状态和集群 Spec 的变化；调用以节点为中心的插件以满足 VMI Spec 定义的网络和存储要求。
virt-launcher
每个 virt-lanuncher pod 对应着一个 VMI，kubelet 只是负责 virt-lanuncher pod 运行状态，不会去关心 VMI 创建情况。
virt-handler 会根据 CRD 参数配置去通知 virt-lanuncher 去使用本地 libvirtd 实例来启动 VMI，virt-lanuncher 就会如果 pid 去管理 VMI，pod 生命周期结束，virt-lanuncher 也会去通知 VMI 去终止。
每个 virt-lanuncher pod 对应一个 libvirtd，virt-lanuncher 通过 libvirtd 去管理 VM 的生命周期，这样做到去中心化，不再是以前虚拟机那套做法，一个 libvirtd 去管理多个 VM。
virtctl
virctl 是 kubevirt 自带类似 kubectl 命令，它是越过 virt-lancher pod 这层去直接管理 vm，可以控制 vm 的 start、stop、restart。
总结：kubevirt 以 CRD 形式将 VM 管理接口接入到 kubernetes，通过一个 pod 去使用 libvirtd 管理 VM 方式，实现 pod 与 VM 的一对一对应，做到如同容器一般去管理虚拟机，并且做到与容器一样的资源管理、调度规划，这个整体与企业 Iaas 关系不大，也方便企业接入。
流程
上述架构里其实已经部分简述了 VM 的创建流程，以下进行流程梳理：
1. K8S API 创建 VMI CRD 对象
2. virt-controller 监听到 VMI 创建时，会根据 VMI 配置生成 pod spec 文件，创建 virt-launcher pods
3. virt-controller 发现 virt-launcher pod 创建完毕后，更新 VMI CRD 状态
4. virt-handler 监听到 VMI 状态变更，通信 virt-launcher 去创建虚拟机，并负责虚拟机生命周期管理
存储
kubevirt 提供很多种存储方式，存储就决定了你使用虚拟机镜像到底什么内核、什么版本，以下主要讲述我看到三种比较常用的形式
registryDisk
定义 image 来创建虚拟机的 root disk。virt-controller 会在 pod 定义中创建 registryVolume 的 container，container 中的 entry 服务负责 将 spec.volumes.registryDisk.image 转化为 qcow2 格式，路径为 pod 根目录。
kubevirt 提供了 registryDIsk 的基础镜像：registry-disk-v1alpha，根据 Dockerfile 形式去创建虚拟机镜像，以下是 window 镜像 demo Dockerfile
`FROM kubevirt/registry-disk-v1alpha
COPY Windows---server-2012-datacenter-64bit-cn-syspreped---2018-01-15.qcow2 /disk/windows2012dc.img`这个最终我们构建成镜像名：windows2012dc:latest，最终在 CRD 表现形式是这样的：
`kind: VirtualMachineInstance
...
spec:
domain:
devices:
disks:
\- disk:
bus: virtio
name: registrydisk
volumeName: registryvolume
... \- name: registryvolume
registryDisk:
image: windows2012dc:latest`PVC
PVC 是持久化存储镜像的形式，它会被挂在到 pod 中，且格式必须满足 /disk/*.img, 这样 kubevirt 才能够实现虚拟机存储。
CDI
CDI 是 kubevirt 自己提供的一种形式，把 registryDisk 转换为 PVC，这个需要消耗时间去讲镜像转换为 PVC 持久化存储下来。
网络
虚拟机网络就是 pod 网络，virt-launcher pod 网络的网卡不再挂有 pod ip，而是作为虚拟机的虚拟网卡的与外部网络通信的交接物理网卡，virt-launcher 实现了简单的单 ip dhcp server，就是需要虚拟机中启动 dhclient，virt-launcher 服务会分配给虚拟机。
监控
Kube-handler 会去调用当前节点下所有虚拟机的 libvirt API，获取虚拟机的监控指标，并提供 metrics 接口，最后通过 kubevirt-prometheus-metrics 聚合所有节点的 kube-handler 的指标数据，提供给 prometheus 使用。
迁移
通过 CRD：VirtualMachineInstanceMigration（VMIM）来实现动态迁移
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: vmi-fedora这种迁移形式其实并没有指定迁移到哪些节点上，内部逻辑应该只是重新调度 virt-lanucher pod，其中 kubeirt-config 可以对此进行迁移的相关限制，比如迁移的频率（同时只能几个节点进行迁移），迁移的网络速率（因为可能实际到数据磁盘复制），通过 VMIM 也能查看到迁移进度。
Kubevirt VS Kata Container
当然 Kube-virt 并不是目前唯一的可以在 Kuberentes 上实践虚拟化的技术。我们把它也和目前比较流行的 kata container 做了一个对比，方便用户根据实际情况来做选择。
关于如何分析基于 K8s 的虚拟化技术 Kube-virt 问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。
