KubeVirt入门介绍

KubeVirt 是一个开源项目，旨在通过 Kubernetes 管理虚拟机（VM），使得 Kubernetes 不仅支持容器化工作负载，还支持虚拟机的部署和管理。这种双重支持的目标是提供一个统一的云原生平台，让开发人员和运维团队在同一环境中管理容器和虚拟机应用。

1. 简介

为什么需要 KubeVirt？

KubeVirt 技术满足了那些已经或希望采用 Kubernetes 的开发团队的需求，这些团队拥有现有的基于虚拟机的工作负载，但这些工作负载无法轻易地容器化。更具体地说，KubeVirt 提供了一个统一的开发平台，让开发人员可以在一个通用的共享环境中构建、修改和部署基于应用容器和虚拟机的应用程序。

其优势广泛而显著。对于依赖现有虚拟机工作负载的团队，KubeVirt 使他们能够快速将应用程序容器化。通过将虚拟化的工作负载直接纳入开发流程中，团队可以逐步拆解这些工作负载，同时在需要时继续使用剩余的虚拟化组件，从而实现灵活的迁移和过渡。

使用 KubeVirt 可以做什么？

• KubeVirt 和 Kubernetes ：利用 KubeVirt 和 Kubernetes 来管理无法容器化的应用所需的虚拟机。

• KubeVirt 和虚拟机 ： 在同一平台上将现有的虚拟化工作负载与新的容器化工作负载结合。

• 容器化应用 ： 支持在容器中开发新的微服务应用，并与现有的虚拟化应用进行交互。

2. 架构

Stack（技术栈）

  +---------------------+| KubeVirt            |
~~+---------------------+~~| Orchestration (K8s) |+---------------------+| Scheduling (K8s)    |+---------------------+| Container Runtime   |
~~+---------------------+~~| Operating System    |+---------------------+| (Virtual)           |
~~+---------------------+~~| Physical            |+---------------------+

需要虚拟化服务的用户通过虚拟化 API进行交互，而该 API 会与 Kubernetes 集群通信以调度请求的虚拟机实例（VMI）。调度、网络和存储全部由 Kubernetes 处理，而 KubeVirt 提供虚拟化功能。

Additional Services

KubeVirt 为你的 Kubernetes 集群提供了额外的功能，以实现虚拟机管理。

回想一下 Kubernetes 是如何处理 Pods 的，我们会记得 Pods 是通过向 Kubernetes API Server 提交 Pod 规格来创建的。这个规格随后会在 API Server 内部转化为一个对象，这个对象具有特定的类型或种类——在规格中就是这样定义的。Pod 的类型是 Pod。Kubernetes 中的控制器知道如何处理这些 Pod 对象。因此，一旦看到一个新的 Pod 对象，控制器就会执行必要的操作以将 Pod 启动，并使其匹配所需的状态。

KubeVirt 使用了相同的机制。因此，KubeVirt 提供了三种东西来实现新的功能：

1. 向 Kubernetes API 添加了额外的类型——所谓的自定义资源定义（CRD）。
2. 为与这些新类型相关的集群级逻辑添加了额外的控制器。
3. 为与新类型相关的节点特定逻辑添加了额外的守护进程。

完成这三个步骤后，你就可以：

• 在 Kubernetes 中创建这些新类型的对象（在我们的例子中是 VMIs）。
• 新的控制器负责将 VMI 调度到某个主机上。
• 一个守护进程: virt-handler – 与 kubelet 一起在主机上工作，启动 VMI 并进行配置，直到它匹配所需的状态。

最后要注意的是，控制器和守护进程都是作为 Pods（或类似的形式）在 Kubernetes 集群上运行的，而不是与集群并行安装的。类型如前所述是在 Kubernetes API Server 内定义的。这使得用户可以与 Kubernetes 进行交互，同时修改 VMIs。

下面的图示展示了额外的控制器和守护进程是如何与 Kubernetes 进行通信的，以及这些额外类型存储的位置：

简化的架构图：

3. 应用布局

集群

1. KubeVirt 组件

   • virt-controller
   • virt-handler
   • libvirtd
   • …

2. KubeVirt 管理的 Pods

   • VMI Foo
   • VMI Bar
   • …

3. KubeVirt 自定义资源

   • VirtualMachine (VM) Foo -> VirtualMachineInstance (VMI) Foo
   • VirtualMachineInstanceReplicaSet (VMIRS) Bar -> VirtualMachineInstance (VMI) Bar

VirtualMachineInstance (VMI) 是表示实例基本、短暂构建块的自定义资源。在许多情况下，这个对象不会由用户直接创建，而是通过高级资源来创建。VMI 的高级资源可以是：

VirtualMachine (VM)

有状态的虚拟机，能够在保留 VM 数据和状态的情况下停止和启动。

VirtualMachineInstanceReplicaSet (VMIRS)

类似于 Pods 的 ReplicaSet，是一个由模板中定义的相似配置的短暂 VMI 组成的组。

4. 原生工作负载

KubeVirt 部署在 Kubernetes 集群之上。这意味着你可以继续运行 Kubernetes 原生工作负载，同时也能管理通过 KubeVirt 管理的 VMI。

此外：如果你可以运行原生工作负载，并且已经安装了 KubeVirt，那么你应该也能够运行基于虚拟机的工作负载。例如，应用操作员在使用集群功能管理虚拟机时，不应需要比使用普通 Pod 时更多的权限。

从安全角度来看，安装和使用 KubeVirt 不应赋予用户任何他们在原生工作负载方面尚未拥有的权限。例如，一个非特权的应用操作员绝不能通过使用 KubeVirt 功能获得对特权 Pod 的访问权限。

5. The Razor（准则）

我们热爱虚拟机，认为它们非常重要，并努力使它们在 Kubernetes 中易于使用。但比虚拟机更重要的是，我们热爱良好的设计和模块化、可重用的组件。我们经常面临一个两难问题：我们应该以最优化虚拟机的方式来解决 KubeVirt 中的问题，还是应该走一条更长的路，把这个解决方案也引入到基于 Pod 的工作负载中？

为了做出这个决策，我们提出了 KubeVirt 准则：“如果某个功能对 Pods 有用，我们不应该仅仅为虚拟机实现它。”

例如，我们曾讨论过如何将虚拟机连接到外部网络资源。最直接的方式似乎是引入 KubeVirt 特定的代码，将虚拟机附加到主机网桥上。然而，我们选择了更长的路径，即与 Multus 和 CNI 集成并加以改进。

6. 相关资料

1. KubeVirt文档：https://kubevirt.io/user-guide/
2. KubeVirt架构：https://github.com/kubevirt/kubevirt/blob/master/docs/architecture.md
3. KubeVirt仓库： https://github.com/kubevirt/kubevirt