基于容器集群的任务处理方法及装置与流程

1.本技术涉及人工智能领域，特别涉及一种基于容器集群的任务处理方法及装置、计算设备和计算机可读存储介质。


背景技术：

2.人工智能(artificial intelligence；ai)是指已工程化(即设计并制造)的系统感知环境的能力，以及获取、处理、应用和表示知识的能力。自然语言处理、机器人、计算机视觉成为了人工智能最为热门的三个产业方向。自然语言处理是计算机科学领域与人工智能领域中的一个重要方向，研究能实现人与计算机之间用自然语言进行有效通信的各种理论和方法，涉及的领域较多，主要包括机器翻译、机器阅读理解和问答系统等。机器学习推理(machine learning inference)是指采用深度神经网络或概率统计模型处理数据，获取预测结果的过程。k8s(kubernetes)是一种基于容器的集群管理平台，kubernetes集群中包括主节点(master node)和分别与主节点通信连接的多个子节点(work node)。主节点用于管理和控制多个计算节点。计算节点是工作负载节点，每个计算节点中部署有多个容器组(pod)，每个容器组中封装有一个或多个用于承载软件程序的容器(container)，pod是kubernetes的基本操作单元，是最小的可创建、调试和管理的部署单元。
3.在现有的机器问答推理项目部署中，基于k8s进行的项目部署往往强调的是项目的精准表现，容易忽略访问项目的速度慢、部署项目的服务器稳定性差、最大并发量不足等问题，造成了用户体验和项目的总体稳定性存在缺陷。在各类的推理任务线上部署实现资料中，解决的一般是局部优化，而缺少制定一套完整的、从接收任务请求到任务分配再到任务的部署的高可用流程，对于最新的推理提速和gpu架构的整合方案也没有提及。


技术实现要素：

4.有鉴于此，本技术实施例提供了一种基于容器集群的任务处理方法及装置、计算设备和计算机可读存储介质，以解决现有技术中存在的技术缺陷。
5.根据本技术实施例的第一方面，提供了一种基于容器集群的任务处理方法，所述容器集群包括主节点和子节点，所述方法包括：
6.所述主节点接收任务处理请求，根据所述任务处理请求确定目标容器组，基于所述目标容器组确定目标子节点，将所述任务处理请求转发至所述目标子节点；
7.所述目标子节点接收所述任务处理请求，将所述任务处理请求分配至所述目标容器组，根据预设的显卡分配策略确定目标显卡，以使所述目标显卡处理所述目标容器组中的所述任务处理请求，其中，所述目标子节点包括至少一个显卡，每个显卡可以处理至少一个容器组中的任务处理请求。
8.根据本技术实施例的第二方面，提供了一种容器集群，所述容器集群包括主节点和子节点；其中，
9.所述主节点，被配置为接收任务处理请求，根据所述任务处理请求确定目标容器
组，基于所述目标容器组确定目标子节点，将所述任务处理请求转发至所述目标子节点；
10.所述目标子节点，被配置为接收所述任务处理请求，将所述任务处理请求分配至所述目标容器组，根据预设的显卡分配策略确定目标显卡，将所述目标容器组部署于所述目标显卡，通过所述目标容器组处理所述任务处理请求，其中，所述目标子节点包括至少一个显卡，每个显卡可以处理至少一个容器组中的任务处理请求。
11.根据本技术实施例的第三方面，提供了一种基于容器集群的任务处理方法，所述方法应用于容器集群中的子节点，包括：
12.接收任务处理请求；
13.将所述任务处理请求分配至对应的目标容器组；
14.根据预设的显卡分配策略确定目标显卡，以使所述目标显卡处理所述目标容器组中的所述任务处理请求，其中，所述目标子节点包括至少一个显卡，每个显卡可以处理至少一个容器组中的任务处理请求。
15.根据本技术实施例的第四方面，提供了一种基于容器集群的任务处理装置，应用于容器集群中的子节点，包括：
16.接收模块，被配置为接收任务处理请求；
17.分配模块，被配置为将所述任务处理请求分配至对应的目标容器组；
18.处理模块，被配置为根据预设的显卡分配策略确定目标显卡，以使所述目标显卡处理所述目标容器组中的所述任务处理请求，其中，所述目标子节点包括至少一个显卡，每个显卡可以处理至少一个容器组中的任务处理请求。
19.根据本技术实施例的第五方面，提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现所述基于容器集群的任务处理方法的步骤。
20.根据本技术实施例的第六方面，提供了一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现所述基于容器集群的任务处理方法的步骤。
21.根据本技术实施例的第七方面，提供了一种芯片，其存储有计算机指令，该指令被芯片执行时实现所述基于容器集群的任务处理方法的步骤。
22.本技术提供的基于容器集群的任务处理方法，通过容器集群部署的推理任务在高并发请求下依然能保持稳定运行，为一张显卡分配一个或多个容器组，满足了多个任务组部署在一张显卡上的业务需求，保证了每张显卡的额定资源的最大利用，节省了资源。
附图说明
23.图1是本技术实施例提供的容器集群的结构示意图；
24.图2是本技术实施例提供的基于容器集群的任务处理方法的流程图；
25.图3是本技术实施例提供的未经优化的inception block(初始块)的结构示意图；
26.图4是本技术实施例提供的优化后的inception block(初始块)的结构示意图；
27.图5是本技术实施例提供的一种容器集群的结构示意图；
28.图6是本技术一实施例的一种应用于容器集群中的子节点的基于容器集群的任务处理方法的流程图；
29.图7是本技术一实施例的一种应用于容器集群中的子节点的基于容器集群的任务
处理装置的结构示意图；
30.图8是本技术一实施例的基于容器集群的任务处理方法的整体框架图。
具体实施方式
31.在下面的描述中阐述了很多具体细节以便于充分理解本技术。但是本技术能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本技术内涵的情况下做类似推广，因此本技术不受下面公开的具体实施的限制。
32.在本技术一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本技术一个或多个实施例。在本技术一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本技术一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
33.应当理解，尽管在本技术一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本技术一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“响应于确定”。
34.首先，对本发明一个或多个实施例涉及的名词术语进行解释。
35.容器集群：k8s(kubernetes)，是一种开源的容器集群管理系统。在docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。
36.主节点：管理节点(master node)，是cpu linux服务器，主节点的数量为奇数个，至少为三台。
37.子节点：工作节点(work node)，是安装了英伟达显卡和英伟达显卡驱动程序的linux服务器，一个主节点可以关联多个子节点。
38.容器：docker，是开源的应用容器引擎，在容器内封装了应用程序。
39.pod：k8s中的最小工作单元，其中包含至少一个容器(docker)。
40.高可用：ha(high availability)对于当前运行的项目，提供负载均衡、灾难备援，高可移植性，高可拓展性。
41.jenkins：提供各种自动化部署插件的平台。
42.轮询：每个请求按照时间顺序分配至不同的后端服务器，若服务器失去响应，则自动剔除请求。
43.在目前的kubernetes容器集群(k8s)的应用场景中，在任务请求被k8s转发至每一个pod时，以往的每个pod都会独占一张显卡的全部资源，就算在等待命令时，pod占据的显卡目前没有工作处理，也不会将显卡资源让出给其它程序使用，从而造成显卡的使用率低下，算力资源被大量浪费。
44.基于此，在本技术中，提供了一种容器集群、一种基于容器集群的任务处理方法及装置、计算设备和计算机可读存储介质，在下面的实施例中逐一进行详细说明。
45.图1示出了根据本技术一实施例的容器集群的结构示意图，如图1所示，在容器集
群中包括有主节点和子节点，主节点(master)负责管理，子节点(node)负责工作。
46.master是集群的控制节点，负责整个集群的管理和控制，在master上运行有以下关键进程：
47.api server(api服务器)，提供了接口的关键服务进程，是容器集群中所有资源的增删改查等操作的唯一入口，也是集群控制的入口进程。
48.controller-manager(控制器)：容器集群里所有资源对象的自动化控制中心，集群内各种资源控制的核心管理者，针对每一种资源都有相应的管理者，保证其管理的每个资源都处于期望状态。
49.scheduler(调度器)：负责资源调度的进程，通过asiserver监听新建pod(容器组)信息，并通过调度算法为该pod分配一个最合适的node。
50.etcd(分布式存储)：容器集群里所有资源对象以及状态的数据都被保存在etcd中。
51.node是容器集群中的工作负载节点，每个node都会被master分配一些工作负载，当某个node宕机时，其工作负载会被master自动转移到其他节点上。每个node上会运行以下进程：
52.kubelet：负责pod对应容器的创建、启停等任务，同时与master密切协作，实现容器集群管理的基本功能。
53.kube-proxy：实现容器集群服务通信与负载均衡机制的重要组件。
54.docker engine：docker引擎，负责本机的容器创建和管理工作。
55.在实际应用中，由master节点接收业务任务，并将业务任务分配给node，由部署在node里的pod(容器组)执行业务，pod是容器集群中能创建、调度、管理的最小部署单元，是一组docker(容器)的集合，而不是单独的应用容器。
56.参见图2，图2示出了本技术一实施例提供的基于容器集群的任务处理方法，所述方法应用于容器集群，所述容器集群包括主节点和子节点，容器集群的架构图参见上述图1，具体包括以下步骤：
57.步骤202：所述主节点接收任务处理请求，根据所述任务处理请求确定目标容器组，基于所述目标容器组确定目标子节点，将所述任务处理请求转发至所述目标子节点。
58.主节点即为管理节点(master node)，在容器集群中负责调度；子节点为工作节点(work node)，负责处理容器集群中的具体任务。
59.在所述容器集群需要处理任务时，所述主节点接收任务处理请求，以容器集群为kubernetes(k8s)为例，在主节点中设置有请求接口(api server)，通过所述请求接口接收任务处理请求，api server提供其他模块之间数据交互和通信的枢纽，其他模块通过api server查询或修改数据，只有api server才直接与etcd(分布式存储)交互，需要说明的是，所述任务请求可以有多种内容，比如将任务处理请求写入任务处理列表，或是将所述任务处理请求写入任务处理队列，由主节点中的api server依次进行处理。任务处理请求来自于用户指令，即用户通过终端登录k8s界面，基于kubectl命令集向容器集群发布任务处理请求。
60.任务处理请求具体是指与业务相关的任务处理请求，任务处理请求由容器组(pod)执行，容器组预先部署于容器集群的子节点中，在所述主节点由api server接收到任
务处理请求后，将任务处理请求传递给scheduler(调度器)，scheduler负责节点资源管理，接收来自api servere的任务处理请求后，会检索出符合该任务的容器组，通过预选策略和优选策略，执行pod调度逻辑，确定该任务处理请求对应的目标容器组(pod)，在确定目标容器组后，即可确定目标子节点，scheduler将调度信息(目标容器组和目标子节点)返回给api server，api server根据该调度信息将该任务处理请求分配至所述目标容器组对应的目标子节点。
61.步骤204：所述目标子节点接收所述任务处理请求，将所述任务处理请求分配至所述目标容器组，根据预设的显卡分配策略确定目标显卡，以使所述目标显卡处理所述目标容器组中的所述任务处理请求，其中，所述目标子节点包括至少一个显卡，每个显卡可以处理至少一个容器组中的任务处理请求。
62.目标子节点中部署有kubelet进程，kubelet负责容器组对应容器的创建、启停等任务，目标子节点中的kubelet在接收到任务处理请求后，将目标任务处理请求分配至对应的目标容器组，根据预设的显卡分配策略为目标容器组分配对应的显卡，通过显卡处理目标容器组中的任务处理请求。
63.其中，预设的显卡分配策略包括：1、限制一个容器组(pod)可见显卡的数量；2、限制一个pod可见显卡的显存最大使用数；3、限制一个pod可见显卡的最大每秒工作量。具体的，限制一个pod可见显卡的数量具体是指一个pod只可在预设数量的显卡上部署，例如某个子节点有8张显卡，限制pod1只可见前4张显卡，即只可在前4张显卡上部署。限制一个pod可见显卡的显存最大使用数具体是指限制pod在显卡上占用资源的最大值，例如一张显卡有16g的显存，可以设置某个pod最多只可占用8g的显存。限制一个pod可见显卡的最大每秒工作量具体是指一个pod在显卡上最大可占用的每秒工作量，例如分配一个pod最多可用50％的显卡每秒工作量。
64.目标子节点包括多张显卡，在实际应用中，任务处理请求需要通过pod进行任务处理，pod运行于显卡中。目标子节点还会监控每张显卡的状态，在接收到任务处理请求时，根据每张显卡的未占用的显存信息和已占用的显存信息的利用率确定可用的显卡，并将所述目标容器组部署于可用的显卡，利用可用显卡上的显存资源来执行相应的任务。在实际应用中，目标子节点优先考虑在当前状态下，当前子节点中可用资源多、负载低的显卡作为目标容器组部署的显卡，用该显卡去执行任务处理请求，可以充分利用目标子节点中的显存资源，做到显存资源的合理分配利用，达到负载均衡的效果。
65.需要说明的是，容器与显卡之间是可见的关系，需要经过配置来确定容器可见的显卡，部署相应目标容器的显卡与所述目标容器之间的对应关系称为“可见”。例如，目标子节点m对应八张显卡m1-m8，目标子节点m中包含三个目标容器组：p1，p2，p3，其中，p1对应显卡m1-m4，即可称为“目标容器组p1的对显卡m1-m4可见”，同理，目标容器组p2对显卡m5-m8可见，目标容器组p3对显卡m2-m5可见，并且，在对目标容器组p1进行部署时，仅能将p1部署于显卡m1-m4中，无法部署于显卡m5-m8。若显卡m2已经部署了目标容器组p1，但p1并未占用显卡m2的全部资源，且显卡m2中剩余的显卡资源也可以满足目标容器组p3的部署，此时可以将目标容器组p3同样部署于显卡m2，可以有效的提升显卡的利用率。
66.容器组每一次仅能接收一个任务处理请求。所述任务处理请求包括单独请求和队列请求，其中，单独请求是指在该任务处理请求中仅有一个待处理任务，队列请求是指在该
任务处理请求中需要处理多个待处理任务，多个待处理任务以队列的形式存在，队列可以有一个，也可以有多个，按照添加待处理任务的时间顺序，可以将待处理任务添加至队列中。
67.目标容器可以通过轮询的方式处理任务处理请求，轮询是指按照任务处理请求的时间顺序来对任务处理请求中的待处理任务进行读取处理。
68.在本技术提供的一具体实施方式中，任务处理请求是单独请求，即只有一个待处理任务，则目标容器组读取该待处理任务并对其进行相应的处理。
69.在本技术提供的另一具体实施方式中，任务处理请求是队列请求，在该队列请求中有10个待处理任务，目标容器组p1可见的显卡为m1、m2、m3和m4，通过计算m1-m4这4个显卡的可用资源和负载信息，确定m1、m2和m4为可用显卡，而目标容器组在同一时间仅能处理1个待处理任务，则可以将目标容器组p1分别部署在m1、m2和m4中，由m1、m2和m4中部署的目标容器组p1依次处理该队列请求中的10个待处理任务，从而提高任务处理请求的处理效率。
70.在本技术提供的一可选实施方式中，所述方法还包括：
71.所述主节点接收携带有目标镜像文件的目标容器组创建请求，响应于所述目标容器组创建请求创建所述目标镜像文件对应的目标容器组，根据预设的容器组分配策略确定所述目标容器组对应的目标子节点，将所述目标容器组调度至所述目标子节点；
72.所述目标子节点部署所述目标容器组。
73.在实际应用中，用户会向容器集群发送目标容器组创建请求，在该创建请求中会携带有目标镜像文件，在镜像文件中存储有封装了用于处理待处理任务的目标任务处理模型，该目标任务处理模型根据实际业务的不同，可以是推理任务，也可以是图形处理任务等，在本技术中对此不做限定。
74.主节点中的api server在接收到该目标容器组创建请求后，将目标镜像文件保存至etcd中，将目标容器组创建请求转发至scheduler，scheduler根据预设的容器组分配策略为该目标容器组分配相应的子节点，预设的容器组分配策略具体是指主节点根据各个子节点中的负载情况进行容器组分配的策略。
75.主节点中scheduler负责资源的调度，其收集和分析当前容器集群中所有子节点的资源(内存、cpu、显存)负载情况，然后依次分发新建的容器组到容器集群中的可用子节点。
76.scheduler还会实时监测容器集群中未分发和已分发的所有运行的容器组，在分发容器组至子节点后，会把该容器组的相关信息回写到api server中。
77.在本技术中，scheduler在接收到api server转发的目标容器组创建请求后，根据当前容器集群中各个子节点的负载情况，为目标容器组分配对应的目标子节点，在确定该目标子节点后，开始执行目标容器组的调度逻辑，调度成功后，将该目标容器组绑定到该目标子节点。
78.在创建所述目标容器组时，会确定所述目标容器组所占用的资源和每一个子节点可用的资源，进而确定所述目标容器组可以部署的子节点，若某个子节点中的可用资源可以满足所述目标容器组正常运行所占用的资源，则可以确定该子节点为目标子节点，进而由主节点调度所述目标容器组至目标子节点，并由所述目标子节点部署所述目标容器组。
79.例如，对于一个图形处理任务，需要由一个图像处理模型进行处理，运行该图像处理模型至少需要用到5g内存、23g的存储空间和2g的显存，scheduler可以实时监测容器集群中各个子节点的资源占用情况，获取每个子节点的资源占用信息，选择可以满足“5g内存、23g的存储空间和2g的显存”的子节点，在实际应用中，可能会有多个子节点满足该条件，可以进一步从多个符合条件的子节点中按照预设条件来确定目标子节点，预设条件可以是可用内存资源最多、可以是可用存储空间最大、也可以是可用显存最多等等，也可以是在多个符合条件的子节点中任选一个为目标子节点。
80.在本技术提供的基于容器集群的任务处理方法中，在部署k8s集群前，为了提高推理模型的运算速度，需要利用tensorrt对推理模型进行优化和提速。tensorrt是一个有助于在gpu(图形处理器graphics processing unit)上高性能推理c++库，现已能支持tensorflow、caffe、mxnet、pytorch等深度学习框架以互补的方式进行工作，将tensorrt和nvidia的gpu结合起来，能在深度学习框架中进行快速和高效的部署推理。
81.具体的，在所述主节点接收携带有目标镜像文件的目标容器组创建请求之前，还包括：
82.获取目标任务对应的初始任务处理模型；
83.通过预设的模型优化工具优化所述初始任务处理模型，获得目标任务处理模型；
84.根据所述目标任务处理模型生成目标镜像文件；
85.基于所述目标镜像文件生成目标容器组创建请求，并将携带有目标镜像文件的目标容器组创建请求发送至所述容器集群。
86.其中，所述目标任务，即为待处理的推理任务；所述初始任务处理模型，即为通过待处理的推理任务确定的推理模型，所述推理模型是已经训练完成的模型。
87.为了提高容器集群对推理任务的处理速度，需要通过预设的模型优化工具对所述初始任务处理模型进行优化，从而达到提高处理推理任务速度的效果。
88.具体地，所述模型优化工具为tensorrt，在训练了神经网络之后，tensorrt可以对该神经网络进行压缩、优化以及运行时部署，并且没有框架的开销，以神经网络模型为flask推理任务模型为例，在启动flask推理任务服务后，首先通过剪枝(层间融合)对模型进行结构优化。参见图3，图3示出了本技术一实施例提供的未经优化的inception block(初始块)的结构示意图，在该结构中有很多层，在部署模型推理时，每一层的运算操作都由gpu(图形处理器graphics processing unit)完成，其本质上是gpu通过启动不同的cuda(compute unified device architecture统一计算设备架构)核心来完成计算。cuda核心计算张量的速度是很快的，但是往往大量的时间是浪费在cuda核心的启动和对每一层输入/输出张量的读写操作上面，这造成了内存带宽的瓶颈和gpu资源的浪费。
89.tensorrt通过对层间的横向或纵向合并(合并后的结构称为cbr，意指convolution,bias,and relu layers are fused to form a single layer)，使得层的数量大大减少。横向合并可以把卷积、偏置和激活层合并成一个cbr结构，只占用一个cuda核心。纵向合并可以把结构相同，但是权值不同的层合并成一个更宽的层，也只占用一个cuda核心。参见图4，图4示出了本技术一实施例提供的优化后的inception block的结构示意图，经过优化后的inception block占用的cuda核心数也少了，因此整个模型结构会更小，更快，更高效。
90.在剪枝操作完成后，还需要通过混合精度(数据精度校准“weight&activation precision calibration”)对推理模型进一步优化。大部分深度学习框架在训练神经网络时网络中的张量(tensor)都是32位浮点数的精度(full 32-bit precision，fp32)，一旦网络训练完成，在部署推理的过程中由于不需要反向传播，完全可以适当降低数据精度，比如降为fp16或int8的精度。更低的数据精度将会使得内存占用和延迟更低，模型体积更小。
91.不同精度的动态范围如下表1所示：
92.表1
[0093][0094][0095]
int8只有256个不同的数值，使用int8来表示fp32精度的数值，肯定会丢失信息，造成性能下降。不过tensorrt会提供完全自动化的校准(calibration)过程，会以最好的匹配性能将fp32精度的数据降低为int8精度，最小化性能损失。
[0096]
本技术中，所示初始任务处理模型可以是fast-transformer，通过模型优化工具对所示初始任务处理模型进行优化后，得到运算速度更快、结构更小、更高效的目标任务处理模型。
[0097]
为了将所示目标任务处理模型应用于容器集群中，用户将需要根据所述目标任务处理模型生成对应的目标镜像文件，并基于该目标镜像文件生成对应的目标容器组创建请求，并将该目标容器组创建请求发送至容器集群的主节点中。
[0098]
在实际应用中，由于需求的变更、业务的变更等因素，经常会需要对目标任务处理模型中的代码进行更新，目标任务处理模型运行在容器组中，就需要对容器集群中的目标容器组进行相应的更新。相应的，所述方法还包括：
[0099]
所述主节点接收所述目标容器组的更新指令，将所述更新指令发送至所述目标子节点，其中，所述更新指令包括更新信息；
[0100]
所述目标子节点接收所述更新指令，根据所述更新信息更新所述目标容器组。
[0101]
其中，更新信息为用于更新所述目标容器组的更新镜像文件，用户向容器集群发出针对目标容器组的更新指令，主节点中的api server在接收到该更新指令后，解析该更新指令对应的目标容器组标识，确定该目标容器组对应的目标子节点，并将该更新指令转发至目标子节点，即将更新镜像文件发送至所述目标子节点。
[0102]
该目标容器组的更新任务在对应的目标子节点中进行，在目标子节点接收到更新
指令后，通过更新指令中携带的更新信息对目标容器组进行更新，也就是说用更新镜像文件更新目标容器组中的镜像文件。
[0103]
例如，出于业务需要，将目标pod由pod1更新为pod1’，则需要预先在代码仓库中存储pod1’的代码并生成镜像文件。具体的更新过程如下所示：
[0104]
1、由用户将目标pod 1’的新代码上传至github，github是一个面向开源及私有软件项目的托管平台，pod 1’的新代码上传至github后，触发github的更新，github确认现有的代码库发生了代码更新，进而触发jenkins的工作流。jenkins是一个开源软件项目，基于java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件项目可以进行持续集成。
[0105]
2、由jenkins在子节点创建辅助pod，所述辅助pod用于帮助k8s集群构建新pod代码。
[0106]
3、由所述辅助pod从github中下载用户上传的新pod代码，并从云镜像仓库中获取所述pod1的基础镜像文件，其中，所述云镜像仓库用于存储容器集群中容器的镜像文件。
[0107]
4、所述辅助pod对所述基础镜像文件和所述新pod代码进行代码合成，在合成完成后得到pod1’的新镜像文件，并将所述新镜像文件上传至所述云镜像库。
[0108]
5、由k8s容器集群对所述pod1’的新代码进行分段处理，具体的，可以按照pod1’中代码的行数进行分段，也可以按照pod1’中的函数进行分段，在本技术中，对pod1’代码的分段格式不做限定，在对pod1’进行分段之后，即可用pod1’中的分段内容逐段替换pod1，逐段替换pod1无需中断该目标容器组的服务，可以保证目标容器组可以正常处理对应的待处理任务，在逐段替换完成后，即可获得更新后的目标容器组pod1’。
[0109]
6、完成上述步骤后，k8s容器集群销毁所述辅助pod，完成目标容器组的更新。
[0110]
通过将更新后的目标容器组的镜像文件中的代码分段，逐段更新目标容器组中的代码，即便目标容器组正在运行，也不会中断目标容器组的正常使用，提高了容器集群的抗风险能力，也提高了容器集群的运行效率。
[0111]
在实际应用中，容器组中设置有第一探针和第二探针，所述第一探针用于监测外部请求的状态，容器组可以通过所述第一探针获取针对所述容器组的任务处理请求的情况，例如“暂无请求”或是“请求发送中”或是“请求超时”等等；所述第二探针用于监测所述容器组内部的服务请求，例如所述容器组中封装了任务处理模型，可以利用第二探针获取容器组内部对所述任务处理请求的处理情况，例如“处理中”或是“暂无请求”或是“请求超时”等等。
[0112]
另外，若在目标容器组的运行过程中发生异常，比如“连接超时”或“运行崩溃”，子节点会销毁所述目标容器组，并在所述目标容器组部署的原有位置重新创建的目标容器组。通过此种方法，可以保证本技术容器集群的运行稳定性，降低了运行风险。
[0113]
可选的，在所述主节点接收所述目标容器组的更新指令之前，还包括：
[0114]
获取所述目标容器组的更新信息；
[0115]
基于所述更新信息生成更新指令，并将携带有所述更新信息的更新指令发送至所述容器集群。
[0116]
需要说明的是，本技术提供的基于容器集群的任务处理方法中，除了容器集群外，还包括代码仓库，所述代码仓库可以通过将目标容器组的代码上传至代码平台(gitlab)实
现。在具体应用中，利用gitlab进行代码的云端存储，可以实现代码的大容量存储，也可以用于存储用于目标容器组中的模型的代码。在所述目标容器组需要进行更新时，通过所述代码仓库中的容器镜像仓库存储、发布需要更新的镜像文件。在每一次代码更新时，通过所述容器镜像仓库在插件平台(jenkins)中触发更新，将需要更新的镜像文件打包发送至所述容器集群。
[0117]
在容器集群的子节点中对目标容器组进行更新，从而完成对目标容器组中的镜像文件的代码更新。
[0118]
本技术提供的基于容器集群的任务处理方法，通过容器集群部署的推理任务在高并发请求下依然能保持稳定运行，为一张显卡分配一个或多个容器组，满足了多个任务组部署在一张显卡上的业务需求，保证了每张显卡的额定资源的最大利用，节省了资源。
[0119]
其次，容器集群本身具有完备的重启救援机制和分布式架构，使单个节点或容器组出现故障时，不会影响总体服务。
[0120]
最后，通过模型优化工具对任务处理模型进行优化，使得通过本方法部署的及其推理任务响应速度和推理速度都有显著的提升，提高了工作效率。
[0121]
图5示出了本技术一实施例提供的一种容器集群的结构示意图，所述容器集群包括主节点502和子节点504，其中：
[0122]
所述主节点502，被配置为接收任务处理请求，根据所述任务处理请求确定目标容器组，基于所述目标容器组确定目标子节点，将所述任务处理请求转发至所述目标子节点；
[0123]
所述目标子节点504，被配置为接收所述任务处理请求，将所述任务处理请求分配至所述目标容器组，根据预设的显卡分配策略确定目标显卡，将所述目标容器组部署于所述目标显卡，通过所述目标容器组处理所述任务处理请求，其中，所述目标子节点包括至少一个显卡，每个显卡可以处理至少一个容器组中的任务处理请求。
[0124]
可选的，所述主节点502，还被配置为接收目标容器组创建请求，响应于所述目标容器组创建请求创建目标容器组，根据预设的容器组分配策略确定所述目标容器组对应的目标子节点，将所述目标容器组调度至所述目标子节点；
[0125]
所述目标子节点504，还被配置为部署所述目标容器组。
[0126]
可选的，所述容器集群还包括：
[0127]
所述主节点502，还被配置为接收所述目标容器组的更新指令，将所述更新指令发送至所述目标子节点，其中，所述更新指令包括更新信息；
[0128]
所述目标子节点504，还被配置为接收所述更新指令，根据所述更新信息更新所述目标容器组。
[0129]
处理器120可以执行图6所示一种基于容器集群的任务处理方法中的步骤。图6示出了根据本技术一实施例的一种基于容器集群的任务处理方法的流程图，所述方法应用于容器集群中的子节点，包括步骤602至步骤606：
[0130]
步骤602：接收任务处理请求。
[0131]
步骤604：将所述任务处理请求分配至对应的目标容器组。
[0132]
步骤606：根据预设的显卡分配策略确定目标显卡，以使所述目标显卡处理所述目标容器组中的所述任务处理请求，其中，所述目标子节点包括至少一个显卡，每个显卡可以处理至少一个容器组中的任务处理请求。
[0133]
本技术提供的基于容器集群的任务处理方法，通过容器集群部署的推理任务在高并发请求下依然能保持稳定运行，为一张显卡分配一个或多个容器组，满足了多个任务组部署在一张显卡上的业务需求，保证了每张显卡的额定资源的最大利用，节省了资源。
[0134]
其次，容器集群本身具有完备的重启救援机制和分布式架构，使单个节点或容器组出现故障时，不会影响总体服务。
[0135]
最后，通过模型优化工具对任务处理模型进行优化，使得通过本方法部署的及其推理任务响应速度和推理速度都有显著的提升，提高了工作效率。
[0136]
与上述应用于容器集群中的子节点的基于容器集群的任务处理方法实施例相对应，本技术还提供了基于容器集群的任务处理装置实施例，图7示出了本技术一个实施例的基于容器集群的任务处理装置的结构示意图，该装置应用于容器集群中的子节点。如图7所示，该装置包括：
[0137]
接收模块702，被配置为接收任务处理请求；
[0138]
分配模块704，被配置为将所述任务处理请求分配至对应的目标容器组；
[0139]
处理模块706，被配置为根据预设的显卡分配策略确定目标显卡，以使所述目标显卡处理所述目标容器组中的所述任务处理请求，其中，所述目标子节点包括至少一个显卡，每个显卡可以处理至少一个容器组中的任务处理请求。
[0140]
本技术提供的基于容器集群的任务处理装置，通过容器集群部署的推理任务在高并发请求下依然能保持稳定运行，为一张显卡分配一个或多个容器组，满足了多个任务组部署在一张显卡上的业务需求，保证了每张显卡的额定资源的最大利用，节省了资源。
[0141]
其次，容器集群本身具有完备的重启救援机制和分布式架构，使单个节点或容器组出现故障时，不会影响总体服务。
[0142]
最后，通过模型优化工具对任务处理模型进行优化，使得通过本方法部署的及其推理任务响应速度和推理速度都有显著的提升，提高了工作效率。
[0143]
上述为本实施例的一种基于容器集群的任务处理装置的示意性方案。需要说明的是，该基于容器集群的任务处理装置的技术方案与上述的基于容器集群的任务处理方法的技术方案属于同一构思，基于容器集群的任务处理装置的技术方案未详细描述的细节内容，均可以参见上述基于容器集群的任务处理方法的技术方案的描述。
[0144]
需要说明的是，装置权利要求中的各组成部分应当理解为实现该程序流程各步骤或该方法各步骤所必须建立的功能模块，各个功能模块并非实际的功能分割或者分离限定。由这样一组功能模块限定的装置权利要求应当理解为主要通过说明书记载的计算机程序实现该解决方案的功能模块构架，而不应当理解为主要通过硬件方式实现该解决方案的实体装置。
[0145]
参见图8，图8示出了本技术一实施例提供的基于容器集群的任务处理方法的整体框架图。
[0146]
在本实施例中，以服务请求为bert类推理项目为例进行解释说明，在机器学习推理领域中，以bert为原型的bert类推理模型的性能常常难以满足在线业务对于低延迟和高吞吐的要求。
[0147]
以bert-base为例，超过90％的计算时间都消耗在transformer的向前计算上，因此急需一个高效的transformer向前计算方案，为在线业务带来降本增效的作用。基于此，
fast transformer应运而生，fast transformer是一个bert transformer单层向前的高效实现，其代码简介明了，后续可以通过简单修改，即可支持多种transformer结构。本技术实施例以图像识别模型为例，通过tensorrt对图像识别模型优化进行解释说明，该图像识别模型使用的是fast transformer模型框架。
[0148]
在实际应用中，预先通过样本训练数据对图像识别模型进行训练，使得图像识别模型具备识别图像内容信息的能力。在本技术中对图像识别模型的训练方法不做限定。
[0149]
通过tensorrt对训练好的图像识别模型进行优化，tensorrt是一个推理优化器，当图像识别模型训练完成之后，将图像识别模型的模型文件输入至tensorrt中，不再依赖深度学习框架(如tensorflow)。
[0150]
tensorrt首先对图像识别模型进行层间融合(剪枝)，图像识别模型包括6个编码层和6个解码层，每个编码层中包括自注意力子层和前馈网络层，每个解码层中包括自注意力子层、编码解码注意力子层和前馈网络层。
[0151]
tensorrt将每个编码层之间进行纵向合并，将每个编码层的自注意力子层和前馈网络层合并成一个cbr结构，只占用一个cuda核心；将每个解码层之间进行纵向合并，将每个解码器的自注意力子层、编码解码注意力子层和前馈网络层合并成一个cbr结构，只占用一个cuda核心。同时，tensorrt将编码层中的自注意力子层和前馈网络层与解码器中的自注意力子层和前馈网络层合并成一个cbr结构，只占用一个cuda核心，图像识别模型合并之后的层次更少了，占用的cuda核心数也更少了，整个模型结构更小、更快、更高效。
[0152]
tensorrt除了对模型进行层间融合之外，对模型中张量的精度进行混合，在实际应用中，大部分深度学习框架在模型训练过程中，模型中的张量都是32位浮点数(fp32)，一旦模型训练完成之后，在部署推理的过程中无需再反向传播调整模型参数，完全可以适当降低数据精度，比如将fp32精度降低为fp16或int8的精度，更低的数据精度会使内存占用和延迟更低，模型体积更小，由于int8只有256个不同的数值，使用int8精度的数值来表示fp32精度的数值，肯定会丢失信息，造成性能下降，不过tensorrt会提供完全自动化的校准过程，会以更好的匹配性能将fp32精度数据降低为int8精度，最小化模型的性能损失。至此，图像识别模型通过tensorrt进行优化后，能有效提高图像识别模型的处理速度。
[0153]
此外还需要将图像识别模型部署到k8s容器集群中，在本实施例中，k8s容器集群中有3个主节点，分别为master node1、master node2、master node3，同时还有n个work node，其中n为正整数。生成针对优化后图像识别模型的pod创建请求，并将该创建请求发送至k8s容器集群的master节点中，master节点通常为单数个节点，k8s容器集群的一致性算法raft，要求集群需要数量大于(n/2)的正常主节点才能提供服务，n为主节点数量，因此，3个主节点会有1个节点的容错率。基于此，k8s容器集群的主节点通常会设为3个或5个。
[0154]
单数个主节点在实际引用中，还会选出一个leader，在本实施例中，以master node1为主节点中的leader为例，master node1中的api server接收到pod创建请求，将图像识别模型的镜像文件保存至etcd，将pod创建请求转发至scheduler，scheduler根据当前容器集群中每个子节点的内存、cpu、显存的负载情况，为该pod分配对应的目标子节点。在确定目标子节点之后，将目标pod分配给目标子节点。
[0155]
在本技术实施例中，以目标子节点为node2为例，在node2中有8张显卡，目标子节点中的kubelet在接收到pod创建指令后，根据pod创建指令创建图像识别模型对应的pod1，
同时在kubelet中规定了该pod1的可见显卡数量为4个，同时限定了该pod1的显存最大使用数为4g，并且该pod1最多可用50％的显卡每秒数据量。以node2中的每张显卡的显存为16g，每秒数据量为2g，则该pod1对应的显卡要求是“可见4张显卡、每张显卡最多占用4g显存、每张显卡最多数据量为1g/秒”。
[0156]
node2中的kubelet根据pod1的显卡要求和当前node2节点上8张显卡的资源占用情况，为该pod1分配了m1、m2、m3和m4共计4张显卡。至此，图像识别模型在该k8s容器集群中完成部署。
[0157]
用户发送图像识别请求至k8s容器集群的主节点，主节点中的api server接收到该图像识别请求，根据该图像识别请求确定用于处理该图像识别请求的容器组是pod1，并且pod1部署在子节点node2中，将该图像识别请求转发至node2中。
[0158]
node2接收到该图像识别请求，通过kubelet来确定pod1可见的显卡为m1、m2、m3和m4，同时获取每张显卡的状态，该图像识别请求中只有一个图像识别任务，则根据每张显卡的状态确定m1为用于该图像识别请求的显卡，则pod1将该图像识别任务分配至显卡m1中进行处理，获得对应的图像识别结果。
[0159]
在本实施例提供的另一具体实施方式中，用户发送图像识别批处理请求，在该图像识别批处理请求中共计有6个图像识别处理任务，这6个图像识别处理任务通过队列的形式发送至主节点中，主节点中的api server接收到该图像识别批处理请求，确定用于处理该图像识别请求的容器组是pod1，并且pod1部署在子节点node2中，将该图像识别批处理请求转发至node2。
[0160]
node2接收到该图像识别批处理请求，由pod1通过轮询的方式依次读取队列中的图像识别处理任务，pod1可见的显卡为m1、m2、m3和m4，当读取到第1个图像识别处理任务时，在m1-m4中确定m2为第1个图像识别处理任务的显卡，当读取到第2个图像识别处理任务时，在m1、m3、m4中确定m1为第2个图像识别处理任务的显卡，当读取到第3个图像识别处理任务时，在m3、m4中确定m4为第3个图像识别处理任务的显卡，当读取到第4个图像识别处理任务时，确定m3为第4个图像识别处理任务的显卡，此时对于pod1而言，已经没有可用的显卡使用，需要等待m1-m4中的处理结果，当m1-m4中任意一个显卡处理完任务后，即可将后面的图像识别处理任务依次分配至空闲的显卡，直至完成该图像识别批处理请求。
[0161]
图像识别模型的由于业务需求的变化，需要对其代码进行改进，在实际引用中，图像识别模型的业务代码会被上传至软件项目托管平台github中，当有代码更新时，用户将新代码也上传至github，触发github的更新流程，github在经过比对之后，确认现有的代码库发生了代码更新，进而触发jenkins的工作流。
[0162]
由jenkins在node2中创建辅助pod，该辅助pod用于帮助k8s容器集群构建新pod代码，由辅助pod从github中下载用户上传的pod1更新后的业务代码，同时从云镜像仓库中获取当前pod1对应的基础镜像文件，由辅助pod对基础镜像文件和更新后的业务代码进行代码合成，合成完成后在辅助pod中保存有新pod1的代码文件。
[0163]
在子节点node2中对辅助pod的代码进行分段处理，具体的分段规则为按照辅助pod中的函数进行分段，可以将辅助pod中的代码分为101个分段，同时按照同样的函数分段规则对pod1中的原代码进行分段，并逐段将辅助pod中的代码更新至pod1中的代码中，此时，无需中断pod1提供的业务服务，可以保证pod1正常处理图像识别任务，在逐段替换换成
之后，pod1中的代码就是更新之后的代码，至此pod1的代码更新完成，可以摧毁辅助pod。
[0164]
在pod1中还设置有用于监测外部请求状态的第一探针和用于监测容器组内部服务请求的第二探针，通过第一探针可以获取该pod1的任务处理请求状态，例如“暂无请求”、“请求处理中”、“请求超时”等等；通过第二探针可以获取pod1内部的处理处理状态，例如“暂无请求”、“请求处理中”、“请求超时”等等，当探测到pod1的运行状态出现异常时，node2会销毁该pod1，并在该pod1的原有部署位置重新创建新的pod1，以此保证容器集群的稳定运行，降低了运行风险。
[0165]
本技术一实施例中还提供一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现所述的基于容器集群的任务处理方法的步骤。
[0166]
上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的基于容器集群的任务处理方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述基于容器集群的任务处理方法的技术方案的描述。
[0167]
本技术一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现如前所述基于容器集群的任务处理方法的步骤。
[0168]
上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的基于容器集群的任务处理方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述基于容器集群的任务处理方法的技术方案的描述。
[0169]
本技术实施例公开了一种芯片，其存储有计算机指令，该指令被处理器执行时实现如前所述基于容器集群的任务处理方法的步骤。
[0170]
上述对本技术特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
[0171]
所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
[0172]
需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本技术并不受所描述的动作顺序的限制，因为依据本技术，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本技术所必须的。
[0173]
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。
[0174]
以上公开的本技术优选实施例只是用于帮助阐述本技术。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本技术的内容，可作很多的修改和变化。本技术选取并具体描述这些实施例，是为了更好地解释本技术的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本技术。本技术仅受权利要求书及其全部范围和等效物的限制。