了解Kubevirt

作者: 杰森·布鲁克斯(Jason Brooks) (红色的帽子)

一旦习惯了在Kubernetes上运行Linux容器工作负载,您可能会发现自己希望在Kubernetes集群上运行其他类型的工作负载。也许您需要运行的应用程序不是为容器而设计的,或者需要与容器主机上可用的应用程序不同的Linux内核版本(或所有不同的操作系统)。

这类工作负载通常非常适合在虚拟机(VM)中运行,并且 KubeVirt,用于Kubernetes的虚拟机管理插件,旨在允许用户在其Kubernetes或OpenShift集群中的容器旁边运行VM。

KubeVirt通过添加Kubernetes的VM和VM集的资源类型来扩展Kubernetes 自定义资源定义API (CRD)。 KubeVirt VM在常规Kubernetes容器内运行,可以在其中访问标准容器网络和存储,并且可以使用诸如Kubectl之类的标准Kubernetes工具进行管理。

与使用oVirt或OpenStack之类的软件相比,使用Kubernetes运行VM涉及一些调整,并且了解KubeVirt的基本体系结构是一个不错的起点。

在这篇文章中,我们将从更高层次上讨论KubeVirt涉及的一些组件。我们将检查的组件包括CRD,KubeVirt 病毒控制者,virt-handler和virt-launcher组件,libvirt,存储和网络。

KubeVirt组件

Kubevirt组件

自定义资源定义

Kubernetes资源是Kubernetes API中的端点,用于存储相关API对象的集合。例如,内置的pods资源包含Pod对象的集合。 Kubernetes 自定义资源定义 API允许用户通过使用给定名称和架构定义新对象来扩展带有其他资源的Kubernetes。将自定义资源应用于集群后,Kubernetes API服务器将服务并处理自定义资源的存储。

KubeVirt的主要CRD是VirtualMachine(VM)资源,其中包含Kubernetes API服务器内部的VM对象的集合。 VM资源定义了虚拟机本身的所有属性,例如计算机和CPU类型,RAM和vCPU的数量以及VM中可用的NIC的数量和类型。

病毒控制者

病毒控制者是一个Kubernetes 操作员 负责整个群集的虚拟化功能。将新的VM对象发布到Kubernetes API服务器时,virt-controller会注意到并创建将在其中运行VM的Pod。当将Pod安排在特定节点上时,virt-controller将使用节点名称更新VM对象,并将进一步的职责移交给特定于节点的KubeVirt组件,virt-handler,其实例在该节点中的每个节点上运行集群。

病毒处理者

与virt-controller一样,virt-handler也是反应性的,监视VM对象的更改,并执行所有必要的操作以更改VM以满足所需状态。 病毒处理者引用VM规范,并使用VM的Pod中的libvirtd实例通知创建相应域的信号。删除VM对象时,virt-handler会观察到该删除并关闭域。

病毒发射器

为每个VM对象创建一个pod。该容器的主容器运行virt-launcher KubeVirt组件。 病毒发射器 Pod的主要目的是提供将用于托管VM进程的cgroup和名称空间。

病毒处理者通过将VM的CRD对象传递给virt-launcher来通知virt-launcher启动VM。然后,virt-launcher使用其容器内的本地libvirtd实例启动虚拟机。从那里,virt-launcher监视VM进程,并在VM退出后终止。

如果Kubernetes运行时在VM退出之前尝试关闭virt-launcher容器,virt-launcher会将信号从Kubernetes转发到VM进程,并尝试推迟容器的终止,直到VM成功关闭。

# kubectl get pods

NAME                                   READY     STATUS        RESTARTS   AGE
virt-controller-7888c64d66-dzc9p   1/1       Running   0          2h
virt-controller-7888c64d66-wm66x   0/1       Running   0          2h
virt-handler-l2xkt                 1/1       Running   0          2h
virt-handler-sztsw                 1/1       Running   0          2h
virt-launcher-testvm-ephemeral-dph94   2/2       Running       0          2h

libvirtd

每个VM Pod中都存在一个libvirtd实例。 病毒发射器使用libvirtd来管理VM进程的生命周期。

存储和网络

KubeVirt VM可以配置有由卷支持的磁盘。

持续体积索赔 卷使Kubernetes永久卷可用作直接连接到VM的磁盘。这是为KubeVirt VM提供永久存储的主要方法。当前,持久卷必须是iscsi块设备,尽管正在进行中的工作是启用 基于文件的光伏磁盘.

临时卷 是使用网络卷作为只读后备存储的写映像的本地副本。当虚拟机启动时,KubeVirt动态生成与该虚拟机关联的临时映像,并在虚拟机停止时丢弃该临时映像。当前,临时卷必须由pvc卷支持。

注册表磁盘 卷参考嵌入了qcow或原始磁盘的docker映像。顾名思义,这些卷是从容器注册表中提取的。像常规的临时容器映像一样,这些卷中的数据仅在Pod存活时才保留。

CloudInit NoCloud 卷为VM提供了一个cloud-init NoCloud用户数据源,该源数据作为磁盘添加到VM中,可用于向安装了cloud-init的来宾提供配置详细信息。可以以明文形式,以base64编码的UserData文件或通过Kubernetes机密提供Cloud-init详细信息。

在下面的示例中,注册表磁盘被配置为提供从中引导虚拟机的映像。提供了cloudInit NoCloud卷,与以明文形式存储在userData字段中的ssh密钥配对,用于通过VM进行身份验证:

apiVersion: kubevirt.io/v1alpha1
kind: VirtualMachine
metadata:
  name: myvm
spec:
  terminationGracePeriodSeconds: 5
  domain:
    resources:
      requests:
        memory: 64M
    devices:
      disks:
      - name: registrydisk
        volumeName: registryvolume
        disk:
          bus: virtio
      - name: cloudinitdisk
        volumeName: cloudinitvolume
        disk:
          bus: virtio
  volumes:
    - name: registryvolume
      registryDisk:
        image: kubevirt/cirros-registry-disk-demo:devel
    - name: cloudinitvolume
      cloudInitNoCloud:
        userData: |
          ssh-authorized-keys:
            - ssh-rsa AAAAB3NzaK8L93bWxnyp test@test.com

与常规的Kubernetes Pod一样,基本的网络功能也自动提供给每个KubeVirt VM,并且可以使用常规的Kubernetes服务将特定的TCP或UDP端口暴露给外界。不需要特殊的网络配置。

卷入

KubeVirt的开发正在加速,并且该项目渴望新的贡献者。如果您有兴趣参与,请查看该项目的 开放式问题 并检查 项目日历.

如果您需要帮助或想要聊天,可以通过#kubevirt或KubeVirt上的freenode IRC连接到团队。 邮件列表。用户文档位于: //kubevirt.gitbooks.io/user-guide/.