CN114579250A - 一种构建虚拟集群的方法、装置及存储介质 - Google Patents

Abstract

本申请提供一种构建虚拟集群的方法、装置及存储介质，用以提供一种简单易用的构建虚拟集群的方式。在本申请中，通过预先部署在物理机集群上的虚拟集群主控制器，在物理机集群中至少一个物理机上构建功能控制组件；基于功能控制组件，对虚拟集群主控制节点进行仿真；基于虚拟集群主控制器和仿真的虚拟集群主控制节点，在物理机集群中至少一个其他物理机上构建至少一个工作组件；基于至少一个工作组件，对虚拟集群工作节点进行仿真，一个工作组件对应一个虚拟集群工作节点；在每次构建虚拟集群时，无需在物理机集群上部署用于构建虚拟集群的脚本，而是通过预先部署在物理机集群上的虚拟集群主控制器构建虚拟集群，构建方式简单易用。

Description

一种构建虚拟集群的方法、装置及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种构建虚拟集群的方法、装置及存储介质。

背景技术

K8s提供一个对K8s集群进行性能测试的工具Kubemark，利用Kubemark在K8s集群中构建虚拟集群，并在虚拟集群上进行测试，获得虚拟集群的性能指标，将获得虚拟集群的性能指标作为K8s集群的测试数据，即将虚拟集群的测试数据作为真实物理机集群的测试数据，以实现对真实物理机集群的测试。

利用Kubemark在K8s集群中构建虚拟集群时，在K8s集群的物理机上构建Kubemark的脚本，利用Kubemark的脚本在物理机上直接构建虚拟集群，但目前利用脚本直接在物理机上构建虚拟集群的构建方式复杂。

发明内容

本申请提供一种构建虚拟集群的方法、设备及存储介质，用以提供一种简单易用的构建虚拟集群的方式。

第一方面，本申请实施例提供一种构建虚拟集群的方法，该方法包括：

通过预先部署在物理机集群上的虚拟集群主控制器(Virtual ClusterController)，在物理机集群中至少一个物理机上构建功能控制组件，并基于功能控制组件，对虚拟集群主控制节点进行仿真；以及

通过虚拟集群主控制器，在物理机集群中至少一个其他物理机上构建至少一个工作组件，并基于至少一个工作组件，对虚拟集群工作节点进行仿真，其中，一个工作组件对应一个虚拟集群工作节点。

第二方面，本申请实施例提供一种构建虚拟集群的装置，该装置包括：

第一构建单元，用于通过预先部署在物理机集群上的虚拟集群主控制器，在物理机集群中至少一个物理机上构建功能控制组件，并基于功能控制组件，对虚拟集群主控制节点进行仿真；以及

第二构建单元，用于通过虚拟集群主控制器，在物理机集群中至少一个其他物理机上构建至少一个工作组件，并基于至少一个工作组件，对虚拟集群工作节点进行仿真，其中，一个工作组件对应一个虚拟集群工作节点。

在一种可能的实现方式中，第一构建单元通过预先部署在物理机集群上的虚拟集群主控制器，在物理机集群中至少一个物理机上构建功能控制组件之前，还用于：

通过虚拟集群主控制器监控到虚拟集群构建指令时，根据物理机集群中预先部署的用于生成虚拟集群实体(Virtualcluster)和集群版本实体(Clusterversion)的规范信息，构建相应的虚拟集群实体和集群版本实体，其中，虚拟集群实体包含用于配置虚拟集群对应的集群信息的第一配置文件，集群版本实体包含用于配置功能控制组件对应的配置和版本及至少一个工作组件对应的配置和版本的第二配置文件；

通过虚拟集群主控制器调用虚拟集群实体和集群版本实体，根据虚拟集群实体包含的第一配置文件中的集群信息，查找与集群信息匹配的集群版本实体；

其中，集群版本实体包含的所述第二配置文件中的功能控制组件对应的配置和版本及至少一个工作组件对应的配置和版本，是根据虚拟集群构建指令中携带的组件的配置和版本确定的。

在一种可能的实现方式中，第一构建单元具体用于：

通过虚拟集群主控制器，根据集群版本实体包含的第二配置文件，在至少一个物理机上构建功能控制组件。

在一种可能的实现方式中，第二构建单元具体用于：

通过虚拟集群主控制器，根据集群版本实体包含的第二配置文件，在至少一个其他物理机上构建至少一个工作组件。

在一种可能的实现方式中，第一构建单元具体用于：

基于集群版本实体包含的第二配置文件，在至少一个物理机上构建用于管理和构建功能控制组件的第一控制器；

通过第一控制器，构建功能控制组件。

在一种可能的实现方式中，第二构建单元具体用于：

基于集群版本实体包含的第二配置文件，在至少一个其他物理机上构建用于管理和构建工作组件的第二控制器；

通过第二控制器，构建至少一个工作组件。

在一种可能的实现方式中，功能控制组件包括应用程序编程接口服务(Application Programming Interface Server，API Server)组件，第一构建单元根据集群版本实体包含的第二配置文件，在至少一个物理机上构建API Server组件，还用于：

根据集群版本实体包含的第二配置文件，构建设置主机网络(Host Network)的API Server组件；

其中，API Server组件以API Server组件所在的物理机的网络协议(InternetProtocol，IP)进行服务配置。

在一种可能的实现方式中，功能控制组件包括调度(Volcano)组件，第一构建单元根据集群版本实体包含的第二配置文件，在至少一个物理机上构建Volcano组件之后，还用于：

构建Volcano组件中的调度器(Scheduler)对应的服务(Service)，以使监控工具通过Service暴露的接口监控Volcano组件的性能指标。

在一种可能的实现方式中，第一构建单元通过预先部署在物理机集群上的虚拟集群主控制器，在物理机集群中至少一个物理机上构建功能控制组件之前，还用于：

通过虚拟集群主控制器，构建用于存储功能控制组件和工作组件的租户命名空间(Namespace)；以及

通过虚拟集群主控制器，构建用于功能控制组件和工作组件进行相互认证和通信使用的公开密钥基础设施(Public Key Infrastructure，PKI)。

在一种可能的实现方式中，虚拟集群工作节点用于实现中央处理器(CentralProcessing Unit，CPU)功能、图形处理器(Graphics Processing Unit,GPU)功能、存储(Memory)功能的之一或组合。

在一种可能的实现方式中，虚拟集群工作节点用于实现GPU功能时，通过虚拟集群工作节点，运行Hollow-Kubelet，构建Kubelet.sock；以及

通过虚拟集群工作节点，运行模拟设备插件(mock-device-plugin)，通过mock-device-plugin监听Kubelet.sock，以使mock-device-plugin与Hollow-Kubelet通信并注册GPU资源。

在一种可能的实现方式中，若mock-device-plugin未监听到Kubelet.sock，则控制mock-device-plugin进入休眠后重启。

在一种可能的实现方式中，第一构建单元通过预先部署在至少一个物理机上的虚拟集群主控制器，在至少一个物理机上构建功能控制组件之前，还用于：

按照物理机集群中部署的用于限制虚拟集群主控制器操作资源的管理权限，运行虚拟集群主控制器。

第三方面，本申请实施例提供一种构建虚拟集群的设备，包括：存储器和处理器，其中，存储器，用于存储计算机指令；处理器，用于执行计算机指令以实现本申请实施例提供的构建虚拟集群的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质存储有计算机指令，计算机指令被处理器执行时实现本申请实施例提供的构建虚拟集群的方法。

本申请有益效果如下：

本申请提供一种构建虚拟集群的方法、装置及存储介质；本申请在物理机集群上构建虚拟集群时，通过预先部署的虚拟集群主控制器在物理机集群中的至少一个物理机上构建功能控制组件，以及在物理机集群的至少一个其他物理机上构建工作组件，并基于功能控制组件对虚拟集群主控制节点进行仿真，以及基于至少一个工作组件对虚拟集群工作节点进行仿真，一个工作组件对应一个虚拟集群工作节点，虚拟集群主控制节点和虚拟集群工作节点组成虚拟集群；通过预先部署在物理机集群上的虚拟集群主控制器进行虚拟集群构建，在每次构建虚拟集群时，无需在物理机集群上部署用于构建虚拟集群的脚本，简化了在物理机集群中部署脚本的过程，且避免了利用脚本在物理机集群上直接构建虚拟集群不利于管理的问题，因此使用本申请提供的通过预先部署在物理机集群上的虚拟集群主控制器构建虚拟集群的构建方式简单易用。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为构建虚拟集群的应用场景示意图；

图2为本申请实施例提供的一种构建虚拟集群的方法流程图；

图3为本申请实施例提供的一种在物理机集群上构建虚拟集群的示意图；

图4为本申请实施例提供的第一种针对虚拟集群进行监控的示意图；

图5为本申请实施例提供的第二种针对虚拟集群进行监控的示意图；

图6为本申请实施例提供的第三种针对虚拟集群进行监控的示意图；

图7为本申请实施例提供的第四种针对虚拟集群进行监控的示意图；

图8为本申请实施例提供的第五种针对虚拟集群进行监控的示意图；

图9为本申请实施例提供的第六种针对虚拟集群进行监控的示意图；

图10为本申请实施例提供的第七种针对虚拟集群进行监控的示意图；

图11为本申请实施例提供的第八种针对虚拟集群进行监控的示意图；

图12为本申请实施例提供的第九种针对虚拟集群进行监控的示意图；

图13为本申请实施例提供的一种Hollow Node组件仿真出虚拟集群工作节点的示意图；

图14为本申请实施例提供的另一种Hollow Node组件仿真出虚拟集群工作节点的示意图；

图15为本申请实施例提供的一种构建虚拟集群的整体方法流程图；

图16为本申请实施例提供的一种构建虚拟集群的装置结构图；

图17为本申请实施例提供的一种计算设备的结构图。

具体实施方式

本申请实施例描述的架构以及业务场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

以下对本申请实施例中的部分用语进行解释说明，以便于本领域技术人员理解：

1、K8s：

K8s全称kubernetes，是用8代替8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效，Kubernetes提供了应用部署、规划、更新、维护的一种机制。

2、Kubemark：

Kubemark是K8s提供的一个对K8s集群进行性能测试的工具，其中K8s集群为本申请的物理机集群。它可以模拟出一个虚拟集群，不受资源限制，从而能够测试的虚拟集群规模比真实集群大的多。这个虚拟集群中主控制节点(master)是真实的机器即物理机集群中的一个物理机，所有的工作节点(node)是Hollow node。Hollow node执行的是真实的程序，只是不会调用容器，因此测试会走一套K8s API调用的完整流程，但是不会真正构建Pod。

Kubemark是在模拟的虚拟集群上跑测试，从而获得虚拟集群的性能指标。虚拟集群的测试数据，虽然与真实集群的稍有误差，不过可以代表真实集群的数据。

3、Pod是K8s的最小单位。Pod的IP地址是随机的，删除Pod会改变IP。Pod都有一个根容器，一个Pod内可以由一个或多个容器组成，一个Pod内的容器共享根容器的网络命名空间，一个Pod的内的网络地址由根容器提供。

4、集群是一种计算机系统，它通过一组松散集成的计算机软件和/或硬件连接起来高度紧密地协作完成计算工作。集群计算机系统中的单个计算机通常称为节点，各个节点之间通常通过局域网连接，但也有其它的可能连接方式。集群计算机系统通常用来改进单个计算机的计算速度和/或可靠性。

5、GPU又称显示核心、视觉处理器、显示芯片，是一种专门在个人电脑、工作站、游戏机和一些移动设备(如平板电脑、智能手机等)上做图像和图形相关运算工作的微处理器。

6、CPU是电子计算机的主要设备之一，电脑中的核心配件。其功能主要是解释计算机指令以及处理计算机软件中的数据。CPU是计算机中负责读取指令，对指令译码并执行指令的核心部件。中央处理器主要包括两个部分，即控制器、运算器，其中还包括高速缓冲存储器及实现它们之间联系的数据、控制的总线。电子计算机三大核心部件就是CPU、内部存储器、输入/输出设备。中央处理器的功效主要为处理指令、执行操作、控制时间、处理数据。

7、PKI是一个包括硬件、软件、人员、策略和规程的集合，用来实现基于公钥密码体制的密钥和证书的产生、管理、存储、分发和撤销等功能。

PKI体系是计算机软硬件、权威机构及应用系统的结合。它为实施电子商务、电子政务、办公自动化等提供了基本的安全服务，从而使那些彼此不认识或距离很远的开发者能通过信任链安全地交流。

8、云技术(Cloud technology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。

云技术(Cloud technology)基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

下面介绍本申请的基本构思。

本申请是针对在物理机集群中构建虚拟集群的，目前在物理机集群中构建虚拟集群的相关技术中，构建虚拟集群的方式为利用Kubemark构建虚拟集群。K8s给出了在物理机上构建Kubemark的脚本，即将Kubemark的脚本部署在物理机集群的物理机上，通过Kubemark的脚本直接在物理机集群的物理机上部署用于构建虚拟集群的集群组件。

由于物理机资源紧张时需要把虚拟集群停掉，当有空闲的物理机资源时，需要再次在物理机集群中构建虚拟集群，因此需要在物理机集群中多次构建虚拟集群，此时需要在物理机集群中多次部署Kubemark的脚本。在物理机集群中部署脚本比较复杂，需要根据集群状况和开发者的个人需求来修改脚本，这就需要开发者在部署集群方面具有一定的经验和知识。且利用Kubemark的脚本在物理机上构建虚拟集群的方式不利于管理。

有鉴于此，本申请提供一种简单易用的构建虚拟集群的方式，且方便多次在物理机集群中构建虚拟集群。

在本申请中，预先在物理机集群中部署虚拟集群主控制器，当确定需要构建虚拟集群时，运行预先部署的虚拟集群中控制器，通过虚拟集群主控制器在物理机集群中至少一个物理机上构建功能控制组件，并基于功能控制组件，对虚拟集群主控制节点进行仿真；以及通过虚拟集群主控制器在物理机集群中至少一个其他物理机上构建至少一个工作组件，并基于至少一个工作组件，对虚拟集群工作节点进行仿真，一个工作组件对应一个虚拟集群工作节点，此时由虚拟集群主控制节点和虚拟集群工作节点组成虚拟集群，实现虚拟集群的构建。

在本申请中，采用虚拟集群主控制器的方式来构建虚拟集群，会在一个物理机集群中构建一个虚拟集群。此时并没有直接在物理机集群的物理机上部署用于构建虚拟集群的集群组件，而是实现了一个虚拟集群主控制器，通过虚拟集群主控制器在物理机集群的物理机上构建虚拟集群必需的组件，通过这种方式可以根据虚拟构建指令中包含的各类参数，简单的在物理机集群中创建虚拟集群，而无需每次在物理机集群上部署用于构建虚拟集群的脚本，且避免了利用脚本在物理机集群上直接构建虚拟集群不利用管理的问题，使通过预先部署在物理机集群上的虚拟集群主控制构建虚拟集群的构建方式简单易用。

在介绍完本申请实施例的设计思想之后，下面对本申请设置的应用场景进行简要说明。需要说明的是，以下场景仅用于说明本申请实施例而非限定。在具体实施时，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

请参照图1，图1示例性的提供的了本申请实施例的一种应用场景示意图；如图1所示，在该应用场景中包括有终端设备10和服务器11。

其中，终端设备10中安装运行有各种应用，终端设备10为开发者使用的电子设备，该电子设备可以是个人计算机、手机、平板电脑、笔记本、电子书阅读器等具有一定计算能力并且运行有即时通信类软件及网站或者社交类软件及网站的计算机设备。

服务器11可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。

在一种可选的实施方式中，终端设备10与服务器11之间可以通过通信网络进行通信。通信网络是有线网络或无线网络。终端设备10通过无线接入点12与服务器11间接地连接，或终端设备10通过因特网与服务器11直接地连接，本申请在此不做限制。

在一种可能的应用场景中，服务器11为由多个物理机构成的物理机集群，物理机集群中预先部署有虚拟集群主控制器，当服务器11接收到终端设备10的虚拟集群构建指令时，服务器11中的虚拟集群主控制器根据虚拟集群构建指令中的各种参数，构建用于构建虚拟集群的集群组件，并根据构建的集群组件，对虚拟集群主控制节点和虚拟集群的工作节点进行仿真，以实现虚拟集群构建。

在一种可能的实现方式中，本申请实施例提供的通过虚拟集群主控制器构建虚拟集群的实施方式可以应用到深度学习训练平台上，比如深度学习训练平台中的星辰算力平台，星辰算力平台是一个基于K8s构建的机器学习GPU算力平台。

具体的，在深度学习训练平台上运行着如调度器/控制器(Controller)等组件，且也在持续地对这些组件进行优化，以更好地支持物理机集群运行。随着物理机集群规模扩大，组件需要面临大量的请求数据，对组件吞吐量的要求也越来越高。因此深度学习训练平台需要一个和物理机集群规模匹配的虚拟集群，通过虚拟集群来测试虚拟集群组件在大并发量场景下运行的性能，此时通过本申请实施例提供的虚拟集群主控制器在深度学习训练平台上构建虚拟集群。并将虚拟集群组件的运行性能作为物理机集群组件的运行性能，来确保组件在物理机集群下运行正常，也可以支持后续的性能优化。

在一种可能的实现方式中，本申请采用云存储的方式存储服务器中的数据。云存储(cloud storage)是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

目前，存储系统的存储方法为：创建逻辑卷，在创建逻辑卷时，就为每个逻辑卷分配物理存储空间，该物理存储空间可能是某个存储设备或者某几个存储设备的磁盘组成。客户端在某一逻辑卷上存储数据，也就是将数据存储在文件系统上，文件系统将数据分成许多部分，每一部分是一个对象，对象不仅包含数据而且还包含数据标识(ID entity，ID)等额外的信息，文件系统将每个对象分别写入该逻辑卷的物理存储空间，且文件系统会记录每个对象的存储位置信息，从而当客户端请求访问数据时，文件系统能够根据每个对象的存储位置信息让客户端对数据进行访问。

存储系统为逻辑卷分配物理存储空间的过程，具体为：按照对存储于逻辑卷的对象的容量估量(该估量往往相对于实际要存储的对象的容量有很大余量)和独立冗余磁盘阵列(Redundant Array of Independent Disk，RAID)的组别，预先将物理存储空间划分成分条，一个逻辑卷可以理解为一个分条，从而为逻辑卷分配了物理存储空间。

下面结合上述描述的应用场景，参考附图来描述本申请示例性实施方式提供的构建虚拟集群的方法，需要注意的是，上述应用场景仅是为了便于理解本申请的精神和原理而示出，本申请的实施方式在此方面不受任何限制。

在本申请中，预先在物理机集群上部署虚拟集群主控制器，并控制虚拟集群主控制器在物理机集群上运行。此时，物理机集群将通过虚拟集群主控制器监控虚拟集群构建指令，当监控到虚拟集群构建指令后，通过预先部署在物理机集群上的虚拟集群主控制器，在物理机集群中至少一物理机上构建功能控制组件；以及通过虚拟集群主控制器在物理机集群中至少一个其他物理机上构建至少一个工作组件；之后通过构建的功能控制组件，对虚拟集群主控制节点进行仿真，通过至少一个工作组件对至少一个工作节点进行仿真，实现虚拟集群的构建。

在一种可能的实现方式中，在监控到虚拟集群构建指令后，通过虚拟集群主控制器在物理机集群中至少一个物理机上构建功能控制组件，以及在物理机集群中至少一个其他物理机上构建至少一个工作组件之前，虚拟集群主控制器根据物理机集群中预先部署的用于生成虚拟集群控制实体和集群版本实体的规范信息，构建与虚拟集群构建指令相应的虚拟集群实体和集群版本实体，即对虚拟集群构建指令中指示的虚拟集群实体和集群版本实体进行构建。

其中，构建的虚拟集群实体包含用于配置虚拟集群对应的集群信息的第一配置文件，以及构建的集群版本实体包含用于配置功能控制组件对应的配置和版本，以及至少一个工作组件的配置及版本的第二配置文件。

在构建了虚拟集群实体和集群版本实体后，虚拟集群主控制器将根据虚拟集群实体的第一配置文件和集群版本实体的第二配置文件，构建虚拟集群。

需要说明的是，虚拟集群主控制器在物理机集群中运行时，物理机集群的主控制物理机会监控虚拟集群主控制器运行，要求虚拟集群主控制器按照预先在物理机集群中部署的用于限制虚拟集群主控制器操作资源的管理权限运行。

因此，本申请实施例提供的通过虚拟集群主控制器构建虚拟集群的技术方案中，在物理机集群中需要预先部署如下信息：

在物理机集群上部署必须的两个自定义资源定义(Custom ResourceDefinition，CRD)规范信息，分别为虚拟集群实体(Virtualcluster)和集群版本实体(Clusterversion)的规范信息；其中虚拟集群实体包含用于配置集群信息的第一配置文件，集群信息包括但不限于：集群组件的命名空间(Namespace)、集群名称、集群版本中的至少一种；集群版本实体包含用于配置虚拟集群中功能控制组件的配置和版本，以及工作组件的配置和版本的第二配置文件。

在物理机集群中部署虚拟集群主控制器对应的基于角色的访问控制(Role-BasedAccess Control，RBAC)管理权限，用于限制虚拟集群主控制器在物理机集群中操作资源的权限。

在物理机集群中部署用于构建虚拟集群的虚拟集群主控制器。

需要说明的是，信息部署的过程没有先后顺序，保证在构建虚拟集群时，在物理机集群中已部署上述信息即可。

在本申请中，在物理机集群中部署了虚拟集群实体(Virtualcluster)和集群版本实体(Clusterversion)的规范信息、RBAC管理权限以及虚拟集群主控制器后，虚拟集群主控制器按照RBAC管理权限运行，并监控虚拟集群构建指令，在监控到虚拟集群构建指令后，基于虚拟集群构建指令中的各种参数，根据预先部署的规范信息，构建与虚拟集群构建指令对应的虚拟集群实体和集群版本实体；其中，虚拟集群实体包含用于配置集群信息的第一配置文件；集群版本实体包含用于配置虚拟集群中功能控制组件的配置和版本，以及工作组件的配置和版本的第二配置文件。

其中，虚拟集群构建指令为：

kubectl create-f examples/Clusterversion.yaml；

kubectl create-f examples/Virtualcluster.yaml。

在构建与虚拟集群构建指令对应的虚拟集群实体和集群版本实体之后，通过预先部署的虚拟集群主控制器，根据虚拟集群实体对应的第一配置文件和集群版本实体对应的第二配置文件，构建虚拟集群。

需要说明的是，为了使构建的虚拟集群与物理机集群状态一致，需要保证构建虚拟集群的功能控制组件的配置和版本与物理机集群中的功能控制组件的配置和版本一致，以及保证虚拟集群的至少一个工作组件的配置和版本与物理机集群中的功能控制组件的配置和版本一致。

因此，在虚拟集群构建指令中携带的各种参数中包含各个组件的配置和版本；以使虚拟集群主控制器根据携带的各个组件的配置和版本，按照规范信息构建集群版本实体，此时集群版本实体对应的第二配置文件中包含的功能控制组件的配置和版本，以及至少一个工作组件的配置和版本是根据虚拟集群构建指令中携带的组件的配置和版本确定的。

请参照图2，图2示例性的提供了本申请实施例中一种构建虚拟集群的方法流程，该方法包括如下步骤：

步骤S200，通过预先部署在物理机集群上的虚拟集群主控制器，在物理机集群中至少一个物理机上构建功能控制组件，并基于功能控制组件，对虚拟集群主控制节点进行仿真。

在本申请中，由于已经构建了虚拟集群实体和集群版本实体，因此通过虚拟集群主控制器调用虚拟集群实体和集群版本实体，根据虚拟集群实体对应的第一配置文件中的集群信息，查找与该集群信息匹配的集群版本实体；

根据查找到的集群版本实体对应的第二配置文件中的功能控制组件的配置和版本，构建功能控制组件，并将构建的功能控制组件部署在物理机集群中至少一个物理机上。

在本申请中，将功能控制组件部署在物理机集群中的至少一个物理机后，基于功能控制组件仿真虚拟集群主控制节点。

在逻辑上可以理解为功能控制组件构成虚拟集群主控制节点，即实现对虚拟集群主控制节点的仿真。

步骤S201，基于虚拟集群主控制器，在物理机集群中至少一个其他物理机上构建至少一个工作组件，并基于至少一个工作组件，对虚拟集群工作节点进行仿真，其中，一个工作组件对应一个虚拟集群工作节点。

在本申请中，在查找到与虚拟集群实体对应的集群信息匹配的集群版本实体后，虚拟集群主控制器根据查找到的集群版本实体对应的第二配置文件中的工作组件的配置和版本，构建至少一个工作组件；

将构建的至少一个工作组件，部署在物理机集群中除部署了功能控制组件的物理机以外的至少一个其他物理机上。

在本申请中，工作组件可以仿真出虚拟集群工作节点，对虚拟集群工作节点的操作和维护与真实物理机一致。

在本申请中，虚拟集群主控制节点和虚拟集群工作节点组成了虚拟集群。

在构建完虚拟集群后，使用kubectl-config_dump获取虚拟集群的kubeconfig，开发者就可以使用kubeconfig和虚拟集群进行交互。

请参照图3，图3示例性的提供了本申请实施例中一种在物理机集群上构建虚拟集群的示意图。通过虚拟集群主控制器在物理机集群中构建了虚拟集群，且虚拟集群不影响物理机集群的运行。

从图3中可知，功能控制组件中包含有：Etcd组件、Volcano组件、API Server组件以及Controller Manager组件，且将Etcd组件、Volcano组件、API Server组件以及Controller Manager组件部署在至少一个真实的物理机上。

图3中将Etcd组件、Volcano组件、API Server组件以及Controller Manager组件部署在同一个物理机上为一种示例性的实施方式。在本申请中，还可以将Etcd组件、Volcano组件、API Server组件以及Controller Manager组件部署在不同的物理机上，在此不再赘述。

从图3中可知，工作组件为Hollow Node组件，且Hollow Node组件部署在物理机集群的物理机上，一个物理机上可以部署至少一个Hollow Node组件，Hollow Node组件可以仿真出虚拟集群工作节点。

其中，部署了Hollow Node组件的物理机与部署了功能控制组件的物理机不同，避免部署功能控制组件的物理机由于负载过大出现问题。

下面，详细介绍通过虚拟集群主控制器，根据集群版本实体包含的第二配置文件，构建各个功能控制组件的实施方式。

1、构建Etcd组件：

Etcd组件是一个高可用的键值存储系统，主要用于共享配置和服务发现，通过一致性算法处理日志复制以保证强一致性，通常理解为一个高可用强一致性的服务发现存储仓库。

Etcd组件主要解决的是分布式系统中数据一致性的问题，而分布式系统中的数据分为控制数据和应用数据，Etcd组件处理的数据类型为控制数据，对于很少量的应用数据也可以进行处理。

在一种可能的实现方式中，通过虚拟集群主控制器，根据集群版本实体包含的第二配置文件，构建Etcd Statefulset和对应的Service。

其中，Statefulset是控制器的一种，Etcd Statefulset用于管理和构建Etcd组件，因此在构建了Etcd Statefulset后，通过Etcd Statefulset构建Etcd组件；

需要说明的是，在通过Etcd Statefulset构建Etcd组件时，可以构建至少一个Etcd组件，也可以说是构建至少一个Etcd Pod。

Etcd组件对应的Service用于实现与其他组件进行数据交互。

需要说明的是，构建虚拟集群主控制节点中需要Etcd组件，但是Etcd组件可不通过虚拟集群主控制器构建。在一种示例性的实施方式中，当虚拟集群主控制器根据集群版本实体包含的第二配置文件，构建虚拟集群主控制节点对应的功能控制组件时，若集群版本实体包含的第二配置文件中未记载与Etcd组件的相关信息，则跳过Etcd组件的构建过程。

此时，虚拟集群主控制节点对应的Etcd组件可以通过其他方式进行构建，构建方式主要取决于开发者，比如在构建虚拟集群时，开发者单独编写构建Etcd组件的脚本，在物理机集群中执行该脚本，构建Etcd组件；或该Etcd组件是预先部署好的，因此在构建虚拟集群时无需重新部署Etcd组件；但是为了保证虚拟集群中各个组件的正常交互，需将根据脚本构建的Etcd组件或预先部署的Etcd组件的相关信息配置在虚拟集群构建指令中携带的API Server配置参数中。

在一种可能的实现方式中，当构建虚拟集群是为了进行性能测试时，为了在性能测试时不构成性能瓶颈，将对Etcd组件进行系统上的优化。具体的，由于Etcd组件需要的空间不大，因此可以把数据(Data)放在内存盘里，节约输入输出(Input/Output，IO)时间。

2、构建Volcano组件：

Volcano组件是批处理系统，属于云原生计算基金会(Cloud Native ComputingFoundation Sandbox，CNCF Sandbox)项目，方便通用计算框架接入，提供高性能任务调度引擎，高性能异构芯片管理，高性能任务运行管理等能力。

在一种可能的实现方式中，通过虚拟集群主控制器，根据集群版本实体包含的第二配置文件，构建Volcano组件中的Admission子组件对应的Admission Statefulset和Admission子组件对应的Service，Controller-Manager子组件对应的Controller-ManagerStatefulset和Controller-Manager子组件对应的Service，以及Scheduler子组件对应的Scheduler Statefulset和Scheduler子组件对应的Service。

其中，各个子组件对应的Statefulset用于管理和构建对应的子组件；

需要说明的是，在通过各个子组件对应的Statefulset构建对应的子组件时，可以构建至少一个子组件，比如，Admission Statefulset用于管理和构建至少一个Admission子组件，也可以说是构建至少一个Admission Pod。

各个子组件对应的Service用于实现数据交互。

在一种可能的实现方式中，Scheduler子组件对应的Service用于暴露接口，以使监控工具通过暴露的接口监控Volcano组件的性能指标。

在本申请中，监控工具为Prometheus；本申请通过Prometheus和Grafana部署了监控，如图3所示。通过Prometheus和Grafana部署了监控后，支持对虚拟集群上虚拟集群主控制节点的负载状态，以及虚拟集群主控制节点上的调度器关键性能指标进行监控，图4-图12示例性提供的本申请实施例中进行性能指标监控的监控图表，具体展示了调度方面模块状态，任务和集群资源相关的信息。

从图4中可知，对2个调度器进行监控，一个作为主调度器，另一个作为备选调度器；图5对调度时延进行了监控；图6对调度变化率进行了监控；图7对任务变化率进行了监控；图8对任务调度延迟进行了监控；图9对内存使用量进行了监控；图10对某物理机上CPU利用率变化量进行了监控；图11对Pod抢占变化率进行了监控；图12对某物理机上任务占用内存量进行监控；需要说明的是，物理机是根据IP地址确定的。

3、构建API Server组件：

API Server组件提供了各类资源对象的增删改查及监控等HTTP Rest接口，是整个系统的数据总线和数据中心。

API Server组件的功能包括：提供集群管理的Rest API接口(包括认证授权、数据校验以及集群状态变更)、提供其他组件之间的数据交互和通信的枢纽(其他组件通过APIServer组件查询或修改数据，只有API Server组件直接操作Etcd组件)、是资源配额控制的入口、拥有完备的集群安全机制。

在一种可能的实现方式中，通过虚拟集群主控制器，根据集群版本实体包含的第二配置文件，构建API Server组件的API Server Statefulset和对应的Service。

其中，API Server Statefulset用于管理和构建API Server组件，因此在构建了API Server Statefulset后，通过API Server Statefulset构建API Server组件；

需要说明的是，在通过API Server Statefulset构建对应的API Server组件时，可以构建至少一个API Server组件，也可以说是构建至少一个API Server Pod。

API Server组件对应的Service用于进行数据交互，以使API Server组件通过Service进行服务配置，即使用Service提供API Server的服务。

需要说明的是，当构建虚拟集群是为了进行性能测试时，为了在性能测试时不构成性能瓶颈，将对API Server组件进行系统上的优化。由于API Server组件的特性，导致API Server组件很容易成为性能瓶颈，因此对API Server组件对应的API Server参数进行参数调整，对API Server组件对应的网络进行调整，以在高可用方向进行调整，具体如下：

网络：

在本申请中，使用Service提供API Server的服务，Service的便利处在于其可以很简单地起多个实例高可用并做负载均衡降低负载，但是在流量大的情况下，使用Service提供API Server的服务时，网络延时会很高。

因此，在一种可能的实现方式中，根据集群版本实体包含的第二配置文件为APIServer组件设置Host Network，以及针对设置了Host Network的API Server组件，设置APIServer组件所在的物理机的IP，以使API Server组件以API Server组件所在的物理机的IP进行服务配置。

将API Server组件设置Host Network，使用母机网络即物理机网络，可以大幅降低时延。但是将API Server组件设置Host Network后，物理机集群的域名系统(DomainName System，DNS)就无法使用了，因此在API Server组件的配置中，以Service配置的服务，都需要改成API Server组件所在物理机节点的IP。其他组件中对API Server的配置，也需要修改。

高可用：

由于API Server组件设置了Host Network，想要部署多个API Server组件，可以使用多个虚拟集群主控制节点配置多个API Server组件。在API Server组件之前用网关gateway做转发和负载均衡来缓解API Server的压力。

参数：

在本申请中，API Server组件中包含的API Server参数包括单不限于下列的部分或全部：

信息存放在Etcd中地址的前缀(Etcd-prefix)；

变更请求量(max-requests-inflight)；

非变更请求量(max-mutating-requests-inflight)。

需要说明的是，Etcd-prefix是根据虚拟集群实体的集群名称添加在API Server参数中的，以使API Server组件与Etcd-prefix对应的Etcd组件进行数据交互，通过Etcd组件保存整个虚拟集群的状态；

max-requests-inflight以及max-mutating-requests-inflight是针对大规模的虚拟集群的需求配置的API Server参数，且是通过虚拟集群构建指令中携带的参数确定。

4、构建Controller Manager组件：

在集群中拥有很多Controller，Controller保证集群中各种资源的状态和开发者定义的状态一致，如果出现偏差，则修正资源的状态。

Controller Manager组件是各种Controller的管理者，是集群内部的管理控制中心。

在一种可能的实现方式中，通过虚拟集群主控制器，根据集群版本实体包含的第二配置文件，构建Controller Manager Statefulset和对应的Service。

Controller Manager Statefulset用于管理和构建Controller Manager组件，因此在构建了Controller Manager Statefulset后，通过Controller Manager Statefulset构建Controller Manager组件；

需要说明的是，在通过Controller Manager Statefulset构建对应的ControllerManager组件时，可以构建至少一个Controller Manager组件，也可以说是构建至少一Controller Manager Pod。

Controller Manager组件对应的Service用于实现与其他组件进行数据交互。

需要说明的是，因为Etcd组件、Volcano组件、API Server组件以及ControllerManager组件是根据集群版本实体包含的第二配置文件进行构建的，且集群版本实体包含的第二配置文件是根据虚拟集群构建指令中携带的配置和版本确定的，虚拟集群构建指令中携带的配置和版本是开发者根据物理机集群中主控制物理机中的组件对应的配置和版本确定的，因此Etcd组件、Volcano组件、API Server组件以及Controller Manager组件的配置和版本与物理机集群中的一致。

下面，详细介绍通过虚拟集群主控制器，根据集群版本实体的配置文件包含的第二配置文件，构建工作组件的实施方式。

构建Hollow Node组件：

Hollow Node组件用于仿真虚拟集群工作节点，对虚拟集群工作节点的操作和维护与物理机集群中的工作节点一致。

在一种可能的实现方式中，通过虚拟集群主控制器，根据集群版本实体包含的第二配置文件，构建Hollow Node Deployments；

通过Hollow Node Deployments构建Hollow Node。

需要说明的是，在通过Hollow Node Deployments构建Hollow Node时，可以构建至少一个Hollow Node组件，也可以说是构建至少一Hollow Node Pod。

在本申请中，使用Hollow-Node Deployments的原因是，在构建大批量节点时，Hollow Node Statefulset串行构建Hollow-Node组件的速度过慢，因此使用并行的Deployments。

在本申请中，在通过虚拟集群主控制器根据集群版本实体包含的第二配置文件构建功能控制组件和工作组件之前，还可以通过虚拟集群主控制器，构建用于放置功能控制组件和至少一个工作组件的租户命名空间；以及

通过虚拟集群主控制器，构建用于功能控制组件和至少一个工作组件进行相互认证和通信使用的PKI，其中PKI包括所有的crt/key pair and kubeconfig，且将PKI以Secret的形式存储在物理机集群上。

需要说明的是，在Clusterversion的实例中，在组件的配置里使用组件所对应的Secret volumes。

当构建完功能控制组件和工作组件后，将功能控制组件部署在物理机集群的至少一个物理机中，基于功能控制组件构建虚拟集群的虚拟集群主控制节点；以及将至少一个工作组件放置在物理机集群中除包含有功能控制组件的物理机以外的至少一个其他物理机中，基于工作组件构建虚拟集群的虚拟集群工作节点；虚拟集群主控制节点和虚拟集群工作节点组成虚拟集群；其中一个工作组件对应一个虚拟集群工作节点，每个虚拟集群工作节点上有CPU资源、Memory资源以及GPU资源等。

在本申请中，Hollow Node组件是虚拟集群的灵魂，Hollow Node组件构成虚拟集群的虚拟集群工作节点，也可以理解成Hollow Node组件即为虚拟集群工作节点。虚拟集群工作节点在虚拟集群中的功能与真实工作节点在物理机集群中的功能类似。

通过Hollow Node组件可以仿真任一数量的虚拟集群工作节点，供压力测试使用。Hollow Node组件仿真了代理服务(Kubelet)，支持仿真虚拟集群工作节点上的CPU/Memory和GPU等资源量。绑定在虚拟集群工作节点上的Pod并不会真正运行，且虚拟集群工作节点上的Pod对应的状态是由仿真Kubelet维持的数据结构记录并更新的。如图13和图14所示，图13和图14示例性提供了本申请实施例中一种Hollow Node组件仿真出虚拟集群工作节点的示意图。

在一个Hollow-Node组件中，运行两个容器(Containers)：hollow-kubelet和mock-device-plugin，以及一个init-container。

由于K8s官方提供的Hollow-Node组件并不支持仿真GPU资源，在本申请实施例中对mock-device-plugin进行了修改，使得仿真的虚拟集群工作节点带有GPU资源。

在本申请中，当Hollow-Node组件用于实现GPU功能时，通过虚拟集群工作节点，运行Hollow-Kubelet，构建Kubelet.sock；以及

通过虚拟集群工作节点，运行mock-device-plugin，通过mock-device-plugin监听Kubelet.sock，以使mock-device-plugin与Hollow-Kubelet通信并注册GPU资源。

由于Kubelet.sock是由hollow-kubelet创建的，所以mock-device-plugin需要在hollow-kubelet起来之后再启动，但K8s不支持Hollow-Node组件内Container的有序启动。因此本方案增加了重启(retry)，在无法获取Kubelet.sock时让mock-device-plugincontainer sleep后再重启。即通过mock-device-plugin监听Kubelet.sock时：若未监听到Kubelet.sock，则控制mock-device-plugin进入休眠后重启。

在一种可能的实现方式中，当虚拟集群工作节点用于实现CPU功能时，通过num-cores设置仿真的CPU资源；

当虚拟集群工作节点用于实现Memory功能时，通过mem-caps设置仿真的Memory资源。

需要说明的是，在本申请实施例提供的构建的虚拟集群中，一个容器(Container)配置需求CPU 0.5核，1G Memory存储，以保证容器进程的正常运行。也可以换成更小的需求量。

原始的Hollow-Node组件不支持绑定在虚拟集群工作节点上面的Pod中含有initcontainer。因为绑定在虚拟集群工作节点上面的Pod实际上不会真正去运行，因此仿真Kubelet中存储的虚拟集群工作节点上面的Pod对应的状态会一直是运行状态(running)，所以Pod对应的init container不会停止。因此本申请实施例在Hollow-Node组件中跳过了运行Pod对应的init container的过程，直接认为Pod对应的init container运行结束，解决了这个问题。

为了更好的仿真虚拟集群工作节点上面的Pod创建过程，本申请中使用sleeptime模拟镜像拉取的耗时。当然，在性能测试时，就不再需要sleep无谓地消耗时间，本方案也增加了一个sleep参数，来关闭包括该模拟镜像拉取在内的4个sleep过程。

Hollow-Node组件运行init-container：由于需要监听文件，所以本申请使用init-container来设置母机的fs.inotify.max_user_instances，来保证不会出现文件句柄缺少的问题，其中fs.inotify.max_user_instances是携带在虚拟集群创建指令中的。

图15示例性提供的本申请实施例中一种构建虚拟集群的整体方法流程图，包括如下步骤：

步骤S1500，在物理机集群中预先配置虚拟集群实体和集群版本实体的规范信息、用于限制虚拟集群主控制器在物理机集群中操作资源的管理权限以及虚拟集群主控制器。

步骤S1501，在物理机集群中按照预先配置的用于限制虚拟集群主控制器在物理机集群中操作资源的管理权限，运行虚拟集群主控制器。

步骤S1502，通过运行的虚拟集群主控制器监控到虚拟集群构建指令时，根据物理机集群中预先部署的用于生成虚拟集群实体和集群版本实体的规范信息，构建相应的虚拟集群实体和集群版本实体；

步骤S1503，通过虚拟集群主控制器调用虚拟集群实体和集群版本实体，根据虚拟集群实体对应的第一配置文件中的集群信息，查找与集群信息匹配的集群版本实体；

步骤S1504，通过虚拟集群主控制器，基于集群版本实体对应的第二配置文件，在物理机集群中至少一个物理机上构建功能控制组件，以及在物理机集群中至少一个其他物理机上构建至少一个工作组件；

步骤S1505，基于功能控制组件，对虚拟集群主控制节点进行仿真，以及基于至少一个工作组件，对虚拟集群工作节点进行仿真，构建虚拟集群。

本申请实施例通过虚拟集群主控制器的方式，简单地部署了一个大规模的虚拟集群。该虚拟集群和物理机集群的规模和状态一致，并且能仿真GPU资源。集群中的虚拟节点占用资源量小，可以在少量物理机上构建大量虚拟节点。使用该虚拟集群，可以用于测试组件在大并发量场景下运行的性能，来确保组件在物理机集群下运行正常，同时本申请中也支持后续的性能优化。

基于同一发明构思，本申请实施例还提供了一种构建虚拟集群的装置1600，图16示例性提供了本申请实施例中一种构建虚拟集群的装置，该构建虚拟集群的装置1600，包括：

第一构建单元1601，用于通过预先部署在物理机集群上的虚拟集群主控制器，在物理机集群中至少一个物理机上构建功能控制组件，并基于功能控制组件，对虚拟集群主控制节点进行仿真；以及

第二构建单元1602，用于通过虚拟集群主控制器，在物理机集群中至少一个其他物理机上构建至少一个工作组件，并基于至少一个工作组件，对虚拟集群工作节点进行仿真，其中，一个工作组件对应一个虚拟集群工作节点。

在一种可能的实现方式中，第一构建单元1601通过预先部署在物理机集群上的虚拟集群主控制器，在物理机集群中至少一个物理机上构建功能控制组件之前，还用于：

通过虚拟集群主控制器监控到虚拟集群构建指令时，根据物理机集群中预先部署的用于生成虚拟集群实体(Virtualcluster)和集群版本实体(Clusterversion)的规范信息，构建相应的虚拟集群实体和集群版本实体，其中，虚拟集群实体包含用于配置虚拟集群对应的集群信息的第一配置文件，集群版本实体包含用于配置功能控制组件对应的配置和版本及至少一个工作组件对应的配置和版本的第二配置文件；

通过虚拟集群主控制器调用虚拟集群实体和集群版本实体，根据虚拟集群实体包含的第一配置文件中的集群信息，查找与集群信息匹配的集群版本实体；

其中，集群版本实体包含的所述第二配置文件中的功能控制组件对应的配置和版本及至少一个工作组件对应的配置和版本，是根据虚拟集群构建指令中携带的组件的配置和版本确定的。

在一种可能的实现方式中，第一构建单元1601具体用于：

通过虚拟集群主控制器，根据集群版本实体包含的第二配置文件，在至少一个物理机上构建功能控制组件。

在一种可能的实现方式中，第二构建单元1602具体用于：

通过虚拟集群主控制器，根据集群版本实体包含的第二配置文件，在至少一个其他物理机上构建至少一个工作组件。

在一种可能的实现方式中，第一构建单元1601具体用于：

基于集群版本实体包含的第二配置文件，在至少一个物理机上构建用于管理和构建功能控制组件的第一控制器；

通过第一控制器，构建功能控制组件。

在一种可能的实现方式中，第二构建单元1602具体用于：

基于集群版本实体包含的第二配置文件，在至少一个其他物理机上构建用于管理和构建工作组件的第二控制器；

通过第二控制器，构建至少一个工作组件。

在一种可能的实现方式中，功能控制组件包括应用程序编程接口服务(Application Programming Interface Server，API Server)组件，第一构建单元701根据集群版本实体包含的第二配置文件，在至少一个物理机上构建API Server组件，还用于：

根据集群版本实体包含的第二配置文件，构建设置主机网络(Host Network)的API Server组件；

其中，API Server组件以API Server组件所在的物理机的网络协议(InternetProtocol，IP)进行服务配置。

在一种可能的实现方式中，功能控制组件包括调度(Volcano)组件，第一构建单元1601根据集群版本实体包含的第二配置文件，在至少一个物理机上构建Volcano组件之后，还用于：

构建Volcano组件中的调度器(Scheduler)对应的服务(Service)，以使监控工具通过Service暴露的接口监控Volcano组件的性能指标。

在一种可能的实现方式中，第一构建单元1601通过预先部署在物理机集群上的虚拟集群主控制器，在物理机集群中至少一个物理机上构建功能控制组件之前，还用于：

通过虚拟集群主控制器，构建用于存储功能控制组件和工作组件的租户命名空间(Namespace)；以及

通过虚拟集群主控制器，构建用于功能控制组件和工作组件进行相互认证和通信使用的公开密钥基础设施(Public Key Infrastructure，PKI)。

在一种可能的实现方式中，虚拟集群工作节点用于实现中央处理器(CentralProcessing Unit，CPU)功能、图形处理器(Graphics Processing Unit,GPU)功能、存储(Memory)功能的之一或组合。

在一种可能的实现方式中，虚拟集群工作节点用于实现GPU功能时，通过虚拟集群工作节点，运行Hollow-Kubelet，构建Kubelet.sock；以及

通过虚拟集群工作节点，运行模拟设备插件(mock-device-plugin)，通过mock-device-plugin监听Kubelet.sock，以使mock-device-plugin与Hollow-Kubelet通信并注册GPU资源。

在一种可能的实现方式中，若mock-device-plugin未监听到Kubelet.sock，则控制mock-device-plugin进入休眠后重启。

在一种可能的实现方式中，第一构建单元1601通过预先部署在至少一个物理机上的虚拟集群主控制器，在至少一个物理机上构建功能控制组件之前，还用于：

按照物理机集群中部署的用于限制虚拟集群主控制器操作资源的管理权限，运行虚拟集群主控制器。

为了描述的方便，以上各部分按照功能划分为各单元(或模块)分别描述。当然，在实施本申请时可以把各单元(或模块)的功能在同一个或多个软件或硬件中实现。

在介绍了本申请示例性实施方式的构建虚拟集群的方法及装置后，接下来介绍本申请的另一示例性实施方式的构建虚拟集群的计算设备。

所属技术领域的技术人员能够理解，本申请的各个方面可以实现为系统、方法或程序产品。因此，本申请的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

在一种可能的实现方式中，本申请实施例提供的构建虚拟集群计算设备可以至少包括处理器和存储器。其中，存储器存储有程序代码，当程序代码被处理器执行时，使得处理器执行本申请中各种示例性实施方式的构建虚拟集群方法中的任一步骤。

下面参照图17来描述根据本申请的这种实施方式的构建虚拟集群计算设备1700。如图17的构建虚拟集群计算设备1700仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图17所示，计算设备1700的组件可以包括但不限于：上述至少一个处理器1701、上述至少一个存储器1702、连接不同系统组件(包括存储器1702和处理器1701)的总线1703。

总线1703表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、外围总线、处理器或者使用多种总线结构中的任意总线结构的局域总线。

存储器1702可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)17021和/或高速缓存存储器17022，还可以进一步包括只读存储器(ROM)17023。

存储器1702还可以包括具有一组(至少一个)程序模块17024的程序/实用工具17025，这样的程序模块17024包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

计算设备1700也可以与一个或多个外部设备1704(例如键盘、指向设备等)通信，还可与一个或者多个使得用户能与计算设备1700交互的设备通信，和/或与使得该计算设备1700能与一个或多个其它计算装置进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口1705进行。并且，计算设备1700还可以通过网络适配器1706与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图17所示，网络适配器1706通过总线1703与用于计算设备1700的其它模块通信。应当理解，尽管图17中未示出，可以结合计算设备1700使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

在一些可能的实施方式中，本申请提供的构建虚拟集群的方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，通过程序指令相关的硬件来完成本说明书上述描述的根据本申请各种示例性实施方式的构建虚拟集群方法中的步骤。

前述的程序可以存储于一计算机可读存储介质中，该程序在执行时，执行包括上述构建虚拟集群方法中的步骤；

而前述的可读存储介质的包括(非穷举的列表)：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(Random Access Memory，RAM)、只读存储器(Read-OnlyMemory，ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (15)

1.一种构建虚拟集群的方法，其特征在于，该方法包括：

通过预先部署在物理机集群上的虚拟集群主控制器，在所述物理机集群中至少一个物理机上构建功能控制组件，并基于所述功能控制组件，对虚拟集群主控制节点进行仿真；以及

通过所述虚拟集群主控制器，在所述物理机集群中至少一个其他物理机上构建至少一个工作组件，并基于所述至少一个工作组件，对虚拟集群工作节点进行仿真，其中，一个工作组件对应一个虚拟集群工作节点。

2.如权利要求1所述的方法，其特征在于，所述通过预先部署在物理机集群上的虚拟集群主控制器，在所述物理机集群中至少一个物理机上构建功能控制组件之前，还包括：

通过所述虚拟集群主控制器监控到虚拟集群构建指令时，根据所述物理机集群中预先部署的用于生成虚拟集群实体和集群版本实体的规范信息，构建相应的虚拟集群实体和集群版本实体，其中，所述虚拟集群实体包含用于配置所述虚拟集群对应的集群信息的第一配置文件，所述集群版本实体包含用于配置所述功能控制组件配置和版本及所述至少一个工作组件配置和版本的第二配置文件；

通过所述虚拟集群主控制器调用所述虚拟集群实体和所述集群版本实体，根据所述虚拟集群实体包含的所述第一配置文件中的集群信息，查找与所述集群信息匹配的集群版本实体；

其中，所述集群版本实体包含的所述第二配置文件中的功能控制组件配置和版本及至少一个工作组件配置和版本，是根据所述虚拟集群构建指令中携带的组件的配置和版本确定的。

3.如权利要求2所述的方法，其特征在于，所述在所述至少一个物理机上构建功能控制组件，包括：

通过所述虚拟集群主控制器，根据所述集群版本实体包含的所述第二配置文件，在所述至少一个物理机上构建功能控制组件；

所述在所述至少一个其他物理机上构建至少一个工作组件，包括：

通过所述虚拟集群主控制器，根据所述集群版本实体包含的所述第二配置文件，在所述至少一个其他物理机上构建至少一个工作组件。

4.如权利要求3所述的方法，其特征在于，所述根据所述集群版本实体包含的所述第二配置文件，在所述至少一个物理机上构建功能控制组件，包括：

基于所述集群版本实体包含的所述第二配置文件，在所述至少一个物理机上构建用于管理和构建所述功能控制组件的第一控制器；

通过所述第一控制器，构建所述功能控制组件；

所述根据所述集群版本实体包含的所述第二配置文件，在所述至少一个其他物理机上构建至少一个工作组件，包括：

基于所述集群版本实体包含的所述第二配置文件，在所述至少一个其他物理机上构建用于管理和构建所述工作组件的第二控制器；

通过所述第二控制器，构建所述至少一个工作组件。

5.如权利要求3所述的方法，其特征在于，所述功能控制组件包括应用程序编程接口服务API Server组件，所述根据所述集群版本实体包含的所述第二配置文件，在所述至少一个物理机上构建所述API Server组件，还包括：

根据所述集群版本实体包含的所述第二配置文件，构建设置主机网络Host Network的API Server组件；

其中，所述API Server组件以所述API Server组件所在的物理机的网络协议IP进行服务配置。

6.如权利要求3所述的方法，其特征在于，所述功能控制组件包括调度Volcano组件，所述根据所述集群版本实体包含的第二配置文件，在所述至少一个物理机上构建所述Volcano组件之后，还包括：

构建所述Volcano组件中的调度器Scheduler对应的服务Service，以使监控工具通过所述Service暴露的接口监控所述Volcano组件的性能指标。

7.如权利要求1所述的方法，其特征在于，该方法还包括：

通过所述虚拟集群主控制器，构建用于存储所述功能控制组件和所述工作组件的租户命名空间；以及

通过所述虚拟集群主控制器，构建用于所述功能控制组件和所述工作组件进行相互认证和通信使用的公开密钥基础设施PKI。

8.如权利要求1所述的方法，其特征在于，所述虚拟集群工作节点用于实现中央处理器CPU功能、图形处理器GPU功能、存储Memory功能的之一或组合。

9.如权利要求8所述的方法，其特征在于，所述虚拟集群工作节点用于实现GPU功能时，通过所述虚拟集群工作节点，运行Hollow-Kubelet，构建Kubelet.sock；以及

通过所述虚拟集群工作节点，运行模拟设备插件mock-device-plugin，通过所述mock-device-plugin监听所述Kubelet.sock，以使所述mock-device-plugin与所述Hollow-Kubelet通信并注册GPU资源。

10.如权利要求9所述的方法，其特征在于，所述通过所述mock-device-plugin监听所述Kubelet.sock，包括：

若未监听到所述Kubelet.sock，则控制所述mock-device-plugin进入休眠后重启。

11.如权利要求1所述的方法，其特征在于，所述通过预先部署在至少一个物理机上的虚拟集群主控制器，在所述至少一个物理机上构建功能控制组件之前，还包括：

按照所述物理机集群中部署的用于限制所述虚拟集群主控制器操作资源的管理权限，运行所述虚拟集群主控制器。

12.一种构建虚拟集群的装置，其特征在于，该装置包括：

第一构建单元，用于通过预先部署在物理机集群上的虚拟集群主控制器，在所述物理机集群中至少一个物理机上构建功能控制组件，并基于所述功能控制组件，对虚拟集群主控制节点进行仿真；以及

第二构建单元，用于通过所述虚拟集群主控制器，在所述物理机集群中至少一个其他物理机上构建至少一个工作组件，并基于所述至少一个工作组件，对虚拟集群工作节点进行仿真，其中，一个工作组件对应一个虚拟集群工作节点。

13.如权利要求12所述的装置，其特征在于，第一构建指令通过预先部署在物理机集群上的虚拟集群主控制器，在所述物理机集群中至少一个物理机上构建功能控制组件之前，还用于：

通过所述虚拟集群主控制器监控到虚拟集群构建指令时，根据所述物理机集群中预先部署的用于生成虚拟集群实体和集群版本实体的规范信息，构建相应的虚拟集群实体和集群版本实体，其中，所述虚拟集群实体包含用于配置所述虚拟集群对应的集群信息的第一配置文件，所述集群版本实体包含用于配置所述功能控制组件配置和版本及所述至少一个工作组件配置和版本的第二配置文件；

通过所述虚拟集群主控制器调用所述虚拟集群实体和所述集群版本实体，根据所述虚拟集群实体包含的所述第一配置文件中的集群信息，查找与所述集群信息匹配的集群版本实体；

其中，所述集群版本实体包含的所述第二配置文件中的功能控制组件配置和版本及至少一个工作组件配置和版本，是根据所述虚拟集群构建指令中携带的组件的配置和版本确定的。

14.一种构建虚拟集群的设备，其特征在于，该设备包括：存储器和处理器，其中，存储器，用于存储计算机指令；处理器，用于执行计算机指令以实现如权利要求1-11任一所述的方法。

15.一种计算机可读存储介质，其特征在于，计算机可读存储介质存储有计算机指令，计算机指令被处理器执行时实现如权利要求1-11任一所述的方法。

Images