乐趣区

关于虚拟机:virtlet是什么virtlet如何管理虚拟机

jiezi

随着 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/v…

  • name: fedora
    url: https://dl.fedoraproject.org/…
    举个例子：
    当你将 image 配置成 virtlet.cloud/cirrors, virtlet 会将该镜像转换成
    https://github.com/mirantis/v…，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 形式对接的局限性，对后续的可扩展性以及迭代开发来说，其可扩大形式不够优雅且低，迭代开发难度相对来说大。

退出移动版