基于强化学习的Kubernetes云边协同计算调度算法

doi:10.3785/j.issn.1008-973X.2025.11.019

基于强化学习的Kubernetes云边协同计算调度算法

汤佳伟^,, 郭铁铮, 闻英友^,

1. 东北大学计算机科学与工程学院，辽宁沈阳 110819

2. 东软集团股份有限公司，辽宁沈阳 110179

Reinforcement learning-based scheduling algorithm for cloud-edge collaborative computing on Kubernetes

TANG Jiawei^,, GUO Tiezheng, WEN Yingyou^,

1. School of Computer Science and Engineering, Northeastern University, Shenyang 110819, China

2. Neusoft Group Limited Company, Shenyang 110179, China

通讯作者: 闻英友，男，教授. orcid.org/0000-0002-6659-1785. E-mail: wenyingyou@mail.neu.edu.cn

收稿日期: 2024-10-28

基金资助:

国家自然科学基金资助项目（62172084, 92167103）.

Received: 2024-10-28

Fund supported:

国家自然科学基金资助项目（62172084,92167103）.

作者简介 About authors

汤佳伟（2000—），男，博士生，从事计算机网络和人工智能的研究.orcid.org/0009-0000-0165-4709.E-mail：2301944@stu.neu.edu.cn , E-mail：2301944@stu.neu.edu.cn

摘要

针对云边协同计算在网络资源和计算资源不平衡、任务类型和到达时间不确定的场景中存在资源利用不充分的问题，提出基于强化学习的云边协同计算资源调度算法KNCS. 通过综合考虑网络资源和计算资源的状态，该算法实现了更短的传输时间、处理时间和周转时间. 设计统一的信息传输平台，聚合来自计算节点和各个任务的信息，支持任务依赖关系的定义，根据运行任务的类型动态调整后续任务，提供更真实的任务调度场景. 实验结果表明，在云边协同计算场景下，KNCS算法的性能优于默认的Kubernetes调度算法.

关键词： 云边协同计算 ; 物联网 ; 任务调度 ; 强化学习算法 ; 分布式计算

Abstract

A reinforcement learning-based cloud-edge collaborative computing resource scheduling algorithm, KNCS, was proposed aiming at the problem of insufficient resource utilization in cloud-edge collaborative computing scenarios due to imbalances in network and computational resources, as well as uncertainties in task types and arrival times. This algorithm achieved shorter transmission time, processing time, and turnaround time by comprehensively considering the state of network resource and computational resource. A unified information transmission platform was designed to aggregate information from computational nodes and various tasks, facilitating the definition of task dependencies, dynamically adjusting subsequent tasks based on the type of running tasks, and providing a more realistic task scheduling scenario. The experimental results show that the performance of the KNCS algorithm surpasses that of the default Kubernetes scheduling algorithm in cloud-edge collaborative computing scenario.

Keywords： cloud-edge collaborative computing ; internet of thing ; task scheduling ; reinforcement learning algorithm ; distributed computing

PDF (783KB) 元数据多维度评价相关文章导出 EndNote| Ris| Bibtex 收藏本文

本文引用格式

汤佳伟, 郭铁铮, 闻英友. 基于强化学习的Kubernetes云边协同计算调度算法. 浙江大学学报(工学版)[J], 2025, 59(11): 2400-2408 doi:10.3785/j.issn.1008-973X.2025.11.019

TANG Jiawei, GUO Tiezheng, WEN Yingyou. Reinforcement learning-based scheduling algorithm for cloud-edge collaborative computing on Kubernetes. Journal of Zhejiang University(Engineering Science)[J], 2025, 59(11): 2400-2408 doi:10.3785/j.issn.1008-973X.2025.11.019

物联网设备和应用的快速发展使得大量数据产生于终端设备. 基于传统的云计算模式，这些数据需要通过网络传输到云服务器进行处理，然后返回终端设备. 这种模式不仅消耗大量的网络资源，还增加了任务的延迟^[1-2]. 云边协同计算应运而生，它利用边缘节点和云服务器协同处理数据，将计算资源推近数据源，有效减少了数据传输时间，降低了任务延迟. 这种模式具有低延迟和高传输速率的优势，尤其适用于实时处理或大量数据传输的物联网应用^[3-5]. 采用边缘节点辅助云端处理任务，可以显著缩短响应时间并节约带宽^[6]. 目前，边缘计算已广泛应用于视频处理，随着大语言模型的兴起，相关的语料处理任务值得关注.

尽管Kubernetes为代表的分布式计算管理框架已广泛采用容器化策略，有效解决了边缘环境的异构性问题^[7-8]，但它们并没有对边缘计算环境进行优化. 边缘计算平台是边缘计算范式的关键组成部分^[9]. 例如KubeEdge是基于Kubernetes为边缘计算场景定制的，并针对云边通信和协作进行了优化. KubeEdge虽然实现了简化设备通信、边缘自治、云边协同等功能，但未包含节点间网络带宽资源的管理，因此在网络资源受限的场景下表现不足.

与传统云计算主要关注计算和内存资源不同，云边协同计算须额外关注节点间的网络带宽资源，因为涉及云端节点和边缘节点间的数据传输. 此外，现有研究主要针对确定性任务流程进行编排，对于后续任务不确定性较大的情况，缺乏有效的调度算法.

为了解决上述的挑战，本文提出基于Kubernetes的云边协同计算场景下的网络与计算资源调度算法KNCS. 采用强化学习策略综合考虑网络资源和计算资源的实时状态，在周转时间、执行时间、传输时间等方面都取得了更好的性能. 此外，设计统一的信息收发平台，汇总计算节点和任务信息，支持任务依赖关系的定义. 根据运行任务类别动态调整后续任务，提供更真实的任务调度场景.

1. 相关工作

研究者们提出多种调度算法，以应对不同场景. Cloudnet^[10]是部署于网络边缘的主机，旨在为移动设备提供低延迟计算资源. ENTS^[11] 作为专为协作边缘计算设计的调度系统，通过纳入数据局部性与网络资源因素，提高了视频分析任务的吞吐量. EaaS^[12]是边缘计算框架，可以跨多个维度增强性能，并克服Kubernetes在边缘计算方面的局限性. EdgeTuner^[13]利用强化学习调度策略，加速模型收敛. KCES^[14]是为KubeEdge设计的云边协同工作流调度框架，提出任务水平漫游和垂直卸载算法. MSGA^[15] 通过对数据源位置和网络资源建模，有效缩短了任务完成时间. CWB^[16]与KubeAdaptor^[17]均实现了工作流调度与Kubernetes实际调度顺序的一致性. Tarema^[18]通过实时监控硬件差异，动态分配资源. Medea ^[19] 针对长、短期容器采取不同的调度策略，降低了部署延迟，展现出弹性优势. iTaskOffloading^[20]是针对个性化、细粒度需求的调度算法. 此外，针对虚拟机调度，有大量的研究^[21-23].

Kubernetes 是类似于 Borg ^[24]的集群管理平台，它启发了多种边缘计算解决方案，例如 KubeEdge^[25]、Cloud4IoT^[26] 和 Fledge^[27]. 这些解决方案主要解决边缘计算中的服务编排、资源管理和节点通信，但缺乏边缘计算场景下的任务调度和资源利用率的优化.

深度强化学习在资源调度研究中得到了广泛的应用. Liu等^[28]构建直接从经验中学习的调度决策模型. Mao等^[29]将强化学习应用于资源分配和电源管理. Yi等^[30]采用深度 Q 网络，降低集群功耗和 CPU 温度. Mao等^[31]利用强化学习和神经网络，针对不同任务采用不同的调度策略. 邝祝芳等^[32]在移动边缘计算场景中以最小化延迟和耗能为目标，提出面向多用户的任务调度算法. 周陈静^[33]使用深度强化学习对视频处理任务进行调度，加速了视频处理，降低了系统时延，为实时视频处理提供了解决方案. 张斐斐等^[34]使用深度Q学习算法和组合多臂赌博机的在线学习方法，设计边缘协作计算的任务调度算法，减少了系统的整体开销.

目前，大部分的调度算法设计主要针对多个任务进行编排，无法应用于需要实时调度的任务. Kubernetes的任务调度是实时的，会立即处理到达的任务. Koordinator是基于QoS的Kubernetes混合工作负载调度系统. Koordinator能够简化与资源相关的配置调整的复杂性，增加Pod部署的密度，提高资源利用率，但Koordinator缺少对网络带宽资源的调度.

2. 问题描述及场景建模

在传统的云计算架构中，边缘节点受限于其处理能力，须将获取的数据回传至云服务器进行处理，处理结果再返回边缘节点. 该过程不仅大量占用网络带宽，而且显著增加了任务延迟. 相较而言，边缘计算平台通过协同调度云端与边缘端的网络、计算及内存资源，实现了更高效的任务处理模式. 当某一边缘节点接收到任务数据时，平台会优先评估并利用邻近边缘节点的闲置计算与内存资源. 鉴于边缘节点间的网络通常具备更高的带宽，这种邻近调度策略能够有效地缩减数据传输时间，从而显著地降低任务完成延迟，提升整个系统的吞吐效率.

在云边协同计算场景中，任务到达时仅能获知任务类型、数据大小和位置，而所需的计算与网络资源状态未知且难以精确获取. 传统的调度算法常对资源进行理想化的线性建模，但这与真实环境中任务（尤其是单线程任务）资源利用率不稳定的情况相悖，给应用开发带来挑战. 为了解决该问题，提出新方法，不再对CPU型号、温度、功耗等难以量化的静态参数进行建模，而是通过实时监控节点的CPU与内存利用率来更准确地评估其动态变化的计算能力. 同理，对于网络资源，通过监测节点间的实时传输速率而非使用静态带宽参数，应对网络波动，从而实现对动态变化的云边资源的更高效调度与利用.

下面将云边协同计算的调度问题形式化为强化学习问题. 按照任务到达的顺序，将任务编号为$ i=\mathrm{ }\mathrm{1,2},3,\cdots ,n $，节点的编号为$ j=\mathrm{ }\mathrm{1,2},3,\cdots ,m $，无先后顺序. 任务的输入大小为$ {D}_{i,{\mathrm{in}}} $，任务的数据源位置为$ {S}_{i} $，需要处理的任务类型为$ {P}_{i} $，任务实际使用的计算资源和网络资源为$ {C}_{i,{\mathrm{use}}} $和$ {N}_{i,{\mathrm{use}}} $，N_i表示是否需要将处理后的输出通过网络传输给后续的任务，$ {N}_{i}=\mathrm{0,1} $，0表示不需要传输，1表示需要传输. 节点的CPU利用率为$ {C}_{j} $，内存利用率为$ {M}_{j} $，网络接口实时的上行和下行传输速率为$ {Q}_{j,{\mathrm{up}}} $和$ {Q}_{j,{\mathrm{down}}} $. 任务消耗的计算资源与任务类型和数据量的映射为$ {F}_{\mathrm{c}\mathrm{p}\mathrm{u}} $，任务的计算时间$ {T}_{i,\mathrm{c}\mathrm{o}\mathrm{m}} $和传输时间$ {T}_{i,{\mathrm{trans}}} $为

(1)$ {T}_{i,{\mathrm{com}}}=\frac{{F}_{{\mathrm{cpu}}}\left({P}_{i},{D}_{i,{\mathrm{in}}}\right)}{{C}_{i,{\mathrm{use}}}}, $

(2)$ {T}_{i,{\mathrm{trans}}}=\frac{{D}_{i,{\mathrm{in}}}}{{N}_{i,{\mathrm{use}}}}. $

周转时间$ {T}_{i,{\mathrm{total}}} $为

(3)$ {T}_{i,{\mathrm{total}}}={T}_{i,{\mathrm{com}}}+{T}_{i,{\mathrm{trans}}}. $

式（3）中未涉及任务的等待时间.

所有任务的平均周转时间 $ {T}_{{\mathrm{avg}}} $为

(4)$ {T}_{{\mathrm{avg}}}=\frac{1}{n}\sum _{i=1}^{n}{T}_{i,{\mathrm{total}}}. $

每个任务选择的节点编号$ {J}_{i} $组成的集合为$ J $，目标是做出能使$ {T}_{{\mathrm{avg}}} $取得最小值的调度决策$ {J}^{*} $，

(5)$ {{J}}^{*}=\mathrm{arg}\underset{{J}}{\mathrm{min}}\left(\frac{1}{n}\sum _{i=1}^{n}{T}_{i,\text{total}}\right). $

在进行任务的调度决策过程中，主要包含的因素为任务的类型$ {P}_{i} $、可利用的网络资源$ {N}_{i,{\mathrm{use}}} $、可利用的计算资源$ {C}_{i,{\mathrm{use}}} $. 可利用的网络资源和计算资源是无法直接获得的，因此需要进一步地细分为数据源所在的节点、节点间实时的传输速率、节点CPU和内存的实时利用率. 通过这些信息，可以更加准确地对网络资源和计算资源进行评估，进而得到更优的调度策略.

在该场景中，任务因存在依赖关系而组成一条处理链. 初始任务从数据源获取并处理数据，随后将结果依序传递给下游任务. 例如，视频处理在速度调整后可能需要变更编码，文本处理在分词后需要根据模型输入长度进行分片. 定义$ \mathrm{n}\mathrm{e}\mathrm{x}\mathrm{t}\left(i\right) $为任务i的下一个任务，$ {D}_{i,\mathrm{o}\mathrm{u}\mathrm{t}} $为任务i的输出大小，数据源的大小为$ {D}_{{S}_{i}} $. 任务链的输入输出关系如下：

(6)$ {D}_{i,{\mathrm{in}}}=\left\{\begin{array}{l}{D}_{{\mathrm{pre}}\left(i\right),{\mathrm{out}}},\;i不是链中的第1个任务;\\ {D}_{{S}_{i}},\; i是链中的第1个任务. \end{array}\right. $

当任务$ i $是链中的第1个任务时，输入大小为数据源中的数据大小，反之则为前一个任务的输出大小.

3. 云边协同任务的调度架构

3.1. 统一信息收发平台架构

统一信息收发平台作为任务信息处理的核心，其架构如图1所示. 调度请求首先送达平台，由任务调度模块根据任务属性与节点状态进行处理. 各节点的资源使用情况由信息上报服务负责汇报. 任务部署模块在创建任务时，会检验并随机组合可用的数据源，以满足任务依赖. 任务申请模块按预设间隔申请创建任务，并将其组装成Kubernetes的Job配置，即一次性执行的容器. 任务执行模块负责执行任务，并向平台实时汇报进度，以供统计分析.

图 1

新窗口打开| 下载原图ZIP| 生成PPT

图 1 统一信息收发平台的架构

Fig.1 Architecture of unified information transceiver platform

为了弥补Kubernetes在CPU与内存资源统计上的不足，须通过上报服务动态更新节点的资源使用情况，并统计网络传输速率，以应对带宽分配问题. 为了供强化学习算法学习，须在任务执行中追踪到达、开始、数据传输完成及结束等关键时间点，记录处理后的数据大小.

上述数据的获取途径主要有以下3类. 1）当任务调度请求到达时，直接从Kubernetes获取节点与任务信息. 2）通过在节点部署的汇报服务，持续向统一平台报告节点状态. 3）在任务执行过程中，实时更新任务所处阶段. 通过整合这3类数据，模型能够有效学习并制定相应的边缘计算任务调度决策.

3.2. 边缘计算平台的架构

云边协同计算平台的架构如图2所示. 该云边协同计算平台基于Kubernetes的Master和Worker节点架构，其Master节点上部署了任务部署模块. 平台内设统一的信息收发中心，集中处理所有交互，如调度请求、任务数据及节点信息上报等. 调度请求会通过该中心调用KNCS调度器进行处理，将相关数据存入数据库和经验池.

图 2

新窗口打开| 下载原图ZIP| 生成PPT

图 2 调度系统的架构图

Fig.2 Architecture diagram of scheduling system

4. 基于强化学习的任务调度算法

由于真实环境中采集到的各项参数是动态变化的，同时根据任务和节点的基础信息难以构建到运行时间映射. 采用深度强化学习算法，能够同时解决映射关系复杂和动态变化的问题. DQN算法是目前深度强化学习中应用最广泛的算法之一，它通过神经网络来拟合Q值函数，实现对状态和动作的价值估计. 将场景建模转化为强化学习问题. 将任务的调度请求到达时节点的状态$ {C}_{j} $、$ {Q}_{j,{\mathrm{up}}} $、$ {M}_{j} $以及任务的属性$ {D}_{i,{\mathrm{in}}} $、$ {P}_{i} $、$ {S}_{i} $、$ {N}_{i} $定义为状态$ {S}_{i} $. 将动作空间定义为$ A=\{\mathrm{1,2},3,\cdots ,m\} $，即选择节点的编号. 根据Kubernetes的节点状态和过滤策略不同，可选择的节点会动态变化，因此需要在算法中解决动作空间动态变化的问题. 将选择的动作定义为$ {A}_{i} $，即第$ i $个任务选择的节点编号. 动作获得的奖励为$ {R}_{i} $. 优化目标为最小化任务的平均完成时间$ {T}_{{\mathrm{avg}}} $. 该过程包含了非常多的任务处理链，即初始的任务从默认数据源获得数据，然后处理数据，将数据传输给下一个任务，在下一个任务处理完成后，依次将数据向后传递. 整个过程由多个任务处理链组成，每个任务处理链的任务数量不定，不同链上的任务彼此是无关的，因此无法将任务的整体处理时间进行累加作为奖励，只能将对任务链的平均处理时间作为奖励. 定义$ \mathrm{n}\mathrm{e}\mathrm{x}\mathrm{t}\left(i\right) $为任务$ i $的下一个任务，动作的奖励函数为$ R $. 根据DQN算法的默认奖励累加策略，奖励的计算如下：

(7)$ R\left({S}_{i},{A}_{i}\right)=\left\{\begin{array}{c}-{T}_{i,{\mathrm{total}}}+ \gamma {\mathrm{max}}_{{A}'}R\left({S}_{{\mathrm{next}}\left(i\right)},{A}'\right),{N}_{i}=1;\\ -{T}_{i,{\mathrm{total}}},{N}_{i}=0.\end{array}\right. $

由于任务链的长度是无法提前预测的，而传统的累加奖励函数使得奖励与任务链的长度线性相关，任务链的长度会对奖励的累计造成非常大的波动，式（7）的奖励函数无法被预测. 为了解决该问题，该算法将奖励的计算方式从累加改为指数滑动平均，如下所示：

(8)$\begin{split} & R\left({S}_{i},{A}_{i}\right)=\\&\left\{\begin{array}{c}-\alpha {T}_{i,{\mathrm{total}}}+ {\left(1-\alpha \right)\mathrm{max}}_{{A}'}R\left({S}_{{\mathrm{next}}\left(i\right)},{A}'\right),{N}_{i}=1;\\ -{T}_{i,{\mathrm{total}}},{N}_{i}=0.\end{array}\right.\end{split} $

式中：$ \alpha $为滑动平均的系数，对应的奖励将变为接下来数个任务周转时间的指数滑动平均值. 在任务链的长度波动较小的情况下，可以适当缩小$ \mathrm{\alpha } $，此时模型将更倾向于当前决策对后续任务的优化，以尽可能实现整个任务链的平均周转时间最小. 当任务链的长度波动较大时，可以适当增大$ \mathrm{\alpha } $，此时模型将更倾向于对当前任务的优化，以避免任务链长度的波动对平均值估计的影响. 这样可以使得奖励的计算更好地适应任务链长度的变化.

KNCS的调度决策算法如算法1所示.

算法1　KNCS调度算法
输入：随机概率ε、动作空间A
1.　首次运行时初始化经验池$ E $和神经网络参数$ {\theta }_{{\mathrm{policy}}} $
2.　接收调度请求
3.　以ε的概率随机选择动作$ {A}_{i} $
4.　否则选择$ {A}_{i}={\mathrm{argma}}{{\mathrm{x}}}_{{A}_{i}}Q\left({S}_{i},{A}_{i},{\theta }_{{\mathrm{policy}}}\right) $
5.　调度决策J$ \leftarrow {A}_{i} $
6.　更新经验池$ E $
输出：调度决策J

在首次执行时，初始化经验池和神经网络参数. 根据任务的属性和节点的状态，计算动作空间内不同动作的Q值，Q值的预测目标与式（8）相同，为任务链上当前与后续任务周转时间的加权平均值. 根据Q值，在目前的动作空间内选择动作. 在实际调度环境中，由于节点会因资源耗尽、与主节点断开连接、状态发生改变等原因，在过滤阶段被排除，可供调度的节点集合随之实时变化，进而构成动态的动作空间. 根据选择的动作将任务调度到对应的节点并统计任务的消耗的总时间，更新数据库. 将状态出现的时刻定义为调度请求到达的时刻，虽然任务已经完成，但是动作的下一个状态还没有出现，因此无法计算目标Q值. 反之，若当前完成的任务依赖于其他任务的输出，则前一个任务的状态此时是已知的，可以将此整体放入经验池中. 若当前任务的输出不再作为后续任务的输入，即$ {N}_{i}=0 $，则直接将当前任务放入经验池，且$ {Q}_{{\mathrm{target}}} $为$ -{T}_{i,{\mathrm{total}}} $.

KNCS的训练算法如算法2所示. 初始化经验池和神经网络参数. 当有新的经验被加入经验池且经验池中包含的样本数量大于训练所需的批量大小时，从经验池中随机抽取一定数量的经验，计算目标Q值$ {Q}_{\mathrm{ta}\mathrm{r}\mathrm{g}\mathrm{e}\mathrm{t}} $. 在$ {Q}_{\mathrm{t}\mathrm{a}\mathrm{r}\mathrm{g}\mathrm{e}\mathrm{t}}\mathrm{的} $计算过程中，涉及的动作空间取当前样本实际可用的动作空间，根据式（8）定义的计算方法，按照任务的输出是否继续作为后续任务的输入，选择相应的计算方式. 根据目标Q值和当前Q值的差异，更新神经网络的参数. 在策略网络更新训练一定步数后，将策略网络与目标网络的参数进行更新同步. 策略网络和目标网络的权重更新采用指数滑动平均的方式，对网络的对应参数进行操作.

虽然KNCS算法基于Kubernetes进行设计，但仅通过API与Kubernetes进行交互. 任务和节点信息的采集能够脱离Kubernetes执行，因此KNCS算法具备迁移到其他边缘计算平台的能力.

算法2　KNCS训练算法
输入：经验池$ E $、衰减系数$ \alpha $
1.　初始化策略网络和目标网络参数$ {\theta }_{{\mathrm{policy}}} $、$ {\theta }_{{\mathrm{target}}} $
2.　for 每一次训练迭代 do
3.　　从 $ E $ 中抽取一批经验
4.　　if $ {N}_{i}==1 $ then
5.　　　将$ \left({S}_{i},{A}_{i},{R}_{i},{S}_{{\mathrm{next}}\left(i\right)}\right) $添加到经验池$ E $
6.　　　$ {Q}_{{\mathrm{target}}}\leftarrow -{T}_{i,{\mathrm{total}}} $
7.　　else
8.　　　 $ {Q}_{{\mathrm{target}}}\leftarrow \left(1-\alpha \right){\mathrm{ma}}{{\mathrm{x}}}_{{A}'}Q\left({S}_{{\mathrm{next}}\left(i\right)},{A}',{\theta }_{{\mathrm{target}}}\right)-\alpha {T}_{i,{\mathrm{total}}} $
9.　　end if
10.　　$ {Q}_{{\mathrm{policy}}}\leftarrow Q\left({S}_{i},{A}_{i},{\theta }_{{\mathrm{policy}}}\right) $
11.　　使用损失函数 $ L={\left({Q}_{{\mathrm{target}}}-{Q}_{{\mathrm{policy}}}\right)}^{2} $ 更新 $ {\theta }_{{\mathrm{policy}}} $
12.　　每 $ N $ 次迭代使用指数移动平均值更新 $ {\theta }_{{\mathrm{target}}} $
13.　end for
输出：迭代后的网络权重$ {\theta }_{\mathrm{p}\mathrm{o}\mathrm{l}\mathrm{i}\mathrm{c}\mathrm{y}} $

5. 实验环境与基线算法

5.1. 实验环境

云边协同场景中受限的计算与网络资源使得任务调度变得复杂^[35]. 鉴于大语言模型在边缘计算领域的兴起，选取典型的视频与文本语料处理任务，验证提出的调度方法的有效性.

实验采用FFmpeg模拟视频处理，通过设计包含编码转换、速度调整、分辨率变更等12种策略，并组合不同大小与位置的视频源，体现任务与数据的多样性. 在文本处理方面，实验准备了预训练纯文本语料和微调指令对话语料，将其切分并置于不同边缘节点. 设计格式处理、分词和数据分片这3大类共7种任务，其中分词任务对计算资源的消耗最大.

如图3、4所示，本次实验的网络拓扑将node-1设为云节点，其余为边缘节点. 其中，同一方格表示节点位于相同区域，享有较高的内部网络带宽（由方框下方数值标示），而连线表示跨区域的网络带宽（由连线上数值标示）. 所有节点与云节点的通信速率均相同. 实验采用Linux流量控制工具TC调整节点间的带宽，使用Socat进行数据传输. 详细的设备配置如下：操作系统为Windows11，虚拟化软件为VMware Workstation Pro 17，CPU为Intel(R) Core(TM) i9-12900KF，内存为32 GB. 节点配置见表1. 其中，N为CPU核数，M为内存.

图 3

新窗口打开| 下载原图ZIP| 生成PPT

图 3 视频处理任务节点网络拓扑的示意图

Fig.3 Schematic diagram of network topology of video processing task nodes

图 4

新窗口打开| 下载原图ZIP| 生成PPT

图 4 语料处理任务节点网络拓扑的示意图

Fig.4 Schematic diagram of network topology of corpus processing task nodes

表 1 虚拟化节点的配置

Tab.1 Configuration of virtualized node

节点	N	M/GB
node1	4	8
node2-node4	2	2
node5-node10	1	2

新窗口打开| 下载CSV

5.2. 对比算法

将Kubernetes默认调度器及第三方调度器Koordinator作为对比，评估KNCS调度算法的性能. Kubernetes的调度包含过滤和优选2个核心阶段. 提出的KNCS算法仅改进了优选阶段，保证了对Kubernetes其他功能的兼容性.

实验的性能评估涵盖5个主要指标：周转时间、等待时间、传输时间、处理时间和任务链耗时. 周转时间指从任务提交至完成的总时长，等待时间主要包含调度请求处理和容器启动耗时，传输时间为数据传输耗时，处理时间为数据处理耗时. 将任务链耗时定义为各任务周转时间之和，以规避任务间随机到达间隔对评估造成的影响.

5.3. 参数设置

算法的参数配置如表2所示，其中指数滑动平均系数有2个，分别用于奖励函数的计算及网络参数的更新. 仿真实验的参数配置如下：视频处理任务间隔平均值为10 s，视频处理任务间隔标准差为1 s，语料处理任务间隔平均值为40 s，语料处理任务间隔标准差为5 s。

表 2 KNCS算法参数的配置

Tab.2 Configuration of KNCS algorithm parameter

参数	数值
训练批量大小	128
指数滑动平均系数(奖励衰减系数)	0.9
起始随机概率	1.0
最小随机概率	0.05
学习率	10⁻³
指数滑动平均系数(参数更新)	0.6

新窗口打开| 下载CSV

6. 实验结果

在视频处理任务中开展1 000次实验，在语料处理任务中开展500次实验. 如表3、4所示为平均性能的对比，如图5、6所示为各项指标在概率分布上的对比，如表5所示为任务链平均时间的对比. 其中，T_w为平均等待时间，CDF为累积概率分布函数，T_i,w为任务i的等待时间.

表 3 算法在视频处理任务中的平均性能对比

Tab.3 Comparison of average performance of algorithm in video processing task

算法	T_avg/s	T_w/s	T_trans/s	T_com/s
KNCS	133.62	1.56	117.38	16.24
默认算法	187.25	1.27	169.36	17.89
Koord	175.89	1.26	158.85	17.03

新窗口打开| 下载CSV

表 4 算法在语料处理任务的平均性能对比

Tab.4 Comparison of average performance of algorithm in corpus processing task

算法	T_avg/s	T_w/s	T_trans/s	T_com/s
KNCS	209.16	1.61	135.79	73.38
默认算法	316.13	1.41	240.87	75.27
Koord	270.63	1.41	193.04	77.59

新窗口打开| 下载CSV

图 5

新窗口打开| 下载原图ZIP| 生成PPT

图 5 视频处理任务中各项指标的概率分布对比

Fig.5 Comparison of probability distribution of various indicator in video processing task

图 6

新窗口打开| 下载原图ZIP| 生成PPT

图 6 语料处理任务中各项指标的概率分布对比

Fig.6 Comparison of probability distribution of various indicator in corpus processing task

表 5 任务链平均耗时的对比

Tab.5 Comparison of average time spent on task chain

算法	T_avg/s
算法	视频处理任务链	语料处理任务链
KNCS	380.82	513.42
默认算法	548.65	795.89
Koord	503.22	688.65

新窗口打开| 下载CSV

由于任务链的随机性，难以对任务链的相关时间进行有效比较，主要针对单个任务分析. 在任务链平均耗时的分析中，为了确保结果的可靠性并避免样本偏差，将任务链的生成限制为从5种固定任务链中随机抽取. 该实验引入基于网格的超参数搜索，将奖励衰减系数调整为0.85.

语料处理任务的数据量与资源需求更高，因此分配了更高的网络带宽和更大的任务到达间隔.

对于数据密集型任务，应在数据源或邻近节点执行本地化计算，以降低传输开销，从而优化任务周转时间. 相对地，对于计算密集型任务，将其调度至算力资源充足的节点，则能够通过最小化处理延迟来有效缩短周转时间.

对调度算法的平均性能进行分析. 在平均传输时间上，KNCS算法对任务进行了更加合理的调度，有效降低了任务的平均传输时间，较默认调度算法降低了30.7%和43.6%，较Koordinator算法降低了26.1%和29.6%. 在语料处理任务中，网络带宽资源的差异更大，将数据在数据源或数据源附近处理，会产生更大的收益，因此传输时间缩短的比例更高.

在节点的计算资源耗尽之前，任务的处理时间不会发生显著变化，而实验中节点计算资源耗尽的情况出现较少，因此在平均处理时间上，KNCS算法较默认算法仅降低了9.2%和2.5%，较Koordinator算法降低了4.6%和5.4%.

在平均等待时间上，相比于默认算法和Koordinator，KNCS有了小幅度的增长，分别是22.8%和14.1%. 分析调度接口日志可知，KNCS调度算法所增加的时间开销并非源于其决策过程本身. 该算法为了实现任务平均传输时间与平均处理时间的平衡，在某些情况下会将任务调度至计算资源已耗尽的节点，以期获得更优的整体周转时间. 在资源耗尽的节点上，容器启动时间会显著延长. 在视频处理这类高任务到达频率的场景中，节点资源耗尽的现象更普遍，导致KNCS算法下的任务等待时间增幅尤为明显. 尽管如此，鉴于等待时间在任务总周转时间中的占比仅约为1%，等待时间对整体的影响可以忽略不计.

综上所述，KNCS算法有效地平衡了任务的传输时间、处理时间及等待时间，有效地缩短了任务的平均周转时间，较默认调度算法缩短了28.6%和33.8%，较Koordinator降低了24.0%和29.6%.

在相关指标的累积概率分布上，KNCS调度算法在周转时间、处理时间和传输时间上几乎始终处在领先地位. 其中传输时间的第80百分位数上，KNCS算法的领先优势非常明显，仅在视频处理任务处理时间60 s之后的位置及语料处理任务处理时间20 s附近的位置呈现了轻微的劣势. 由于不同数据源的数据大小不同，在累计概率分布上呈现出一定程度的阶梯性.

在视频处理和语料处理任务链的平均耗时上，KNCS算法较默认调度算法降低了30.6%和35.5%，较Koordinator算法降低了24.3%和25.4%. 因超参数搜索的加入，KNCS算法的性能在平均周转时间上的表现具有更加明显的优势.

7. 结　语

本文提出基于Kubernetes的云边协同计算调度算法KNCS，解决了在云边协同计算计算场景中网络带宽和计算资源的不均衡问题. 后续到达的任务存在随机性导致资源调度存在困难的问题. KNCS算法引入深度强化学习模型，在任务调度决策时考虑当前任务和后续任务的处理时间，显著降低了任务的平均周转时间、平均传输时间及任务链平均耗时，小幅度减少了任务的平均处理时间. 实验结果表明，KNCS算法在解决云边协同计算问题中具有更好的性能.

参考文献

原文顺序

文献年度倒序

文中引用次数倒序

被引期刊影响因子

[1]

王凌, 吴楚格, 范文慧, 等

边缘计算资源分配与任务调度优化综述

[J]. 系统仿真学报, 2021, 33 (3): 509- 520