CN114327881A - 任务调度方法及装置 - Google Patents

Abstract

本公开关于一种任务调度方法及装置。该任务调度包括：获取待调度任务的CPU预估使用资源量和内存预估使用资源量；针对集群中每个节点，执行如下第一操作：基于当前节点的CPU总资源量和CPU资源利用率以及CPU预估使用资源量，得到当前节点的CPU预估剩余资源量；基于当前节点的内存总资源量和内存资源利用率以及内存预估使用资源量，得到当前节点的内存预估剩余资源量；基于集群中每个节点的CPU预估剩余资源量和内存预估剩余资源量，确定集群中资源利用率最低的节点作为目标节点；将待调度任务调度到目标节点上运行。

Description

任务调度方法及装置

技术领域

本公开涉及计算机领域，尤其涉及一种任务调度方法及装置。

背景技术

目前，云原生是一个非常典型且流行的技术，由于云原生具有构建应用简便快捷，部署应用轻松自如、运行应用按需伸缩等诸多优点，近年来受到各大厂家的青睐和追捧。Kubernetes是云原生技术落地的核心要素，它是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。

相关技术中kube-scheduler的调度策略是静态的，只关心待调度任务的标记语言(Yet Another Markup Language，缩写为yaml)配置文件中设置的固定的申请资源(request)值以及节点的总资源量，由于request值对应的申请资源一般不会被完全利用，因此，基于此得到节点的未使用资源并不准确，也即相关技术没有考虑集群中节点的实际资源使用情况，导致集群中有些节点没有被充分利用，还有些节点的资源使用水位比较高，有内存用完(Out Of Memory，缩写为OOM)的风险。

发明内容

本公开提供一种任务调度方法及装置，以至少解决相关技术中的调度策略常常导致集群中节点的资源无法被充分利用或者存在OOM风险的问题。

根据本公开实施例的第一方面，提供一种任务调度，包括：获取待调度任务的CPU预估使用资源量和内存预估使用资源量；针对集群中每个节点，执行如下第一操作：基于当前节点的CPU总资源量和CPU资源利用率以及CPU预估使用资源量，得到当前节点的CPU预估剩余资源量；基于当前节点的内存总资源量和内存资源利用率以及内存预估使用资源量，得到当前节点的内存预估剩余资源量；基于集群中每个节点的CPU预估剩余资源量和内存预估剩余资源量，确定集群中资源利用率最低的节点作为目标节点；将待调度任务调度到目标节点上运行。

可选地，在基于当前节点的CPU总资源量和CPU资源利用率以及CPU预估使用资源量，得到当前节点的CPU预估剩余资源量和基于当前节点的内存总资源量和内存资源利用率以及内存预估使用资源量，得到当前节点的内存预估剩余资源量之前，包括：监控当前节点的CPU实际资源利用率和内存实际资源利用率；将监控到的CPU实际资源利用率和内存实际资源利用率发送到时序数据库；周期性的将时序数据库中CPU实际资源利用率和内存实际资源利用率写入当前节点。

可选地，在获取待调度任务的CPU预估使用资源量和内存预估使用资源量之后，还包括：基于待调度任务的CPU预估使用资源量、当前节点的CPU总资源量和CPU实际资源利用率，得到当前节点的CPU预估资源利用率；基于待调度任务的内存预估使用资源量、当前节点的内存总资源量和内存实际资源利用率，得到当前节点的内存预估资源利用率；基于CPU预估资源利用率和内存预估资源利用率更新当前节点中的CPU资源利用率和内存资源利用率。

可选地，在任务调度方法应用于Kubernetes平台的情况下，写入和更新操作通过Kubernetes平台的调度器中Reserve拓展点执行。

可选地，基于集群中每个节点的CPU预估剩余资源量和内存预估剩余资源量，确定集群中资源利用率最低的节点作为目标节点，包括：确定集群中每个节点的CPU预估剩余资源量在CPU总资源量的第一占比和内存预估剩余资源量在内存总资源量的第二占比；基于集群中第一占比和第二占比，确定集群中资源利用率最低的节点作为目标节点。

可选地，基于集群中第一占比和第二占比，确定集群中资源利用率最低的节点作为目标节点，包括：针对集群中每个节点，执行如下第二操作：基于当前节点的第一占比，得到当前节点的第一评估指标；基于当前节点的第二占比，得到当前节点的第二评估指标；将第一评估指标和第二评估指标进行加权处理，得到当前节点的评估指标，其中，评估指标与第一占比、第二占比成正比例关系；将集群中评估指标最高的节点，确定为目标节点。

可选地，在任务调度方法应用于Kubernetes平台的情况下，第一操作和第二操作通过Kubernetes平台的调度器中Score拓展点执行。

可选地，获取待调度任务的CPU预估使用资源量和内存预估使用资源量，包括：基于待调度任务的CPU资源申请量和待调度任务的CPU资源利用率，得到待调度任务的CPU预估使用资源量；基于待调度任务的内存资源申请量和待调度任务的内存资源利用率，得到待调度任务的内存预估使用资源量。

可选地，基于当前节点的CPU总资源量和CPU资源利用率以及CPU预估使用资源量，得到当前节点的CPU预估剩余资源量，包括：基于当前节点的CPU总资源量和CPU资源利用率，得到当前节点的CPU未使用资源；基于当前节点的CPU未使用资源量和CPU预估使用资源量，得到当前节点的CPU预估剩余资源量；基于当前节点的内存总资源量和内存资源利用率以及内存预估使用资源量，得到当前节点的内存预估剩余资源量，包括：基于当前节点的内存总资源量和内存资源利用率，得到当前节点的内存未使用资源；基于当前节点的内存未使用资源量和内存预估使用资源量，得到当前节点的内存预估剩余资源量。

根据本公开实施例的第二方面，提供一种任务调度装置，包括：预估使用资源量获取单元，被配置为获取待调度任务的CPU预估使用资源量和内存预估使用资源量；剩余资源量获取单元，被配置为针对集群中每个节点，执行如下第一操作：基于当前节点的CPU总资源量和CPU资源利用率以及CPU预估使用资源量，得到当前节点的CPU预估剩余资源量；基于当前节点的内存总资源量和内存资源利用率以及内存预估使用资源量，得到当前节点的内存预估剩余资源量；确定单元，被配置为基于集群中每个节点的CPU预估剩余资源量和内存预估剩余资源量，确定集群中资源利用率最低的节点作为目标节点；调度单元，被配置为将待调度任务调度到目标节点上运行。

可选地，剩余资源量获取单元，还被配置为在基于当前节点的CPU总资源量和CPU资源利用率以及CPU预估使用资源量，得到当前节点的CPU预估剩余资源量和基于当前节点的内存总资源量和内存资源利用率以及内存预估使用资源量，得到当前节点的内存预估剩余资源量之前，监控当前节点的CPU实际资源利用率和内存实际资源利用率；将监控到的CPU实际资源利用率和内存实际资源利用率发送到时序数据库；周期性的将时序数据库中CPU实际资源利用率和内存实际资源利用率写入当前节点。

可选地，剩余资源量获取单元，还被配置为在获取待调度任务的CPU预估使用资源量和内存预估使用资源量之后，基于待调度任务的CPU预估使用资源量、当前节点的CPU总资源量和CPU实际资源利用率，得到当前节点的CPU预估资源利用率；基于待调度任务的内存预估使用资源量、当前节点的内存总资源量和内存实际资源利用率，得到当前节点的内存预估资源利用率；基于CPU预估资源利用率和内存预估资源利用率更新当前节点中的CPU资源利用率和内存资源利用率。

可选地，在任务调度方法应用于Kubernetes平台的情况下，写入和更新操作通过Kubernetes平台的调度器中Reserve拓展点执行。

可选地，确定单元，还被配置为确定集群中每个节点的CPU预估剩余资源量在CPU总资源量的第一占比和内存预估剩余资源量在内存总资源量的第二占比；基于集群中第一占比和第二占比，确定集群中资源利用率最低的节点作为目标节点。

可选地，确定单元，还被配置为针对集群中每个节点，执行如下第二操作：基于当前节点的第一占比，得到当前节点的第一评估指标；基于当前节点的第二占比，得到当前节点的第二评估指标；将第一评估指标和第二评估指标进行加权处理，得到当前节点的评估指标，其中，评估指标与第一占比、第二占比成正比例关系；将集群中评估指标最高的节点，确定为目标节点。

可选地，在任务调度方法应用于Kubernetes平台的情况下，第一操作和第二操作通过Kubernetes平台的调度器中Score拓展点执行。

可选地，预估使用资源量获取单元，还被配置为基于待调度任务的CPU资源申请量和待调度任务的CPU资源利用率，得到待调度任务的CPU预估使用资源量；基于待调度任务的内存资源申请量和待调度任务的内存资源利用率，得到待调度任务的内存预估使用资源量。

可选地，剩余资源量获取单元，还被配置为基于当前节点的CPU总资源量和CPU资源利用率，得到当前节点的CPU未使用资源；基于当前节点的CPU未使用资源量和CPU预估使用资源量，得到当前节点的CPU预估剩余资源量；基于当前节点的内存总资源量和内存资源利用率，得到当前节点的内存未使用资源；基于当前节点的内存未使用资源量和内存预估使用资源量，得到当前节点的内存预估剩余资源量。

根据本公开实施例的第五方面，提供了一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，处理器被配置为执行指令，以实现根据本公开的任务调度方法。

根据本公开实施例的第六方面，提供了一种计算机可读存储介质，当计算机可读存储介质中的指令被至少一个处理器运行时，促使至少一个处理器执行如上根据本公开的任务调度方法。

根据本公开实施例的第七方面，提供了一种计算机程序产品，包括计算机指令，计算机指令被处理器执行时实现根据本公开的任务调度方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

根据本公开的任务调度方法及装置，从节点的资源利用率出发充分考虑了节点的实际资源使用情况，从而可以得到准确的预估剩余资源量，进而可以基于准确的预估剩余资源确定资源利用率最低的节点，并将待调度任务调度到该节点上，使得每次调度完任务，即将节点调度到目标节点后，集群中所有节点的资源利用率更加均衡，方差更小，一方面可以避免部分节点的资源利用率过高，带来潜在的危险，另一方面也使得所有节点的资源都能得到充分利用。因此，本公开解决了相关技术中的调度策略常常导致集群中节点的资源无法被充分利用或者存在OOM风险的问题。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是相关技术中Kubernetes的结构示意图；

图2是相关技术中Scheduling Framework的工作流程图；

图3是示出根据本公开的示例性实施例的任务调度方法的实施场景示意图；

图4是根据一示例性实施例示出的一种任务调度方法的流程图；

图5是根据一示例性实施例示出的一种Reserve拓展点更新资源利用率的逻辑示意图；

图6是根据一示例性实施例示出的一种Score拓展点打分的逻辑示意图；

图7是根据一示例性实施例示出的一种可选任务调度方法的示意图；

图8是根据一示例性实施例示出的一种从开发到调度的流程图；

图9是根据一示例性实施例示出的一种任务调度装置的框图；

图10是根据本公开实施例的一种电子设备1000的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

在此需要说明的是，在本公开中出现的“若干项之中的至少一项”均表示包含“该若干项中的任意一项”、“该若干项中的任意多项的组合”、“该若干项的全体”这三类并列的情况。例如“包括A和B之中的至少一个”即包括如下三种并列的情况：(1)包括A；(2)包括B；(3)包括A和B。又例如“执行步骤一和步骤二之中的至少一个”，即表示如下三种并列的情况：(1)执行步骤一；(2)执行步骤二；(3)执行步骤一和步骤二。

针对上述问题，本公开提供了一种任务调度方法，能够避免部分节点的资源利用率过高，带来潜在的危险，也使得所有节点的资源都能得到充分利用，下面以基于Kubernetes的同步数据的场景为例进行说明。

为了方便理解本公开，首先对Kubernetes进行简单介绍。

图1是相关技术中Kubernetes的结构示意图，如图1所示，主要包括以下几类组件：

(1)kube-apiserver：它是Kubernetes最重要的核心组件之一，提供集群管理的REST API接口，包括认证授权、数据校验以及集群状态变更等。此外它还提供其他模块之间的数据交互和通信的功能，也就是其他模块通过API Server查询或修改数据，只有APIServer才直接操作etcd。

(2)控制器管理器(Controller Manager)：它由Kubernetes控制器管理器(kube-controller-manager)和云控制器管理器(cloud-controller-manager)组成，是Kubernetes的大脑，通过apiserver监控整个集群的状态，并确保集群处于预期的工作状态。

(3)etcd：是一种分布式key-value数据库，基于Raft一致性协议开发，可用于服务发现、共享配置以及一致性保障(如数据库选主、分布式锁等)。

(4)Kubernetes调度器(kube-scheduler)：它是Kubernetes的调度器，也属于控制平面组件，负责监视新创建的、未指定运行节点的任务(Pods)，选择一个合适的节点并将Pod调度到其上运行。kube-scheduler调度决策考虑的因素包括单个Pod和Pod集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。随着企业应用场景的增加，对调度的方式和效果也提出了更高的要求，kube-scheduler能提供的策略已经无法满足，因此，可以使用K8s提供的一种用于拓展kube-scheduler功能的方式，即调度框架(Scheduling Framework)来拓展kube-scheduler的功能，图2是相关技术中Scheduling Framework的工作流程图，可以看到每次调度器在调度一个Pod的过程都分为两个阶段：调度周期和绑定周期。在调度周期中，调度器会为Pod选择一个最合适它运行的节点，这里又分为预选和优选两个阶段，预选是从所有节点中筛选出能承载该Pod的一部分，优选则是对这些筛选后的节点按照某种策略打分，pod就会被调度到得分最高的节点上。然后调度过程将进入绑定周期，在绑定周期中，调度器会检测调度周期中选中的那个“最合适的节点”是不是真的可以让这个Pod稳定的运行，或者需不需要做一些初始化操作。Scheduling Framework最核心的部分就是拓展点的设计，它为开发者提供了丰富的扩展点，当开发者想实现新的调度策略时，就可以通过实现这些不同拓展点的接口，在调度pod期间的不同阶段执行相应的逻辑处理，从而组合实现更复杂或有状态的任务，上述过程就相当于实现了一个插件，在调度pod期间，不同的插件在相同或不同的拓展点执行各自的逻辑，就组成了整个调度的流程。

需要说明的是，kube-scheduler作为Kubernetes的默认调度器，在1.15版本后开始基于调度框架(Scheduling Framework)重构，并将预制的若干策略进行插件化，这些插件分别实现了不同的逻辑方法，一个逻辑方法集成一个接口，其中，可以修改的逻辑方法集成的接口称为拓展点。在设计上，Kubernetes允许开发者自己写一个调度组件并替换原有的kube-scheduler中的某一组件(组件可以包括一个拓展点或多个拓展点)。

(5)kubelet：运行在Worker Node上，接收并执行Kubernetes Master发来的指令，管理Pod及Pod中的容器。每个Kubelet进程会在API Server上注册所在Node节点的信息，定期向主节点(Master)汇报该节点的资源使用情况，并通过cAdvisor监控节点和容器的资源。

(6)Kubernetes代理(kube-proxy)：同样运行在Worker Node上，监听API server中service和endpoint的变化情况，为服务配置负载均衡。

图3是示出根据本公开的示例性实施例的任务调度方法的实施场景示意图，如图3所述，该实施场景包括服务器100、用户终端110和用户终端120，其中，用户终端不限于2个，包括并不限于手机、个人计算机等设备，用户终端可以安装运行代码的应用程序，服务器可以是一个服务器，也可以是若干个服务器组成服务器集群，还可以是云计算平台或虚拟化中心，在本实施例中服务器100以若干个服务器组成服务器集群为例。

用户终端110和用户终端120需要同步数据时，其上的应用程序可以向kube-apiserver发起创建任务(pod)的请求，kube-apiserver处理请求，将pod的yaml配置文件存储到etcd，然后，controller-Manager通过查看(watch)机制，发现kube-apiserver中pod信息的更新，整合该资源所依赖的拓扑结构，然后将对应的信息写到etcd。接下来进入pod的调度阶段，kube-scheduler获取待调度任务pod的CPU预估使用资源量和内存预估使用资源量；针对集群(服务器100)中每个节点(也即组成集群的服务器)，执行如下第一操作：基于当前节点的CPU总资源量和CPU资源利用率，得到当前节点的CPU未使用资源；基于当前节点的CPU未使用资源量和待调度任务的CPU预估使用资源量，得到当前节点的CPU预估剩余资源量；基于当前节点的内存总资源量和内存资源利用率，得到当前节点的内存未使用资源；基于当前节点的内存未使用资源量和待调度任务的内存预估使用资源量，得到当前节点的内存预估剩余资源量；基于集群中每个节点的CPU预估剩余资源量和内存预估剩余资源量，确定集群中资源利用率最低的节点作为目标节点。确定完目标节点后，将pod调度到目标节点上运行，也即通过目标节点实现用户终端110和用户终端120的数据同步。

下面，将参照图4至图9详细描述根据本公开的示例性实施例的任务调度方法及装置。

图4是根据一示例性实施例示出的一种任务调度方法的流程图，如图4所示，任务调度方法包括以下步骤：

在步骤S401中，获取待调度任务的CPU预估使用资源量和内存预估使用资源量。

根据本公开的示例性实施例，获取待调度任务的CPU预估使用资源量和内存预估使用资源量，包括：基于待调度任务的CPU资源申请量和待调度任务的CPU资源利用率，得到待调度任务的CPU预估使用资源量；基于待调度任务的内存资源申请量和待调度任务的内存资源利用率，得到待调度任务的内存预估使用资源量。根据本实施例，由于资源申请量和资源利用率比较容易获取，因此，基于资源申请量和资源利用率可以方便、快速的得到预估使用资源量。

例如，可以创建该待调度任务时的配置文件，获取待调度任务针对CPU的资源申请量(也即上述CPU资源申请量)和内存的资源申请量(也即上述内存资源申请量)，再获取过去一段时间内与该待调度任务同类别的CPU资源利用率和内存资源利用率，将过去一段时间内CPU资源利用率的平均值和内存资源利用率平均值分别作为待调度任务的CPU资源利用率和内存资源利用率，然后，通过各自的资源申请量和资源利用率的平均值的乘积，得到各自的预估使用资源量。需要说明的时，过去一段时间内与该待调度任务同类别的CPU的资源利用率和内存资源利用率可以存储在时序数据库(Prometheus)中，但是本公开对此并不限定。当过去一段时间内与该待调度任务同类别的CPU的资源利用率和内存资源利用率存储在时序数据库中时，可以通过客户端(client)与Prometheus建立连接，执行相应的PromQL语句获取过去一段时间内与该待调度任务同类别的CPU的资源利用率和内存资源利用率。

返回图4，在步骤S402中，针对集群中每个节点，执行如下第一操作：基于当前节点的CPU总资源量和CPU资源利用率以及CPU预估使用资源量，得到当前节点的CPU预估剩余资源量；基于当前节点的内存总资源量和内存资源利用率以及内存预估使用资源量，得到当前节点的内存预估剩余资源量。

根据本公开的示例性实施例，基于当前节点的CPU总资源量和CPU资源利用率以及CPU预估使用资源量，得到当前节点的CPU预估剩余资源量，包括：基于当前节点的CPU总资源量和CPU资源利用率，得到当前节点的CPU未使用资源；基于当前节点的CPU未使用资源量和CPU预估使用资源量，得到当前节点的CPU预估剩余资源量；基于当前节点的内存总资源量和内存资源利用率以及内存预估使用资源量，得到当前节点的内存预估剩余资源量，包括：基于当前节点的内存总资源量和内存资源利用率，得到当前节点的内存未使用资源；基于当前节点的内存未使用资源量和内存预估使用资源量，得到当前节点的内存预估剩余资源量。根据本实施例，基于总资源量和资源利用率得到未使用资源量，再结合预估使用资源，可以得到准确的预估剩余资源。例如，可以将当前节点的CPU的总资源量和资源利用率相乘，得到当前节点的CPU的未使用资源，可以将当前节点的CPU的未使用资源量减去针对CPU的预估使用资源量，得到当前节点的CPU的剩余资源量。对于内存的剩余资源量与CPU的类似，此处不再展开论述。

根据本公开的示例性实施例，在基于当前节点的CPU总资源量和CPU资源利用率以及CPU预估使用资源量，得到当前节点的CPU预估剩余资源量和基于当前节点的内存总资源量和内存资源利用率以及内存预估使用资源量，得到当前节点的内存剩余资源量之前，包括：监控当前节点的CPU实际资源利用率和内存实际资源利用率；将监控到的CPU实际资源利用率和内存实际资源利用率发送到时序数据库；周期性的将时序数据库中CPU实际资源利用率和内存实际资源利用率写入当前节点。根据本实施例，通过监控系统实时监控集群中每个节点的CPU和内存的实际资源利用率，将其存储在时序数据库中，并将时序数据库中的实际资源利用率周期性的写入当前节点，从而在后续当前节点需要调用资源利用率时，可以及时提供CPU资源利用率和内存资源利用率。

例如，可以单设置一个可以独立运行的监控模块，主要功能就是监测节点的pod的资源使用情况并为任务调度提供及时的资源利用率数据，具体地，监控模块可以通过Prometheus+cAdvisor实现，首先，监测单元(cAdvisor)运行在每个节点上，检测所在节点的容器的各项指标，并上报给时序数据库(Prometheus)存储，该时序数据库可通过其提供的PromQL语言来对各项指标进行多维度的查询和运算。而考虑到网络开销和实时性，时间过短会使得网络开销增大，时间过长就无法满足实时性，故上述周期可以设置为5分钟。此时，Prometheus每5分钟会更新一次节点中资源利用率，例如资源利用率可以存储在节点的预定位置(如，节点的属性中Annotation字段，又如已调度任务的yaml配置文件中)，后续再进行打分时，只需要读取该字段就能知道节点的资源利用率是否发生了变化。

根据本公开的示例性实施例，在获取待调度任务的CPU预估使用资源量和内存预估使用资源量之后，还包括：基于待调度任务的CPU预估使用资源量、当前节点的CPU总资源量和CPU实际资源利用率，得到当前节点的CPU预估资源利用率；基于待调度任务的内存预估使用资源量、当前节点的内存总资源量和内存实际资源利用率，得到当前节点的内存预估资源利用率；基于CPU预估资源利用率和内存预估资源利用率更新当前节点中的CPU资源利用率和内存资源利用率。根据本实施例，更新周期内，如果有待调度任务已经调度到当前节点时，可以通过预估资源利用率更新，保证当前节点的资源利用率是随着调度任务实时变化的，避免在更新周期内，调度到重复的资源利用率。例如，在更新周期中需要调度两个任务，在第一个任务调度完，但并未到下一个更新周期时，则并不更新预定位置的资源利用率，然而实际资源利用率已经发生了变化，即第一个任务占用了一部分资源，如果仍按未更新的资源利用率调度第二任务，未考虑到第一个任务，使得最终的调度结果并不符合选取资源利用率最低的节点这一思想，导致调度的结果并不准确。

例如，由于每5分钟更新一次，在5分钟中间很有可能完成了一次任务调度，也就是说该任务已经占用一部分资源，但是，当前节点中的资源利用率还是该任务调度前的实际资源利用率，此时如果已经开始下一任务的调度，也就是开始了给下一任的节点打分的情况下，如果还是用上述实际资源利用率是不合理的。因此，在读取和更新节点的资源利用率时可以用到两个变量，设为(readValue，actualValue)，readValue是每次读取到的值，每5分钟会用Prometheus中监测得到的数据更新一次；actualValue是估算的值，也即本公开实施例中预估资源利用率。每次在更新某个节点的资源利用率时，应该先比较当前readValue的值和上一次读取readValue的值是否发生了变化。如果没有变，则直接在actualValue原来的值的基础上增加当次的pod的预估使用资源量与目标节点的比值即可；如果发生了变化，则actualValue应该先设为和readValue值一致，达到校准的目的，然后再更新。

根据本公开的示例性实施例，在任务调度方法应用于Kubernetes平台的情况下，上述写入和更新操作通过Kubernetes平台的调度器中Reserve拓展点执行。通过Reserve拓展点可以更及时的更新资源利用率，以方便后续调用资源利用率。

具体地，Reserve拓展点更新资源利用率的逻辑如图5所示，由于该拓展点传入的参数就是最终承载待调度pod的节点，因此需要做的就是先根据pod申请的资源量和资源利用率计算估计pod的预估使用资源量，然后计算预估使用资源量占目标节点总资源量的比例，最后在资源利用率Map中更新该节点对应的值即可。目标节点更新后的资源利用率计算公式为：目标节点新资源利用率＝目标节点原资源利用率+(pod申请资源量×pod资源利用率)/目标节点总资源量。由于Reserve拓展点的前面几步和Score拓展点的逻辑是类似的，因此可以将重复值存放在Map中，从而避免重复计算获取。

Reserve拓展点在Kubernetes平台中调度器的原始作用是在pod等待绑定操作成功之前避免出现竞争条件，但在本公开修改后不仅保留原来的逻辑方法，还执行如下逻辑：根据调度结果更新Score拓展点的代码中节点的资源利用率对应的Map，即实现上述实施例中的写入和更新操作。需要说明的时，虽然更新的是Score拓展点的代码中节点的资源利用率对应的Map，但是采用Score拓展点来执行并不理想，这是因为在一个pod的调度周期中，Score拓展点只负责打分，为了计算多个节点的分数，其逻辑会被多个协程并发执行，因此无法得知哪个节点得分最高，而到了Reserve拓展点时，可以获取所有节点的得分，以确定承载该pod的目标节点，从而可以更新代码中维护的节点的资源利用率。而且，经过尝试，在其他拓展点也不理想，如，在绑定周期的拓展点上执行上述逻辑的话，也是有问题的，因为当多个pod同时等待调度时，上一个pod的绑定周期还未执行完时，下一个pod可能就要执行Score拓展点的逻辑了，而此时资源利用率的Map还未更新，因此会对调度结果造成影响。因此，在调度周期中Score拓展点后面的Reserve拓展点执行更新资源利用率的Map是最合适的。

返回图4，在步骤S403中，基于集群中每个节点的CPU预估剩余资源量和内存预估剩余资源量，确定集群中资源利用率最低的节点作为目标节点。例如，本步骤和步骤402相当于调度周期中的优选部分，一般来讲，在优选部分之前还需要进行预选部分，预选部分是从集群的节点中根据若干条件筛选出符合条件的节点(比如剩余资源大于pod需求、pod镜像本地已存在等)，优选部分是按照算法对这批符合条件的节点进行筛选，选出最合适的节点，如资源利用率最低的节点。接下来进入绑定周期，pod就会被绑定到该节点上，也即调度到该节点上。

在步骤S403中，将待调度任务调度到目标节点上运行。

根据本公开的示例性实施例，基于集群中每个节点的CPU预估剩余资源量和内存预估剩余资源量，确定集群中资源利用率最低的节点作为目标节点，包括：确定集群中每个节点的CPU预估剩余资源量在CPU总资源量的第一占比和内存预估剩余资源量在内存总资源量的第二占比；基于集群中第一占比和第二占比，确定集群中资源利用率最低的节点作为目标节点。根据本实施例，通过剩余资源在总资源的占比，可以快速的确定资源利用率量最低的节点，以及时避免部分节点的资源利用率过高，带来潜在的危险，以及进一步的得所有节点的资源都能得到充分利用。

根据本公开的示例性实施例，基于集群中第一占比和第二占比，确定集群中资源利用率最低的节点作为目标节点，包括：针对集群中每个节点，执行如下第二操作：基于当前节点的第一节点，得到当前节点的第一评估指标；基于当前节点的第二占比，得到当前节点的评估指标；将第一评估指标和第二评估指标进行加权处理，得到当前节点的评估指标，其中，评估指标与第一节点、第二占比成正比例关系；将集群中评估指标最高的节点，确定为目标节点。根据本实施例，使用加权后处理的方式，可以较好的考虑到CPU和内存的预估剩余资源量的占比，以得到更准确的资源利用率最低的节点。

例如，此时是按照算法对这批符合条件的节点进行打分，选出得分最高的节点，也即本公开剩余资源量在总资源量中占比最高的节点，此时，可以将CPU的剩余资源量对应的占比得分和内存的剩余资源量的占比得分进行加权处理，来得到一个综合分数，从而最高分的节点可以表示剩余资源量占比最高的节点。

根据本公开的示例性实施例，在任务调度方法应用于Kubernetes平台的情况下，第一操作和第二操作通过于Kubernetes平台的调度器中Score拓展点执行。通过本实施例，由于在Kubernetes平台中，一直采用Score拓展点实现打分逻辑，本公开没有更换打分逻辑在整个平台中的执行顺序，因此可以方便的将本公开的调度方法中的打分环节引入Kubernetes的调度器中。例如，执行Score拓展点的方法逻辑，即从监控模块中获取集群中节点的资源利用率，结合待调度任务的预估使用资源量，确定资源利用率最低的节点并为其打最高分，这样会使得集群中节点的资源利用率的水位比较均衡。

具体地，通过Score拓展点打分逻辑如图6所示，首先，需要计算pod的CPU资源申请量和内存资源申请量(request)，然后从Prometheus中用PromQL查询获取该类Pod在过去一段时间的CPU和内存的资源利用率，从而计算出pod的CPU和内存的预估使用资源量，接下来由于能够得到节点能提供的总资源量和资源利用率，因此可以计算节点实际已使用的资源量，从节点的总资源量中减去实际已使用的资源量，可以得到节点未使用的资源量，再用节点未使用的资源量减去pod的预估使用资源量，就得到了若pod被调度到该节点上之后，节点的剩余资源量(包括CPU和内存的剩余资源量)。用该剩余资源量除以节点的总资源量再乘100，就得到了该节点的分值，节点分数的计算公式为：节点的分数＝(节点的未使用的资源量-pod的预估使用资源量)*100/节点的总资源量。

下面结合图7系统的说明本公开的任务调度方法，图7是根据一示例性实施例示出的一种可选任务调度方法的示意图，图7给出了本公开中最小调度单元(Least-scheduler)的工作方式和涉及到的组件，整体分为监控模块和调度模块：监控模块通过Prometheus+cAdvisor实现，首先，监测单元(cAdvisor)运行在每个节点上，检测所在节点的容器的各项指标，并上报给时序数据库(Prometheus)存储，Prometheus可通过其提供的PromQL语言来对各项指标进行多维度的查询和运算，这一模块的主要作用是监测节点的pod的资源使用情况，为调度提供数据决策的支持。调度模块，则是通过K8s提供的Scheduling Framework调度框架实现，在k8s集群中以Pod的形式运行。Scheduling Framework在调度阶段中提供了若干拓展点，开发者通过实现拓展点对应的接口，就可在调度pod的过程中(也就是预选、优选和绑定阶段)执行自定义的逻辑。可以看到7中的调度阶段有若干黑色节点，一个节点代表调度过程中的某个阶段，它们之间是有先后顺序的。本公开主要实现了优选阶段中的Score和Reserve两个拓展点(对应着图7中的第四个和第六个黑色节点)对应的接口，前者为经过筛选后的节点打分，后者用于节点的资源预留，也即资源更新。

下面系统的介绍Pod从创建到最终绑定到节点(node)上运行的过程。

(1)初始化创建阶段

a)用户输入创建pod的命令后，kubectl向kube-apiserver发起create pod的请求。

b)kube-apiserver处理请求，将pod的yaml配置文件存储到etcd。

c)controller-Manager通过watch机制，发现kube-apiserver中pod信息的更新，整合该资源所依赖的拓扑结构，然后将对应的信息写到etcd。

(2)调度阶段

a)接下来pod需要被调度到某个具体的node上才能被创建。首先kube-scheduler通过watch接口获取到API Server创建了新的Pod对象，但是还没有绑定到任何工作节点上。

b)pod进入调度阶段，分为调度周期和绑定周期。调度周期的目的是选出一个合适的工作节点。当一个pod从进入调度阶段开始到Score拓展点之前，是预选阶段，这一阶段包括的拓展点有Prefilter、Filter和PreScore。它们的作用是从集群中筛选出满足要求的工作节点。接下来进入优选阶段，首先执行Score拓展点的逻辑，其次执行Normalize拓展点，进行分数的归一化操作，再次执行Reserve拓展点的逻辑。由于执行Score拓展点的逻辑和Reserve拓展点的逻辑上面已经详细论述，此处不再展开论述。接下来会执行调度周期最后一个拓展点Permit的逻辑，再然后，进入了绑定周期，分别执行Prebind，Bind，Postbind三个拓展点的逻辑，此时，pod就被调度并绑定到了最终的目标节点上。

c)Kube-scheduler调用API Server的API将pod调度结果更新到etcd中。

d)目标节点的kubelet调用CNI接口给pod创建pod网络，调用CRI接口去启动容器，调用CSI进行存储卷的挂载，至此pod创建完成，等业务进程启动后，pod运行成功。Kubelet也会将容器的状态结果返回到API Server，更新到etcd中。

以上是从pod的创建到绑定这一流程的角度介绍了本公开，下面从开发流程和代码逻辑的执行顺序角度进行更具体、更细节的描述，作为补充。根据图8所示，在注册完插件、实现对应拓展点的接口之后，再编译代码、打包镜像并上传到镜像仓库，就可以在集群中以pod的形式运行least-scheduler方法了。K8s中待调度pod会先进入调度队列，然后依次出队，经过调度周期和绑定周期后，最终运行在某个节点上。期间如果失败，会进入backoff queue或unschedulable queue，并在未来某个时间继续被添加到调度队列重新尝试。

对于一个待调度pod，当其从调度队列出队后，多种插件会在不同的拓展点执行各自的逻辑。如在调度周期进行到Score拓展点时，会执行打分的逻辑，由于需要对之前流程筛选过的所有节点打分，因此为了效率，K8s会创建多个线程同时打分。Kube-scheduler使用静态的request打分，执行一次计算即可得到结果，且不涉及到同步问题；本公开的方法因为涉及到维护pod和节点的资源使用量，需要进行更复杂的同步处理来避免协程的并发执行对调度结果造成错误，具体的打分逻辑如上图6所示，此处不再展开论述。在执行完Score拓展点以后，K8s会对打分进行归一化，下一步就来到了Reserve拓展点，此时K8s会相应地执行Reserve拓展点逻辑，其流程如上图5所示，此处不再展开论述。

本公开使用Scheduling Framework框架，根据Prometheus获取的节点资源利用率信息，实现了自定义调度器，其实现了Score和Reserve两个拓展点，分别用于为节点打分和更新调度器维护的节点资源利用率信息，最终选择资源利用率最低的节点并将pod调度到该节点上。也即，将集群中节点(也即服务器)的资源利用率作为调度的考量因素之一，通过每次给实际资源利用率较低的节点(workder节点)打出较高的分数，让每次调度时都会选择资源利用率最低的节点，而非节点上pod的request之和最小的节点。这样在调度后，虽然各节点中pod的request值不同，但集群中节点的资源利用率更加均衡，方差更小，即让集群中的服务器的资源利用率相差不大，分布在一个范围较小的区间中，从而让集群中的节点都得到了充分的利用，同时也避免了原有调度策略下部分节点的资源利用率过高可能造成的OOM等问题。当要执行的任务(pod)增加时，增加的负载会分散到所有节点上，它们的资源利用率会同时升高，而不是集中在少量节点上。本公开的调度方法在复杂资源需求场景下的效果表现比K8s的默认调度器kube-scheduler更好。

图9是根据一示例性实施例示出的一种任务调度装置的框图。参照图9，该任务调度装置，包括：预估使用资源量获取单元90、剩余资源量获取单元92、确定单元94和调度单元96。

预估使用资源量获取单元90，被配置为获取待调度任务的CPU预估使用资源量和内存预估使用资源量；剩余资源量获取单元92，被配置为针对集群中每个节点，执行如下第一操作：基于当前节点的CPU总资源量和CPU资源利用率以及CPU预估使用资源量，得到当前节点的CPU预估剩余资源量；基于当前节点的内存总资源量和内存资源利用率以及内存预估使用资源量，得到当前节点的内存预估剩余资源量；确定单元94，被配置为基于集群中每个节点的CPU预估剩余资源量和内存预估剩余资源量，确定集群中资源利用率最低的节点作为目标节点；调度单元96，被配置为将待调度任务调度到目标节点上运行。

根据本公开的示例性实施例，剩余资源量获取单元92，还被配置为在基于当前节点的CPU总资源量和CPU资源利用率以及CPU预估使用资源量，得到当前节点的CPU预估剩余资源量和基于当前节点的内存总资源量和内存资源利用率以及内存预估使用资源量，得到当前节点的内存预估剩余资源量之前，监控当前节点的CPU实际资源利用率和内存实际资源利用率；将监控到的CPU实际资源利用率和内存实际资源利用率发送到时序数据库；周期性的将时序数据库中CPU实际资源利用率和内存实际资源利用率写入当前节点。

根据本公开的示例性实施例，剩余资源量获取单元92，还被配置为在获取待调度任务的CPU预估使用资源量和内存预估使用资源量之后，基于待调度任务的CPU预估使用资源量、当前节点的CPU总资源量和CPU实际资源利用率，得到当前节点的CPU预估资源利用率；基于待调度任务的内存预估使用资源量、当前节点的内存总资源量和内存实际资源利用率，得到当前节点的内存预估资源利用率；基于CPU预估资源利用率和内存预估资源利用率更新当前节点中的CPU资源利用率和内存资源利用率。

根据本公开的示例性实施例，在任务调度方法应用于Kubernetes平台的情况下，写入和更新操作通过Kubernetes平台的调度器中Reserve拓展点执行。

根据本公开的示例性实施例，确定单元94，还被配置为确定集群中每个节点的CPU预估剩余资源量在CPU总资源量的第一占比和内存预估剩余资源量在内存总资源量的第二占比；基于集群中第一占比和第二占比，确定集群中资源利用率最低的节点作为目标节点。

根据本公开的示例性实施例，确定单元94，还被配置为针对集群中每个节点，执行如下第二操作：基于当前节点的第一占比，得到当前节点的第一评估指标；基于当前节点的第二占比，得到当前节点的第二评估指标；将第一评估指标和第二评估指标进行加权处理，得到当前节点的评估指标，其中，评估指标与第一占比、第二占比成正比例关系；将集群中评估指标最高的节点，确定为目标节点。

根据本公开的示例性实施例，在任务调度方法应用于Kubernetes平台的情况下，第一操作和第二操作通过Kubernetes平台的调度器中Score拓展点执行。

根据本公开的示例性实施例，预估使用资源量获取单元90，还被配置为基于待调度任务的CPU资源申请量和待调度任务的CPU资源利用率，得到待调度任务的CPU预估使用资源量；基于待调度任务的内存资源申请量和待调度任务的内存资源利用率，得到待调度任务的内存预估使用资源量。

根据本公开的示例性实施例，剩余资源量获取单元，还被配置为基于当前节点的CPU总资源量和CPU资源利用率，得到当前节点的CPU未使用资源；基于当前节点的CPU未使用资源量和CPU预估使用资源量，得到当前节点的CPU预估剩余资源量；基于当前节点的内存总资源量和内存资源利用率，得到当前节点的内存未使用资源；基于当前节点的内存未使用资源量和内存预估使用资源量，得到当前节点的内存预估剩余资源量。

根据本公开的实施例，可提供一种电子设备。图10是根据本公开实施例的一种电子设备1000的框图，该电子设备包括至少一个存储器1001和至少一个处理器1002，所述至少一个存储器中存储有计算机可执行指令集合，当计算机可执行指令集合被至少一个处理器执行时，执行根据本公开实施例的任务调度方法。

作为示例，电子设备1000可以是PC计算机、平板装置、个人数字助理、智能手机、或其他能够执行上述指令集合的装置。这里，电子设备1000并非必须是单个的电子设备，还可以是任何能够单独或联合执行上述指令(或指令集)的装置或电路的集合体。电子设备1000还可以是集成控制系统或系统管理器的一部分，或者可被配置为与本地或远程(例如，经由无线传输)以接口互联的便携式电子设备。

在电子设备1000中，处理器1002可包括中央处理器(CPU)、图形处理器(GPU)、可编程逻辑装置、专用处理器系统、微控制器或微处理器。作为示例而非限制，处理器1002还可包括模拟处理器、数字处理器、微处理器、多核处理器、处理器阵列、网络处理器等。

处理器1002可运行存储在存储器中的指令或代码，其中，存储器1001还可以存储数据。指令和数据还可经由网络接口装置而通过网络被发送和接收，其中，网络接口装置可采用任何已知的传输协议。

存储器1001可与处理器1002集成为一体，例如，将RAM或闪存布置在集成电路微处理器等之内。此外，存储器1001可包括独立的装置，诸如，外部盘驱动、存储阵列或任何数据库系统可使用的其他存储装置。存储器1001和处理器1002可在操作上进行耦合，或者可例如通过I/O端口、网络连接等互相通信，使得处理器1002能够读取存储在存储器1001中的文件。

此外，电子设备1000还可包括视频显示器(诸如，液晶显示器)和用户交互接口(诸如，键盘、鼠标、触摸输入装置等)。电子设备的所有组件可经由总线和/或网络而彼此连接。

根据本公开的实施例，还可提供一种计算机可读存储介质，其中，当计算机可读存储介质中的指令被至少一个处理器运行时，促使至少一个处理器执行本公开实施例的任务调度方法。这里的计算机可读存储介质的示例包括：只读存储器(ROM)、随机存取可编程只读存储器(PROM)、电可擦除可编程只读存储器(EEPROM)、随机存取存储器(RAM)、动态随机存取存储器(DRAM)、静态随机存取存储器(SRAM)、闪存、非易失性存储器、CD-ROM、CD-R、CD+R、CD-RW、CD+RW、DVD-ROM、DVD-R、DVD+R、DVD-RW、DVD+RW、DVD-RAM、BD-ROM、BD-R、BD-R LTH、BD-RE、蓝光或光盘存储器、硬盘驱动器(HDD)、固态硬盘(SSD)、卡式存储器(诸如，多媒体卡、安全数字(SD)卡或极速数字(XD)卡)、磁带、软盘、磁光数据存储装置、光学数据存储装置、硬盘、固态盘以及任何其他装置，所述任何其他装置被配置为以非暂时性方式存储计算机程序以及任何相关联的数据、数据文件和数据结构并将所述计算机程序以及任何相关联的数据、数据文件和数据结构提供给处理器或计算机使得处理器或计算机能执行所述计算机程序。上述计算机可读存储介质中的计算机程序可在诸如客户端、主机、代理装置、服务器等计算机设备中部署的环境中运行，此外，在一个示例中，计算机程序以及任何相关联的数据、数据文件和数据结构分布在联网的计算机系统上，使得计算机程序以及任何相关联的数据、数据文件和数据结构通过一个或多个处理器或计算机以分布式方式存储、访问和执行。

根据本公开实施例，提供了一种计算机程序产品，包括计算机指令，计算机指令被处理器执行时实现本公开实施例的任务调度方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种任务调度方法，其特征在于，包括：

获取待调度任务的CPU预估使用资源量和内存预估使用资源量；

针对集群中每个节点，执行如下第一操作：基于当前节点的CPU总资源量和CPU资源利用率以及所述CPU预估使用资源量，得到所述当前节点的CPU预估剩余资源量；基于当前节点的内存总资源量和内存资源利用率以及所述内存预估使用资源量，得到所述当前节点的内存预估剩余资源量；

基于所述集群中每个节点的CPU预估剩余资源量和内存预估剩余资源量，确定所述集群中资源利用率最低的节点作为目标节点；

将所述待调度任务调度到所述目标节点上运行。

2.如权利要求1所述的任务调度方法，其特征在于，在基于当前节点的CPU总资源量和CPU资源利用率以及所述CPU预估使用资源量，得到所述当前节点的CPU预估剩余资源量和基于当前节点的内存总资源量和内存资源利用率以及所述内存预估使用资源量，得到所述当前节点的内存预估剩余资源量之前，包括：

监控所述当前节点的CPU实际资源利用率和内存实际资源利用率；

将监控到的所述CPU实际资源利用率和所述内存实际资源利用率发送到时序数据库；

周期性的将所述时序数据库中所述CPU实际资源利用率和所述内存实际资源利用率写入所述当前节点。

3.如权利要求2所述的任务调度方法，其特征在于，在获取待调度任务的CPU预估使用资源量和内存预估使用资源量之后，还包括：

基于所述待调度任务的CPU预估使用资源量、所述当前节点的CPU总资源量和CPU实际资源利用率，得到所述当前节点的CPU预估资源利用率；

基于所述待调度任务的内存预估使用资源量、所述当前节点的内存总资源量和内存实际资源利用率，得到所述当前节点的内存预估资源利用率；

基于所述CPU预估资源利用率和内存预估资源利用率更新所述当前节点中的CPU资源利用率和内存资源利用率。

4.如权利要求3所述的任务调度方法，其特征在于，在所述任务调度方法应用于Kubernetes平台的情况下，所述写入和更新操作通过Kubernetes平台的调度器中Reserve拓展点执行。

5.如权利要求1所述的任务调度方法，其特征在于，所述基于所述集群中每个节点的CPU预估剩余资源量和内存预估剩余资源量，确定所述集群中资源利用率最低的节点作为目标节点，包括：

确定所述集群中每个节点的CPU预估剩余资源量在CPU总资源量的第一占比和内存预估剩余资源量在内存总资源量的第二占比；

基于所述集群中第一占比和第二占比，确定所述集群中资源利用率最低的节点作为目标节点。

6.如权利要求5所述的任务调度方法，其特征在于，所述基于所述集群中第一占比和第二占比，确定所述集群中资源利用率最低的节点作为目标节点，包括：

针对所述集群中每个节点，执行如下第二操作：基于所述当前节点的第一占比，得到所述当前节点的第一评估指标；基于所述当前节点的第二占比，得到所述当前节点的第二评估指标；将所述第一评估指标和所述第二评估指标进行加权处理，得到所述当前节点的评估指标，其中，所述评估指标与所述第一占比、所述第二占比成正比例关系；

将所述集群中评估指标最高的节点，确定为所述目标节点。

7.一种任务调度装置，其特征在于，包括：

预估使用资源量获取单元，被配置为获取待调度任务的CPU预估使用资源量和内存预估使用资源量；

剩余资源量获取单元，被配置为针对集群中每个节点，执行如下第一操作：基于当前节点的CPU总资源量和CPU资源利用率以及所述CPU预估使用资源量，得到所述当前节点的CPU预估剩余资源量；基于当前节点的内存总资源量和内存资源利用率以及所述内存预估使用资源量，得到所述当前节点的内存预估剩余资源量；

确定单元，被配置为基于所述集群中每个节点的CPU预估剩余资源量和内存预估剩余资源量，确定所述集群中资源利用率最低的节点作为目标节点；

调度单元，被配置为将所述待调度任务调度到所述目标节点上运行。

8.一种电子设备，其特征在于，包括:

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至6中任一项所述的任务调度方法。

9.一种计算机可读存储介质，其特征在于，当所述计算机可读存储介质中的指令被至少一个处理器运行时，促使所述至少一个处理器执行如权利要求1至6中任一项所述的任务调度方法。

10.一种计算机程序产品，包括计算机指令，其特征在于，所述计算机指令被处理器执行时实现如权利要求1至6中任一项所述的任务调度方法。

Images