一种应用调度方法、平台及存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种应用调度方法、平台及存储介质。

背景技术

随着通信网络技术的快速发展，边缘计算(Mobile Edge Computing，MEC)技术也日渐成熟，得到广泛应用，例如无人驾驶和智慧工厂等。目前，边缘集群有众多实现方案和开源社区，比如管理容器集群的平台(Kubernetes，k8s)社区的酷比边缘(kubeedge)、k3s、openyurt、云计算管理平台(openstack)社区的边缘基础设施软件平台(Starlingx)等。

但是，由于边缘集群的存储方案实现机制各不相同，支持的应用类型和格式也多种多样，因此上述方案在实现边缘集群存储管理时，只能管理单一应用类型的边缘集群，即导致目前的边缘集群的存储方案的使用效率较低。

申请内容

为解决上述技术问题，本申请实施例期望提供一种应用调度方法、平台及存储介质，解决了目前实现边缘集群存储管理时，只能管理单一应用类型的边缘集群的问题，实现了一种边缘集群存储管理时，可以管理多种应用类型的边缘集群方法，有效提高了边缘集群存储管理对异构应用的调度效率。

本申请的技术方案是这样实现的：

第一方面，一种应用调度方法，所述方法包括：

确定具有第一标识信息的至少一个第一虚拟节点；其中，所述第一虚拟节点与应用调度平台管理的边缘集群具有对应关系；

确定具有第二标识信息的第一待调度容器的资源需求信息；其中，所述第一待调度容器与待创建虚拟应用实例对应；

基于所述资源需求信息，从所述至少一个第一虚拟节点中确定目标虚拟节点；

调度所述第一待调度容器至所述目标虚拟节点；

通过所述目标虚拟节点基于所述第一待调度容器的资源需求信息，创建所述待创建虚拟应用实例，以使所述待创建虚拟应用实例运行于所述目标虚拟节点对应的边缘集群。

可选的，所述确定具有第一标识信息的至少一个第一虚拟节点，包括：

确定所述应用调度平台管理的至少一个边缘集群；

确定所述至少一个边缘集群的资源信息，得到至少一个目标资源信息；

基于每一所述目标资源信息，生成所述至少一个边缘集群对应的至少一个第二虚拟节点；

采用所述第一标识信息对所述至少一个第二虚拟节点进行标识，得到所述至少一个第一虚拟节点。

可选的，所述基于每一所述目标资源信息，生成所述至少一个边缘集群对应的至少一个第二虚拟节点，包括：

基于每一所述目标资源信息，确定每一所述目标资源信息对应的资源类别；

基于每一所述目标资源信息对应的每一所述资源类别，生成对应的虚拟节点，得到所述至少一个第二虚拟节点。

可选的，所述确定具有第二标识信息的第一待调度容器的资源需求信息之前，所述方法还包括：

确定所述待创建虚拟应用实例的配置内容；

基于所述配置内容，创建目标虚拟应用；

基于所述目标虚拟应用，创建第一参考调度容器；

采用所述第二标识信息对所述第一参考调度容器进行标识，得到所述第一待调度容器。

可选的，所述基于所述资源需求信息，从所述至少一个第一虚拟节点中确定目标虚拟节点，包括：

基于所述资源需求信息和所述至少一个第一虚拟节点的服务目录信息，从所述至少一个第一虚拟节点中筛选得到至少一个第三虚拟节点；

基于所述至少一个第三虚拟节点的服务信息，对每一所述第三虚拟节点进行评估，得到至少一个评估值；

基于所述至少一个评估值，从所述至少一个第三虚拟节点中确定得到所述目标虚拟节点。

可选的，所述通过所述目标虚拟节点基于所述第一待调度容器的资源需求信息，创建所述待创建虚拟应用实例之后，所述方法还包括：

监测所述第一待调度容器的状态；

若所述第一待调度容器的状态为第一状态，更新所述目标虚拟应用的状态为所述第一状态；其中，所述第一待调度容器为所述第一状态表明所述待创建虚拟应用实例在所述目标虚拟节点对应的边缘集群上的运行状态为目标状态；

若所述第一待调度容器的状态为第二状态，基于所述目标虚拟应用，创建第二参考调度容器；

采用所述第二标识信息对所述第二参考调度容器进行标识，得到第二待调度容器；

调度所述第二待调度容器至所述目标虚拟节点；

通过所述目标虚拟节点基于所述第二待调度容器的资源需求信息，创建所述待创建虚拟应用实例。

可选的，所述若所述第一待调度容器的状态为第一状态，更新所述目标虚拟应用的状态为所述第一状态之后，所述方法还包括：

若检测到所述目标虚拟应用的状态为所述第一状态，删除所述目标虚拟应用；

若监测到所述目标虚拟应用已删除，删除所述第一待调度容器。

可选的，所述若所述第一待调度容器的状态为第一状态，更新所述目标虚拟应用的状态为所述第一状态之后，所述方法还包括：

采用目标通信方式对所述目标虚拟节点进行管理控制，以实现对所述待创建虚拟应用实例进行运维管理。

第二方面，一种应用调度平台，所述应用调度平台至少包括：边缘系统和云端系统；其中：

所述边缘系统，用于管理所述应用调度平台管理的至少一个边缘集群；

所述云端系统，用于基于所述边缘系统管理的至少一个边缘集群，实现如上述任一项所述的应用调度方法的步骤。

第三方面，一种存储介质，所述存储介质上存储有应用调度程序，所述应用调度程序被处理器执行时实现如上述任一项所述的应用调度方法的步骤。

本申请实施例提供了一种应用调度方法、平台及存储介质，通过确定具有第一标识信息的至少一个第一虚拟节点，并确定具有第二标识信息的第一待调度容器的资源需求信息，然后基于资源需求信息，从至少一个第一虚拟节点中确定目标虚拟节点，并调度第一待调度容器至目标虚拟节点，最后通过目标虚拟节点基于第一待调度容器的资源需求信息，创建待创建虚拟应用实例，以使待创建虚拟应用实例运行于目标虚拟节点对应的边缘集群。这样，基于具有第二标识信息的第一待调度容器的资源需求信息，从至少一个具有第一标识信息的第一虚拟节点中确定目标虚拟节点后，调度第一待调度容器至目标虚拟节点，从而使目标虚拟节点基于第一待调度容器的资源需求信息创建待创建虚拟应用实例，解决了目前实现边缘集群存储管理时，只能管理单一应用类型的边缘集群的问题，实现了一种边缘集群存储管理时，可以管理多种应用类型的边缘集群方法，有效提高了边缘集群存储管理对异构应用的调度效率。

附图说明

图1为本申请实施例提供的一种应用调度方法的流程示意图；

图2为本申请实施例提供的另一种应用调度方法的流程示意图；

图3为本申请实施例提供的又一种应用调度方法的流程示意图；

图4为本申请另一实施例提供的一种应用调度方法的流程示意图；

图5为本申请另一实施例提供的另一种应用调度方法的流程示意图；

图6为本申请另一实施例提供的又一种应用调度方法的流程示意图；

图7为本申请实施例提供的一种应用调度平台的结构示意图；

图8为本申请实施例提供的一种云端系统的结构示意图；

图9为本申请实施例提供的一种边缘系统与边缘集群的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

本申请的实施例提供一种应用调度方法，参照图1所示，方法应用于应用调平台，该方法包括以下步骤：

步骤101、确定具有第一标识信息的至少一个第一虚拟节点。

其中，第一虚拟节点与应用调度平台管理的边缘集群具有对应关系。

在本申请实施例中，应用调度平台可以是用于对边缘集群进行管理控制的MEC平台，应用调度平台可以同时管理控制至少一种应用类型和格式的边缘集群。第一标识信息的作用于是将至少一个第一虚拟节点与构成应用调度平台的虚拟节点进行区分的信息，第一虚拟节点与应用调度平台的物理节点不同。至少一个第一虚拟节点是基于应用调度平台管理的边缘集群创建得到的，即应用调度平台基于应用调度平台管理的每一边缘集群创建对应的至少一个第一虚拟节点。每一边缘集群对应的至少一个第一虚拟节点的数量由每一边缘集群包括的类型来确定。

步骤102、确定具有第二标识信息的第一待调度容器的资源需求信息。

其中，第一待调度容器与待创建虚拟应用实例对应。

在本申请实施例中，第二标识信息的作用是将第一待调度容器与应用调度平台的原始容器进行区分的信息。容器可以是Pod。第一待调度容器的资源需求信息是应用调度平台对边缘集群预先获取得到的，第一待调度容器的资源需求信息至少包括服务等级协议(Service-Level Agreement，SLA)需求、第三方服务需求等。

步骤103、基于资源需求信息，从至少一个第一虚拟节点中确定目标虚拟节点。

在本申请实施例中，目标虚拟节点是至少一个第一虚拟节点中的一个能够满足第一待调度容器的资源需求信息的最优虚拟节点。也就是说，目标虚拟节点是能够满足第一待调度容器的资源需求信息。

步骤104、调度第一待调度容器至目标虚拟节点。

在本申请实施例中，将第一待调度容器调度至目标虚拟节点的意思是建立第一塞调度容器与目标虚拟节点之间的对应关系，以使目标虚拟节点与第一待调度容器绑定，使第一待调度容器运行于目标虚拟节点。

步骤105、通过目标虚拟节点基于第一待调度容器的资源需求信息，创建待创建虚拟应用实例。

其中，通过目标虚拟节点基于第一待调度容器的资源需求信息，创建待创建虚拟应用实例，以使待创建虚拟应用实例运行于目标虚拟节点对应的边缘集群。

在本申请实施例中，在第一待调度容器调度至目标虚拟节点后，目标虚拟节点根据第一待调度容器的资源需求信息，创建与第一待调度容器对应的待创建虚拟应用实例，这样，待创建虚拟应用实例在创建成功后，会运行于目标虚拟节点对应的边缘集群中。这样，通过创建虚拟节点来代表应用调度平台中的边缘集群，使应用调度平台对虚拟节点的管理来实现对对应的边缘集群的管理控制，而虚拟节点不受边缘集群的类型限制，因此，应用调度平台可以管理多种不同类型的边缘集群，有效提高了应用调度平台对边缘集群的管理效率。

本申请实施例提供的一种应用调度方法，通过确定具有第一标识信息的至少一个第一虚拟节点，并确定具有第二标识信息的第一待调度容器的资源需求信息，然后基于资源需求信息，从至少一个第一虚拟节点中确定目标虚拟节点，并调度第一待调度容器至目标虚拟节点，最后通过目标虚拟节点基于第一待调度容器的资源需求信息，创建待创建虚拟应用实例，以使待创建虚拟应用实例运行于目标虚拟节点对应的边缘集群。这样，基于具有第二标识信息的第一待调度容器的资源需求信息，从至少一个具有第一标识信息的第一虚拟节点中确定目标虚拟节点后，调度第一待调度容器至目标虚拟节点，从而使目标虚拟节点基于第一待调度容器的资源需求信息创建待创建虚拟应用实例，解决了目前实现边缘集群存储管理时，只能管理单一应用类型的边缘集群的问题，实现了一种边缘集群存储管理时，可以管理多种应用类型的边缘集群方法，有效提高了边缘集群存储管理对异构应用的调度效率。

基于前述实施例，本申请的实施例提供一种应用调度方法，参照图2所示，方法应用于应用调度平台，该方法包括以下步骤：

步骤201、确定应用调度平台管理的至少一个边缘集群。

在本申请实施例中，应用调度平台统计自身管理的至少一个边缘集群。

步骤202、确定至少一个边缘集群的资源信息，得到至少一个目标资源信息。

在本申请实施例中，应用调度平台获取至少一个边缘集群中每一边缘集群的资源信息，得到至少一个目标资源信息，即有几个边缘集群，会统计得到几个目标资源信息，其中目标资源信息包括边缘集群的多种类型的资源信息。示例性的，假设应用调度平台包括边缘集群1、边缘集群2和边缘计算3这3个边缘集群时，确定边缘集群1对应的目标资源信息1、边缘集群2对应的目标资源信息2和边缘集群3对应的目标资源信息3。

步骤203、基于每一目标资源信息，生成至少一个边缘集群对应的至少一个第二虚拟节点。

在本申请实施例中，基于至少一个目标资源信息中的每一目标资源信息，生成每一边缘集群对应的至少一个第二虚拟节点，即每一目标资源信息，对应至少一个第二虚拟节点。但在一些特定应用场景中，在每一边缘集群提供包括两种类型的应用时，需针对每一类型的应用生成一个第二虚拟节点。

示例性的，若边缘集群1只提供云应用的编排系统Cloudify的部署和管理(blueprint)应用时，生成一个与边缘集群1对应的第二虚拟节点1；若边缘集群2也只提供云应用的编排系统Cloudify的部署和管理(blueprint)应用时，生成一个与边缘集群2对应的第二虚拟节点2；若边缘集群3提供云应用的编排系统Cloudify的部署和管理(blueprint)应用和虚拟机(Virtual Machine，VM)应用时，需生成两个与边缘集群3对应的第二虚拟节点3和第二虚拟节点4，其中，第二虚拟节点3对应的边缘集群3提供的blueprint应用，第二虚拟节点4对应边缘集群3提供的VM应用。

步骤204、采用第一标识信息对至少一个第二虚拟节点进行标识，得到至少一个第一虚拟节点。

在本申请实施例中，第一标识信息用于将至少一个第二虚拟节点与应用调度平台中本来就存在的虚拟节点进行区分，即第一标识信息是用于唯一标识与应用调度平台管理的边缘集群的信息。将至少一个第二虚拟节点中的每一第二虚拟节点采用第一标识信息进行标识，从而得到至少一个第一虚拟节点，即对几个第二虚拟节点采用第一标识信息进行标识，即可得到几个第一虚拟节点。

示例性的，第一标识信息可以记为label，这样，只要识别到label时，即可确定对应的虚拟节点是应用调度平台管理的边缘集群对应的虚拟节点。

步骤205、确定具有第二标识信息的第一待调度容器的资源需求信息。

其中，第一待调度容器与待创建虚拟应用实例对应。

在本申请实施例中，第一待调度容器是根据需要创建的待创建虚拟应用实例进行创建得到的Pod，第一待调度容器的资源需求信息是对应的边缘集群的资源需求信息。第二标识信息是用于唯一标识待创建虚拟应用实例对应的容器的信息，例如第二标识信息可以是Nodeselector。

步骤206、基于资源需求信息，从至少一个第一虚拟节点中确定目标虚拟节点。

在本申请实施例中，基于资源需求信息，对至少一个第一虚拟节点对应的边缘集群进行资源过滤，然后对过滤后基本符合要求的至少一个第一虚拟节点再次进行最优匹配分析，从而确定得到目标虚拟节点。目标虚拟节点通常为一个虚拟节点。资源需求信息包括显卡(Graphics Processing Unit，GPU)、现场可编程逻辑门阵列(Field ProgrammableGate Array，FPGA)和虚拟网卡等本地资源

步骤207、调度第一待调度容器至目标虚拟节点。

步骤208、通过目标虚拟节点基于第一待调度容器的资源需求信息，创建待创建虚拟应用实例。

其中，通过目标虚拟节点基于第一待调度容器的资源需求信息，创建待创建虚拟应用实例，以使待创建虚拟应用实例运行于目标虚拟节点对应的边缘集群。

在本申请实施例中，应用调度平台通过目标虚拟节点基于第一待调度容器的资源需求信息，创建待创建虚拟应用实例，以便有效利用边缘集群的资源提供待创建虚拟应用实例对应的服务。

基于前述实施例，在本申请其他实施例中，步骤203可以由步骤203a～203b来实现：

步骤203a、基于每一目标资源信息，确定每一目标资源信息对应的资源类别。

在本申请实施例中，每一目标资源信息对应的资源类别即每一目标资源信息对应的边缘集群的类别。在一些应用场景中，每一目标资源信息对应的资源类别至少包括一种类别。

步骤203b、基于每一目标资源信息对应的每一资源类别，生成对应的虚拟节点，得到至少一个第二虚拟节点。

在本申请实施例中，基于每一目标资源信息对应的每一资源类别，生成对应的一个虚拟节点，这样，每一目标资源信息对应多个资源类别时，会针对每一目标资源信息生成多个虚拟节点。这样，应用调度平台生成的第二虚拟节点的数量至少与确定的目标资源信息的数量相同。需说明的是，假设统计到的两个目标资源信息的类型相同，且两个目标资源信息也基本相同时，仍需分别基于这两个目标资源信息创建两个第二虚拟节点。

基于前述实施例，在本申请其他实施例中，参照图3所示，应用调度平台执行步骤205之前，还用于执行步骤209～212：

步骤209、确定待创建虚拟应用实例的配置内容。

在本申请实施例中，待创建虚拟应用实例的配置内容可以是用户进行设置得到的，在一些应用场景中，也可以是在用户希望创建待创建虚拟应用实例时，针对待创建虚拟应用实例的默认配置内容。配置内容即可以是针对待创建虚拟应用实例的配置参数。

步骤210、基于配置内容，创建目标虚拟应用。

在本申请实施例中，应用调度平台根据配置内容，按照预先封装好的异构应用的应用模板进行配置调整，创建得到目标虚拟应用。

步骤211、基于目标虚拟应用，创建第一参考调度容器。

在本申请实施例中，示例性的，基于创建得到的目标虚拟应用，创建一个k8s的节点Pod，得到第一参考调度容器。

步骤212、采用第二标识信息对第一参考调度容器进行标识，得到第一待调度容器。

在本申请实施例中，为了将第一参考调度容器与k8s平台中的Pod节点进行区分，需采用针对目标虚拟应用创建的Pod节点进行区分，因此，采用唯一标识信息第二标识信息对第一参考调度容器进行标识，以便后续对第一参考调度容器进行快速识别，从而得到第一待调度容器。

基于前述实施例，在本申请其他实施例中，步骤206可以由步骤206a～206c来实现：

步骤206a、基于资源需求信息和至少一个第一虚拟节点的服务目录信息，从至少一个第一虚拟节点中筛选得到至少一个第三虚拟节点。

在本申请实施例中，至少一个第一虚拟节点的服务目录信息是对应的每一边缘集群提供的。从至少一个第一虚拟节点的服务目录信息中确定与资源需求信息匹配的至少一个服务目录信息，从而可以确定匹配的至少一个服务目录信息对应的第一虚拟节点为至少一个第三虚拟节点。其中，可以通过预先编写好的k8s预选调度插件来实现筛选得到至少一个第三虚拟节点的过程。

示例性的，当前包括第一虚拟节点1的服务目录信息1、第二虚拟节点2的服务目录信息2和第三虚拟节点3的服务目录信息3时，假设其中服务目录信息2和服务目标信息3与资源需求信息匹配，因此，可以确定至少一个第三虚拟节点为服务目录信息2对应的第二虚拟节点2和服务目录信息3对应的第三虚拟节点3。

步骤206b、基于至少一个第三虚拟节点的服务信息，对每一第三虚拟节点进行评估，得到至少一个评估值。

在本申请实施例中，至少一个第三虚拟节点的服务信息为每一第三虚拟节点对应的边缘集群可提供的计算资源，这样，对每一第三虚拟节点的服务信息对每一第三虚拟节点进行评估，得到每一第三虚拟节点的评估值，进而得到全部第三虚拟节点的评估值。

步骤206c、基于至少一个评估值，从至少一个第三虚拟节点中确定得到目标虚拟节点。

在本申请实施例中，在评估值越大表明对应的边缘集群能为第一待调度容器提供最优的计算资源时，确定至少一个评估值中最大评估值对应的第三虚拟节点为目标虚拟节点。或者，在评估值越小表明对应的边缘集群能为第一待调度容器提供最优的计算资源时，确定至少一个评估值中最小评估值对应的第三虚拟节点为目标虚拟节点。其中，步骤206b和步骤206c可以通过预先编写好的k8s优选调度插件来实现。

若基于至少一个评估值确定得到最大评估值或最小评估值对应至少两个第三虚拟节点时，可以从确定的至少两个第三虚拟节点随机确定一个第三虚拟节点为目标虚拟节点，也可以进一步优先考虑其服务信息中的某一资源例如时针对待创建虚拟应用实例所消耗最多的资源来进行选择，例如根据确定的至少两个第三虚拟节点对应的中央处理器(Central Processing Unit，CPU)的剩余资源的多少来确定，如确定CPU剩余资源最多的第三虚拟节点为目标虚拟节点。

基于前述实施例，在本申请其他实施例中，参照图4所示，应用调度平台执行步骤208之后，还用于执行步骤213～218：

步骤213、监测第一待调度容器的状态。

在本申请实施例中，第一待调度容器的状态包括成功状态或失败状态；成功状态指的是第一待调度容器与目标虚拟节点之间调度成功或连接成功的状态，失败状态指的是第一待调度容器与目标虚拟节点之间调度失败或连接失败的状态。

步骤214、若第一待调度容器的状态为第一状态，更新目标虚拟应用的状态为第一状态。

其中，第一待调度容器为第一状态表明待创建虚拟应用实例在目标虚拟节点对应的边缘集群上的运行状态为目标状态。

在本申请实施例中，第一状态指的是第一待调度容器的成功状态。在确定第一待调度容器为第一状态的情况下，对目标虚拟应用的状态也进行更新，并更新为第一状态，即成功状态。

步骤215、若第一待调度容器的状态为第二状态，基于目标虚拟应用，创建第二参考调度容器。

在本申请实施例中，第二状态用于指示第一待调度容器的失败状态。在确定第一待调度容器的状态为失败状态时，重新基于目标虚拟应用，创建第二参考调度容器。

步骤216、采用第二标识信息对第二参考调度容器进行标识，得到第二待调度容器。

步骤217、调度第二待调度容器至目标虚拟节点。

步骤218、通过目标虚拟节点基于第二待调度容器的资源需求信息，创建待创建虚拟应用实例。

在本申请实施例中，在第一待调度容器的状态为第二状态时，将第一待调度容器抛弃，重新创建新的与目标虚拟应用对应的第二待调度容器，并重新进行调度，以便实现对目标虚拟应用的边缘集群的有效管理和应用。

基于前述实施例，在本申请其他实施例中，参照图5所示，应用调度平台执行步骤214之后，还用于执行步骤219～220：

步骤219、若检测到目标虚拟应用的状态为第一状态，删除目标虚拟应用。

步骤220、若监测到目标虚拟应用已删除，删除第一待调度容器。

在本申请实施例中，在检测到目标虚拟应用的状态为第一状态时，表明待创建应用实例已经成功运行于目标虚拟应用对应的边缘集群中，为了降低应用调度平台的资源消耗，因此可以将目标虚拟应用进行删除，并在目标虚拟应用已删除的状态下，进一步删除第一待调度容器，提高应用调度平台的资源的利用率。

基于前述实施例，在本申请其他实施例中，参照图6所示，应用调度平台执行步骤214之后，还用于执行步骤221：

步骤221、采用目标通信方式对目标虚拟节点进行管理控制，以实现对待创建虚拟应用实例进行运维管理。

在本申请实施例中，目标通信方式可以异步通信方式，具体可以是队列形式的异步通信方式。运维管理包括对已创建的待创建虚拟应用实例的版本进行管理、扩缩容或删除实例等。

其中，图4、图5和图6中的不同步骤可根据实际情况选择并列或递进执行。

基于前述实施例，本申请实施例提供一种应用调度平台的结构示意图，参照图7所示，应用调度平台3包括云端系统31和边缘系统32。参照图8所示，云端系统31包括5个组件：云端镜像管理服务311、云端镜像仓库312、云端虚拟应用处理器313、虚拟提供程序314和云端应用生命周期管理服务315；其中：

云端镜像管理服务311，用于对外提供表现层状态转化(Representational StateTransfer，RESTful)应用数据接口(Application Programming Interface，API)，并支持上传、删除和查看虚拟机镜像、容器镜像和应用包的功能。支持显示虚拟机镜像、容器镜像和应用包的同步状态。

云端镜像仓库(Harbor)312，用于负责统一存储云端虚拟机镜像、容器镜像和应用包，可直接将虚拟机镜像和应用包以及相关的元数据包装为容器镜像存储和同步。

云端虚拟应用处理器(Operator)313，用于将不同的第三方资源虚拟应用，转换成例如kubernetes能调度的Pod。第三方虚拟应用可以支持多种虚拟应用子类型，比Cloudify的Blueprint、单独的VM和单独的容器(Container)。第三方虚拟应用里面详细记录其对应的资源需求，例如SLA需求和/或第三方服务需求。Operator监听这些第三方虚拟应用，即在新建第三方虚拟应用时，Operator会创建一个k8s的Pod，Pod的资源需求信息中汇总第三方虚拟应用的总需求，其中，SLA需求和/或第三方服务需求可以写在Pod的注解(Annotation)里，应用包等其它信息可以放到Pod所引用的配置图(Configmap)里。

虚拟提供程序(Virtual Kubelet Provider)314，用于将所管理的每一边缘集群虚拟成kubernetes的节点，这样，方便将应用调度给异构的边缘集群。具体原因是：有些边缘集群为虚拟机和容器提供了不同的物理基础设施，所以需要为每个这样的边缘集群分别创建用于运行虚拟机的虚拟kubernetes节点和用于运行容器的虚拟kubernetes节点。虚拟提供程序还用于将远程边缘集群的GPU、虚拟网卡和存储器看作3种设备，分别创建对应的设备插件(device-plugin)。每一device-plugin用于采集对应的资源信息，即GPU对应的device-plugin用于采集边缘集群的GPU信息，虚拟网卡对应的device-plugin用于采集边缘集群的虚拟网卡信息，存储器对应的device-plugin用于采集边缘集群的存储资源信息。上述三种device-plugin采集到的信息通过虚拟提供程序传给云端虚拟应用处理器，以使云端虚拟应用处理器做调度决策。其中，可以将边缘集群的存储资源信息分为若干类型，比如文件存储，对象存储，块存储，快速存储，慢速存储等。每类存储对应一种设备，并将存储的容量转换作为设备的数量。

云端应用生命周期管理服务(Appmanager)315，用于基于存储于Harbor中的应用模板，负责创建虚拟应用。同时会将针对应用实例的删除，版本管理，扩缩容，SLA管理等运维管理信息经过消息队列转发给边缘系统中的边缘应用生命周期管理服务。

参照图9所示，边缘系统32包括的4个组件：镜像同步服务321、边缘Harbor 322、边缘应用生命周期管理服务323和调度程序适配器324；其中：

镜像同步服务321，用于监控边缘Harbor中虚拟机镜像、容器镜像和应用包的状态，将其同步到边缘集群4相应的管理器中。

边缘Harbor 322，用于负责统一存储边缘集群的虚拟机镜像，容器镜像和应用包。

边缘应用生命周期管理服务(Appmanager)323，用于直接对接边缘集群的应用执行器，负责应用实例的创建、删除，版本管理，扩缩容，SLA管理等功能。

调度程序适配器(Scheduler Adapter)324，用于负责收集边缘集群4的实时资源信息，将其同步给云端系统中的Virtual Kubelet Provider，并在接收到Virtual KubeletProvider的创建虚拟应用的请求后，将创建虚拟应用的请求转发给边缘Appmanager。

这样，基于图7～9所示的应用调度平台实现应用调度方法的流程的实现步骤可以如下所示：

步骤a11、前端页面调用边缘系统中的镜像管理服务的API，上传虚拟机镜像、容器镜像或应用包。

其中，前端页面为用户操作的界面，与应用调度平台无关。

步骤a12、云端Harbor接收镜像管理服务发送的虚拟机镜像、容器镜像或应用包，实现虚拟机镜像、容器镜像或应用包的同步，并存储虚拟机镜像、容器镜像或应用包。

步骤a13、前端页面调用云端Appmanager的应用部署API，以使云端Appmanager获得虚拟机镜像、容器镜像或应用包。

其中，虚拟机镜像、容器镜像或应用包即为前述用于创建虚拟应用实例的配置内容。

步骤a14、云端Appmanager创建第三方资源(VirtApp)，并监控VirtApp的状态。

其中，第三方资源即前述目标虚拟应用。

步骤a15、虚拟应用operator，依据VirtApp创建kubernetes Pod。示例性的，Pod还标识为nodeselector:virtualnode:vm(container)。

其中，依据VirtApp创建的kubernetes Pod即前述第一待调度容器。nodeselector为第二标识信息。

步骤a16、Virtual kubelet provider基于边缘系统中的Scheduler Adapter返回的边缘集群资源信息，构建出一个或两个kubernetes虚拟节点记为virtual-kubelet。

其中，边缘集群资源信息包括边缘集群的GPU，存储资源信息、虚拟网卡等可以作为创建的kubernetes虚拟节点的设备资源能力对外输出。同时为kubernetes虚拟节点添加第一标识信息，示例性的，添加第一标识信息后的kubernetes虚拟节点可以记为label:virtualnode:vm(container)NoScheduler。

其中，kubernetes虚拟节点即为前述目标虚拟节点。

步骤a17、云端虚拟应用处理器将创建的kubernetes Pod调度到筛选出的边缘集群对应的目标虚拟节点。

其中，目标虚拟节点是通过k8s预选调度插件，依据各边缘集群提供的服务目录信息和kubernetes Pod对第三方服务的需求即前述资源需求信息对边缘集群进行过滤，然后通过k8s优选调度插件对过滤得到的边缘集群的的SLA相关信息对边缘集群打分，并自动进行资源匹配，为Kubernetes Pod找到最优的边缘集群对应的目标虚拟节点。

步骤a18、目标虚拟节点根据Kubernetes Pod信息以及边缘Scheduler Adapter和边缘Appmanager创建应用实例；并更新Kubernetes Pod的状态。

其中，创建的应用实例即前述创建应用实例。

步骤a19、虚拟应用operator监控Kubernetes Pod的状态，如果发现KubernetesPod是失败(failed)状态，则重新创建Kubernetes Pod，重新调度，即跳到步骤a16。如果Kubernetes Pod是成功(succeed)状态，则更新VirtApp的状态为succeed状态。

其中，failed状态为前述第二状态，succeed状态为前述第一状态。

步骤a20、云端Appmanager发现VirtApp状态为succeed是，删除VirtApp。

步骤a21、虚拟应用Operator接收到已删除VirtApp事件的信息时，删除对应的Kubernetes Pod。

步骤a22、应用实例创建成功后，云端Appmanager通过消息队列与边缘Appmanager异步通信，执行包括版本管理、扩缩容和/或删除实例等运维操作，以通过边缘Appmanager对运行于边缘集群中的应用实例进行管理。

这样，可扩展性高，基于kubernetes调度器的扩展框架，支持对异构应用的调度的预选和优选步骤进行定制，比如支持基于最大网络延迟选择边缘集群，支持将边缘集群的可用存储/可用gpu等设备作为边缘集群的筛选条件等，使可扩展性较高；当选定的边缘集群由于资源碎片化，网络等问题无法创建应用时，能及时重新寻找一个新的边缘集群实现高可用性；并且基于一套调度框架和接口，调度多种类型的应用到各类边缘集群，使易用性强。

需要说明的是，本实施例中与其它实施例中相同步骤和相同内容的说明，可以参照其它实施例中的描述，此处不再赘述。

本申请实施例提供的一种应用调度方法，通过确定具有第一标识信息的至少一个第一虚拟节点，并确定具有第二标识信息的第一待调度容器的资源需求信息，然后基于资源需求信息，从至少一个第一虚拟节点中确定目标虚拟节点，并调度第一待调度容器至目标虚拟节点，最后通过目标虚拟节点基于第一待调度容器的资源需求信息，创建待创建虚拟应用实例，以使待创建虚拟应用实例运行于目标虚拟节点对应的边缘集群。这样，基于具有第二标识信息的第一待调度容器的资源需求信息，从至少一个具有第一标识信息的第一虚拟节点中确定目标虚拟节点后，调度第一待调度容器至目标虚拟节点，从而使目标虚拟节点基于第一待调度容器的资源需求信息创建待创建虚拟应用实例，解决了目前实现边缘集群存储管理时，只能管理单一应用类型的边缘集群的问题，实现了一种边缘集群存储管理时，可以管理多种应用类型的边缘集群方法，有效提高了边缘集群存储管理对异构应用的调度效率。

基于前述实施例，本申请的实施例提供一种应用调度平台，该应用调度平台可以应用于图1～6对应的实施例提供的应用调度方法中，参照图7所示，该应用调度平台3可以包括：边缘系统31和云端系统32，其中：

边缘系统31，用于管理应用调度平台管理的至少一个边缘集群；

云端系统32，用于基于边缘系统管理的至少一个边缘集群，实现以下步骤：

确定具有第一标识信息的至少一个第一虚拟节点；其中，第一虚拟节点与应用调度平台管理的边缘集群具有对应关系；

确定具有第二标识信息的第一待调度容器的资源需求信息；其中，第一待调度容器与待创建虚拟应用实例对应；

基于资源需求信息，从至少一个第一虚拟节点中确定目标虚拟节点；

调度第一待调度容器至目标虚拟节点；

通过目标虚拟节点基于第一待调度容器的资源需求信息，创建待创建虚拟应用实例，以使待创建虚拟应用实例运行于目标虚拟节点对应的边缘集群。

在本申请其他实施例中，云端系统执行步骤确定具有第一标识信息的至少一个第一虚拟节点时，可以通过以下步骤来实现：

确定应用调度平台管理的至少一个边缘集群；

确定至少一个边缘集群的资源信息，得到至少一个目标资源信息；

基于至少一个目标资源信息，生成至少一个边缘集群对应的至少一个第二虚拟节点；

采用第一标识信息对至少一个第二虚拟节点进行标识，得到至少一个第一虚拟节点。

在本申请其他实施例中，云端系统执行步骤基于至少一个目标资源信息，生成至少一个边缘集群对应的至少一个第二虚拟节点时，可以通过以下步骤来实现：

基于至少一个目标资源信息，确定每一目标资源信息对应的资源类别；

基于每一目标资源信息对应的资源类别，生成对应的第二虚拟节点，得到至少一个第二虚拟节点。

在本申请其他实施例中，云端系统执行步骤确定具有第二标识信息的第一待调度容器的资源需求信息之前，还用于执行以下步骤：

确定待创建虚拟应用实例的配置内容；

基于配置内容，创建目标虚拟应用；

基于目标虚拟应用，创建第一参考调度容器；

采用第二标识信息对第一参考调度容器进行标识，得到第一待调度容器。

在本申请其他实施例中，云端系统执行步骤基于资源需求信息，从至少一个第一虚拟节点中确定目标虚拟节点时，可以通过以下步骤来实现：

基于资源需求信息和至少一个第一虚拟节点的服务目录信息，从至少一个第一虚拟节点中筛选得到至少一个第三虚拟节点；

基于至少一个第三虚拟节点的服务信息，对每一第三虚拟节点进行评估，得到至少一个评估值；

基于至少一个评估值，从至少一个第三虚拟节点中确定得到目标虚拟节点。

在本申请其他实施例中，云端系统执行步骤通过目标虚拟节点基于第一待调度容器的资源需求信息，创建待创建虚拟应用实例之后，还用于执行以下步骤：

监测第一待调度容器的状态；

若第一待调度容器的状态为第一状态，更新目标虚拟应用的状态为第一状态；其中，第一待调度容器为第一状态表明待创建虚拟应用实例在目标虚拟节点对应的边缘集群上的运行状态为目标状态；

若第一待调度容器的状态为第二状态，基于目标虚拟应用，创建第二参考调度容器；

采用第二标识信息对第二参考调度容器进行标识，得到第二待调度容器。

在本申请其他实施例中，云端系统执行步骤若第一待调度容器的状态为第一状态，更新目标虚拟应用的状态为第一状态之后，还用于执行以下步骤：

若检测到目标虚拟应用的状态为第一状态，删除目标虚拟应用；

若监测到目标虚拟应用已删除，删除第一待调度容器。

在本申请其他实施例中，云端系统执行步骤若第一待调度容器的状态为第一状态，更新目标虚拟应用的状态为第一状态之后，还用于执行以下步骤：

采用目标通信方式对目标虚拟节点进行管理控制，以实现对待创建虚拟应用实例进行运维管理。

需要说明的是，本实施例中处理器所执行的步骤的具体实现过程，可以参照图1～6对应的实施例提供的应用调度方法中的实现过程，此处不再赘述。

本申请实施例提供的一种应用调度平台，通过确定具有第一标识信息的至少一个第一虚拟节点，并确定具有第二标识信息的第一待调度容器的资源需求信息，然后基于资源需求信息，从至少一个第一虚拟节点中确定目标虚拟节点，并调度第一待调度容器至目标虚拟节点，最后通过目标虚拟节点基于第一待调度容器的资源需求信息，创建待创建虚拟应用实例，以使待创建虚拟应用实例运行于目标虚拟节点对应的边缘集群。这样，基于具有第二标识信息的第一待调度容器的资源需求信息，从至少一个具有第一标识信息的第一虚拟节点中确定目标虚拟节点后，调度第一待调度容器至目标虚拟节点，从而使目标虚拟节点基于第一待调度容器的资源需求信息创建待创建虚拟应用实例，解决了目前实现边缘集群存储管理时，只能管理单一应用类型的边缘集群的问题，实现了一种边缘集群存储管理时，可以管理多种应用类型的边缘集群方法，有效提高了边缘集群存储管理对异构应用的调度效率。

基于前述实施例，本申请的实施例提供一种计算机可读存储介质，简称为存储介质，该计算机可读存储介质存储有一个或者多个程序，以实现如图1～6对应的实施例提供的应用调度方法中的实现过程，此处不再赘述。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述，仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。