CN114090201A - 资源调度方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种资源调度方法、装置、设备及存储介质，属于计算机技术领域。所述方法包括：获取待调度节点的实时消耗资源以及已请求资源；根据实时消耗资源以及已请求资源，确定待调度节点的实时可用资源；响应于资源调度请求，根据资源调度请求中的请求运行资源和实时可用资源，对待调度节点进行资源调度。根据节点的实时消耗资源，来动态调整待调度节点基于已请求资源确定的可用资源，从而得到实时可用资源。根据实时可用资源来对待调度节点进行资源调度，能够避免出现节点的剩余可调度资源比较多但是真实负载却比较高，以及节点的剩余可调度资源比较少但是真实负载却比较低的情况。从而能够实现提升资源调度的准确度，提升系统的性能。

Description

资源调度方法、装置、设备及存储介质

技术领域

本申请涉及计算机技术领域，特别涉及一种资源调度方法、装置、设备及存储介质。

背景技术

容器技术是云计算中应用的主要技术之一。提供服务的系统可以将用于提供服务的程序部署在容器中，再将容器部署在系统的不同节点中，从而能够实现系统中服务的分布式部署。为了保证系统的运行效率，在系统新增服务后，需要进行资源调度，以确定新增服务所在的容器被部署至哪个节点，在此过程中需要考虑节点之间的性能平衡以及运行效率。

库伯内茨(Kubernetes，K8s)系统是能够对容器集群进行编排和调度的管理系统。Kubernetes系统中的调度器，是Kubernetes系统中运行的调度程序。调度器负责收集和分析节点已占用的资源，然后以分析的结果为依据，根据容器部署单元(Pod)请求的运行资源来进行资源调度，从而将新建的容器部署单元分配到可用节点中部署。可用节点是剩余资源大于请求的运行资源的节点，剩余资源是根据节点的总资源和已占用的资源的差确定的，已占用的资源是根据节点中部署的容器部署单元，在调度时请求的运行资源的和确定的。其中，容器部署单元中部署有一个或多个容器，资源包括处理器资源以及内存资源。

在通过上述方式进行资源调度时，可能会导致系统内一些节点的剩余资源比较多，但是真实负载却比较高。而另一些节点的剩余资源比较少，但是真实负载却比较低。其中，真实负载是节点中已部署的容器部署单元运行时消耗的资源。但是这时调度器会优先将容器部署单元调度到剩余资源比较多的节点中，存在资源调度的准确度较低的问题，从而会影响系统的性能。

发明内容

本申请提供了一种资源调度方法、装置、设备及存储介质，可以提升资源调度的准确度，提升系统的性能。所述技术方案如下：

根据本申请的一方面，提供了一种资源调度方法，所述方法包括：

获取待调度节点的实时消耗资源以及已请求资源，所述实时消耗资源是根据所述待调度节点中实时运行的程序消耗的运行资源确定的，所述已请求资源是根据所述待调度节点中部署的程序在请求调度时请求的运行资源确定的；

根据所述实时消耗资源以及所述已请求资源，确定所述待调度节点的实时可用资源；

响应于资源调度请求，根据所述资源调度请求中的请求运行资源和所述实时可用资源，对所述待调度节点进行资源调度。

根据本申请的另一方面，提供了一种资源调度装置，所述装置包括：

获取模块，用于获取待调度节点的实时消耗资源以及已请求资源，所述实时消耗资源是根据所述待调度节点中实时运行的程序消耗的运行资源确定的，所述已请求资源是根据所述待调度节点中部署的程序在请求调度时请求的运行资源确定的；

确定模块，用于根据所述实时消耗资源以及所述已请求资源，确定所述待调度节点的实时可用资源；

调度模块，用于响应于资源调度请求，根据所述资源调度请求中的请求运行资源和所述实时可用资源，对所述待调度节点进行资源调度。

在一个可选的设计中，所述获取模块，用于：

通过监控组件监控所述待调度节点的所述实时消耗资源；

在所述监控组件向接口服务上报所述实时消耗资源的过程中，通过所述接口服务调用的修改插件，根据所述监控组件上报的实时消耗资源获取所述实时消耗资源，所述修改插件是具有获取所述接口服务收发的信息以及修改所述收发的信息功能的插件；

通过所述修改插件获取所述待调度节点的所述已请求资源。

在一个可选的设计中，所述确定模块，用于：

通过所述修改插件，根据所述实时消耗资源以及所述已请求资源，计算所述实时可用资源；

响应于所述修改插件向所述接口服务上报所述实时可用资源，通过所述接口服务将所述实时可用资源存储至所述待调度节点的元数据中。

在一个可选的设计中，所述确定模块，用于：

通过所述修改插件，根据如下公式计算所述实时可用资源：

实时可用资源＝静态可用资源+(已请求资源-实时消耗资源)*计算系数；

其中，所述静态可用资源是根据所述待调度节点的总运行资源与所述已请求资源的差确定的，所述已请求资源不小于所述实时消耗资源。

在一个可选的设计中，所述调度模块，用于：

响应于容器部署单元的资源调度请求，通过调度器在所述待调度节点的元数据中获取所述实时可用资源，所述容器部署单元中部署有至少一个容器；

通过所述调度器根据所述容器部署单元的请求运行资源以及所述实时可用资源对所述待调度节点进行资源调度。

在一个可选的设计中，所述调度模块，用于：

通过所述调度器在所述待调度节点中，基于所述实时可用资源以及所述容器部署单元的请求运行资源，根据各个所述待调度节点的优先级确定目标节点，所述目标节点的实时可用资源大于所述请求运行资源；

将所述容器部署单元调度至所述目标节点。

在一个可选的设计中，所述装置还包括：

存储模块，用于响应于所述监控组件向所述接口服务上报所述实时消耗资源，通过所述接口服务将所述实时消耗资源存储至所述待调度节点的节点注释中。

根据本申请的另一方面，提供了一种计算机设备，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上方面所述的资源调度方法。

根据本申请的另一方面，提供了一种计算机可读存储介质，所述可读存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如上方面所述的资源调度方法。

根据本申请的另一方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述方面的各种可选实现方式中提供的资源调度方法。

本申请提供的技术方案带来的有益效果至少包括：

通过根据节点的实时消耗资源，来动态调整待调度节点基于已请求资源确定的可用资源，从而得到实时可用资源。根据实时可用资源来对待调度节点进行资源调度，能够避免出现节点的剩余可调度资源比较多但是真实负载却比较高，以及节点的剩余可调度资源比较少但是真实负载却比较低的情况。从而能够实现提升资源调度的准确度，提升系统的性能。

附图说明

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

图1是本申请一个示例性实施例提供的计算机系统的结构示意图；

图2是本申请一个示例性实施例提供的进行资源调度的过程的示意图；

图3是本申请一个示例性实施例提供的资源调度方法的流程示意图；

图4是本申请一个示例性实施例提供的资源调度方法的流程示意图；

图5是本申请一个示例性实施例提供的存储实时消耗资源的过程的示意图；

图6是本申请一个示例性实施例提供的获取实时可用资源的过程的示意图；

图7是本申请一个示例性实施例提供的资源调度装置的结构示意图；

图8是本申请一个示例性实施例提供的资源调度装置的结构示意图；

图9是本申请一个示例性实施例提供的计算机设备的结构示意图。

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

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

图1是本申请一个示例性实施例提供的计算机系统的结构示意图。如图1所示，该计算机系统100中包括主节点101以及子节点102a-102c(统称为子节点102)。

主节点101可以是一台服务器，或者由若干台服务器组成的服务器集群，或者是一个云计算服务中心中的虚拟服务器等。主节点101安装有能够进行资源调度的系统，例如为Kubernetes系统。主节点101中还能够运行有提供服务的程序。主节点101通过安装的能够实现资源调度的系统，基于资源调度请求能够确定新增的服务部署在哪一个子节点102中，以实现资源调度。主节点101和子节点102之间可以通过有线网络或无线网络建立连接。

子节点102可以是一台服务器，或者由若干台服务器组成的服务器集群，或者是一个云计算服务中心中的虚拟服务器等。当主节点101通过Kubernetes系统管理子节点102时，子节点102中能够部署容器部署单元，容器部署单元中能够部署一个或多个容器，容器中运行有程序以提供服务。

示例性的，计算机系统100中能够包括多个主节点101，以实现管理容器集群。其中每个主节点101管理系统中的一部分子节点102，每个主节点101还能够对应有备用的主节点。需要说明的是，上述计算机系统100中主节点101的数量以及子节点102的数量仅用作示意，不作为对本申请实施例提供的计算机系统100的限制。

图2是本申请一个示例性实施例提供的进行资源调度的过程的示意图。如图2所示，在步骤A1中，资源调度系统通过监控组件中的监控服务，定时获取待调度节点的实时消耗资源，以及获取待调度节点的已请求资源，并上报至接口服务。其中，实时消耗资源是根据待调度节点中实时运行的程序消耗的运行资源确定的，已请求资源是根据待调度节点中部署的程序在请求调度时请求的运行资源确定的。

在步骤A2中，资源调度系统通过接口服务，根据监控组件上报的待调度节点的实时可用资源以及已请求资源，更新待调度节点的节点注释。节点注释中存储有待调度节点的属性信息。

在步骤A3中，资源调度系统通过接口服务，基于监控组件上报的待调度节点的实时消耗资源以及已请求资源，计算待调度节点的实时可用资源，并存储至待调度节点的元数据中以实现更新元数据。可选地，计算实时可用资源的公式为：实时可用资源＝静态可用资源+(已请求资源-实时消耗资源)*计算系数。其中，静态可用资源是根据待调度节点的总运行资源与已请求资源的差确定的，已请求资源不小于实时消耗资源。

在步骤A4中，响应于资源调度请求，资源调度系统通过调度器根据资源调度请求中的请求运行资源和从待调度节点的元数据中获取的待调度节点的实时可用资源，对待调度节点进行资源调度。

示例性的，上述资源调度系统为Kubernetes系统，监控组件为普罗米修斯(Prometheus)，监控服务为度量服务(Metric Server)，接口服务为应用程序接口服务(Application Programming Interface Server，API Server)，资源调度请求是容器部署单元(Pod)的请求，调度器为Kubernetes系统调度器(Kube-Scheduler)，待调度节点的元数据存储在分布式键值对存储系统(Etcd)中。

通过上述方式，能够根据节点的实时消耗资源，来动态调整待调度节点基于已请求资源确定的可用资源，从而得到实时可用资源。根据实时可用资源来对待调度节点进行资源调度，能够避免出现节点的剩余可调度资源比较多但是真实负载却比较高，以及节点的剩余可调度资源比较少但是真实负载却比较低的情况。从而实现提升资源调度的准确度，提升系统的性能。

图3是本申请一个示例性实施例提供的资源调度方法的流程示意图。该方法可以用于如图1所示的系统中的主节点或主节点上运行的资源调度系统。如图3所示，该方法包括：

步骤302：获取待调度节点的实时消耗资源以及已请求资源。

在进行资源调度时，资源调度系统会在待调度节点中确定用于部署待调度的程序的节点，并将待调度的程序调度至该节点中运行。示例地，待调度节点能够为图1所示系统中的子节点，资源调度系统部署在图1所示系统中的主节点，主节点通过资源调度系统能够对子节点进行资源调度。

该实时消耗资源是根据待调度节点中实时运行的程序消耗的运行资源确定的。该已请求资源是根据待调度节点中部署的程序在请求调度时请求的运行资源确定的。

可选地，该运行资源包括处理器资源以及内存资源，例如包括中央处理器(Central Processing Unit，CPU)资源以及随机存取存储器(Random Access Memory，RAM)资源。程序在待调度节点中运行会消耗运行资源，例如待调度节点中运行有程序1和程序2，程序1消耗1C(1Core，一个CPU核心)处理资源和16G内存资源，程序2消耗2C处理资源和4G内存资源，则此时待调度节点的实时消耗资源为3C处理资源和20G内存资源。

示例地，待调度节点中部署有程序1和程序2，程序1在请求调度时请求的运行资源为1C处理资源和2G内存资源，程序2在请求调度时请求的运行资源为2C处理资源和4G的内存资源，则该待调度节点的已请求资源为3C的处理资源和6G的内存资源。

可选地，资源调度系统通过监控组件，能够获取待调度节点的实时消耗资源以及已请求资源，监控组件具有监控资源调度系统管理的节点的运行指标的功能。该资源调度系统为Kubernetes系统，监控组件为Prometheus。资源调度系统会定期获取待调度节点的实时消耗资源以及已请求资源。

步骤304：根据实时消耗资源以及已请求资源，确定待调度节点的实时可用资源。

待调度节点中部署的程序，在请求调度时请求的运行资源和其在待调度节点中运行时消耗的运行资源可能不同。但待调度节点中部署的程序在待调度节点中运行时消耗的运行资源的最大值小于最大值限制(limit)。

相关技术中，资源调度系统会根据待调度节点的已请求资源来确定待调度节点当前的可用资源。具体地，资源调度系统根据待调度节点的总运行资源与待调度节点的累计已请求资源之间的差，确定待调度节点当前的可用资源。待调度节点的总运行资源取决于待调度节点的硬件配置，累计已请求资源是待调度节点中部署的各程序的已请求资源之间的和。

本申请实施例提供的方法，资源调度系统根据待调度节点的实时消耗资源，能够实时更新待调度节点当前根据已请求资源确定的可用资源，从而得到待调度节点的实时可用资源。待调度节点的实时可用资源会随实时消耗资源的变化而实时产生变化，能够保证评估的待调度节点当前的可用资源更准确。

可选地，资源调度系统通过接口服务调用的修改插件，能够实现根据实时消耗资源以及已请求资源，确定待调度节点的实时可用资源。该资源调度系统为Kubernetes系统，接口服务为API Server，该修改插件能够为转换准入网络钩子(Mutating AdmissionWebhook)。修改插件在获取到实时消耗资源时，会确定待调度节点的实时可用资源。

步骤306：响应于资源调度请求，根据资源调度请求中的请求运行资源和实时可用资源，对待调度节点进行资源调度。

当资源调度系统所管理的系统中需要增加运行新的程序时，资源调度系统会接收到该资源调度请求，该资源调度请求能够是管理人员发送的。

实时可用资源会受待调度节点中实时运行的程序消耗的运行资源，以及部署在待调度节点中的程序在请求资源调度时请求的运行资源影响，实时可用资源相较于仅使用已请求资源确定待调度节点当前的可用资源，能够更准确的反映待调度节点当下可被使用的运行资源。

资源调度系统在进行资源调度时，会在待调度节点中确定目标节点，从而将待调度的程序调度至目标节点。目标节点的实时可用资源大于资源调度请求中的请求运行资源。资源调度系统会根据待调度节点的优先级、资源调度请求中的请求运行资源以及待调度节点的实时可用资源，在待调度节点中确定出目标节点。可选地，待调度节点的优先级与待调度节点的实时可用资源正相关。

可选地，资源调度系统通过调度器，能够获取待调度节点的实时可用资源，之后通过调度器，根据待调度节点的实时可用资源以及请求运行资源，对待调度节点进行资源调度。该资源调度系统为Kubernetes系统，该调度器为Kube-Scheduler。

综上所述，本实施例提供的方法，根据节点的实时消耗资源，来动态调整待调度节点基于已请求资源确定的可用资源，从而得到实时可用资源。根据实时可用资源来对待调度节点进行资源调度，能够避免出现节点的剩余可调度资源比较多但是真实负载却比较高，以及节点的剩余可调度资源比较少但是真实负载却比较低的情况。从而能够实现提升资源调度的准确度，提升系统的性能。

图4是本申请一个示例性实施例提供的资源调度方法的流程示意图。该方法可以用于如图1所示的系统中的主节点或主节点上运行的资源调度系统。如图4所示，该方法包括：

步骤402：通过修改插件获取待调度节点的实时消耗资源以及已请求资源。

该实时消耗资源是根据待调度节点中实时运行的程序消耗的运行资源确定的。该已请求资源是根据待调度节点中部署的程序在请求调度时请求的运行资源确定的，待调度节点的已请求资源为待调度节点中部署的各个程序，在请求调度时请求的运行资源的总和。

资源调度系统通过监控组件，能够实现监控待调度节点的实时消耗资源，即监控组件能够获取到待调度节点的实时消耗资源。监控组件在获取到待调度节点的实时消耗资源后，会向接口服务进行上报。在监控组件向接口服务上报实时消耗资源的过程中，资源调度系统通过接口服务调用的修改插件，能够根据监控组件上报的实时消耗资源获取到待调度节点的实时消耗资源。资源调度系统也能够通过修改插件获取待调度节点的已请求资源，获取的逻辑也为通过修改插件获取。其中，修改插件通过拦截向接口服务发送的信息，从而能够获取到待调度节点的实时消耗资源以及待调度节点的已请求资源。该修改插件是具有获取接口服务收发的信息以及修改收发的信息功能的插件。

需要说明的是，资源调度系统能够同时获取实时消耗资源以及已请求资源，或者在不同的时刻获取实时消耗资源以及已请求资源。

可选地，资源调度系统为Kubernetes系统，监控组件为Prometheus，接口服务为API Server，修改插件为Mutating Admission Webhook。Kubernetes系统中的操作(例如数据的读取、处理、存储等)通常都需要经过API Server进行处理。

可选地，响应于监控组件向接口服务上报实时消耗资源，资源调度系统会通过接口服务将实时消耗资源存储至实时消耗资源对应的待调度节点的节点注释中，以实现持久化存储数据。节点注释属于节点属性，节点注释中包括用于描述待调度节点的信息。可选地，资源调度系统为Kubernetes系统，节点注释为Node Annotation。

示例地，待调度节点的节点属性如下：

#Node Annotation

apiVersion:v1

kind:Node

metadata:

name:node-0001

labels:

failure-domain.beta.kubernetes.io/zone:"0"

kubernetes.io/arch:amd64

kubernetes.io/hostname:apaas8026

kubernetes.io/os:linux

node-role.kubernetes.io/compute:"true"

annotations:

hook.kubernetes.io/cpu-used:17500m

hook.kubernetes.io/mem-used:18000mi

其中，节点注释中的“hook.kubernetes.io/cpu-used:17500m”表示待调度节点使用了处理器的17.5核，节点注释中“hook.kubernetes.io/mem-used:18000mi”表示待调度节点使用了内存的18G。

示例地，图5是本申请一个示例性实施例提供的存储实时消耗资源的过程的示意图。如图5所示，在步骤B1中，监控组件周期性的采集待调度节点的运行数据，从而得到待调度节点的实时消耗资源以及已请求资源。该周期是资源调度系统设置的。在步骤B2中，监控组件会周期性的向接口服务上报待调度节点的实时消耗资源以及已请求资源，在此过程中修改插件会对该信息进行拦截并进行处理。在步骤B3中，监控组件将待调度节点的实时消耗资源以及已请求资源发送至接口服务，以实现将待调度节点的实时消耗资源以及已请求资源存储至待调度节点的节点注释中。

步骤404：通过修改插件根据实时消耗资源以及已请求资源，确定待调度节点的实时可用资源。

资源调度系统通过修改插件，根据实时消耗资源以及已请求资源，能够计算待调度节点的实时可用资源。响应于修改插件向接口服务上报实时可用资源，资源调度系统通过接口服务能够将实时可用资源存储至待调度节点的元数据中。从而能够在进行资源调度的过程中，通过待调度节点的元数据获取到待调度节点的实时可用资源，实现确定待调度节点的实时可用资源。

可选地，资源调度系统通过修改插件，根据如下公式计算实时可用资源：

实时可用资源＝静态可用资源+(已请求资源-实时消耗资源)*计算系数；

其中，静态可用资源是根据待调度节点的总运行资源与已请求资源的差确定的，已请求资源不小于实时消耗资源。计算系数是资源调度系统设置的，例如默认为70％，并且可动态配置。示例地，待调度节点的总运行资源为处理资源16C，内存资源128G，待调度节点的已请求资源为处理资源10C，内存资源64G，则该待调度节点的静态可用资源为处理资源6C，内存资源64G。

示例地，静态可用资源为待调度节点的总运行资源的50％，实时消耗资源为待调度节点的总运行资源的20％。若直接使用静态可用资源进行资源调度，则可申请的运行资源为待调度节点的总运行资源的50％。通过上述方式计算的待调度节点的实时可用资源，为待调度节点的总运行资源的50％+(50％-20％)*70％＝71％。相较于直接使用静态可用资源，待调度节点可申请的运行资源由50％变为71％，因此提升了资源调度的准确性。将待调度节点可申请的运行资源增大，可称为资源超卖。

可选地，资源调度系统为Kubernetes系统，待调度节点的元数据存储在Etcd中。静态可用资源存储在待调度节点的节点分配资源(Node Resource Allocation)中，在Mutating Admission Webhook计算出实时可用资源后，API Server会将Node ResourceAllocation中的静态可用资源替换存储为实时可用资源，从而实现资源调度系统进行资源调度时使用实时可用资源进行调度。

示例地，修改前的资源如下所示：

"attachable-volumes-azure-disk"："16"，

"cpu"："7"，

"memory"："62815008Ki"，

"ephemeral-storage"："247375001601"，

"hugepages-lGi"："0"，

"hugepages-2Mi"："0"，

"pods"："1k"

其中，“"cpu"："7"”为静态可用资源中的处理资源，“"memory"："62815008Ki"”为静态可用资源中的内存资源。

修改后的资源如下所示：

"attachable-volumes-azure-disk"："16"，

"cpu"："8"，

"memory"："68815008Ki"，

"ephemeral-storage"："247375001601"，

"hugepages-lGi"："0"，

"hugepages-2Mi"："0"，

"pods"："1k"

其中，“"cpu"："8"”为实时可用资源中的处理资源，“"memory"："68815008Ki"”为实时可用资源中的内存资源。根据上述示例可知，实时可用资源相较于静态可用资源，处理资源以及内存资源都实现了增大。增大处理资源以及内存资源，可以实现在进行资源调度时，将原本无法调度至增大前的待调度节点的程序，调度至增大后的该待调度节点，且该待调度节点的实时运行性能满足待调度的程序的需求。

步骤406：响应于容器部署单元的资源调度请求，通过调度器在待调度节点的元数据中获取实时可用资源。

该容器部署单元中部署有至少一个容器。可选地，资源调度系统为Kubernetes系统，该容器部署单元为Pod，调度器为Kube-Scheduler。资源调度请求为创建Pod的请求(PodRequest)。将程序部署在容器中，再将容器部署在容器部署单元中，可以实现通过运行容器部署单元来提供程序对应的服务。

Kube-Scheduler在进行资源调度时，基于列表查阅(List-Watch)机制能够通过API Server，从待调度节点的元数据中获取到待调度节点的可用资源。由于API Server已将待调度节点的静态可用资源替换存储为实时可用资源，因此在进行资源调度时，Kube-Scheduler获取到的待调度节点的可用资源为实时可用资源。

示例地，图6是本申请一个示例性实施例提供的获取实时可用资源的过程的示意图。如图6所示，在步骤C1中，监控组件在向接口服务上报待调度节点的实时运行资源以及已请求资源时，修改插件会对上述信息进行拦截，并确定实时可用资源，上报至接口服务。在步骤C2中，当接口服务接收到待调度节点的实时可用资源，会将其存储在待调度节点的元数据中。在步骤C3中，当需要进行资源调度时，调度器会通过接口服务，获取存储在待调度节点的元数据中的实时可用资源，并根据实时可用资源进行资源调度。

步骤408：通过调度器根据容器部署单元的请求运行资源以及实时可用资源对待调度节点进行资源调度。

资源调度系统通过调度器在待调度节点中，基于实时可用资源以及容器部署单元的请求运行资源，根据各个待调度节点的优先级能够确定目标节点，并将容器部署单元调度至该目标节点。其中，目标节点的实时可用资源大于请求运行资源。

可选地，资源调度系统为Kubernetes系统，请求运行资源为Pod的请求资源(PodRequest Resource)。

实时可用资源会受待调度节点中实时运行的程序消耗的运行资源，以及部署在待调度节点中的程序在请求资源调度时请求的运行资源影响，实时可用资源相较于仅使用已请求资源确定待调度节点当前的可用资源，能够更准确的反映待调度节点当下可被使用的运行资源。

资源调度系统在进行资源调度时，会在待调度节点中确定目标节点，从而将待调度的程序调度至目标节点。资源调度系统会根据待调度节点的优先级、资源调度请求中的请求运行资源以及待调度节点的实时可用资源，在待调度节点中确定出目标节点。可选地，待调度节点的优先级与待调度节点的实时可用资源正相关。可选地，资源调度系统除了考虑待调度节点的优先级，还会考虑将程序分散到不同节点运行以使集群节点资源均衡，以及根据标签配置调度程序到指定范围的节点中，以及根据反亲和性将程序不调度到指定范围的节点中等因素。其中，节点对应有第一标签(Label)，待调度的程序对应有第二标签，资源调度系统在进行资源调度时，会考虑将待调度的程序调度至与其标签匹配(即第二标签与第一标签匹配)的待调度节点中。指定范围的节点是由系统的管理人员指示的。

综上所述，本实施例提供的方法，根据节点的实时消耗资源，来动态调整待调度节点基于已请求资源确定的可用资源，从而得到实时可用资源。根据实时可用资源来对待调度节点进行资源调度，能够避免出现节点的剩余可调度资源比较多但是真实负载却比较高，以及节点的剩余可调度资源比较少但是真实负载却比较低的情况。从而能够实现提升资源调度的准确度，提升系统的性能。

另外，通过修改插件获取待调度节点的已请求资源以及实时消耗资源，能够确定待调度节点的实时可用资源，并存储实时可用资源。提供了一种不影响资源调度系统的结构，即可确定实时可用资源的方式。通过计算系数计算待调度节点的实时可用资源，能够实现根据需求灵活调整增大待调度节点的可用资源的幅度。存储实时消耗资源以及实时可用资源，能够实现数据的持久化保存，便于之后对数据进行回溯。

需要说明的是，本申请实施例提供的方法步骤的先后顺序可以进行适当调整，步骤也可以根据情况进行相应增减，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化的方法，都应涵盖在本申请的保护范围之内，因此不再赘述。

图7是本申请一个示例性实施例提供的资源调度装置的结构示意图。该装置可以用于如图1所示的系统中的主节点。如图7所示，该装置包括：

获取模块701，用于获取待调度节点的实时消耗资源以及已请求资源，实时消耗资源是根据待调度节点中实时运行的程序消耗的运行资源确定的，已请求资源是根据待调度节点中部署的程序在请求调度时请求的运行资源确定的。

确定模块702，用于根据实时消耗资源以及已请求资源，确定待调度节点的实时可用资源。

调度模块703，用于响应于资源调度请求，根据资源调度请求中的请求运行资源和实时可用资源，对待调度节点进行资源调度。

在一个可选的设计中，获取模块701，用于：

通过监控组件监控待调度节点的实时消耗资源。在监控组件向接口服务上报实时消耗资源的过程中，通过接口服务调用的修改插件，根据监控组件上报的实时消耗资源获取实时消耗资源，修改插件是具有获取接口服务收发的信息以及修改收发的信息功能的插件。通过修改插件获取待调度节点的已请求资源。

在一个可选的设计中，确定模块702，用于：

通过修改插件，根据实时消耗资源以及已请求资源，计算实时可用资源。响应于修改插件向接口服务上报实时可用资源，通过接口服务将实时可用资源存储至待调度节点的元数据中。

在一个可选的设计中，确定模块702，用于：

通过修改插件，根据如下公式计算实时可用资源：

实时可用资源＝静态可用资源+(已请求资源-实时消耗资源)*计算系数。

其中，静态可用资源是根据待调度节点的总运行资源与已请求资源的差确定的，已请求资源不小于实时消耗资源。

在一个可选的设计中，调度模块703，用于：

响应于容器部署单元的资源调度请求，通过调度器在待调度节点的元数据中获取实时可用资源，容器部署单元中部署有至少一个容器。通过调度器根据容器部署单元的请求运行资源以及实时可用资源对待调度节点进行资源调度。

在一个可选的设计中，调度模块703，用于：

通过调度器在待调度节点中，基于实时可用资源以及容器部署单元的请求运行资源，根据各个待调度节点的优先级确定目标节点，目标节点的实时可用资源大于请求运行资源。将容器部署单元调度至目标节点。

在一个可选的设计中，如图8所示，装置还包括：

存储模块704，用于响应于监控组件向接口服务上报实时消耗资源，通过接口服务将实时消耗资源存储至待调度节点的节点注释中。

需要说明的是：上述实施例提供的资源调度装置，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的资源调度装置与资源调度方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

本申请的实施例还提供了一种计算机设备，该计算机设备包括：处理器和存储器，存储器中存储有至少一条指令、至少一段程序、代码集或指令集，至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行以实现上述各方法实施例提供的资源调度方法。

可选地，该计算机设备为服务器。示例地，图9是本申请一个示例性实施例提供的计算机设备的结构示意图。

所述计算机设备900包括中央处理单元(Central Processing Unit，CPU)901、包括随机存取存储器(Random Access Memory，RAM)902和只读存储器(Read-Only Memory，ROM)903的系统存储器904，以及连接系统存储器904和中央处理单元901的系统总线905。所述计算机设备900还包括帮助计算机设备内的各个器件之间传输信息的基本输入/输出系统(Input/Output系统，I/O系统)906，和用于存储操作系统913、应用程序914和其他程序模块915的大容量存储设备907。

所述基本输入/输出系统906包括有用于显示信息的显示器908和用于用户输入信息的诸如鼠标、键盘之类的输入设备909。其中所述显示器908和输入设备909都通过连接到系统总线905的输入输出控制器910连接到中央处理单元901。所述基本输入/输出系统906还可以包括输入输出控制器910以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器910还提供输出到显示屏、打印机或其他类型的输出设备。

所述大容量存储设备907通过连接到系统总线905的大容量存储控制器(未示出)连接到中央处理单元901。所述大容量存储设备907及其相关联的计算机可读存储介质为计算机设备900提供非易失性存储。也就是说，所述大容量存储设备907可以包括诸如硬盘或者只读光盘(Compact Disc Read-Only Memory，CD-ROM)驱动器之类的计算机可读存储介质(未示出)。

不失一般性，所述计算机可读存储介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读存储指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、可擦除可编程只读寄存器(Erasable Programmable Read OnlyMemory，EPROM)、电子抹除式可复写只读存储器(Electrically-Erasable ProgrammableRead-Only Memory，EEPROM)、闪存或其他固态存储设备，CD-ROM、数字多功能光盘(DigitalVersatile Disc，DVD)或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然，本领域技术人员可知所述计算机存储介质不局限于上述几种。上述的系统存储器904和大容量存储设备907可以统称为存储器。

存储器存储有一个或多个程序，一个或多个程序被配置成由一个或多个中央处理单元901执行，一个或多个程序包含用于实现上述方法实施例的指令，中央处理单元901执行该一个或多个程序实现上述各个方法实施例提供的方法。

根据本申请的各种实施例，所述计算机设备900还可以通过诸如因特网等网络连接到网络上的远程计算机设备运行。也即计算机设备900可以通过连接在所述系统总线905上的网络接口单元911连接到网络912，或者说，也可以使用网络接口单元911来连接到其他类型的网络或远程计算机设备系统(未示出)。

所述存储器还包括一个或者一个以上的程序，所述一个或者一个以上程序存储于存储器中，所述一个或者一个以上程序包含用于进行本申请实施例提供的方法中由计算机设备所执行的步骤。

本申请实施例中还提供了一种计算机可读存储介质，该可读存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，当该至少一条指令、至少一段程序、代码集或指令集由计算机设备的处理器加载并执行时，实现上述各方法实施例提供的资源调度方法。

本申请还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各方法实施例提供的资源调度方法。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，上述提到的可读存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同切换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种资源调度方法，其特征在于，所述方法包括：

获取待调度节点的实时消耗资源以及已请求资源，所述实时消耗资源是根据所述待调度节点中实时运行的程序消耗的运行资源确定的，所述已请求资源是根据所述待调度节点中部署的程序在请求调度时请求的运行资源确定的；

根据所述实时消耗资源以及所述已请求资源，确定所述待调度节点的实时可用资源；

响应于资源调度请求，根据所述资源调度请求中的请求运行资源和所述实时可用资源，对所述待调度节点进行资源调度。

2.根据权利要求1所述的方法，其特征在于，所述获取待调度节点的实时消耗资源以及已请求资源，包括：

通过监控组件监控所述待调度节点的所述实时消耗资源；

在所述监控组件向接口服务上报所述实时消耗资源的过程中，通过所述接口服务调用的修改插件，根据所述监控组件上报的实时消耗资源获取所述实时消耗资源，所述修改插件是具有获取所述接口服务收发的信息以及修改所述收发的信息功能的插件；

通过所述修改插件获取所述待调度节点的所述已请求资源。

3.根据权利要求2所述的方法，其特征在于，所述根据所述实时消耗资源以及所述已请求资源，确定所述待调度节点的实时可用资源，包括：

通过所述修改插件，根据所述实时消耗资源以及所述已请求资源，计算所述实时可用资源；

响应于所述修改插件向所述接口服务上报所述实时可用资源，通过所述接口服务将所述实时可用资源存储至所述待调度节点的元数据中。

4.根据权利要求3所述的方法，其特征在于，所述通过所述修改插件，根据所述实时消耗资源以及所述已请求资源，计算所述实时可用资源，包括：

通过所述修改插件，根据如下公式计算所述实时可用资源：

实时可用资源＝静态可用资源+(已请求资源-实时消耗资源)*计算系数；

其中，所述静态可用资源是根据所述待调度节点的总运行资源与所述已请求资源的差确定的，所述已请求资源不小于所述实时消耗资源。

5.根据权利要求1至4任一所述的方法，其特征在于，所述响应于资源调度请求，根据所述资源调度请求中的请求运行资源和所述实时可用资源，对所述待调度节点进行资源调度，包括：

响应于容器部署单元的资源调度请求，通过调度器在所述待调度节点的元数据中获取所述实时可用资源，所述容器部署单元中部署有至少一个容器；

通过所述调度器根据所述容器部署单元的请求运行资源以及所述实时可用资源对所述待调度节点进行资源调度。

6.根据权利要求5所述的方法，其特征在于，所述通过所述调度器根据所述容器部署单元的请求运行资源以及所述实时可用资源对所述待调度节点进行资源调度，包括：

通过所述调度器在所述待调度节点中，基于所述实时可用资源以及所述容器部署单元的请求运行资源，根据各个所述待调度节点的优先级确定目标节点，所述目标节点的实时可用资源大于所述请求运行资源；

将所述容器部署单元调度至所述目标节点。

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

响应于所述监控组件向所述接口服务上报所述实时消耗资源，通过所述接口服务将所述实时消耗资源存储至所述待调度节点的节点注释中。

8.一种资源调度装置，其特征在于，所述装置包括：

获取模块，用于获取待调度节点的实时消耗资源以及已请求资源，所述实时消耗资源是根据所述待调度节点中实时运行的程序消耗的运行资源确定的，所述已请求资源是根据所述待调度节点中部署的程序在请求调度时请求的运行资源确定的；

确定模块，用于根据所述实时消耗资源以及所述已请求资源，确定所述待调度节点的实时可用资源；

调度模块，用于响应于资源调度请求，根据所述资源调度请求中的请求运行资源和所述实时可用资源，对所述待调度节点进行资源调度。

9.一种计算机设备，其特征在于，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或所述指令集由所述处理器加载并执行以实现如权利要求1至7任一所述的资源调度方法。

10.一种计算机可读存储介质，其特征在于，所述可读存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如权利要求1至7任一所述的资源调度方法。

Images