虚拟机与容器的混合管理实践

1. 背景

当前容器已经成为企业上云的主流选择，经过2019年下半年的深度研发和推广，2020年OPPO基本实现了基于kubernetes的容器的大规模使用和全业务上云。容器的优势是敏捷和高性能，然而由于需要共享宿主机内核，隔离不彻底等原因，当用户需要修改很多定制的内核参数或者在低版本的 Linux 宿主机上运行高版本的 Linux 容器，或者只是需要隔离性更高时，在容器上都是难以实现的。而由于历史原因，公司内部也仍然有一些业务需要使用强隔离的虚拟机，因此提供虚拟机服务，势在必行。

经过调研，我们发现对于已经建设有容器平台的公司，虚拟机的管理方案大部分是维护一套OpenStack或者类似的系统。然而OpenStack庞大且繁重，维护成本较高，且底层资源不能够统一管理，将会为混合调度带来很多不便。因此我们将统一的控制面管理，实现容器与虚拟机的统一调度和管理，作为选型的主要方向。

2. 方案选型 Kubevirt or Virtlet

虚拟机与容器通过k8s平台进行混合管理，业界比较好的项目有kubevirt和virtlet等。

Kubevirt是Redhat开源的以容器方式运行虚拟机的项目，以k8s add-on方式，利用k8s CRD增加资源类型VirtualMachineInstance（VMI）， 使用容器的image registry去创建虚拟机并提供VM生命周期管理。

Virtlet是一个Kubernetes（Container Runtime Interface）的实现，能够在Kubernetes上运行基于虚机的Pods。（CRI能够令Kubernetes运行非docker的容器，例如Rkt）。

下面这张图是我们2020年初做选型时做的一个Kubevirt和Virtlet的对比图的部分。可以看到，Virtlet使用同一种资源类型Pod描述容器和虚拟机，因此如果使用原生的方式，虚拟机也只能有Running和删除两种状态，无法支持pause/unpause， start/stop等虚拟机专属状态，显然这是无法满足用户需求的。如果想要支持这些状态，又得深度定制kubelet，会导致虚拟机管理和容器管理耦合太重；另外考虑到当时virtlet社区不如kubevirt社区活跃，因此我们最终选择的方案是Kubevirt。

3. Kubevirt介绍

3.1 VmiCRD/Pod/Domain对应关系

3.2 组件介绍

kubevirt的各组件服务是部署在k8s上的，其中virt-api和virt-controller是deployment，可以多副本高可用部署，virt-api是无状态的，可以任意扩展；virt-controller是通过选举的方式选出一个主台提供服务；virt-handler以daemonset的方式部署，每一台虚拟机节点都运行一个virt-handler；而一个virt-launcher服务则对应一个虚拟机，每当创建一个虚拟机，都会创建一个对应的virt-launcher pod。
virt-api