CN115686731A - 离线任务的集群控制方法、装置和设备及存储介质 - Google Patents

Abstract

本发明公开了一种离线任务的集群控制方法、装置和设备及存储介质，涉及容器集群技术领域，在该方法中，每个计算节点中部署有原生管理组件和离线管理组件，分别管理着该计算节点中的第一资源管理目录和第二资源管理目录，分别对应于在线任务和离线任务，在目标计算任务为离线任务时，则离线管理组件会将其资源管理目录修改为自身管理的第二资源管理目录，这样，后续原生管理组件为其创建运行容器时，则会在第二资源管理目录下进行创建，从而离线任务则会由离线管理组件进行资源管理，从而能够与在线任务的资源进行区分，以避免与在线任务进行资源竞争。此外，避免对原生代码进行侵入，在集群后续版本的迭代升级时，兼容性也更好，适用性更广。

Description

离线任务的集群控制方法、装置和设备及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及容器集群技术领域，提供一种离线任务的集群控制方法、装置和设备及存储介质。

背景技术

Kubernetes(k8s)是一种用于容器编排的资源调度管理平台，用户可以在云厂商提供的kubernetes的平台上提交任务，任务在该平台中以容器的形式运行。用户提交在线任务，通常会申请更多的资源，且任务运行过程中会有波峰波谷现象，这就会造成资源得不到充分利用，尤其是在波谷时段在线任务消耗的资源较少，那么在资源空闲时段，则通过填充离线任务来提升资源利用率，这种部署方式称为在线和离线混合部署方式。

但是，离线任务通过复用在线任务的空闲资源，那么则会与在线任务进行资源竞争，从而产生离线任务资源与在线任务资源冲突的问题，针对该问题，目前还并未提出较好的解决方案。

发明内容

本申请实施例提供一种离线任务的集群控制方法、装置和设备及存储介质，用于解决离线任务资源与在线任务资源冲突的问题。

一方面，提供一种离线任务的集群控制方法，应用于集群包括的计算节点中，所述计算节点包括原生管理组件和离线管理组件，所述方法包括：

通过所述原生管理组件接收目标计算任务，并将所述目标计算任务转发给所述离线管理组件；其中，所述目标计算任务至少携带表征任务属性的类型标签和第一容器参数，所述任务属性包括离线任务和在线任务，所述第一容器参数指示所述原生管理组件管理的第一资源管理目录；

若通过所述离线管理组件，基于所述类型标签确定所述目标计算任务为离线任务，则将所述第一容器参数修改为第二容器参数，并将所述第二容器参数返回给所述原生管理组件；所述第二容器参数指示所述离线管理组件管理的第二资源管理目录；

通过所述原生管理组件，基于所述第二容器参数，在所述第二资源管理目录下创建所述目标计算任务的运行容器。

一方面，提供一种离线任务的集群控制装置，应用于集群包括的计算节点中，所述计算节点包括原生管理组件和离线管理组件，所述装置包括：

任务获取单元，用于通过所述原生管理组件接收目标计算任务，并将所述目标计算任务转发给所述离线管理组件；其中，所述目标计算任务至少携带表征任务属性的类型标签和第一容器参数，所述任务属性包括离线任务和在线任务，所述第一容器参数指示所述原生管理组件管理的第一资源管理目录；

参数修改单元，用于若通过所述离线管理组件，基于所述类型标签确定所述目标计算任务为离线任务，则将所述第一容器参数修改为第二容器参数，并将所述第二容器参数返回给所述原生管理组件；所述第二容器参数指示所述离线管理组件管理的第二资源管理目录；

容器创建单元，用于通过所述原生管理组件，基于所述第二容器参数，在所述第二资源管理目录下创建所述目标计算任务的运行容器。

可选的，所述离线管理组件包括离线资源管理子组件，则所述装置还包括：

资源监控单元，用于通过所述原生管理组件，监测各个在线任务各自对应的实际使用资源量；

离线资源管理单元，用于通过所述离线资源管理子组件，调用所述原生管理组件的资源量获取接口，获取所述各个在线任务各自对应的实际使用资源量；通过所述离线资源管理子组件，基于获得的各个实际使用资源量，以及所述计算节点的总资源量，确定所述计算节点的空闲资源量；以及通过所述离线资源管理子组件，基于所述空闲资源量，调整所述第二资源管理目录的可用资源上限；其中，所述可用资源上限为在所述第二资源管理目录下创建的运行容器可使用的最大资源量。

可选的，所述装置还包括资源分配单元，用于：

通过所述原生管理组件，基于各个在线任务的资源申请请求，分别为各个在线任务分配相应的计算资源量；

若通过所述原生管理组件，监测到任一在线任务的实际使用资源量与分配的计算资源量不符时，则基于所述实际使用资源量，调整为所述任一在线任务分配的计算资源量。

可选的，所述原生管理组件包括节点管理子组件和容器引擎子组件，所述离线管理组件包括任务转发子组件；则所述任务获取单元，用于：

将所述节点管理子组件中调用所述容器引擎子组件对应的第一调用接口，修改为所述任务转发子组件对应的第二调用接口；

通过所述节点管理子组件接收目标计算任务，并调用所述第二调用接口，将所述目标计算任务发送给所述任务转发子组件。

可选的，所述参数修改单元，具体用于：

若通过所述任务转发子组件，基于所述类型标签确定所述目标计算任务为离线任务，则将所述第一容器参数修改为所述第二容器参数；

通过所述任务转发子组件，将携带所述第二容器参数的容器创建请求，发送给所述容器引擎子组件，所述容器创建请求用于请求所述容器引擎子组件为所述目标计算任务创建所述运行容器；

所述容器创建单元，具体用于：

通过所述容器引擎子组件，响应于所述容器创建请求，基于所述第二容器参数，在所述第二资源管理目录下创建所述目标计算任务的运行容器。

可选的，所述第二资源管理目录包括多个子目录，不同子目录的重要等级或者任务类型不同；则所述容器创建单元，具体用于：

通过所述容器引擎子组件，响应于所述容器创建请求，基于所述第二容器参数、所述目标计算任务对应的目标任务类型以及目标重要等级，确定所述目标计算任务对应的目标子目录；

通过所述容器引擎子组件，在所述目标子目录下，创建所述目标计算任务的运行容器。

可选的，

所述参数修改单元，还用于若通过所述任务转发子组件，基于所述类型标签确定所述目标计算任务为在线任务，则将携带所述第一容器参数的容器创建请求，发送给所述容器引擎子组件；

所述容器创建单元，还用于通过所述容器引擎子组件，响应于所述容器创建请求，基于所述第一容器参数，在所述第一资源管理目录下创建所述目标计算任务的运行容器。

可选的，所述参数修改单元，具体用于：

若通过所述任务转发子组件，基于所述类型标签确定所述目标计算任务为在线任务，则将第一容器参数中的所述第一资源管理目录，修改为所述第二资源管理目录；以及，

删除所述第一容器参数中的资源限制参数，以获得所述第二容器参数，所述资源限制参数用于指示为所述目标计算任务分配的最大资源量。

一方面，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任一种方法的步骤。

一方面，提供一种计算机存储介质，其上存储有计算机程序指令，该计算机程序指令被处理器执行时实现上述任一种方法的步骤。

一方面，提供一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述任一种方法的步骤。

本申请实施例中，每个计算节点中部署有原生管理组件和离线管理组件，分别管理着该计算节点中的第一资源管理目录和第二资源管理目录，分别对应于在线任务和离线任务，在有新的目标计算任务下发时，原生管理组件接收目标计算任务之后，将其转发给离线管理组件，离线管理组件能够基于该任务的类型标签判定其任务类型，当确定该目标计算任务为离线任务时，则离线管理组件会将其资源管理目录修改为自身管理的第二资源管理目录，这样，后续原生管理组件为其创建运行容器时，则会在第二资源管理目录下进行创建，从而离线任务则会由离线管理组件进行资源管理，从而能够与在线任务的资源进行区分，以避免与在线任务进行资源竞争。此外，离线管理组件为不同于原生管理组件的组件，即采用了旁路的方式在集群原生管理组件外部实现了离线资源的管理，避免对集群原生代码进行侵入，在集群后续版本的迭代升级时，兼容性也更好，同时，也便于应用到不同云厂商的集群平台，适用性更广。

附图说明

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

图1为本申请实施例提供的应用场景示意图；

图2为本申请实施例提供的计算节点的架构示意图；

图3为本申请实施例提供的离线任务的集群控制方法的流程示意图；

图4为本申请实施例提供的当该容器集群平台为kubernetes平台时的架构示意图；

图5为本申请实施例提供的一种目录结构示意图；

图6为本申请实施例提供的离线资源管理子组件进行离线资源管理的原理示意图；

图7为本申请实施例提供的离线任务的集群控制装置的一种结构示意图；

图8为本申请实施例提供的计算机设备的一种结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

为便于理解本申请实施例提供的技术方案，这里先对本申请实施例使用的一些关键名词进行解释：

原生管理组件：用户可以在云厂商的基于容器集群平台上提交任务，任务以容器的形式运行。以kubernetes平台为例，kubernetes是一个开源的，用于管理云平台中多个计算节点上的容器化的任务，Kubernetes的目标是让部署容器化的任务简单并且高效，Kubernetes的原生管理组件提供了任务部署、规划、更新以及维护的机制。

离线管理组件：该组件为本申请实施例为了解决在线和离线资源冲突的问题，在原生管理组件基础上，新增的管理组件，用于对离线任务进行资源管理，从而使得离线任务能够脱离原生管理组件的管理，避免离线任务与在线任务竞争资源。

容器(Container)：Kubernetes通过部署容器方式实现任务部署，每个容器之间互相隔离，每个容器有自己的文件系统，容器之间进程不会相互影响，能区分计算资源。容器是一组受到资源限制，彼此间相互隔离的进程，每个容器进程都有自己独立的进程空间，看不到其他进程，换句话说，容器就是一种基于操作系统能力的隔离技术，使得不同的任务的进程间相互隔离，无法相互感知。

Cgroup：为一种进程组资源控制器，属于Kubernetes平台的原生组件，用于实现Kubernetes平台的资源限制，例如，对中央处理器(central processing unit，CPU)资源、内存资源、存储资源以及网络资源进行限制。

Kubelet组件：为Kubernetes在计算节点的从属(slave)组件，属于Kubernetes平台的原生组件，用于跟kubernetes的管理端(master)交互，并通过docker组件来对各个任务的运行容器实例进行操作。

Docker组件：为计算节点中的容器引擎组件，属于Kubernetes平台的原生组件，用于管理各个任务的运行容器的生命周期的组件，如创建容器、启动容器、停止容器以及删除容器等。

下面对本申请实施例的设计思想进行简要介绍。

用户提交的在线任务，通常会申请更多的资源，但在线任务在任务运行过程中会有资源利用的波峰波谷现象，这就会造成在线任务申请的资源得不到充分利用，尤其是在波谷时段，会有大量的资源被闲置，那么，通过在资源空闲时段，填充离线任务复用在线任务的空闲资源，从而能够提升资源利用率，这种方式即称为在线离线混合部署方式。

但是，在基于kubernetes的在线离线混部过程中，离线任务通过复用在线任务的空闲资源，那么则存在与在线任务进行资源竞争，从而产生离线任务资源与在线任务资源冲突的问题，针对该问题，相关技术中提供了如下的几种解决方式：

(1)为云厂商定制kubernetes资源管理特性的方式

在这种方式中，需要采用入侵kubernetes代码的方式，在kubernetes原生资源管理代码逻辑的基础上定制开发针对离线任务的管理逻辑，各厂商云平台部署相应定制化的kubernetes组件，但是这种方式显然不能兼容其他云厂商的kubernetes平台，尤其是kubernetes升级迭代快，后期维护成本高。

(2)关闭kubernetes原生资源管理机制

在这种方式中，通过关闭kubernetes的原生资源管理机制，在外部实现与原生资源管控逻辑相同的组件，在该组件的基础上增加对离线任务的管控，这种方式不仅浪费了kubernetes原有的资源管理能力，且有开发量较大，成本较高，且若kubernetes后续版本对资源管理机制有改动，同样也要同步到外部组件中，后期维护成本高。

(3)周期性移除离线任务进程

在这种方式中，需要周期性把离线任务的进程PID从kubernetes管理的cgroup目录中移除，移动到一个新建的cgroup目录，再对该cgroup目录单独进行离线管理，但这种方式会产生对离线资源管理不彻底的问题，如移动离线进程之前，若离线任务消耗大量资源，但此时还未受离线管控，仍然会和在线任务形成资源竞争，进而影响在线任务的正常运行。

由此可见，相关技术中的解决方式或需要大量的人力物力成本，或无法彻底解决的资源竞争的问题。

针对离线任务与在线任务竞争资源的问题，需要对离线任务的资源进行单独的管理，以限制其对在线任务产生影响，同时，为了减少后续的维护成本，需要尽量减少对集群原生代码的依赖和修改。本发明通过一种旁路的方式将离线资源管理脱离kubernetes原生的资源管理范围，来解决冲突问题。

基于此，本申请实施例提供一种离线任务的集群控制方法、装置和设备及存储介质，在该方法中，每个计算节点中部署有原生管理组件和离线管理组件，分别管理着该计算节点中的第一资源管理目录和第二资源管理目录，分别对应于在线任务和离线任务，在有新的目标计算任务下发时，原生管理组件接收目标计算任务之后，将其转发给离线管理组件，离线管理组件能够基于该任务的类型标签判定其任务类型，当确定该目标计算任务为离线任务时，则离线管理组件会将其资源管理目录修改为自身管理的第二资源管理目录，这样，后续原生管理组件为其创建运行容器时，则会在第二资源管理目录下进行创建，从而离线任务则会由离线管理组件进行资源管理，从而能够与在线任务的资源进行区分，以避免与在线任务进行资源竞争。此外，离线管理组件为不同于原生管理组件的组件，即采用了旁路的方式在集群原生管理组件外部实现了离线资源的管理，避免对集群原生代码进行侵入，在集群后续版本的迭代升级时，兼容性也更好，同时，也便于应用到不同云厂商的集群平台，适用性更广。

在介绍完本申请实施例的设计思想之后，下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施过程中，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

本申请实施例提供的方案可以适用于在线和离线混合部署的容器集群平台中，例如上述提及的kubernetes平台。如图1所示，为本申请实施例提供的一种应用场景图，在该场景中，包括终端设备101、管理服务器102和计算节点103，一般而言，计算节点103的数量是较多的，参见图1所示的计算节点103～1至计算节点103～n。

终端设备101可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端设备101可以打开管理服务器102对应的容器集群平台的页面，例如通过浏览器或者客户端等打开相应的页面，用户可以通过在页面中提交自己的计算任务。

管理服务器102可以为容器集群平台的管理端，计算节点103则为容器集群平台的任务执行端。管理服务器102和计算节点103都可以通过服务器来实现，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

具体的，用户在终端设备101上提交了目标计算任务后时，管理服务器102可基于负载均衡策略，为该目标计算任务确定相应的计算节点103，并将目标计算任务下发给计算节点103，从而计算节点103执行目标计算任务，并通过管理服务器102将任务结果返回给终端设备101。

在一种可能的应用场景中，本申请实施例中的集群平台一般可以采用云平台的方式，云平台是基于云技术构建的架构平台。云技术(Cloud technology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。云技术基于云计算(cloud computing)商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑，技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

云计算是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。

作为云计算的基础能力提供商，会建立云计算资源池(简称云平台，一般称为IaaS(Infrastructure as a Service，基础设施即服务)平台，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作系统)、存储设备、网络设备。

按照逻辑功能划分，在IaaS层上可以部署PaaS(Platform as a Service，平台即服务)层，PaaS层之上再部署SaaS(Software as a Service，软件即服务)层，也可以直接将SaaS部署在IaaS上。PaaS为软件运行的平台，如数据库、web容器等。SaaS为各式各样的业务软件，如web门户网站、短信群发器等。一般来说，SaaS和PaaS相对于IaaS是上层。

在一种可能的应用场景中，本申请实施例的容器集群平台可以作为区块链(Blockchain)的实现架构，区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。

区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成(账户管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置(风控审计)；基础服务模块部署在所有区块链节点设备上，用来验证业务请求的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理(接口适配)，然后通过共识算法将业务信息加密(共识管理)，在加密之后完整一致的传输至共享账本上(网络通信)，并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上(合约注册)，根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、监控网络情况、监控节点设备健康状态等。

平台产品服务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。

在实际应用中，区块链包括的各层可部署于图1所示的架构中，例如区块链的区块链底层平台、平台产品服务层可部署于各个计算节点103中，管理服务器102可部署应用服务层，终端设备101则可以部署区块链产品的前端应用，实现与用户层面的交互。

当然，本申请实施例提供的方法并不限用于图1所示的应用场景中，还可以用于其他可能的应用场景，本申请实施例并不进行限制。对于图1所示的应用场景的各个设备所能实现的功能将在后续的方法实施例中一并进行描述，在此先不过多赘述。

在介绍本申请实施例提供的方法之前，首先对本申请实施例的计算节点的结构进行介绍，请参见图2所示，为本申请实施例提供的计算节点的架构示意图，每个计算节点中，包括原生管理组件和离线管理组件，原生管理组件可以包括节点管理子组件和容器引擎子组件，离线管理组件可以包括任务转发子组件和离线资源管理子组件，为便于区分，原生管理组件和离线管理组件的子组件采用不同的线型进行表示，原生管理组件采用实线表示，离线管理组件采用虚线进行表示。

(1)节点管理子组件，用于与管理服务器进行通信，即节点管理子组件接收管理服务器下发的目标计算任务。例如，当容器集群平台为kubernetes平台时，Kubernetes在每个计算节点上都安装有一个slave组件，称为kubelet组件，那么节点管理子组件可以为kubernetes平台的kubelet组件。Kubelet组件的首要功能是跟kubernetes master通信，若被通知有任务分配到其所管理节点，kubelet便负责通知docker组件，让其拉起任务的实例容器。同时kubelet组件还负责对所有正在运行的任务进行统一的资源管理。

(2)容器引擎子组件，用于管理各个任务的运行容器的生命周期的组件，如创建容器、启动容器、停止容器以及删除容器，例如，当容器集群平台为kubernetes平台时，则节点管理子组件可以为kubernetes平台的docker组件。

(3)任务转发子组件，用于对新下发的计算任务进行类型感知，在计算任务为离线任务时，则对离线任务的容器参数进行修改，而在线任务不进行处理。

(4)离线资源管理子组件，用于对离线任务的可用资源进行管理，例如配置离线任务的可用资源上限。

请参见图3，为本申请实施例提供的离线任务的集群控制方法的流程示意图，该方法可以通过图1中的计算节点103来执行，在下面的介绍中，主要是以容器集群平台为kubernetes平台为例进行介绍，当然，该方法同样适用于其他的容器集群平台，本申请对此并不进行限制。该方法的流程介绍如下。

步骤301：通过原生管理组件接收目标计算任务，并将目标计算任务转发给离线管理组件。

本申请实施例中，用户可以在容器集群平台提供的页面中提交相应的计算任务，相应的，容器集群平台的管理服务器可以基于负载均衡策略，判断执行该计算任务的一个或者多个计算节点，进而将每个计算节点所需执行的任务下发，这样，每个计算节点则可以接收到该节点所需处理的目标计算任务。

一般而言，管理服务器与计算节点之间通过容器集群平台的原生管理组件进行通信，即每个计算节点可以通过部署于其上的原生管理组件与管理服务器进行通信，以获取目标计算任务。参见图4所示，为当该容器集群平台为kubernetes平台时的架构示意图，在管理服务器中部署了kubernetes平台的管理端kubernetes Master，而每个计算节点中部署有与kubernetes Master对应的从属端kubelet组件，从而可通过kubernetes Master与kubelet组件之间的通信进行任务的下发。

在kubernetes的原生逻辑中，也就是图4中所示的方式1，kubernetes Master下发任务给kubelet组件后，kubelet组件会直接向docker组件发起容器创建请求，但是由于这种方式不会对在线任务和离线任务进行区分，从而无法避免离线任务竞争在线任务的资源的问题。

因此，在本申请实施例中，为了实现对离线实现的管理，通过增加了旁路的外部组件的方式，当原生管理组件接收目标计算任务时，需要将目标计算任务转发给离线管理组件进行处理。其中，这里的离线管理组件即为本申请实施例增加的外部组件，离线管理组件与原生管理组件为独立的组件，从而采用这种方式，则无需对容器集群平台的原生代码进行修改，从而减少后续的维护成本。

在具体实施时，一般原生管理组件拥有既定的转发方式，例如通常是节点管理子组件中调用容器引擎子组件对应的第一调用接口，来发送容器创建请求给容器引擎子组件，以请求容器引擎子组件创建容器，因而想要原生管理组件将目标计算任务转发给新增的离线管理组件，那么需要进行一定的处理。

具体的，可以将节点管理子组件中调用容器引擎子组件对应的第一调用接口，修改为任务转发子组件对应的第二调用接口，这样，通过原生管理组件接收目标计算任务后，原生管理组件则会调用第二调用接口，将目标计算任务发送给任务转发子组件，以使得任务转发子组件能够拦截到节点管理子组件向容器引擎子组件发送的容器创建请求，容器创建请求携带了第一容器参数，以及其他目标计算任务相关的信息，例如类型标签。

示例性的，参见图4所示，当容器集群平台为kubernetes平台时，可以将kubelet组件的参数中docker组件的套接字(socket)替换为hook组件(即任务转发子组件)的socket，使得kubelet组件可以和hook组件通信，并将目标计算任务传给hook组件。

当然，离线管理组件可以采用条任何可能的任务获取方式，例如，可以采用任务截取的方式，获取目标计算任务，即离线管理组件可以对节点管理子组件的接收任务进行监听，当监听到新的目标计算任务下发时，则截取目标计算任务。

步骤302：通过离线管理组件，基于类型标签确定目标计算任务是否为离线任务。

本申请实施例中，在线任务和离线任务都是通过容器集群平台来提交的，因而需要对在线任务和离线任务进行区分，那么可以提供给用户在线任务和离线任务的选项，从而基于用户的选择，为用户提交的任务打上相应的类型标签，即，当用户选择离线任务时，则为用户提交的任务添加离线任务对应的类型标签，而当用户选择在线任务时，则为用户提交的任务添加在线任务对应的类型标签。

在一种可能的实施方式中，由于通常任务属性仅包括在线任务和离线任务，那么可以仅对离线任务进行标记，而当未添加类型标签时，则该任务为在线任务。

具体的，当容器集群平台为kubernetes平台时，可以利用kubernetes平台的label功能，在Kubernetes平台提交的任务称之为pod，每个pod都可以打上自定义的评注(annotation)，以展示不同的属性，那么可以给离线任务添加一个特殊的annotation，进而可以通过该annotation区分该任务是否为离线任务。参见如下，为增加了离线标记的样例：

上述为基于kubernetes平台的一个任务类型为daemonset的样例，其annotation增加了离线标记：mixer.kubernetes.io/app-class：greedy，从而该样例属于离线任务。

目标计算任务携带了表征任务属性的类型标签，那么，离线管理组件接收到目标计算任务之后，则可以基于目标计算任务的类型标签确定目标计算任务的任务属性，即确定目标计算任务为离线任务还是在线任务。

具体的，参见图2所示，计算节点的节点管理子组件接收目标计算任务后，将目标计算任务转发给任务转发子组件，从而任务转发子组件基于类型标签确定目标计算任务的任务属性。

步骤303：若通过离线管理组件，基于类型标签确定目标计算任务为离线任务，则将第一容器参数修改为第二容器参数，并将第二容器参数返回给原生管理组件。

本申请实施例中，若通过离线管理组件，基于类型标签确定目标计算任务为离线任务，那么离线管理组件则会对目标计算任务的容器参数进行修改。一般而言，按照容器集群平台的原生逻辑，通常目标计算任务还携带了第一容器参数，第一容器参数指示了原生管理组件管理的第一资源管理目录，即不进行任何处理的情况下，会在第一资源管理目录下创建目标计算任务的运行容器，而第一资源管理目录是由原生管理组件所管理的，例如kubernetes平台的Cgroup目录，在线任务和离线任务均统一管理，从而会产生离线资源竞争在线任务资源的问题。

因此，离线管理组件在判定目标计算任务为离线任务时，则会将第一容器参数修改为第二容器参数，再将第二容器参数发送给原生管理组件，第二容器参数指示了离线管理组件管理的第二资源管理目录，即脱离了容器集群平台管理的目录。

具体的，容器参数的修改可以是由图2所示的任务转发子组件完成的，且任务转发子组件将第一容器参数修改为第二容器参数之后，将携带第二容器参数的容器创建请求，发送给容器引擎子组件，容器创建请求用于请求容器引擎子组件为目标计算任务创建运行容器。

同样以容器集群平台为kubernetes平台为例，参见图3中的方式2，在kubelet组件收到kubernetes Master下发的任务后，会将任务转发给hook组件，hook组件对该任务进行判断，以确定其为离线任务或者在线任务，若为离线任务，则对其容器参数进行修改，即将资源管理目录修改为外部组件管理的第二资源管理目录，并将修改后的容器参数透传给docker组件。

本申请实施例中，任务转发子组件在进行容器参数的修改时，不仅会将第一容器参数中的第一资源管理目录，修改为第二资源管理目录，还会删除第一容器参数中的资源限制参数，从而得到第二容器参数，资源限制参数用于指示为目标计算任务分配的最大资源量，例如CPU资源大小等。

步骤304：通过原生管理组件，基于第二容器参数，在第二资源管理目录下创建目标计算任务的运行容器。

具体的，可通过容器引擎子组件，响应于容器创建请求，基于第二容器参数，在第二资源管理目录下创建目标计算任务的运行容器。

沿用上述kubernetes平台的例子，docker组件基于修改后的容器参数在进行最终的实例拉起操作时，则会在第二资源管理目录下进行创建运行容器，离线任务的运行容器将直接在新的第二资源管理目录创建，而该目录脱离kubernetes平台的管控，从而能够避免离线任务竞争在线任务资源的问题。

本申请实施例中，第二资源管理目录可以包括多个子目录，不同子目录的重要等级或者任务类型不同，那么通过容器引擎子组件创建运行容器时，容器引擎子组件可以基于第二容器参数、目标计算任务对应的目标任务类型以及目标重要等级，来确定目标计算任务对应的目标子目录，从而在目标子目录下，创建目标计算任务的运行容器。

参见图5所示，为本申请实施例提供的目录结构示意图。其中，该目录结构是以kubernetes平台为例，在原生目录结构中，根目录下包含了任务目录(kubepods)以及系统目录(system slice)等目录，其中，任务目录主要用于实现计算任务相关的管理，系统目录主要用于实现系统服务相关的管理，且在任务目录之下，还包括了众多子目录，用于管理不同任务类型和重要等级的任务，如besteffort和burstable属于两种不同任务类型的管理目录，而与这两额子目录平级的任务podxxx其重要等级高于besteffort和burstable下的各个任务。

上述原生目录结构即为kubernetes管理的第一资源管理目录，此外，本申请实施例在任务目录下，还新增了offine目录，即本申请实施例的第二资源管理目录，用于对离线任务进行资源管理，与原生目录结构类似，在第二资源管理目录下，也可以按照不同任务类型和重要等级的不同，对各个离线任务进行管理。

步骤305：若通过离线管理组件，基于类型标签确定目标计算任务为在线任务，则将第一容器参数返回给原生管理组件。

步骤306：通过原生管理组件，基于第一容器参数，在第一资源管理目录下创建目标计算任务的运行容器。

具体的，若基于类型标签确定目标计算任务为在线任务，则任务转发子组件可以将携带第一容器参数的容器创建请求，发送给容器引擎子组件，进而通过容器引擎子组件，响应于容器创建请求，基于第一容器参数，在第一资源管理目录下创建目标计算任务的运行容器。

本申请实施例中，按照图5所示的目录结构，通过hook组件，kubelet组件拉起离线任务的时候，离线任务的进程标识(Process Identification，PID)就直接被放入了offline目录下，但由于offline目录不受kubenetes管理，那么需要额外的组件对其进行管理，因而本申请实施例的离线管理组件还包括了离线资源管理子组件，用于实现对离线资源的代理管理，亦可称为agent组件，可以对offline目录下的所有离线任务进行统一资源管控，即配置offline目录的资源上限，该上限值即为离线任务可用资源，由节点资源和在线任务的空闲资源而来，离线资源管理子组件根据在线任务的空闲资源，实时更新离线可用资源，防止离线任务使用过多的资源，进而对在线任务造成干扰，影响在线任务的正常运行。

请参见图6所示，为离线资源管理子组件进行离线资源管理的原理示意图。其中，离线资源管理子组件可预先获取计算节点的总资源量。此外，计算节点中的原生管理组件还会实时监控各个在线任务各自对应的实际使用资源量，从而离线资源管理子组件，可以调用原生管理组件的资源量获取接口，获取各个在线任务各自对应的实际使用资源量，这样，离线资源管理子组件就可以计算得到该计算节点当前的空闲资源量，进而实时更新调整第二资源管理目录的可用资源上限，也就是在第二资源管理目录下创建的离线任务的运行容器可使用的最大资源量。

在第二资源管理目录下，所有的离线任务弹性共享第二资源管理目录的可用资源，从而进一步提升离线资源利用率，进而提升混部效率。

本申请实施例中，为了解决在线任务和离线任务资源冲突的问题，还可以采用实时资源量调整的方式。具体而言，一般在线任务需要资源时，需要向原生管理组件进行资源申请，从而原生管理组件基于各个在线任务的资源申请请求，分别为各个在线任务分配相应的计算资源量，但是这个时候一般是在线任务申请多少资源就为其分配多少资源，一般申请的资源量都高于实际使用的资源量，因而可以通过原生管理组件对在线任务的实际使用资源量的监测，当监测到任一在线任务的实际使用资源量与分配的计算资源量不符时，则基于实际使用资源量，调整为任一在线任务分配的计算资源量，使得在线任务的资源申请值，接近实际使用资源量，空间的资源则可用于离线任务，这样离线任务可以与在线任务一样受kubernetes统一管理。

此外，还可以在kubenets平台的原生代码提供对外适配接口时，通过扩展用户自定义资源管理方式，来让用户可以对不同的任务设置不同的管理方式。

综上所述，本申请实施例中，采用一种旁路的方式，将离线资源脱离kubernetes的管理，再通过额外组件单独管理离线资源，避免对在线任务造成干扰，进一步提升混部的效率。基于这种旁路机制，可以将混部产品很方便地推广到其他云厂商，另外无需考虑kubernetes版本的升级迭代，直接兼容，维护成本低。

请参见图7，基于同一发明构思，本申请实施例还提供了一种离线任务的集群控制装置70，应用于集群包括的计算节点中，计算节点包括原生管理组件和离线管理组件，该装置包括：

任务获取单元701，用于通过原生管理组件接收目标计算任务，并将目标计算任务转发给离线管理组件；其中，目标计算任务至少携带表征任务属性的类型标签和第一容器参数，任务属性包括离线任务和在线任务，第一容器参数指示原生管理组件管理的第一资源管理目录；

参数修改单元702，用于若通过离线管理组件，基于类型标签确定目标计算任务为离线任务，则将第一容器参数修改为第二容器参数，并将第二容器参数返回给原生管理组件；第二容器参数指示离线管理组件管理的第二资源管理目录；

容器创建单元703，用于通过原生管理组件，基于第二容器参数，在第二资源管理目录下创建目标计算任务的运行容器。

可选的，离线管理组件包括离线资源管理子组件，则该装置还包括：

资源监控单元704，用于通过原生管理组件，监测各个在线任务各自对应的实际使用资源量；

离线资源管理单元705，用于通过离线资源管理子组件，调用原生管理组件的资源量获取接口，获取各个在线任务各自对应的实际使用资源量；通过离线资源管理子组件，基于获得的各个实际使用资源量，以及计算节点的总资源量，确定计算节点的空闲资源量；以及通过离线资源管理子组件，基于空闲资源量，调整第二资源管理目录的可用资源上限；其中，可用资源上限为在第二资源管理目录下创建的运行容器可使用的最大资源量。

可选的，装置还包括资源分配单元706，用于：

通过原生管理组件，基于各个在线任务的资源申请请求，分别为各个在线任务分配相应的计算资源量；

若通过原生管理组件，监测到任一在线任务的实际使用资源量与分配的计算资源量不符时，则基于实际使用资源量，调整为任一在线任务分配的计算资源量。

可选的，原生管理组件包括节点管理子组件和容器引擎子组件，离线管理组件包括任务转发子组件；则任务获取单元701，用于：

将节点管理子组件中调用容器引擎子组件对应的第一调用接口，修改为任务转发子组件对应的第二调用接口；

通过节点管理子组件接收目标计算任务，并调用第二调用接口，将目标计算任务发送给任务转发子组件。

可选的，参数修改单元702，具体用于：

若通过任务转发子组件，基于类型标签确定目标计算任务为离线任务，则将第一容器参数修改为第二容器参数；

通过任务转发子组件，将携带第二容器参数的容器创建请求，发送给容器引擎子组件，容器创建请求用于请求容器引擎子组件为目标计算任务创建运行容器；

容器创建单元703，具体用于：

通过容器引擎子组件，响应于容器创建请求，基于第二容器参数，在第二资源管理目录下创建目标计算任务的运行容器。

可选的，第二资源管理目录包括多个子目录，不同子目录的重要等级或者任务类型不同；则容器创建单元703，具体用于：

通过容器引擎子组件，响应于容器创建请求，基于第二容器参数、目标计算任务对应的目标任务类型以及目标重要等级，确定目标计算任务对应的目标子目录；

通过容器引擎子组件，在目标子目录下，创建目标计算任务的运行容器。

可选的，

参数修改单元702，还用于若通过任务转发子组件，基于类型标签确定目标计算任务为在线任务，则将携带第一容器参数的容器创建请求，发送给容器引擎子组件；

容器创建单元703，还用于通过容器引擎子组件，响应于容器创建请求，基于第一容器参数，在第一资源管理目录下创建目标计算任务的运行容器。

可选的，参数修改单元702，具体用于：

若通过任务转发子组件，基于类型标签确定目标计算任务为在线任务，则将第一容器参数中的第一资源管理目录，修改为第二资源管理目录；以及，

删除第一容器参数中的资源限制参数，以获得第二容器参数，资源限制参数用于指示为目标计算任务分配的最大资源量。

该装置可以用于执行图3～图6所示的实施例中所示的方法，因此，对于该装置的各功能模块所能够实现的功能等可参考图3～图6所示的实施例的描述，不多赘述。

请参见图8，基于同一技术构思，本申请实施例还提供了一种计算机设备80，可以包括存储器801和处理器802。

所述存储器801，用于存储处理器802执行的计算机程序。存储器801可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据计算机设备的使用所创建的数据等。处理器802，可以是一个中央处理单元(central processing unit，CPU)，或者为数字处理单元等等。本申请实施例中不限定上述存储器801和处理器802之间的具体连接介质。本申请实施例在图8中以存储器801和处理器802之间通过总线803连接，总线803在图8中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线803可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器801可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器801也可以是非易失性存储器(non-volatilememory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)、或者存储器801是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器801可以是上述存储器的组合。

处理器802，用于调用所述存储器801中存储的计算机程序时执行如图3～图6所示的实施例中设备所执行的方法。

在一些可能的实施方式中，本申请提供的方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算机设备上运行时，所述程序代码用于使所述计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的方法中的步骤，例如，所述计算机设备可以执行如图3～图6所示的实施例中设备所执行的方法。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (11)

1.一种离线任务的集群控制方法，其特征在于，应用于集群包括的计算节点中，所述计算节点包括原生管理组件和离线管理组件，所述方法包括：

通过所述原生管理组件接收目标计算任务，并将所述目标计算任务转发给所述离线管理组件；其中，所述目标计算任务至少携带表征任务属性的类型标签和第一容器参数，所述任务属性包括离线任务和在线任务，所述第一容器参数指示所述原生管理组件管理的第一资源管理目录；

若通过所述离线管理组件，基于所述类型标签确定所述目标计算任务为离线任务，则将所述第一容器参数修改为第二容器参数，并将所述第二容器参数返回给所述原生管理组件；所述第二容器参数指示所述离线管理组件管理的第二资源管理目录；

通过所述原生管理组件，基于所述第二容器参数，在所述第二资源管理目录下创建所述目标计算任务的运行容器。

2.如权利要求1所述的方法，其特征在于，所述离线管理组件包括离线资源管理子组件，则所述方法还包括：

通过所述原生管理组件，监测各个在线任务各自对应的实际使用资源量；

通过所述离线资源管理子组件，调用所述原生管理组件的资源量获取接口，获取所述各个在线任务各自对应的实际使用资源量；

通过所述离线资源管理子组件，基于获得的各个实际使用资源量，以及所述计算节点的总资源量，确定所述计算节点的空闲资源量；

通过所述离线资源管理子组件，基于所述空闲资源量，调整所述第二资源管理目录的可用资源上限；其中，所述可用资源上限为在所述第二资源管理目录下创建的运行容器可使用的最大资源量。

3.如权利要求2所述的方法，其特征在于，所述方法还包括：

通过所述原生管理组件，基于各个在线任务的资源申请请求，分别为各个在线任务分配相应的计算资源量；

若通过所述原生管理组件，监测到任一在线任务的实际使用资源量与分配的计算资源量不符时，则基于所述实际使用资源量，调整为所述任一在线任务分配的计算资源量。

4.如权利要求1所述的方法，其特征在于，所述原生管理组件包括节点管理子组件和容器引擎子组件，所述离线管理组件包括任务转发子组件；则所述方法还包括：

将所述节点管理子组件中调用所述容器引擎子组件对应的第一调用接口，修改为所述任务转发子组件对应的第二调用接口；

则通过所述原生管理组件接收目标计算任务，并将所述目标计算任务转发给所述离线管理组件，包括：

通过所述节点管理子组件接收目标计算任务，并调用所述第二调用接口，将所述目标计算任务发送给所述任务转发子组件。

5.如权利要求4所述的方法，其特征在于，若通过所述离线管理组件，基于所述类型标签确定所述目标计算任务为离线任务，则将所述第一容器参数修改为第二容器参数，并将所述第二容器参数返回给所述原生管理组件，包括：

若通过所述任务转发子组件，基于所述类型标签确定所述目标计算任务为离线任务，则将所述第一容器参数修改为所述第二容器参数；

通过所述任务转发子组件，将携带所述第二容器参数的容器创建请求，发送给所述容器引擎子组件，所述容器创建请求用于请求所述容器引擎子组件为所述目标计算任务创建所述运行容器；

则通过所述原生管理组件，基于所述第二容器参数，在所述第二资源管理目录下创建所述目标计算任务的运行容器，包括：

通过所述容器引擎子组件，响应于所述容器创建请求，基于所述第二容器参数，在所述第二资源管理目录下创建所述目标计算任务的运行容器。

6.如权利要求5所述的方法，其特征在于，所述第二资源管理目录包括多个子目录，不同子目录的重要等级或者任务类型不同；

则通过所述容器引擎子组件，响应于所述容器创建请求，基于所述第二容器参数，在所述第二资源管理目录下创建所述目标计算任务的运行容器，包括：

通过所述容器引擎子组件，响应于所述容器创建请求，基于所述第二容器参数、所述目标计算任务对应的目标任务类型以及目标重要等级，确定所述目标计算任务对应的目标子目录；

通过所述容器引擎子组件，在所述目标子目录下，创建所述目标计算任务的运行容器。

7.如权利要求4所述的方法，其特征在于，所述方法还包括：

若通过所述任务转发子组件，基于所述类型标签确定所述目标计算任务为在线任务，则将携带所述第一容器参数的容器创建请求，发送给所述容器引擎子组件；

通过所述容器引擎子组件，响应于所述容器创建请求，基于所述第一容器参数，在所述第一资源管理目录下创建所述目标计算任务的运行容器。

8.如权利要求1～7任一所述的方法，其特征在于，若通过所述离线管理组件，基于所述类型标签确定所述目标计算任务为离线任务，则将所述第一容器参数修改为第二容器参数，包括：

若通过所述任务转发子组件，基于所述类型标签确定所述目标计算任务为在线任务，则将第一容器参数中的所述第一资源管理目录，修改为所述第二资源管理目录；以及，

删除所述第一容器参数中的资源限制参数，以获得所述第二容器参数，所述资源限制参数用于指示为所述目标计算任务分配的最大资源量。

9.一种离线任务的集群控制装置，其特征在于，应用于集群包括的计算节点中，所述计算节点包括原生管理组件和离线管理组件，所述装置包括：

任务获取单元，用于通过所述原生管理组件接收目标计算任务，并将所述目标计算任务转发给所述离线管理组件；其中，所述目标计算任务至少携带表征任务属性的类型标签和第一容器参数，所述任务属性包括离线任务和在线任务，所述第一容器参数指示所述原生管理组件管理的第一资源管理目录；

参数修改单元，用于若通过所述离线管理组件，基于所述类型标签确定所述目标计算任务为离线任务，则将所述第一容器参数修改为第二容器参数，并将所述第二容器参数返回给所述原生管理组件；所述第二容器参数指示所述离线管理组件管理的第二资源管理目录；

容器创建单元，用于通过所述原生管理组件，基于所述第二容器参数，在所述第二资源管理目录下创建所述目标计算任务的运行容器。

10.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，

所述处理器执行所述计算机程序时实现权利要求1至8任一项所述方法的步骤。

11.一种计算机存储介质，其上存储有计算机程序指令，其特征在于，

该计算机程序指令被处理器执行时实现权利要求1至8任一项所述方法的步骤。

Images