CN115981790B - 基于Kubernetes的边缘云集群资源优化的容器化调度系统 - Google Patents

Abstract

本发明公开了一种基于Kubernetes的边缘云集群资源优化的容器化调度系统，包括：用于生成请求服务序列的负载生成器模块：参数收集模块：用于生成服务编排参数和请求指派参数；边缘集群管理模块：基于请求服务序列和请求指派参数以及用户预设算法容器生成请求调度决策，并发送给请求指派模块；请求指派模块：将请求指派参数发送给边缘集群管理模块，并将请求调度决策发送给对应的节点；服务编排模块：将服务编排参数发送给云管理模块，将服务编排决策发送给边缘集群管理模块；云管理模块：基于请求服务序列、服务编排参数以及用于用户预设算法容器生成服务编排决策，并将服务编排决策发送给服务编排模块。本发明可以降低实验环境的开销。

Description

基于Kubernetes的边缘云集群资源优化的容器化调度系统

技术领域

本发明属于计算机网络技术领域，具体涉及一种基于Kubemetes的边缘云集群资源优化的容器化调度系统。

背景技术

近几年来，边缘计算正在蓬勃发展。通过设置分布式的边缘节点，边缘计算基础设施可为附近用户提供网络、计算、应用、存储服务，从而避免终端设备与距离较远的云端进行通信产生的时延，弥补了云计算的弱点。随着人工智能等不同类型服务的不断涌现，服务侧重的需求也不尽相同。而面对如今各种不同类型的任务，云边协同变得极为重要，现在生活中最常见的便是云-边-端三层架构。并且随着K8s(Kubemetes)的不断发展，人们也通常会使用K8s来进一步管理自己的云边系统，而在云边端三层架构上，设计能够适应k8s的合适的服务编排和请求指派算法被认为是可以尽可能地满足用户的QoS需求的一种有效解决方案。为了验证所设计算法的效果，现有技术中的定制化环境难以作为通用的测试床以便找到各种算法的细分适用场景。因此，如何实现一个基于K8s的云边端融合系统的优化调度算法的实验平台已成为一个急需解决的问题。

发明内容

针对以上问题，本发明提出了一种基于Kubemetes的边缘云集群资源优化的容器化调度系统，给出了一个模块化的体系结构，其中每个模块都会处理一个方面的事务，且支持的操作系统为Linux。为解决以上技术问题，本发明所采用的技术方案如下：

一种基于Kubernetes的边缘云集群资源优化的容器化调度系统，包括：

负载生成器模块：用于生成请求服务序列并将请求服务序列发送到边缘集群管理模块和云管理模块；

参数收集模块：用于基于边缘集群管理模块收集的各边缘集群的节点状态信息生成服务编排参数和请求指派参数，并将服务编排参数发送给云管理模块，将请求指派参数发送给边缘集群管理模块；

边缘集群管理模块：基于接收到的请求服务序列和请求指派参数以及用户预设的算法容器生成请求调度决策，并将请求调度决策发送给请求指派模块；

请求指派模块：用于将参数收集模块收集的请求指派参数发送给边缘集群管理模块，并将接收到的边缘集群管理模块生成的请求调度决策发送给对应的节点；

服务编排模块：将服务编排参数发送给云管理模块，并将云管理模块生成的服务编排决策发送给边缘集群管理模块；

云管理模块：基于接收到的请求服务序列、服务编排参数以及用于用户预设的算法容器生成服务编排决策，并将服务编排决策发送给服务编排模块。

所述请求服务序列满足泊松分布，且请求服务序列基于用户预设的任务产生总时间和各服务类型的请求总数生成。

所述请求服务序列包括请求序号、服务类型、请求开始时间、请求结束时间、请求数据类型和请求数据内容。

所述请求指派参数包括请求序号、每个请求序号所对应的服务类型、各个边缘集群上满足每个请求序号所需服务类型的pod实例的运行状态、每个边缘集群到其它边缘集群之间的传播时延；

所述各个边缘集群上满足每个请求序号所需服务类型的pod实例的运行状态的表达式为：

((0，N_i，0，P_i，0)，...，(k，N_i，k，P_i，k)，...，(K，N_i，K，P_i，K))；

式中，N_i，k表示边缘集群k的各个节点上，请求服务序列中请求i所对应的pod实例的数量，P_i，k表示边缘集群k所拥有的请求i所对应的所有pod实例的CPU使用率和内存使用率，K表示边缘集群的总数；

所述每个边缘集群到其它边缘集群之间的传播时延的表达式为：

((0，T₀)，...，(k，T_k)，...，(K，T_K))；

式中，T_k表示边缘集群k到其它边缘集群的传播时延的集合，T_k＝{t_k，1，...，t_k，k-1，t_k，k+1，...，t_k，K}，t_k，k+1表示边缘集群k和边缘集群k+1之间的传播时延，T₀表示云到其它边缘集群的传播时延的集合，t_k，k-1示边缘集群k和边缘集群k-1之间的传播时延。

还包括核心配置模块和日志记录模块，所述核心配置模块用于基于用户的配置文件生成云边协同场景；所述日志记录模块用于输出用户算法容器的运行日志。

所述服务编排决策包括边缘集群及对对应的边缘集群所采取的动作，其表达式为：

式中，表示请求服务序列中请求i的服务编排决策，/>表示pod实例的集合， 当l＝0时，表示不添加pod实例，当l为正时，表示在边缘集群k内增加类型为l的pod实例，当l为负时，表示在边缘集群k内删除类型为l的pod实例，S表示pod实例类型的总数，/>表示边缘集群的集合。

所述请求调度决策的表达式为：

式中，表示请求服务序列中请求i的请求调度决策，/>表示边缘集群k的各个节点的集合，该请求调度决策表示请求服务序列中请求i由边缘集群k的工作节点j执行。

本发明的有益效果：

本申请采用面向接口的系统架构，搭建在由云和边缘集群组成的真实系统上，方便研究人员在系统上部署和切换各种算法，并支持定制，大幅降低了试验者们前期建成实验环境的开销，有利于算法的快速实验和切换；支持K8s，并集成了云边协同的场景，使用了协程进行编程，创建一个协程的消耗远小于一个进程；研究人员可以使用它观察在各个场景下算法的效果然后选用最合适的算法。

附图说明

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

图1为本发明的系统流程示意图。

图2为模块关系结构图。

图3为算法部署流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有付出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

边缘计算(Edge Computing)：边缘计算是指在靠近物或数据源头的网络边缘侧，融合了网络、计算、存储以及应用处理能力的分布式平台，就近提供智能服务。它是一种致力于使计算尽可能靠近数据源、以减少延迟和带宽使用的网络理念。简而言之，边缘计算意味着在云端运行更少的进程，将这些进程移动到本地，例如用户的计算机、IoT设备或边缘服务器。将计算放到网络边缘可以最大程度地减少客户端和服务器之间必须进行的长距离通信量。边缘计算着重要解决的问题，是传统云计算模式下存在的高延迟、网络不稳定和低带宽问题。由于资源条件的限制，云计算服务不可避免收到高延迟和网络不稳定带来的影响，但是通过将部分或者全部处理程序迁移至靠近用户或数据收集点，边缘计算能够大大减少在云中心模式站点下给应用程序所带来的影响。

深度强化学习(Deep Reinforcement Learning，DRL)：深度强化学习将深度学习DL的感知能力和强化学习RL的决策能力相结合，可以直接根据输入的信息进行控制，是一种更接近人类思维方式的人工智能方法。在与世界的正常互动过程中，强化学习会通过试错法利用奖励来学习。它跟自然学习过程非常相似，而与深度学习不同。在强化学习中，可以用较少的训练信息，这样做的优势是信息更充足，而且不受监督者技能限制。

深度强化学习DRL是深度学习和强化学习的结合。这两种学习方式在很大程度上是正交问题，二者结合得很好。强化学习定义了优化的目标，深度学习给出了运行机制——表征问题的方式以及解决问题的方式。深度强化学习解决了在强化学习RL中使用函数逼近的基本不稳定性问题：经验重放和目标网络。经验重放使得强化学习RL智能体能够从先前观察到的数据离线进行抽样和训练。这不仅大大减少了环境所需的交互量，而且可以对一批经验进行抽样，减少学习更新的差异。此外，通过从大存储器均匀采样，可能对强化学习RL算法产生不利影响的时间相关性被打破了。最后，从实际的角度看，可以通过现代硬件并行地高效地处理批量的数据，从而提高吞吐量。

一种基于Kubernetes的边缘云集群资源优化的容器化调度系统，如图1和图2所示，包括：

负载生成器模块：负责根据用户设定的配置生成请求，它是为边缘集群管理模块和云管理模块提供输入的主要组件，以通过请求与各边缘集群进行交互。

所述负载生成器模块包括用于生成请求服务序列的请求生成模块和用于接收请求服务序列并将请求服务序列发送到边缘集群管理模块和云管理模块的请求发送模块，请求生成模块可以根据用户输入的任务产生总时间、λ参数(泊松分布参数)和各服务类型的总体数量生成满足泊松分布的每种服务类型的请求服务序列，泊松分布是统计与概率学里常见到的一种离散概率分布，学界认为人类行为是服从泊松分布的。所述请求服务序列包括请求序号、服务类型、请求开始时间、请求结束时间、请求数据类型和请求数据内容，所示服务类型包括离线批处理服务和延迟敏感服务，且离线批处理服务和延迟敏感服务均分别包括若干种业务类型，比如延迟敏感服务也即LC服务包括直播和云游戏等，离线批处理服务也即BE服务包括数据分析和模型训练等，请求数据类型包括数字、图片、视频和音频等，请求数据内容是指请求的具体内容。另外，用户也可以不通过请求生成模块生成请求服务序列，而采用直接输入的方式。

具体设计时请求发送模块可以使用Python的asyncio编写，asyncio是用来编写并发代码的库，使用async/await语法。asyncio被用作多个提供高性能Python异步框架的基础，它往往是构建IO密集型和高层级结构化网络代码的最佳选择，使用协同程序和多路复用I/O访问sockets和其它资源，具体支持TCP(Transmission Control Protocol，传输控制协议)、UDP(User Datagram Protocol，用户数据报协议)等，还可以提供一组用于并发地运行Python协程的高层级API(Application Programming Interface，应用程序编程接口)以减少IO等待时间，并对其执行过程实现完全控制。请求生成模块使用pandas和random库。

参数收集模块：用于基于边缘集群管理模块收集的各边缘集群的节点状态信息收集服务编排参数和请求指派参数，以便在合适的时间为请求指派模块和服务编排模块提供参数，所述参数包括如下：

服务编排周期内边缘集群中每种服务类型请求成功与请求失败的数量、服务编排周期内边缘集群因pod数量不足而被积压的请求的服务类型及请求的数量、每个边缘集群的各工作节点上所部署的pod实例的类型与pod实例的数量、每个边缘集群上各个节点的CPU使用率和内存使用率、请求序号、每个请求序号所对应的服务类型、各个边缘集群上满足每个请求序号所需服务类型的pod实例的运行状态、每个边缘集群到其它边缘集群之间的传播时延。其中，前四个为服务编排参数，后四个为请求指派参数，所述各个边缘集群上满足每个请求序号所需服务类型的pod实例的运行状态的表达式为：

((0，N_i，0，P_i，0)，...，(k，N_i，k，P_i，k)，...，(K，N_i，K，P_i，K))；

式中，N_i，k表示边缘集群k的各个节点上，请求服务序列中请求i所对应的pod实例的数量，P_i，k表示边缘集群k所拥有的请求i所对应的所有pod实例的CPU使用率和内存使用率，K表示边缘集群的总数。每个边缘集群内均包括一个控制节点和若干个工作节点，每个工作节点将各自的参数发送给所在集群的控制节点，参数收集模块再通过每个边缘集群的控制节点进行参数收集即可。

所述每个边缘集群到其它边缘集群之间的传播时延的表达式为：

((0，T₀)，...，(k，T_k)，...，(K，T_K))；

式中，T_k表示边缘集群k到其它边缘集群的传播时延的集合，T_k＝{t_k，1，...，t_k，k-1，t_k，k+1，...，t_k，K}，t_k，k+1表示边缘集群k和边缘集群k+1之间的传播时延，T₀表示云到其它边缘集群的传播时延的集合，当k为0时，表示云，也即边缘集群0即为云。

为了实现参数收集，必须提前在每个边缘集群的控制节点上安装k8s的组件metrics-server。metrics-server是资源指标监控服务器，是Kubernetes内置可扩展、高效的容器资源指标来源，参数收集模块与metrics-server进行交互，在需要时从metrics-server的metric-api(例如/apis/metrics.k8s.io/v1beta1/namespaces/)采集指标信息如pod的个数和种类、节点的个数、每个节点的CPU及内存资源，聚合后的数据存储在内存中，并以information-collection-module-api的形式暴露出去。proc文件系统是一个伪文件系统，提供一个可以从用户空间读取系统参数的接口，可以从中收集大量的系统消息。由于系统的信息，如进程，是动态改变的，所以用户或应用程序读取proc文件时，proc文件系统是动态从系统内核读出所需信息并提交的。另外，用户还可以通过参数收集模块直接将对应的参数输入。

核心配置模块：包括云配置模块、边缘配置模块和终端配置模块，负责从配置文件中读取并加载云边协同场景，所述配置文件为json格式；比如在配置模块中定义各个边缘集群的IP、各边缘集群接口对应开启的端口也即port、用户算法的名字及其对应的端口号等。请求发送模块通过读取核心配置模块中所存储的请求URL与边缘集群接口之间的关系准确地将请求发送到对应的边缘集群。

日志记录模块：用于输出运行日志，通过所输出的日志可以获取用户算法运行过程中的报错信息，通过客户端如Python内置的logging模块，试验者可以根据自己实验的要求，在logging.json文件中设置输出日志的等级、日志保存路径等。logging模块提供了5种日志级别，分别为：CRITICAL＞ERROR＞WARNING＞INFO＞DEBUG。这些级别具有不同的优先级，其中CRITICAL的优先级最高，而DEBUG的优先级最低，debug：打印所有级别的日志，通常在调试代码过程中使用；info：打印info、warning、error和critical级别的日志，用于确认代码按预期运行；waming：打印waring、error和critical级别的日志，用于警示一些情况；error：打印error和critical级别的日志，用于警示一些严重的错误；critical：仅打印critical级别日志，用于警示一些非常严重的。

服务编排模块：用于将参数收集模块所收集的服务编排参数发送给云管理模块，并将云管理模块生成的服务编排决策发送给边缘集群管理模块，以便对边缘集群内各节点的容器的工作状态进行调节。所述服务编排决策包括边缘集群及对对应的边缘集群所采取的动作，所述服务编排决策的表达式为：

式中，表示请求服务序列中请求i的服务编排决策，/>表示pod实例的集合， 当l＝0时，表示不添加pod实例，当l为正时，表示在边缘集群k内增加类型为l的pod实例，当l为负时，表示在边缘集群k内删除类型为l的pod实例，S表示pod实例类型的总数，/>表示边缘集群的集合，且/>K表示边缘集群的总数。

由于边缘集群是有资源限制的，现实情况下只能在资源允许的范围下部署某些服务的几个实例，因此确定部署哪些服务就很关键。需要在边缘集群中部署最常被使用到的服务，这样延迟敏感的请求才可以有更少的传输时延。通过服务编排决策可以决定将实例部署在哪个工作节点上，还可以对工作节点上的服务进行增加或者删除，以实现尽可能多的LC服务在时间延迟的范围内被执行完成。

请求指派模块：用于将参数收集模块所收集的请求指派参数发送给边缘集群管理模块，并将边缘集群管理模块生成的请求调度决策发送给对应的控制节点或工作节点，所述请求调度决策包括边缘集群及执行请求的该边缘集群的工作节点。原生K8s并不提供请求指派这个功能，只是通过ingress进行简单的负载均衡。所述请求调度决策的表达式为：

式中，表示请求服务序列中请求i的请求调度决策，/>表示边缘集群k中各个节点的集合也即边缘集群k中工作节点和控制节点的集合，该请求调度决策表示请求服务序列中的请求i由边缘集群k的节点j执行。

边缘集群管理模块：用于接收请求发送模块所发送的请求及各边缘集群内的节点状态信息，并基于用户预设的算法容器和请求指派模块发送的请求指派参数生成请求调度决策，将请求调度决策发送给请求指派模块。所述节点状态信息包括节点上的pod类型和个数、节点的CPU和内存资源。边缘集群管理模块基于K8s开发，用于管理边缘集群内的节点和基于用户预设算法部署pod实例，同时负责执行请求指派决策和服务编排决策。另外，边缘集群管理模块还对每个边缘集群处理完成的请求进行计数，当分别处理完成一定数量的请求时，即发送服务编排请求启动服务编排模块，进而通过云管理模块生成新的服务编排决策。

云管理模块：用于接收请求发送模块所发送的请求，并基于用户预设的算法容器和服务编排模块发送的服务编排参数生成服务编排决策，并将服务编排决策发送给服务编排模块。云管理模块同样基于k8s进行开发，负责管理并部署云上的pod实例。

为了使研究人员对于算法的部署更加清晰明了，以下说明如何部署算法：如图3所示，首先，在app.py中完成算法，并且根据自己的算法加入所需的Dockerfile和requirements.txt，制作docker镜像。接着把刚刚的镜像push到k8s使用的镜像仓库中。最后就可以使用yaml文件在k8s集群部署应用，可以使用简单一点的deployment方式来部署。K8s会为每一个pod实例分配ip和端口号，这些信息会被边缘集群管理模块和云管理模块收集，也即用户算法会被打包容器部署在边缘集群管理模块和云管理模块中，此为现有技术，本实施例不再详述。用户可以将各种算法，比如深度强化学习算法、启发式算法等等按照上述方法打包并部署在系统中。本实施例中，不同模块间通信使用了asyncio中的aiohttp，这样可以减少IO操作等待的时间，提高效率并且更加灵活。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (5)

1.一种基于Kubernetes的边缘云集群资源优化的容器化调度系统，其特征在于，包括：

负载生成器模块：用于生成请求服务序列并将请求服务序列发送到边缘集群管理模块和云管理模块；

参数收集模块：用于基于边缘集群管理模块收集的各边缘集群的节点状态信息生成服务编排参数和请求指派参数，并将服务编排参数发送给服务编排模块，将请求指派参数发送给请求指派模块；

边缘集群管理模块：基于接收到的请求服务序列和请求指派参数以及用户预设的算法容器生成请求调度决策，并将请求调度决策发送给请求指派模块；

请求指派模块：用于将参数收集模块收集的请求指派参数发送给边缘集群管理模块，并将接收到的边缘集群管理模块生成的请求调度决策发送给对应的节点；

服务编排模块：将服务编排参数发送给云管理模块，并将云管理模块生成的服务编排决策发送给边缘集群管理模块；

云管理模块：基于接收到的请求服务序列、服务编排参数以及用于用户预设的算法容器生成服务编排决策，并将服务编排决策发送给服务编排模块；

所述服务编排参数包括服务编排周期内边缘集群中每种服务类型请求成功与请求失败的数量、服务编排周期内边缘集群因pod数量不足而被积压的请求的服务类型及请求的数量、每个边缘集群的各工作节点上所部署的pod实例的类型与pod实例的数量、每个边缘集群上各个节点的CPU使用率和内存使用率，所述请求指派参数包括请求序号、每个请求序号所对应的服务类型、各个边缘集群上满足每个请求序号所需服务类型的pod实例的运行状态、每个边缘集群到其它边缘集群之间的传播时延；

所述服务编排决策包括边缘集群及对对应的边缘集群所采取的动作，其表达式为：

式中，表示请求服务序列中请求i的服务编排决策，/>表示pod实例的集合，/> 当l＝0时，表示不添加pod实例，当l为正时，表示在边缘集群k内增加类型为l的pod实例，当l为负时，表示在边缘集群k内删除类型为l的pod实例，S表示pod实例类型的总数，/>表示边缘集群的集合；

所述请求调度决策的表达式为：

式中，表示请求服务序列中请求i的请求调度决策，/>表示边缘集群k的各个节点的集合，该请求调度决策表示请求服务序列中请求i由边缘集群k的工作节点j执行。

2.根据权利要求1所述的基于Kubernetes的边缘云集群资源优化的容器化调度系统，其特征在于，所述请求服务序列满足泊松分布，且请求服务序列基于用户预设的任务产生总时间和各服务类型的请求总数生成。

3.根据权利要求1所述的基于Kubernetes的边缘云集群资源优化的容器化调度系统，其特征在于，所述请求服务序列包括请求序号、服务类型、请求开始时间、请求结束时间、请求数据类型和请求数据内容。

4.根据权利要求1所述的基于Kubernetes的边缘云集群资源优化的容器化调度系统，其特征在于，所述各个边缘集群上满足每个请求序号所需服务类型的pod实例的运行状态的表达式为：

((0,N_i,0,P_i,0),...,(k,N_i,k,P_i,k),...,(K,N_i,K,P_i,K))；

式中，N_i,k表示边缘集群k的各个节点上，请求服务序列中请求i所对应的pod实例的数量，P_i,k表示边缘集群k所拥有的请求i所对应的所有pod实例的CPU使用率和内存使用率，K表示边缘集群的总数；

所述每个边缘集群到其它边缘集群之间的传播时延的表达式为：

((0,T₀),...,(k,T_k),...,(K,T_K))；

式中，T_k表示边缘集群k到其它边缘集群的传播时延的集合，T_k＝{t_k,1,…,t_k,k-1,t_k,k+1,…,t_k,K}，t_k,k+1表示边缘集群k和边缘集群k+1之间的传播时延，T₀表示云到其它边缘集群的传播时延的集合，t_k,k-1示边缘集群k和边缘集群k-1之间的传播时延。

5.根据权利要求1所述的基于Kubernetes的边缘云集群资源优化的容器化调度系统，其特征在于，还包括核心配置模块和日志记录模块，所述核心配置模块用于基于用户的配置文件生成云边协同场景；所述日志记录模块用于输出用户算法容器的运行日志。