随着Docker和Kubernetes生态圈的发展，云计算领域对容器的兴趣达到了狂热的程度。容器技术为应用程序提供了隔离的运行空间，每个容器内都包含一个独享的完整用户环境空间，容器内的变动不会影响其他容器的运行环境。因为容器之间共享同一个系统内核，当同一个库被多个容器使用时，内存的使用效率会得到提升。基于物理主机操作系统内核的，那就意味着对于不同内核或者操作系统需求的应用是不可能部署在一起的。

虚拟化技术则是提供了一个完整的虚拟机，为用户提供了不依赖于宿主机内核的运行环境。对于从物理服务器过渡到虚拟服务器是一个很自然的过程，从用户使用上并没有什么区别。

目前Redhat开源的kubevirt和Mirantis开源的virtlet都提供了以容器方式运行虚拟机的方案。

kubevirt 是 Redhat 开源的以容器方式运行虚拟机的项目，以 k8s add-on方式，利用 k8s CRD 为增加资源类型Virtual Machine Instance（VMI）， 使用容器的image registry去创建虚拟机并提供VM生命周期管理。 用pod管理能力，要自主去实现，目前kubevirt实现了类似RS的功能。

那Virtlet是什么呢？

Virtlet 来自于 Mirantis，跟 kubevirt 的不同之处在于它使用 POD 来描述一个 VM（Virtual Machine,虚拟机)。Virtlet 是 Kubernetes 一个运行时服务，能够根据 QCOW2 映像运行 VM 工作负载。Virtlet是是K8S的一个插件，CRI接口兼容的插件，能够在 Kubernetes 集群上运行基于虚拟机的 Pods。

Virtlet的架构

CRIProxy作为代理，可以实现在一个节点上支持多种CRI。

kubelet会去调用CRIProxy，由CRIProxy根据pod image前缀（默认virtlet.cloud）决定将请求发给virtlet process 还是dockershim server，从而去创建虚拟机或者容器。

每个节点上会由daemonset负责启动virtlet pod，该virtlet pod包括三个容器：

• virtlet：接收 CRI 调用，管理VM
• libvirt：接收 virtlet 的请求创建、停止或销毁VM
• VMs：所有 virtlet 管理的VM 都会在这个容器的命名空间里

vm的确在vms container下，可以看到对应/proc/{id}/ns/下都是一致的，其实其他container ns只有mnt ns是不一样的。

Virtlet如何管理虚拟机

虚拟机生命周期管理流程

virtlet使用原生的workload（deployment，statefulset）去管理vm pod，vm的生命周期与pod一致。vm随着pod的创建而创建，随着pod的销毁而销毁。

整体流程：

1. deploy、statefulset等workload创建出对应的pod；
2. kubelet list-watch发现了调度到该节点的pod，根据cri调用criproxy；
3. criproxy会根据pod image前缀判断是将请求发给virtlet还是docker，比如pod image为virtlet.cloud/library/cirrors, 根据前缀匹配到virtlet.cloud,则将请求转给virtlet；
4. virtlet process会根据请求去调用libvirt api通过qemu-kvm去创建/输出虚拟机

虚拟机存储

virtlet支持原生存储范畴：

• emptydir
• hostpath
• pvc， 需要mode类型是block
• flexvolumes
• secret，configmap

可以通过annotation字段去配置磁盘驱动以及系统磁盘大小：

metadata:

name: my-vm

annotations:

kubernetes.io/target-runtime: virtlet.cloud

VirtletRootVolumeSize: 4Gi

VirtletDiskDriver: virtio

….

VirtletRootVolumeSize定义了根卷的磁盘大小，VirtletDiskDriver定义了磁盘驱动，常规磁盘驱动默认为virtio-scsi。

其中virtlet也支持cloud-init进行初始化配置，定义ssh密码以及相关用户、网络等初始化：

apiVersion: v1

kind: Pod

metadata:

name: ubuntu-vm

annotations:

kubernetes.io/target-runtime: virtlet.cloud

# override some fields in cloud-init meta-data

VirtletCloudInitMetaData: |

instance-id: foobar

# override some fields in cloud-init user-data

VirtletCloudInitUserData: |

users:

– name: cloudy

gecos: Magic Cloud App Daemon User

inactive: true

system: true

virtlet管理的虚拟机与容器如何实现整体交互

virtlet与常规CRI一样，也是使用CNI管理虚拟机的网络。

virtlet去调用cni之前，会创建出新的network namespace，通过tap设备连接虚拟机，veth pair连接主机网络与cni 网络模型。

当前连通virtlet管理的虚拟机方式：

• 根据virtlet pod IP地址，直接ssh形式
• kubectl attach命令， virtlet提供attach接口，能够以类似console形式访问
• virtletctl 命令，提供ssh，vps形式

虚拟机镜像

virtlet支持qcow格式的镜像文件，但需要在pod image定义中指定virtlet.cloud前缀。virtlet会将对镜像进行名称转换, 将名称转换成虚拟机镜像下载地址。

当前virtlet支持两种镜像名称转换的方式：

• 静态配置：默认kube-system会创建名为virtlet-image-translations的configmap

translations:

– name: cirros

url: https://github.com/mirantis/virtlet/releases/download/v0.9.3/cirros.img

– name: fedora

url: https://dl.fedoraproject.org/pub/fedora/linux/releases/29/Cloud/x86_64/images/Fedora-Cloud-Base-29-1.2.x86_64.qcow2

举个例子：

当你将image配置成virtlet.cloud/cirrors, virtlet会将该镜像转换成

https://github.com/mirantis/virtlet/releases/download/v0.9.3/cirros.img，virtlet根据该地址去下载，下载完毕后从而去创建虚拟机。

• 自定义对象配置：virtlet提供VirtletImageMapping资源对象，相对来说，优先级会高于静态配置

apiVersion: “virtlet.k8s/v1”

kind: VirtletImageMapping

metadata:

name: primary

namespace: kube-system

spec:

prefix: “”

translations:

– …

– …

默认的是，virtlet是基于文件系统进行存储虚拟机镜像，镜像存储地址如下：

/var/lib/virtlet/images

links/

example.com%whatever%etc -> ../data/2d711642b726b04401627ca9fbac32f5c8530fb1903cc4db02258717921a4881

example.com%same%image   -> ../data/2d711642b726b04401627ca9fbac32f5c8530fb1903cc4db02258717921a4881

anotherimg               -> ../data/a1fce4363854ff888cff4b8e7875d600c2682390412a8cf79b37d0b11148b0fa

data/

2d711642b726b04401627ca9fbac32f5c8530fb1903cc4db02258717921a4881

a1fce4363854ff888cff4b8e7875d600c2682390412a8cf79b37d0b11148b0fa

镜像名称中/字段转换成%，并软连接到匹配的数据文件。

Virtlet优缺点

优点

• 沿用原生workload，virtlet可无缝接入已有平台
• 复用CRI能力，侵入性小

缺点

• 引入CRIPROXY链路风险
• 限于CRI的整体框架内，无法灵活扩展
• 不支持CSI，仅支持flexvolume存储驱动
• 不支持备份与迁移等能力
• 社区活跃度低，已不再继续维护

整体来说，virtlet是一种接入成本低，能够快速融入已有云平台的方式，但由于社区已不维护且本身CRI方式对接的局限性，对后续的可扩展性以及迭代开发来说，其可扩展方式不够优雅且低，迭代开发难度相对来说大。