共计 5316 个字符，预计需要花费 14 分钟才能阅读完成。
大家好，我是张晋涛。
随着云计算和容器技术的倒退，Kubernetes 曾经成为了业界的规范和领导者，为用户提供了一个弱小，灵便和可扩大的平台，来部署和治理各种类型的利用。
然而，对于一些难以容器化的利用，例如传统的企业应用，遗留的零碎，或者须要非凡硬件反对的利用，虚拟机依然是一个必要和无效的解决方案。
如何在 Kubernetes 上运行和治理虚拟机，以及如何实现容器和虚拟机之间的互操作性和一致性，是一个亟待解决的问题。
这就是 KubeVirt 我的项目诞生的背景和指标。
KubeVirt 是一个开源我的项目，它使得虚拟机能够像容器一样被 Kubernetes 部署，生产和治理。它提供了一个对立的平台，让用户能够依据不同的需要，应用容器或者虚拟机来构建云原生利用。KubeVirt 我的项目于 2016 年启动，由 Red Hat, IBM, Google, Intel, SUSE 等多家公司和组织独特推动和奉献。通过 7 年的不懈努力，KubeVirt 于 2023 年 7 月公布了 v1.0.0 版本，标记着它曾经达到了生产就绪的程度，并且有着衰弱的社区。(在此之前，它曾经被很多公司用到了生产环境)
在这篇中，我将回顾 KubeVirt 的倒退历程，介绍 KubeVirt 的外围性能和劣势，以及剖析 KubeVirt 的将来瞻望和挑战。
KubeVirt 的倒退历程
KubeVirt 的想法最早能够追溯到 2015 年，在第一届 KubeCon 上 Red Hat 的工程师 Fabian Deutsch 提出了一个问题：是否在 Kubernetes 上运行虚拟机？过后的答复是不确定的，然而这个问题引起了很多人的趣味和探讨。在接下来的一年里，Fabian Deutsch 和他的共事开始了一些原型和实验性的工作，摸索了不同的计划和技术。最终，他们抉择了应用 libvirt 和 QEMU 来实现虚拟机在 Kubernetes 上的运行和治理。
在 2016 年底，KubeVirt 我的项目正式启动，并在 GitHub 上开源。我的项目的次要指标是提供一个 Kubernetes 原生的虚拟化 API 和运行时，让用户能够像应用 Pod 和 Deployment 一样应用 VirtualMachine 和 VirtualMachineInstance 来定义和治理虚拟机。我的项目的次要挑战是如何将虚拟机与 Kubernetes 的资源模型，调度器，网络，存储等组件进行集成和协调。
在接下来的几年里，KubeVirt 我的项目经验了多个阶段和版本的迭代和改良。其中一些重要的里程碑包含：
- 2017 年底，KubeVirt 实现了根本的虚拟机创立和删除性能，并公布了 v0.1.0 版本。
- 2018 年初，KubeVirt 从新设计了 VirtualMachine 的 API，并公布了 v0.2.0 版本。
- 2018 年中，KubeVirt 兼容了 Kubernetes 的网络，以及离线虚拟机反对，并公布了 v0.3.0 版本。
- 2018 年底，KubeVirt 反对了初始化空 PV，以及 liveness 和 readiness，并公布了 v0.9.0 ~ v0.11.0 版本。
- 2019 年中，KubeVirt 反对了
virtctl migrate，并公布了 v0.21.0 版本。 - 2022 年初，KubeVirt 移除了旧的对 GPU 设施的反对，能够通过对立的形式进行定义，并公布了 v0.50.0 版本。
- 2023 年中，KubeVirt 公布了 v1.0.0 版本。
其实能够看到 KubeVirt 尽管始终没有公布 v1.0 版本，然而却始终放弃着比拟频繁的公布频率。
在这个过程中，KubeVirt 的社区也一直地壮大和沉闷。截至目前，KubeVirt 的 GitHub 仓库曾经有超过 270 个贡献者，超过 17k 提交，超过 4.5k star。
KubeVirt 的用户和合作伙伴也在一直地减少，包含 IBM, Google, Intel, SUSE, Red Hat, Huawei, VMware, Canonical, Rancher 等多家出名公司和组织。
KubeVirt 的外围性能和劣势
KubeVirt 的外围性能是在 Kubernetes 上运行和治理虚拟机。为了实现这个性能，KubeVirt 提供了以下几个方面的解决方案：
虚拟化 API
KubeVirt 定义了一套 Kubernetes 原生的虚拟化 API，让用户能够像应用 Pod 和 Deployment 一样应用 VirtualMachine 和 VirtualMachineInstance 来定义和治理虚拟机。VirtualMachine 是一种申明式的资源类型，示意一个冀望的虚拟机状态。VirtualMachineInstance 是一种实时的资源类型，示意一个正在运行的虚拟机实例。用户能够通过 YAML 文件或者 kubectl 命令来创立，更新，删除或者查问这些资源。例如：
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
annotations:
kubevirt.io/latest-observed-api-version: v1
kubevirt.io/storage-observed-api-version: v1
creationTimestamp: "2023-09-01T00:25:41Z"
finalizers:
- kubevirt.io/virtualMachineControllerFinalize
generation: 1
name: testvm
namespace: default
resourceVersion: "12691"
uid: d5509381-5f21-438b-9440-cb7c9ee82b37
spec:
running: false
template:
metadata:
creationTimestamp: null
labels:
kubevirt.io/domain: testvm
kubevirt.io/size: small
spec:
architecture: amd64
domain:
devices:
disks:
- disk:
bus: virtio
name: containerdisk
- disk:
bus: virtio
name: cloudinitdisk
interfaces:
- masquerade: {}
name: default
machine:
type: q35
resources:
requests:
memory: 64M
networks:
- name: default
pod: {}
volumes:
- containerDisk:
image: quay.io/kubevirt/cirros-container-disk-demo
name: containerdisk
- cloudInitNoCloud:
userDataBase64: SGkuXG4=
name: cloudinitdisk这个 YAML 文件定义了一个名为 testvm 的虚拟机，它有 2 个磁盘。其中一个磁盘是一个容器镜像，另一个磁盘是一个云初始化配置。用户能够通过 kubectl apply -f testvm.yaml 来创立这个虚拟机，或者通过 kubectl get vm testvm 来查问它的状态。
moelove $ kubectl get vms
NAME AGE STATUS READY
testvm 3m20s Running True虚拟化运行时
KubeVirt 实现了一套虚拟化运行时，让用户能够在 Kubernetes 集群中的任何节点上运行和治理虚拟机。KubeVirt 的运行时次要由以下几个组件形成：
- virt-controller：负责监控和调谐虚拟机的状态，以及解决虚拟机的生命周期事件，如创立，删除，启动，进行，迁徙等。
- virt-handler：负责在每个节点上执行虚拟机的操作，如启动，进行，暂停，复原等。它也负责与 libvirt 和 QEMU 进行通信，以及收集和报告虚拟机的性能指标。
- virt-operator：负责在每个节点上启动和治理 libvirt 和 QEMU 过程。
- virt-api：负责提供虚拟化 API 的服务端点，以及验证和转换用户的申请。
moelove $ kubectl get pods -n kubevirt
NAME READY STATUS RESTARTS AGE
virt-operator-6c649b9567-m2tbl 1/1 Running 0 6m36s
virt-operator-6c649b9567-kqfnl 1/1 Running 0 6m36s
virt-api-66859f4c8d-tnf68 1/1 Running 0 5m53s
virt-controller-8545966675-wskv9 1/1 Running 0 5m17s
virt-controller-8545966675-z68gb 1/1 Running 0 5m17s
virt-handler-h8zx4 1/1 Running 0 5m17sKubeVirt 的运行时采纳了 Kubernetes 的原生架构和模式，让用户能够像治理容器一样治理虚拟机。例如：
- 用户能够应用 kubectl logs 命令来查看虚拟机的日志。
网络解决方案
KubeVirt 反对多种网络插件和计划，让用户能够依据不同的需要，为虚拟机提供适合的网络连接和配置。KubeVirt 的网络解决方案次要包含以下几种：
- Pod 网络：这是最简略和最罕用的网络计划，它让虚拟机共享 Pod 的网络命名空间和接口。这样，虚拟机就能够像 Pod 一样拜访集群内外的网络资源，并且能够被集群内外的网络资源拜访。
- 多网络：这是一种更灵便和更高级的网络计划，它让虚拟机能够有多个网络接口，并且能够连贯到不同的网络立体。这样，虚拟机就能够依据不同的用处和场景，应用不同的网络策略和配置。例如，一个虚拟机能够有一个用于治理的网络接口，一个用于数据传输的网络接口，和一个用于公网拜访的网络接口。
- 桥接网络：这是一种更靠近传统虚拟化的网络计划，它让虚拟机能够间接应用节点上的物理网络接口和地址。这样，虚拟机就能够像物理机一样，与节点上的其余设施进行通信，并且能够应用节点上的网络安全和监控工具。
- SR-IOV 网络：这是一种更高性能和更低提早的网络计划，它让虚拟机能够间接应用节点上的物理网卡的虚构性能。这样，虚拟机就能够绕过软件层的开销，间接拜访硬件层的资源，并且能够享受硬件层的减速和优化。
存储解决方案
KubeVirt 反对多种存储插件和计划，让用户能够依据不同的需要，为虚拟机提供适合的存储空间和配置。KubeVirt 的存储解决方案次要包含以下几种：
- 容器磁盘：这是一种基于容器镜像的存储计划，它让虚拟机能够应用容器镜像作为其根磁盘。这样，虚拟机就能够像容器一样，疾速地启动和进行，并且能够享受容器镜像的便当和安全性。
- 长久卷：这是一种基于 Kubernetes 的存储计划，它让虚拟机能够应用 Kubernetes 的长久卷（PV）和长久卷申明（PVC）作为其数据磁盘。这样，虚拟机就能够像 Pod 一样，应用 Kubernetes 的存储类（StorageClass）来动静地申请和开释存储空间，并且能够应用 Kubernetes 的存储插件来连贯到不同的存储后端。
- 主机磁盘：这是一种基于节点的存储计划，它让虚拟机能够应用节点上的本地磁盘或者目录作为其数据磁盘。这样，虚拟机就能够利用节点上的存储性能和容量，并且能够防止网络层的开销和提早。
- CDI 磁盘：这是一种基于 CDI（Containerized Data Importer）我的项目的存储计划，它让用户能够从不同的起源（如 HTTP, S3, Registry 等）导入或者克隆数据到 Kubernetes 的长久卷中，并且能够主动地转换数据的格局（如 qcow2, raw, vmdk 等）。这样，用户就能够不便地将现有的虚拟机镜像或者数据迁徙或者复制到 Kubernetes 中，并且能够应用 KubeVirt 来运行和治理它们。
镜像解决方案
KubeVirt 反对多种镜像插件和计划，让用户能够依据不同的需要，为虚拟机提供适合的镜像源和配置。KubeVirt 的镜像解决方案次要包含以下几种：
- 容器镜像：这是一种基于容器技术的镜像计划，它让用户能够应用容器镜像作为虚拟机的根磁盘或者 CD-ROM。这样，用户就能够利用容器技术的劣势，如轻量级，疾速启动，易于散发，平安隔离等。
- 虚拟机镜像：这是一种基于传统虚拟化技术的镜像计划，它让用户能够应用虚拟机镜像作为虚拟机的初始化配置。
KubeVirt 的将来
现在 KubeVirt 曾经公布 v1.0 版本，红帽作为开创成员，在 OpenShift 虚拟化中携带了 KubeVirt。Kubermatic、Rancher、Google、Oracle 等也提供内置 KubeVirt 的产品。Civio、Puzl、Platform9 和其余公司将 KubeVirt 带到了云端，并提供托管和自治理的产品。
KubeVirt 的价值曾经被大家看到，将来也将会有更多的企业将其利用到本人的环境中，并且推动社区的倒退。
我在 2019 年左右已经尝试过 KubeVirt，过后它还不是很成熟，所以最终并没有驳回它，当初我感觉我能够再试试如何将它退出到我的零碎中了。
欢送订阅我的文章公众号【MoeLove】