CN114301924A - 一种云边协同环境的应用任务调度方法及节点设备 - Google Patents

Abstract

本发明公开了一种云边协同环境的应用任务调度方法，所述云边协同环境包括多个边缘端节点和至少一个云端主节点；应用任务调度方法包括：获取第一数量的任务；基于各任务遍历各边缘端节点，以确定满足各任务的候选节点；基于各候选节点的节点参数确定出与各任适配的目标节点，节点参数包括各任务和相应候选节点的时延相关参数；利用目标节点从对应的用户终端获取需要计算的数据。本公开的方法基于各候选节点的节点参数确定出与各任适配的目标节点，节点参数包括各任务和相应候选节点的时延相关参数，由此可以实现将一定数量的任务从本地终端调度到边缘端节点或主节点，并实现满足任务的时延需求。

Description

一种云边协同环境的应用任务调度方法及节点设备

技术领域

本发明涉及云计算技术领域，尤其涉及一种云边协同环境的应用任务调度方法及节点设备。

背景技术

云计算为大数据处理提供了高效的计算平台，已经改变了人们日常工作和生活的方式。

为了应对上述挑战，业界提出在网络边缘提供计算处理与数据存储的能力，即边缘计算，以达到在网络边缘向用户提供优质服务的目的。边缘计算的基本思想是：把云计算平台(包括计算、存储和网络资源)迁移到网络边缘。

现有技术中对于Kubernetes调度算法的传统思想是：单个Pod通过预选算法和优选算法选择目标节点进行卸载。关于预选过程和优选过程的基础算法的设计是“插件化”的，开发者可以根据自己的需求自定义调度算法并注册，只需要提供算法函数、名称，如果是优选算法的话还需提供一个整数类型的权重值。除此之外，关于Kubernetes的主流改进调度算法当前大多数研究关注的是对优选过程中集群资源利用率和负载均衡效率的考虑。

然而，在边缘计算环境(如Kubeedge平台)下，一部分应用或服务对时延和带宽的要求非常高，现有技术中无法解决在该场景下如何来满足带宽和时延的要求。

发明内容

本发明实施例提供一种云边协同环境的应用任务调度方法，用以在集群的资源利用率和负载均衡效率已经达到了基本水平的条件下，将一定数量的任务从本地终端调度到边缘端节点或主节点，并实现满足任务的时延需求。

本公开实施例提出一种云边协同环境的应用任务调度方法，所述云边协同环境包括多个边缘端节点和至少一个云端主节点，所述边缘端节点用于实现用户终端与云端主节点的通信；

所述应用任务调度方法包括：

获取第一数量的任务；

基于各任务遍历各边缘端节点，以确定满足各任务的候选节点；

基于各候选节点的节点参数确定出与各任适配的目标节点，所述节点参数包括各任务和相应候选节点的时延相关参数；

利用所述目标节点从对应的用户终端获取需要计算的数据。

在一些实施例中，获取第一数量的任务是在任务消息缓存队列中获取的，且获取第一数量的任务之前间隔指定的时延，所述任务消息缓存队列中缓存有从各用户终端获取的任务。

在一些实施例中，基于各候选节点的节点参数确定出与各任适配的目标节点包括：

建立各任务与各候选节点之间的二分图；

为各任务配置相应的时延期望，并为各候选节点配置相应的时延值；

基于各时延期望与各候选节点的时延值进行匹配，以确定各任务对应的目标节点。

在一些实施例中，基于各时延期望与各候选节点的时延值进行匹配，以确定各任务对应的目标节点包括：

在各任务的时延期望与各候选节点的时延值直接完成匹配的情况下，确定具有相应时延值的候选节点为各任务相应的目标节点，其中，匹配出的目标节点与各任务一一对应；

在任一任务的时延期望无法与各候选节点的时延值匹配的情况下，确定与该时延期望偏差最小的时延值对应的节点作为目标节点。

在一些实施例中，基于各时延期望与各候选节点的时延值进行匹配，以确定各任务对应的目标节点还包括：

在当前候选节点被其他任务匹配的情况下，判断匹配失败；

降低冲突所涉及任务的时延期望，以及增加冲突候选节点的期望，以重复执行匹配，直至各任务的时延期望与各候选节点的时延值完成匹配。

在一些实施例中，基于各候选节点的节点参数确定出与各任适配的目标节点之后还包括：将各目标节点的任务信息通知除自身以外的其他各边缘端节点。

在一些实施例中，各边缘节点配置有本地数据库，该边缘节点的本地数据库中保存有该节点与云端主节点的所有通信数据。

本公开还提出一种节点设备，包括存储器和处理器，所述存储器上存储有计算机程序，所述计算机程序被处理器执行时实现本公开各实施例所述的云边协同环境的应用任务调度方法的步骤。

本发明实施例通过遍历各边缘端节点，从而能够筛选掉不满足任务需求的节点，降低后续匹配的计算量，并基于各候选节点的节点参数确定出与各任适配的目标节点，各任务和相应候选节点的时延相关参数，由此可以实现将一定数量的任务从本地终端调度到边缘端节点或主节点，并实现满足任务的时延需求。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本公开的应用任务调度方法的基本流程图；

图2为本公开的KM算法匹配的初始过程示意图；

图3为本公开的KM算法匹配子流程图；.

图4为本公开的KM算法匹配的中间过程示意图；

图5为本公开的KM算法匹配的结果示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

KubeEdge是一个开源的系统，可将本机容器化应用编排和管理扩展到边缘端设备。它构建在Kubernetes之上，为网络和应用程序提供核心基础架构支持，并在云端和边缘端部署应用，同步元数据。100％兼容K8S API，可以使用K8SAPI原语管理边缘节点和设备。KubeEdge还支持MQTT协议，允许开发人员编写客户逻辑，并在边缘端启用设备通信的资源约束。

与Kubernetes类似，Kubeedge的集群也由Master节点(云端主节点)和Node节点(边缘端节点)组成，每个Master或者Node上的最小调度单位是由Kubernetes设计的Pod对象，每个Pod对象可以运行一个或几个容器。Kubeedge的Service(服务)就是由每个Pod中运行的一组容器所提供的，而它的容器技术来源于Docker。

下面进一步介绍Kubeedge框架中涉及的模块组件

Device模块：本地用户设备端

UE：用户终端，发起Pod应用任务申请；

Node-scheduling模块：负责接收调度信息的边缘端节点

MQTT/HTTP：Kubeedge目前对外部设备的接入支持MQTT和HTTP；

EventBus/ServiceBus：分别针对MQTT和HTTP，将边缘端各模块或是设备端通信的message做转换的组件，最终将结果传给边缘端的MQTT服务器和HTTP服务器；

EdgeHub：是一个Web socket客户端，负责将接受到的消息转发到各edge端的模块处理，同时将来自各edge端模块的消息通过隧道发送到cloud端。提供可靠和高效的云边信息同步。

Edged：是运行在边缘节点的代理，用于管理容器化的应用程序。是轻量化的Kubelet，实现Pod、Volume、Node等Kubernetes资源对象的生命周期管理。

Master模块：云端主节点

CloudHub：是一个Web socket服务器，用于大量edge端基于websocket或者quic协议连接上来。负责监听云端的变化，缓存并发送消息到EdgeHub。

Scheduler：是Kubeedge运行在Master节点上的调度器，它的作用是负责将Pod调度到合适的目标Node节点进行调度(卸载)。

Node-execution模块：Pod调度完成后的边缘端(或云端)目标节点，执行Pod任务。

基于此本公开提出一种云边协同环境的应用任务调度方法，所述云边协同环境包括多个边缘端节点和至少一个云端主节点，所述边缘端节点用于实现用户终端与云端主节点的通信，如图1所示，本公开的应用任务调度方法包括：

在步骤S101中，获取第一数量的任务。在一些实施例中，获取第一数量的任务是在任务消息缓存队列中获取的，且获取第一数量的任务之前间隔指定的时延，所述任务消息缓存队列中缓存有从各用户终端获取的任务。具体可以利用在云端的CloudHub模块建立一个Pod任务消息缓存队列并等待指定的时延后开始向Scheduler调度器模块循环传输M个Pod的任务消息。

在步骤S102中，基于各任务遍历各边缘端节点，以确定满足各任务的候选节点。该次遍历可以遍历所有的边缘端节点，从而筛选掉不满足任务需求节点，保留可以满足任务需求的节点作为候选节点，各个Pod任务所匹配出的候选节点之间可以存在重叠，也可以不同，但候选节点的数量需要大于或者等于任务数量，以保证每个任务均能够被调度到一个节点中，并且一个节点不会同时加载2个任务。例如M个Pod任务匹配出了N个候选节点，M≤N。

在步骤S103中，基于各候选节点的节点参数确定出与各任适配的目标节点，所述节点参数包括各任务和相应候选节点的时延相关参数。具体实施中可以使用KM算法来确定出与各任适配的目标节点。

在步骤S104中，利用所述目标节点从对应的用户终端获取需要计算的数据。在获取数据后各目标节点执行对应的数据运算，从而实现将Pod任务卸载到边缘端节点。

本公开通过遍历各边缘端节点，从而能够筛选掉不满足任务需求的节点，降低后续匹配的计算量，并基于各候选节点的节点参数确定出与各任适配的目标节点，各任务和相应候选节点的时延相关参数，由此可以实现将一定数量的任务从本地终端调度到边缘端节点或主节点，并实现满足任务的时延需求。

在一些实施例中，基于各候选节点的节点参数确定出与各任适配的目标节点包括：

建立各任务与各候选节点之间的二分图；

为各任务配置相应的时延期望，并为各候选节点配置相应的时延值；

基于各时延期望与各候选节点的时延值进行匹配，以确定各任务对应的目标节点。

具体的，本公开的方法利用KM算法实现，具体的建立任务与候选节点之间的二分图，并在二分图为各任务配置相应的时延期望，并为各候选节点配置相应的时延值。例如现有M个任务和N个边缘节点，而一些任务到一些节点之间存在传输计算的时延成本，而部分应用或服务对时延和带宽的要求非常高。因此本公开的方法利用KM算法的二分图对时延进行匹配，从而达到使所有任务的真实时延总和降到最低的目的。本公开的候选节点配置的时延值是基于其资源利用率和负载均衡效率来确定的，从而利用该时延值来进行匹配，极大提高了卸载决策的合理性。具体实施过程中可以为时延的值前面加一个负号变成负数，将任务时延期望和节点的时延值两两配对。让每个任务分别能够调度到合适的边缘节点，使最后每个任务的负数时延相加起来总和最大(绝对值最小)。

在一些实施例中，基于各时延期望与各候选节点的时延值进行匹配，以确定各任务对应的目标节点包括：

在各任务的时延期望与各候选节点的时延值直接完成匹配的情况下，确定具有相应时延值的候选节点为各任务相应的目标节点，其中，匹配出的目标节点与各任务一一对应；

在任一任务的时延期望无法与各候选节点的时延值匹配的情况下，确定与该时延期望偏差最小的时延值对应的节点作为目标节点。

具体的本示例中，需要保证每个任务均能够被调度到一个节点中，并且一个节点不会同时加载2个任务。通过本公开的时延匹配方式能够该目的，以任务数量为3候选节点数量为3进行举例，如图2、图3所示，一种具体的匹配流程如下：

在步骤S301中、从第一个任务(任务1)开始，为每一个任务匹配边缘端节点。如图2中，根据前述遍历方式获得的任务1的候选节点为节点1和节点3，任务2的候选节点为节点1、节点2和节点3，任务3的候选节点为节点3。

在步骤S302中、为每个任务设定一个时延期望的期望值，具体的期望值可以取自每个任务到不同节点所需的负数时延中最大值(绝对值最小)，这表示每个任务更期望去往负数时延较大(即：真实时延较小)的边缘端节点进行卸载。同时本公开的方法还为每个候选节点配置了期望值，节点的期望值初始设置为0。

在步骤S303中、每个任务每次都从第一个边缘节点(节点1)开始尝试匹配，选择一个节点，使任务的期望值和所选节点的期望和等于它们两者间的负数时延的值，例如图2中首次匹配时，任务1与节点3的匹配过程是：

-2(任务1的时延期望)+0(节点3的期望值)＝-2(节点3的时延值)

由此首次匹配时任务1可以匹配到节点3中，每个节点只允许被匹配成功过一次。

在步骤S304中、在接下来每个任务的匹配过程中，用匈牙利算法(KM算法的匹配逻辑)寻找所有任务的完整匹配；若未找到完整匹配则降低相关任务(尝试匹配过的任务)的期望值和增加相关节点(匹配成功过的节点)的期望值；

在步骤S305中、重复步骤S304直到完整匹配为止，则该任务本次匹配已找到合适的边缘节点。

在一些实施例中，基于各时延期望与各候选节点的时延值进行匹配，以确定各任务对应的目标节点还包括：

在当前候选节点被其他任务匹配的情况下，判断匹配失败；

降低冲突所涉及任务的时延期望，以及增加冲突候选节点的期望，以重复执行匹配，直至各任务的时延期望与各候选节点的时延值完成匹配。

在具体匹配过程中，有可能出现由于该候选节点已经别其他任务进行匹配，从而匹配失败的情况。对于这种情况，本公开中进一步的，降低冲突所涉及任务的时延期望，以及增加冲突候选节点的期望。以图2为例，由于是顺序执行的匹配，因此任务2与任务1均只能匹配到节点3中，因此存在匹配冲突。如图4所示，本公开的方法将任务2与任务1的时延期望降低，并增加节点3的期望，进行第二轮匹配。通过改变冲突所涉及任务的时延期望，以及增加冲突候选节点的期望，可以提高让冲突的任务匹配到其他节点中去，从而保证每个节点只允许被匹配成功一次。按照这样的方式，图2最终匹配的结果如图5所示，匹配结束时，任务1与节点1匹配，任务2与节点2匹配，任务3与节点3匹配。此时所有任务的负数时延相加起来总和最大：-3-5-1＝-9，也即所有任务的真实时延总和最低，即：3+5+1＝9。在大规模的匹配中，本公开的方法能够让所有POD应用任务卸载的时延总和降到最低，从而满足边缘计算环境下，例如Kubeedge平台部分应用或服务对时延和带宽的特殊要求。

在一些实施例中，基于各候选节点的节点参数确定出与各任适配的目标节点之后还包括：将各目标节点的任务信息通知除自身以外的其他各边缘端节点。通过这样的方式能够进一步保证每个节点只与一个任务匹配。

在一些实施例中，各边缘节点配置有本地数据库，该边缘节点的本地数据库中保存有该节点与云端主节点的所有通信数据。

对于前述匹配过程中所使用的KM算法，边缘端节点还设置有MetaManager模块。MetaManager模块后端对应一个本地的数据库(SqlLite)，所有该节点其他模块需要与cloud端通信的内容都会被保存到本地DB中一份，当需要查询数据时，如果本地DB中存在该数据，直接从本地获取，从而避免了与cloud端之间频繁的网络交互。同时，在网络中断的情况下，本地的缓存的数据也能够保障其稳定运行，在通信恢复之后，重新同步数据。设置本地数据库是边缘节点自治能力的关键。

本公开还提出一种云边协同环境的应用任务调度方法，在Kubeedge平台的应用实例，包括如下步骤：

步骤1：一定数量的用户向附近的边缘节点发起各自的Pod应用任务请求。

步骤2：经由MQTT/HTPP协议将相关POD应用任务消息传给EventBus/ServiceBus组件。

步骤3：EventBus/ServiceBus组件将接受到的消息整理转换后传输给EdgeHub模块的websocket客户端。

步骤4：EdgeHub模块继续将相关消息传输给云端CloudHub模块的websocket服务器。

步骤5：在云端的CloudHub模块建立一个Pod任务消息缓存队列并进行一定时间的等待后开始向Scheduler调度器模块循环传输M个Pod的任务消息。

步骤6、步骤7：Scheduler调度器在预选过程分别针对每一个Pod遍历一定数量满足条件的N个边缘节点后，在优选过程将传统的优选算法打分机制固化到KM算法的参数(该参数影响负数时延的具体值)之中，并建立POD任务和边缘节点的二分图，基于每个节点的资源利用率和负载均衡效率分值的影响，在KM算法作用下，得出该周期内所有Pod任务卸载到边缘节点的时延总和最小化的分配结果，并将结果消息返回给CloudHub模块的websocket服务器；

步骤8：继续将结果消息返回给调度节点EdgeHub的websocket客户端；

步骤9：将结果消息发送给EventBus/ServiceBus组件；

步骤10：结果消息在EventBus/ServiceBus组件转换后发送给MQTT/和HTTP的外部接口；

步骤11：通过MQTT/HTTP外部接口，根据结果消息，将消息传达给各个POD的边缘端(或云端)目标执行节点；

步骤12：目标执行节点将消息传输给MetaManager组件；

步骤13：MetaManager继续将结果消息传输给Edged模块；

步骤14：Edged模块根据结果消息内容启动相应的Pod；

步骤15：开始运行的Pod中的容器服务根据需要从数据库获取数据；

步骤16：相应的数据被Pod中的容器服务调用；

步骤17：将目前目标执行节点的状态消息发送给该节点的外部接口；

步骤18：从相应接口将消息传回用户终端，用户终端开始将需要计算的数据传给相应节点的容器服务，或者准备接收从相应节点的容器服务传回的数据。

本公开的方法能够在保证每个Pod的执行节点的资源利用率和负载均衡效率达到一定水平的基础上，寻找到满足要求的一定数量的边缘节点分别进行卸载，并保证所有的Pod应用的卸载延迟总和降到最低，满足了在边缘计算环境部分应用或服务对时延和带宽的特殊要求。

本公开还提出一种节点设备，包括存储器和处理器，所述存储器上存储有计算机程序，所述计算机程序被处理器执行时实现本公开各实施例所述的云边协同环境的应用任务调度方法的步骤。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本发明的保护之内。

Claims (8)

1.一种云边协同环境的应用任务调度方法，其特征在于，所述云边协同环境包括多个边缘端节点和至少一个云端主节点，所述边缘端节点用于实现用户终端与云端主节点的通信；

所述应用任务调度方法包括：

获取第一数量的任务；

基于各任务遍历各边缘端节点，以确定满足各任务的候选节点；

基于各候选节点的节点参数确定出与各任适配的目标节点，所述节点参数包括各任务和相应候选节点的时延相关参数；

利用所述目标节点从对应的用户终端获取需要计算的数据。

2.如权利要求1所述的云边协同环境的应用任务调度方法，其特征在于，获取第一数量的任务是在任务消息缓存队列中获取的，且获取第一数量的任务之前间隔指定的时延，所述任务消息缓存队列中缓存有从各用户终端获取的任务。

3.如权利要求1所述的云边协同环境的应用任务调度方法，其特征在于，基于各候选节点的节点参数确定出与各任适配的目标节点包括：

建立各任务与各候选节点之间的二分图；

为各任务配置相应的时延期望，并为各候选节点配置相应的时延值；

基于各时延期望与各候选节点的时延值进行匹配，以确定各任务对应的目标节点。

4.如权利要求3所述的云边协同环境的应用任务调度方法，其特征在于，基于各时延期望与各候选节点的时延值进行匹配，以确定各任务对应的目标节点包括：

在各任务的时延期望与各候选节点的时延值直接完成匹配的情况下，确定具有相应时延值的候选节点为各任务相应的目标节点，其中，匹配出的目标节点与各任务一一对应；

在任一任务的时延期望无法与各候选节点的时延值匹配的情况下，确定与该时延期望偏差最小的时延值对应的节点作为目标节点。

5.如权利要求4所述的云边协同环境的应用任务调度方法，其特征在于，基于各时延期望与各候选节点的时延值进行匹配，以确定各任务对应的目标节点还包括：

在当前候选节点被其他任务匹配的情况下，判断匹配失败；

降低冲突所涉及任务的时延期望，以及增加冲突候选节点的期望，以重复执行匹配，直至各任务的时延期望与各候选节点的时延值完成匹配。

6.如权利要求1所述的云边协同环境的应用任务调度方法，其特征在于，基于各候选节点的节点参数确定出与各任适配的目标节点之后还包括：将各目标节点的任务信息通知除自身以外的其他各边缘端节点。

7.如权利要求1所述的云边协同环境的应用任务调度方法，其特征在于，各边缘节点配置有本地数据库，该边缘节点的本地数据库中保存有该节点与云端主节点的所有通信数据。

8.一种节点设备，其特征在于，包括存储器和处理器，所述存储器上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的云边协同环境的应用任务调度方法的步骤。

Images