随着人工智能的快速发展和普及, 越来越多的用户希望通过人工智能相关服务来提升工作效率和质量, 然而随着人工智能服务应用数量的飞速增加, 如何进行合理的服务应用调度来充分利用服务器资源和简化平台的运维流程成为一个摆在企业级软件面前的现实问题. 美亚柏科作为深耕公安大数据领域的龙头企业, 承建全国超三分之一的省级公安大数据平台, 急需研发适配自身业务需求的AI调度引擎平台对图片取证、票据信息提取、图片敏感信息识别等服务应用进行合理调度和运维.

近年来, 云计算中的容器化技术和容器编排技术发展迅速, 特别是以Docker为代表的容器化已逐渐取代传统使用虚拟机进行操作系统级别的虚拟, 成为虚拟化技术中新的代表技术^[1]. 容器通过将物理机器或裸机划分为数百个容器将资源虚拟化^[2], 实现了进程隔离和资源限制. 然而, 随着容器数量的快速增长, 容器化平台的运营和管理复杂性必然会急剧上升, 因此, 与容器化技术对应的容器编排技术也得到了逐步提高, 特别是谷歌于2014年开源的Kubernetes可以承载以微服务为中心的应用程序, 可用于自动化部署、操作和扩展容器应用程序^[3], 是一个完备的分布式系统支持平台, 具有超强集群管理能力^[4], 已成为容器管理领域的事实标准^[1], VMware发布的《The State of Kubernetes 2022》^[5]指出99%的受访者已经从部署Kubernetes中获益, 最大的两个好处是提高资源利用率和简化应用程序升级和维护. 因此, 基于Kubernetes改进人工智能开发应用中的容器调度和服务管理具有较强的研究价值和可行性.

国内外学者对Kubernetes在人工智能领域的应用做了许多研究. Wu等人^[6]针对大规模人工智能训练中出现的资源利率低, 机器负载分布不均匀的问题, 引入Kubernetes实现自动化应用程序的部署、扩展和操作, 极大程度简化了应用的配置流程, 减少了系统的运维成本. Menouer^[7]在容器调度策略中综合考虑节点的CPU利用率、内存利用率、磁盘利用率、功耗、容器数量和传输时间6个指标来选择最佳调度节点. Chang等人^[8]通过节点资源利用率和应用程序QoS指标决定资源的动态分发. 文献[9-11]针对Kubernetes未能实现对GPU资源的访问, 引入NVIDIA device plugin插件将GPU作为扩展资源进行访问. Yeh等人^[12]设计的KubeShare扩展了Kubernetes以支持GPU共享和细粒度分配. 文献[13, 14]利用K-均值和皮尔逊相关系数等聚类思想将虚拟机放置于与其资源互补的物理节点上, 充分利用了节点资源. 但是其仍只考虑节点中的CPU和内存两种资源, 未考虑GPU资源的使用情况, 使得该算法不适用于人工智能等需要GPU资源的业务中.

通过上述研究, 针对企业在容器调度过程中遇到的困难, 本文提出了一种基于Kubernetes实现的AI调度引擎平台解决方案, 该平台通过device plugin实现对GPU资源的感知和调度; 同时研究了AI调度引擎平台的运行流程和实现细节, 实现了AI服务构建的全流程管理; 最后在李想和黄纬等人的基础上完善了基于皮尔逊相关系数的优选策略, 综合节点上GPU资源的使用情况决定调度结果, 成功减少了服务器中资源碎片的产生, 提高了调度平台的整体性能和节点的资源均衡性.

1 Kubernetes架构^[15]

Kubernetes (k8s)是一个容器编排平台, 用于容器调度、自动化部署、管理和扩展容器化应用. 如今, k8s和更广泛的容器生态系统逐渐融合, 正在形成一个通用的计算平台和生态系统, 为企业提供高生产力的平台即服务 (PaaS), 解决围绕云原生开发、基础架构和运维相关的多个任务及问题^[16]. Kubernetes的集群由Master节点和Node节点构成, 其结构如图1所示.

Master节点负责整个集群的管理和控制, 是k8s中的集群控制节点. k8s的所有控制命令都将发送到Master节点, 由它负责具体的执行过程. Master节点上运行着API Server, controller manager, scheduler, ETCD等组件. 其中scheduler是Kubernetes的调度器, 会根据特定的调度算法和调度策略将Pod调度到合适的Node节点上去.

Node节点是k8s集群中的工作负载节点, 每个Node都会被Master分配一些工作负载, 当某个Node节点故障时, 其上的工作负载会被Master自动转移到其他节点上去. Node节点维护着运行的Pod并提供Kubernetes运行时环境, 运行着kubelet, kube-proxy等组件.

2 AI调度引擎平台设计 2.1 模块设计

该平台围绕AI镜像的封装和调度, 将AI模型以镜像的形式部署到Kubernetes所管理的平台中并新建Pod, 然后对Pod配置接口地址等信息, 以服务的形式供外部用户使用, 最后对服务进行安全管控, 防止恶意请求.

经过对平台的需求分析, 为了保证各模块之间符合低耦合高内聚的要求, 将整个平台分为算子模块、算子实例模块、服务模块和安全管控模块, 各模块之间的交互关系如图2所示.

该AI调度引擎平台的模块主要有:

(1)算子模块: 算子是具备例如AI能力、逻辑运算、数据接入、数据输出等功能的数据处理逻辑单元. 用户通过为算子绑定相关AI模型镜像使其具备对应的AI能力. 该模块可以实现算子的新增、上线、下线等操作.

(2)算子实例模块: 算子实例是在算子的基础上设置实例名称和副本数. 该模块可以实现算子实例的上线、下线、扩缩容等操作. 算子实例的上线即向Kubernetes的API Server发送请求创建deployment, 然后由deployment创建和管理Pod, 并将Pod调度到合理的工作节点上运行.

(3)服务模块: 当Pod调度到工作节点后, AI应用便已部署到服务器上并分配所需资源, 但此时外部用户并不能简易的访问该AI应用, 可以先在算子实例的基础上进行对应的配置构成服务, 用户通过服务调度对应的AI能力.

(4)安全管控: 安全管控模块可对服务模块构建的服务提供多维的请求控制, 如支持流量控制、黑白名单、中断控制等功能, 保证系统的安全性和稳定性.

2.2 AI调度引擎平台架构实现

在该调度平台中, 资源对象主要为Pod、deployment、service这3类, 三者构成了该平台的具体架构, 如图3所示.

架构最底层的Pod承载有容器镜像, 挂载了对应的AI模型镜像文件, 并运行着对应的程序, 是Kubernetes中执行功能的最基本单位, 对应于该平台中的算子. 在本平台中, 一个Pod可以包含一个或多个容器, 以便将多个紧耦合的应用容器作为一个实体来管理, 并为每个容器设置应用存活探针和应用业务探针定时检测容器是否启动完成和是否处于就绪状态.

每个Pod都运行着给定应用程序的单个实例, 若想水平扩展应用程序则会带来较多的运维成本, 本平台只需在算子实例模块为Pod设置副本数量, 即可通过deployment控制器实现对服务的扩缩容, 避免了运维人员的繁琐操作.

Service对象实现了对Pod的代理, 保证了客户端请求时, 上游服务不受Pod的变动而影响. 为了使service对集群外的用户提供服务, 将其类型设置为NodePort, 这样, service就定义了一个服务的访问入口地址, 用户的服务请求通过这个入口地址访问其背后的一组由Pod副本组成的集群实例, 并负载均衡到后端的各个容器应用上.

该平台架构中的每台服务器都会作为Node节点提供底层的物理机计算资源. 每个Pod创建后会根据Kubernetes的预选和优选算法将其调度到某个Node节点上.

2.3 Kubernetes实现对GPU资源管理

GPU作为一种最初专门针对图形计算而设计的处理器, 逐渐被设计成专门做类似运算的处理器, 现在也广泛应用于人工智能中以加速AI计算. 然而Kubernetes本地识别和分配的计算资源只有CPU和内存^[12], 未能实现对GPU资源的感知和调度, 因此本平台利用Kubernetes热插拔的特性, 通过插件扩展的机制来访问和管理GPU资源, 使Kubernetes可根据用户的GPU请求来决定Pod的调度结果并为其分配所需资源, 扩展了其应用场景.

本平台通过device plugin使Kubernetes根据约束将Pod正确调度到具有GPU资源的节点上, 并实现后续的资源分配, 但是目前Kubernetes仅支持卡级别的调度, 即用户Pod可以申请独占一张或者多张GPU卡^[17]. 用户只需在平台中的算子模块为容器组中的每个容器设置GPU卡数, 便会通过生成的YAML文件向系统申请对应数量的GPU资源, 无需再通过命令行进行申请, 降低了平台使用门槛. Device plugin与Kubernetes交互机制如图4所示.

当Pod需要使用GPU资源时, 其工作流程如下.

(1) Device plugin以容器的方式运行在节点上, 通过gRPC协议向kubelet内部集成的device manager发起注册请求.

(2) Kubelet将设备数量和Node状态上报到API Server, 以便后续调度器根据这些信息进行调度.

(3) Kubelet会建立一个到device plugin的ListAndWatch 长链接来发现该Node上GPU设备的ID和健康状态, 当某个设备不健康时会主动通知kubelet, 并将这个设备从可调度的GPU列表中移除.

(4)当Pod需要申请一个GPU资源时, 只需在Pod的limits字段声明: nvidia.com/gpu: 1, Kubernetes的调度器便会寻找GPU数量满足条件的Node, 完成Pod与Node的绑定.

(5)当kubelet发现调度成功的Pod请求GPU资源时, kubelet就会向device plugin发起allocate请求为Pod分配GPU资源.

3 AI调度引擎平台的运行 3.1 算子的创建

在实现调度平台模块功能的过程中, 首先需要结合实际业务场景从镜像仓库中选择对应的镜像, 然后在镜像的基础上设置所需的计算资源、启动命令等封装为容器组, 最后设置算子的基础信息即可完成模型算子的构建; 考虑到平台实际应用中可能调用第三方的AI镜像实现既定功能, 因此该模块也可以通过URL使用第三方的容器镜像完成三方算子的构建. 算子创建后即可向Kubernetes的API Server发起请求创建Pod. 创建算子的流程如图5所示.

3.2 算子实例的构建和调度流程

当算子创建完成后, 即可向Kubernetes的API Server请求创建Pod并调度到合适的节点上运行. 为了提高系统的可用性, 平台并不直接创建Pod, 而是按照前文图3所示结构通过deployment实现Pod的创建, 并设置对应Pod的副本数构成算子实例, 算子实例对应Kubernetes中的deployment.

当算子实例创建并完成调度后, 集群会根据deployment设置的约束生成相应数量的Pod供用户调用. 然而, 此时Pod的IP是不固定的, 当Pod重启后IP等状态信息可能会变动, 因此需要按照图3所示构建service, 外部请求通过service负载均衡到Pod.

由于Kubernetes原生不支持对GPU等异构资源的访问, 而AI应用往往需要GPU资源进行计算, 因此需要为平台引入device plugin, 使Kubernetes实现将服务调度到多节点的GPU上. 当用户请求创建Pod时, kubelet会根据YAML文件向API Server发送一个请求命令, 然后待创建的Pod会被放入到一个FIFO队列中. 调度器scheduler每次从这个队列中取出一个Pod, 根据相应的预选算法过滤掉不满足条件的节点, 然后对预选出来的节点根据优选算法进行打分, 将Pod与最优节点进行绑定完成调度. 调度流程如图6所示. 调度算法作为调度平台的核心, 合理的调度策略和算法, 可以提升集群的资源使用率, 减少资源的浪费, 提升集群运行的稳定性和效率^[18].

3.3 服务创建与安全管控

当Pod完成调度后, 绑定的Node节点便已为其分配所需的各种资源. 但直接通过Pod或service调用对应的AI能力仍需一定的技术门槛且操作繁琐, 这对普通用户来说是不现实的. 服务创建模块实现了通过选择算子来创建对应的AI服务, 并选择协议类型和认证方式, 然后设置接口地址、连接超时时间等配置, 最后为服务设置服务描述等基本信息, 形成服务接口供用户调用. 用户可通过已创建的服务接口直接使用对应的AI能力.

当服务构建完成后, 为防止过量请求对服务器造成危害, 可对服务的访问请求设置多维度的访问控制, 平台共实现4种请求管控类型, 分别是请求管控、流量管控、中断管控、黑白名单管控, 各类安全管控的功能描述如表1所示.

4 AI调度引擎平台的调度算法优化 4.1 Kubernetes默认调度策略

Scheduler作为Kubernetes的集群调度器, 它根据用户创建的Pod请求为Pod找到一个合适的节点并运行在其上^[19]. 前文中提到, Pod在调度过程中需要经过预选策略和优选策略后与最优节点进行绑定.

预选是根据用户提交的YAML文件, 遍历集群中的Node节点, 过滤掉不符合用户定义要求的节点. 优选过程则是为通过预选的Node节点进行打分, 选出评分最高的Node节点与Pod绑定. Scheduler默认采用的优选算法为LeastRequestedPriority算法和BalanceResourceAllocation算法. LeastRequestedPriority算法的目标是在通过预选的Node节点上选取一个资源 (内存和CPU)占比最小的节点, 其计算公式为:

$ \begin{split} score = &\frac{{\left( {{{cpu}}NodeCap - sum\left( {cpuPod{Re} q} \right)} \right) \times 10}}{{2 \times cpuNodeCap}} \\ & + \frac{{\left( {memoryNodeCap - sum\left( {memoryPod{Re} q} \right)} \right) \times 10}}{{2 \times memoryNodeCap}} \end{split} $

(1)

其中, cpuNodeCap和memoryNodeCap分别表示节点可分配的CPU和内存, cpuPodReq和memoryPodReq分别表示待调度Pod的CPU和内存的请求量.

BalanceResourceAllocation算法的目标是挑选CPU和内存使用率更加接近的节点, 该算法平衡了节点各种资源使用率的均衡性. 其计算公式为:

$ score = 10 - \left| {\frac{{cpuPod{Re} q}}{{cpuNodeCap}} - \frac{{memoryPod{Re} q}}{{memoryNodeCap}}} \right| \times 10 $

(2)

4.2 基于皮尔逊相关系数的优选调度算法

在一个拥有多种资源的系统中往往需要面对资源平均分配的问题, 每个用户对每个资源都有不同的需求, 如果某一节点上某种资源接近满载, 而其他资源使用率却很低, 就会导致利用率低的资源由于该节点无法调度Pod而被浪费掉. 上述Kubernetes采取的默认优选算法虽然在一定程度上维护了Node节点资源使用率的均衡, 但是也存在两处不足: (1) BalanceResourceAllocation算法仅通过CPU和内存使用率的差值来判定节点的资源均衡性, 该算法相对比较简单, 不能较好的衡量节点资源使用率的均衡性. 且该算法不能满足不同类型应用对资源需求的差异, 如内存敏感型应用对内存的需求较高, 从而造成资源碎片浪费节点资源; (2)默认调度算法只考虑了CPU和内存两种资源指标, 无法满足各异的应用需求^[20]. 而本文所实现的AI调度引擎平台应用于人工智能领域, 默认调度算法无法满足平台的业务需求.

针对以上两点不足, 为改进默认调度算法存在的缺点, 本文基于皮尔逊相关系数实现了新的优选调度算法, 与默认算法相比显著提高了集群中各节点资源使用率的均衡度. 此外该算法将GPU使用情况纳入Pod调度的影响因素, 从而满足人工智能等业务的应用需求.

该改进算法的设计思路是通过皮尔逊相关系数法计算Pod资源请求量与各Node节点资源使用率的相关性, 由于具有负相关性的虚拟机与物理节点之间一般具有更多的资源互补^[14], 从而由相关性计算出每一个待调度的Pod与Node节点之间的互补度, 互补度越高表示Pod越合适调度到该Node节点上.

本文在量化资源需求时, 将考虑节点的CPU、内存、GPU这3个指标, 每一个Pod的资源请求量的特征矩阵表示如下:

$ {p_i} = \left( {{r_{i1}}, {r_{i2}}, {r_{i3}}} \right) $

(3)

其中, p_i表示第i个Pod资源需求特征矩阵, r_i1表示的是该Pod的CPU请求量, r_i2表示的是该Pod的内存请求量, r_i3表示的是该Pod的GPU请求量.

集群中每一个Node节点的资源利用率也将从CPU、内存、GPU这3个指标考虑, 其特征矩阵如下:

$ {n_j} = \left( {{d_{j1}}, {d_{j2}}, {d_{j3}}} \right) $

(4)

其中, n_j表示第j个Node节点资源利用率的特征矩阵, d_j1表示该节点的CPU使用率, d_j2表示该节点的内存使用率, d_j3表示该节点的GPU利用率.

然后通过皮尔逊相关系数法来计算Pod资源请求量与集群中各节点资源使用率的相关性, 其计算公式如下所示:

$ \begin{split} {\rho _{i, j}} &= \frac{{{cov} \left( {{p_i}, {n_j}} \right)}}{{{\sigma _{{p_i}}}{\sigma _{{n_j}}}}} \\ & = \frac{{\displaystyle\sum\limits_{{\textit{k = }}1}^3 {\left( {{p_{ik}} - \overline {{p_i}} } \right)\left( {{{\textit{n}}_{{\textit{j}}k}} - \overline {{{\textit{n}}_{\textit{j}}}} } \right)} }}{{\sqrt {\displaystyle\sum\limits_{{\textit{k = }}1}^3 {{{\left( {{p_{ik}} - \overline {{p_i}} } \right)}^2}} } \sqrt {\displaystyle\sum\limits_{{\textit{k = }}1}^3 {{{\left( {{{\textit{n}}_{{\textit{j}}k}} - \overline {{{\textit{n}}_{\textit{j}}}} } \right)}^2}} } }} \end{split} $

(5)

其中, ρ_i,j表示第i个Pod和第j个Node节点的相似度, 其值为Pod资源请求量与Node节点资源使用率两个变量之间协方差和标准差乘积的比值. 其值介于−1与1之间. 其值越大表明Pod和Node节点的相关性越高, 值越低表明相关性越低, 值为正数表示正相关, 负数表示负相关. ${{{\bar p}}_{{i}}}$ 表示第i个Pod各维度资源请求量的平均值, ${{{\overline n}}_{j}}$ 表示第j个Node节点各维度资源使用率的平均值, 其计算公式如下:

$ \overline{{p}}_{{i}}=\frac{1}{3} \sum_{k=1}^{3} p_{ik} $

(6)

$ \bar{n}_{j}=\frac{1}{3} \sum_{k=1}^{3} {p}_{jk} $

(7)

通过式(5)计算出Pod与每一个Node节点间的相似度, 最终使用式(8)来表示每一个待调度Pod与集群中所以Node节点之间的互补度.

$ com{p_{i, j}} = \left( {1 - \left| {{\rho _{i, j}}} \right|} \right) \times 10 $

(8)

其中, comp_i,j表示第i个Pod和第j个Node节点间的互补度, 其值越大说明第i个Pod的资源请求量与第j个Node节点的资源越互补, 从而使调度后的Node节点各维度资源越均衡, 因此从维护节点资源均衡度的角度看, Pod更适合调度到该Node节点上.

本文实现的基于皮尔逊相关系数的优选调度算法是将待调度Pod调度到与其资源互补度最大的Node节点上, 从而保证集群中节点各种资源的均衡度. 同时实现了对GPU资源的感知和使用, 使得该算法可应用于人工智能等业务场景. 改进后的scheduler调度器执行流程如图7所示.

5 实验结果与分析 5.1 测试环境

本平台是在3台采用Kubernetes 1.18.0的服务器上进行应用部署和调度实验, 3台服务器上均安装有Docker 18.09.7、NVIDIA docker 2、NVIDIA device plugin. 1台服务器作为Master节点, 另外2台服务器作为Node节点, 为充分利用Master节点资源, 将其设置成Pod可调度型, 即Pod也可分配到Master节点并运行. 3台服务器的配置如表2所示.

5.2 实验设计

为了验证本文提出的基于皮尔逊相关系数改进的优选调度算法的可行性和有效性, 实验共设置4次对照实验, 每次实验设置一个实验组和对照组, 实验组和对照组均创建6个资源需求完全相同的Pod. 对照组采用Kubernetes默认的优选算法, 实验组的优选算法采用上述的皮尔逊相关系数算法 (PCC). 为了检测不同场景下皮尔逊相关系数算法的效果, 4次实验的Pod分别设置成GPU需求比CPU和内存高 (GPU型)、内存需求比CPU和GPU高 (内存型)、CPU需求比内存和GPU高 (CPU型), CPU与内存和GPU需求差不多 (均衡型).

在每次实验中, 分别采用Kubernetes的默认优选调度算法和基于皮尔逊相关系数 (PCC)的优选调度算法对6个Pod进行调度, 统计每个节点上的CPU、内存、GPU使用率, 然后计算每个节点上各维度资源使用率的方差, 用集群中节点方差的平均值来表示集群中节点资源的均衡度, 通过对比说明皮尔逊相关系数 (PCC)算法能显著提高集群中节点资源的均衡度.

5.3 实验结果

第1组实验数据如表3所示, 该组实验的Pod为GPU型, 即GPU资源的需求量高于内存和CPU. 实验数据显示默认优选算法调度后, 集群中各节点资源使用率的平均方差为230, 采用PCC算法调度后平均方差为217, 表明对于此类Pod, 基于皮尔逊相关系数的优选算法能明显提高节点各种资源的均衡性.

第2组实验数据如表4所示, 该组实验的Pod为内存型, 即内存资源的需求量高于CPU和GPU. 实验数据显示PCC算法调度后的各节点资源使用率的方差均值为60, 明显小于默认算法的方差98, 表明对于此类Pod, 基于皮尔逊相关系数的优选算法能明显提高节点各种资源的均衡性.

第3组实验数据如表5所示, 该组实验的Pod为CPU型, 即CPU资源的需求量高于内存和GPU. 实验数据显示PCC算法调度后集群资源使用率的平均方差为196, 明显小于默认优选算法的318. 表明对于此类Pod, 基于皮尔逊相关系数的优选算法能明显提高节点各种资源的均衡性.

第4组实验数据如表6所示, 该组实验的Pod为均衡存型, 即内存、CPU和GPU资源的需求量类似. 实验结果表明对于此类Pod, 基于皮尔逊相关系数的优选算法能明显提高节点各种资源的均衡性.

5.4 实验结论

上述4次实验分别展示了GPU型、内存性、CPU型和均衡型4类Pod在Kubernetes默认优选算法和基于皮尔逊相关系数优选算法下集群中各节点资源使用率的情况, 并以各节点资源使用率的方差平均值作为衡量均衡度的指标, 并将其绘制成柱状图, 如图8所示. 实验证明针对4种不同类型的Pod, 相比于Kubernetes默认的优选算法, 本文提出的基于皮尔逊相关系数的优选算法能明显降低集群中节点各维度资源使用率的方差, 提高了调度后节点资源的均衡度, 有效减少了资源碎片的产生, 提高集群整体负载能力.

6 结束语

本文采用Kubernetes容器编排技术, 搭建了基于容器的AI调度引擎平台, 实现了从AI镜像到AI服务的全流程管理, 用户仅需简易操作便可定制稳定可靠的AI服务, 此外本文引入device plugin使Kubernetes实现了对异构资源GPU的访问和管理, 同时优化了Kubernetes的优选调度算法, 根据皮尔逊相关系数算法计算待调度Pod与集群中节点资源的互补性进行调度, 提高了集群中节点各维度资源的均衡度, 减少了资源碎片的产生. 应用实例证明, 该AI调度引擎平台可完成AI容器的调度和AI服务的创建, 并完成模块设计中的各项功能.