一种实现云原生应用管理虚拟机的方法与流程

本发明涉及云计算技术领域，具体地说是一种实现云原生应用管理虚拟机的方法。

背景技术：

随着云计算及虚拟化在各个生产环境更大规模的广泛应用，以容器为代表的基于linuxnamespace+cgroup实现虚拟化技术与生俱来的安全问题日益突出。

技术实现要素：

本发明的技术任务是针对以上不足之处，提供一种实现云原生应用管理虚拟机的方法，能够能够有效实现公有云，私有云，混合云厂商的客户对于传统虚拟机应用的诉求，同时也能保持容器化应用的快速启动速度，沿用容器编排的使用习惯，改善用户满意度。

本发明解决其技术问题所采用的技术方案是：

一种实现云原生应用管理虚拟机的方法，该方法中，

虚拟机使用现有容器运行时在pod中运行；

使用自定义的声明式api管理虚拟机，并通过虚拟机控制器、虚拟机处理程序和虚拟机启动程序实现虚拟机专用api和相应的工作负载控制器：

虚拟机控制器实现自定义的kubernetesoperator，用于处理集群中的虚拟化功能；虚拟机处理程序负责从虚拟机管理器调度过来请求，并执行必要的操作更改虚拟机以满足所需状态；创建的每个虚拟机对象都创建一个pod，该pod运行就是虚拟机启动程序。

该方法结合管理容器的技术管理传统的虚拟机，实现容器原生的虚拟化，将虚拟机带入容器化的工作流，能够解决很多两者单独解决不了的问题。

优选的，通过pvc机制提供持久性存储来交付虚拟机磁盘。虚拟机需要永久性磁盘，用户应该能够停止虚拟机，启动虚拟机并保留数据。kubernetes有一个称为pvc(持久卷声明)的存储抽象，它允许将持久存储附加到pod，这意味着通过将虚拟机放置在pod中，我们可以使用现有的pvc机制来提供持久性存储来交付我们的虚拟机磁盘。

优选的，虚拟机需要访问群集网络，提供pod网络接口，这些接口通过cni直接绑定到pod网络中。

进一步的，使用pod环境中已经存在的默认的cni分配的网络接口，使在pod中运行的虚拟机访问pod网络。

优选的，通过使用pod规范上的资源请求/限制，将cpu和内存分配给虚拟机。用户需要能够将cpu和内存资源分配给虚拟机，我们可以使用pod规范上的资源请求/限制将cpu和内存分配给pod，这意味着通过使用容器资源请求/限制，我们也可以直接将资源分配给虚拟机。

优选的，在创建新的虚拟机对象时，所述虚拟机控制器会创建供所述虚拟机在其中运行的pod，将pod安排到特定节点后，虚拟机控制器使用计划在其上的节点名称更新虚拟机对象，并将控制权移交给特定于节点的vm-launcher组件，该组件运行在虚拟机中的每个节点上。

优选的，虚拟机处理程序在pod中根据虚拟机描述文件创建相应的域，当pod从其运行的节点上删除时，它也会删除域。

优选的，所述虚拟机启动程序提供虚拟机进程所需的cgroup和名称空间，虚拟机处理程序将虚拟机的crd传递给虚拟机启动程序，虚拟机启动程序在其容器中使用本地libvirtd实例启动时机的虚拟机。虚拟机启动程序密切关注虚拟机进程，并在虚拟机退出后终止。在某些情况下，kubernetes运行时可能会在虚拟机进程退出之前尝试关闭虚拟机启动程序pod，发生这种情况时，虚拟机启动程序会将kill信号传递给虚拟机进程，并尝试推迟pod的终止，直到虚拟机进程正常关闭为止。

本发明还要求一种实现云原生应用管理虚拟机的装置，包括：至少一个存储器和至少一个处理器；

所述至少一个存储器，用于存储机器可读程序；

所述至少一个处理器，用于调用所述机器可读程序，执行权利上述的方法。

本发明还要求保护一种计算机可读介质，所述计算机可读介质上存储有计算机指令，所述计算机指令在被处理器执行时，使所述处理器执行上述的方法。

本发明的一种实现云原生应用管理虚拟机的方法与现有技术相比，具有以下有益效果：

该方法将容器管理技术kubernetes和虚拟机管理技术两者结合到一个管理平台，充分利用容器以及容器编排技术的简捷快速的特点，同时可以为设计运行在虚拟机上那些应用服务；

能够有效实现公有云，私有云，混合云厂商的客户对于传统虚拟机应用的诉求，同时也能保持容器化应用的快速启动速度，沿用容器编排的使用习惯，改善用户满意度。

附图说明

图1是本发明一个实施例提供的实现云原生应用管理虚拟机的方法架构图。

具体实施方式

下面结合附图和具体实施例对本发明作进一步说明。

本发明实施例提供一种实现云原生应用管理虚拟机的方法，本方法着眼于云计算场景下，如何将容器管理技术kubernetes和虚拟机管理技术两者结合到一个管理平台，充分利用容器以及容器编排技术的简捷快速的特点，同时可以为设计运行在虚拟机上那些应用服务，毕竟目前还有为数众多的应用是跑在虚拟机上的。

该方法结合管理容器的技术管理传统的虚拟机，实现容器原生的虚拟化，将虚拟机带入容器化的工作流，能够解决很多两者单独解决不了的问题。

虚拟机使用现有容器运行时在pod中运行。这个决定是在其他kubernetes虚拟化努力正在创建自己的虚拟化特定cri运行时的时候做出的，pod环境中运行虚拟机可以使用现有和将来的容器运行时最新的技术和能力。

就kubernetes而言，没有虚拟机，只有pod和容器，从根本上说，虚拟机与集群其余部分的任何其他容器化应用程序一样。所以将虚拟机作为pod来运行，在kubernetespod中运行虚拟机的收益对我们来说是巨大的，如何为pod提供对网络，存储，主机设备，cpu，内存等的访问权，整个生态系统在不断发展，这意味着每次将问题或功能添加到pod时，本方案在pod中运行虚拟机都能受益。

存储：

通过pvc机制提供持久性存储来交付虚拟机磁盘。虚拟机需要永久性磁盘，用户应该能够停止虚拟机，启动虚拟机并保留数据。kubernetes有一个称为pvc(持久卷声明)的存储抽象，它允许将持久存储附加到pod，这意味着通过将虚拟机放置在pod中，我们可以使用现有的pvc机制来提供持久性存储来交付我们的虚拟机磁盘。

网络：

虚拟机需要访问群集网络，提供pod网络接口，这些接口通过cni直接绑定到pod网络中。使用pod环境中已经存在的默认的cni分配的网络接口，使在pod中运行的虚拟机访问pod网络。

cpu/内存：

用户需要能够将cpu和内存资源分配给虚拟机。我们可以使用pod规范上的资源请求/限制将cpu和内存分配给pod。这意味着通过使用容器资源请求/限制，我们也可以直接将资源分配给虚拟机。

使用自定义的“类似kubernetes”声明式api管理虚拟机，并通过虚拟机控制器、虚拟机处理程序和虚拟机启动程序实现虚拟机专用api和相应的工作负载控制器。

以前，命令性api是其他平台如何管理虚拟机的事实上的标准。但是，为了使用现有kubernetes工具(如kubectl)管理的真正云原生api的并享受其带来的好处，就必须完全遵守声明式工作流程。

虚拟机不仅可以运行一次即可完成，虚拟机具有状态，它们可以启动、停止和重新启动任何次数，虚拟机也具有实时迁移等概念，此外，如果虚拟机上运行的节点死亡，则期望该完全相同的虚拟机在保持其状态的另一个节点上恢复，因此，pod只能运行一次，而虚拟机将永远存在。

为了实现类似kubernetes的声明式api来管理虚拟机，需要实现虚拟机专用api和相应的工作负载控制器。用户通过将虚拟机对象的描述文件(也是yaml格式)发布到集群中。(这里需要注意，与pod的管理方式不同的最大区别是，虚拟机对象的声明可以定义不同的状态。例如，可以通过在虚拟机对象的描述文件设置为“running：true”来声明要“启动”虚拟机。同样，可以通过在虚拟机对象的描述文件上设置“running：false”来声明要“停止”虚拟机。在后台，将“运行”字段设置为true或false会导致工作负载控制器创建或删除供虚拟机使用的容器。)

通过以上两点，api和控制器知道如何通过构造具有所有正确网络，存储卷，cpu和内存的pod来复活“已停止”的虚拟机，从而准确的管理的虚拟机的整个生命周期。

基于以上两点实现本技术方案需要基于kubernetescrd(自定义资源扩展)开发以下三个组件：虚拟机控制器(vm-controller)、虚拟机处理程序(vm-handler)和虚拟机启动程序(vm-launcher)。

虚拟机控制器(vm-controller)：

实现自定义的kubernetesoperator，用于处理群集中的虚拟化功能。创建新的vm对象时，vm-controller会创建虚拟机将在其中运行的pod。将pod安排到特定节点后，vm-controller会使用计划在其上的节点名称更新vm对象，并将控制权移交给特定于节点的vm-launcher组件，该组件运行在虚拟机中的每个节点上。

虚拟机处理程序(vm-handler)：

虚拟机处理程序负责从vm-controller调度过来的请求。然后，vm-handler执行必要的操作更改vm以满足所需状态。它负责在pod中根据vm描述文件创建相应的域。当pod从其运行的节点上删除时，它也会删除域。

虚拟机启动程序(vm-launcher)：

创建的每个vm对象都创建一个pod，该pod运行的就是虚拟机启动程序。该组件提供了vm进程所需的cgroup和名称空间。vm-handler将虚拟机的crd传递给vm-launcher，然后vm-launcher在其容器中使用本地libvirtd实例来启动实际的vm。vm-launcher密切关注vm进程，并在vm退出后终止。在某些情况下，kubernetes运行时可能会在vm进程退出之前尝试关闭vm-launcherpod。发生这种情况时，vm-launcher会将kill信号传递给vm进程，并尝试推迟pod的终止，直到vm进程正常关闭为止。

该方法能有效实现公有云，私有云，混合云厂商的客户对于传统虚拟机应用的诉求，同时也能保持容器化应用的快速启动速度，沿用容器编排的使用习惯，改善用户满意度。

本发明实施例还提供了一种实现云原生应用管理虚拟机的装置，包括：至少一个存储器和至少一个处理器；

所述至少一个存储器，用于存储机器可读程序；

所述至少一个处理器，用于调用所述机器可读程序，执行本发明上述实施例中所述的实现云原生应用管理虚拟机的方法。

本发明实施例还提供了一种计算机可读介质，所述计算机可读介质上存储有计算机指令，所述计算机指令在被处理器执行时，使所述处理器执行本发明上述实施例中所述的实现云原生应用管理虚拟机的方法。具体地，可以提供配有存储介质的系统或者装置，在该存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机(或cpu或mpu)读出并执行存储在存储介质中的程序代码。

在这种情况下，从存储介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此程序代码和存储程序代码的存储介质构成了本发明的一部分。

用于提供程序代码的存储介质实施例包括软盘、硬盘、磁光盘、光盘(如cd-rom、cd-r、cd-rw、dvd-rom、dvd-ram、dvd-rw、dvd+rw)、磁带、非易失性存储卡和rom。可选择地，可以由通信网络从服务器计算机上下载程序代码。

此外，应该清楚的是，不仅可以通过执行计算机所读出的程序代码，而且可以通过基于程序代码的指令使计算机上操作的操作系统等来完成部分或者全部的实际操作，从而实现上述实施例中任意一项实施例的功能。

此外，可以理解的是，将由存储介质读出的程序代码写到插入计算机内的扩展板中所设置的存储器中或者写到与计算机相连接的扩展单元中设置的存储器中，随后基于程序代码的指令使安装在扩展板或者扩展单元上的cpu等来执行部分和全部实际操作，从而实现上述实施例中任一实施例的功能。

上文通过附图和优选实施例对本发明进行了详细展示和说明，然而本发明不限于这些已揭示的实施例，基与上述多个实施例本领域技术人员可以知晓，可以组合上述不同实施例中的代码审核手段得到本发明更多的实施例，这些实施例也在本发明的保护范围之内。