CN114035941A - 资源调度系统、方法以及计算设备 - Google Patents

资源调度系统、方法以及计算设备 Download PDF

Info

Publication number
CN114035941A
CN114035941A CN202111212405.8A CN202111212405A CN114035941A CN 114035941 A CN114035941 A CN 114035941A CN 202111212405 A CN202111212405 A CN 202111212405A CN 114035941 A CN114035941 A CN 114035941A
Authority
CN
China
Prior art keywords
resource
scheduling
container group
specified
resources
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111212405.8A
Other languages
English (en)
Inventor
韩柔刚
张佐玮
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba China Co Ltd
Alibaba Cloud Computing Ltd
Original Assignee
Alibaba China Co Ltd
Alibaba Cloud Computing Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba China Co Ltd, Alibaba Cloud Computing Ltd filed Critical Alibaba China Co Ltd
Priority to CN202111212405.8A priority Critical patent/CN114035941A/zh
Publication of CN114035941A publication Critical patent/CN114035941A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本说明书实施例提供资源调度系统、方法以及计算设备，其中资源调度系统包括：中心调度器、管控组件和至少一个节点组件，节点组件可以检测本地的资源使用信息，管控组件可以基于各节点组件的资源使用信息，计算各节点组件中指定资源的资源容量，中心调度器在接收到容器组的调度请求时，可以根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件，并将该容器组调度至目标节点组件。这种情况下，可以利用各节点组件的资源使用信息，实时计算指定资源的资源容量，对节点组件的各类型资源中已分配、且未被使用的资源进行回收，重新用于容器组调度，为容器组调度提供更多的资源容量，满足各任务对于资源容量的需求，更灵活地进行各节点组件的资源调度。

Description

资源调度系统、方法以及计算设备
技术领域
本说明书实施例涉及计算机技术领域，特别涉及一种资源调度系统。本说明书一个或者多个实施例同时涉及一种资源调度方法，以及一种计算设备。
背景技术
随着计算机技术的快速发展，可以通过集群来实现不同场景下的任务，如图像识别、语音识别、自然语言理解等内容识别场景下的任务，或者在线购物、在线课程等在线场景下的任务。在通过集群实现不同场景下的任务时，需要进行集群调度，以调度相应的资源执行任务，因而高效的资源调度是集群调度领域内的一个热点问题。
现有技术中，资源调度系统可以基于任务的资源请求来分配合适的物理节点，以分配相应的资源执行该任务。集群在某些阶段执行任务时资源使用率会偏低，而在某些阶段执行任务时资源使用率会偏高，在需要使用更多资源时，目前采用的方法是选择重要性较低的任务进行资源压缩，让出资源供其他任务调度使用。然而，上述资源调度方法会对在执行的某些任务产生损害，降低任务的执行效果，因而需要提供更可靠的资源调度方案。
发明内容
有鉴于此，本说明书实施例提供了一种资源调度系统。本说明书一个或者多个实施例同时涉及一种资源调度方法，一种资源调度装置，一种计算设备，以及一种计算机可读存储介质，以解决现有技术中存在的技术缺陷。
根据本说明书实施例的第一方面，提供了一种资源调度系统，包括：中心调度器、管控组件和至少一个节点组件；
节点组件，被配置为检测本地的资源使用信息；
管控组件，被配置为根据各个节点组件检测到的资源使用信息，分别计算各个节点组件中指定资源的资源容量，其中，指定资源为节点组件的各类型资源中已分配、且未被使用的资源；
中心调度器，被配置为接收容器组的调度请求，在调度请求中携带的资源类型为指定类型的情况下，根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件，并将容器组调度至目标节点组件，指定类型为指定资源所属类型。
根据本说明书实施例的第二方面，提供了一种资源调度方法，应用于上述资源调度系统中包括的中心调度器，方法包括：
接收容器组的调度请求；
在调度请求中携带的资源类型为指定类型的情况下，根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件，其中，指定类型为指定资源所属类型，指定资源为节点组件的各类型资源中已分配、且未被使用的资源，各个节点组件中指定资源的资源容量为管控组件根据各个节点组件检测到的资源使用信息分别计算得到；
将容器组调度至目标节点组件。
根据本说明书实施例的第三方面，提供了一种资源调度装置，应用于上述资源调度系统中包括的中心调度器，装置包括：
接收模块，被配置为接收容器组的调度请求；
确定模块，被配置为在调度请求中携带的资源类型为指定类型的情况下，根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件，其中，指定类型为指定资源所属类型，指定资源为节点组件的各类型资源中已分配、且未被使用的资源，各个节点组件中指定资源的资源容量为管控组件根据各个节点组件检测到的资源使用信息分别计算得到；
调度模块，被配置为将容器组调度至目标节点组件。
根据本说明书实施例的第四方面，提供了一种计算设备，包括：
存储器和处理器；
存储器用于存储计算机可执行指令，处理器用于执行计算机可执行指令：
接收容器组的调度请求；
在调度请求中携带的资源类型为指定类型的情况下，根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件，其中，指定类型为指定资源所属类型，指定资源为节点组件的各类型资源中已分配、且未被使用的资源，各个节点组件中指定资源的资源容量为管控组件根据各个节点组件检测到的资源使用信息分别计算得到；
将容器组调度至目标节点组件。
根据本说明书实施例的第五方面，提供了一种计算机可读存储介质，其存储有计算机可执行指令，该指令被处理器执行时实现任意一项资源调度方法的步骤。
本说明书一个实施例中可以将节点组件的各类型资源中已分配、且未被使用的资源作为指定资源，节点组件可以检测本地的资源使用信息，管控组件可以基于各节点组件的实际资源使用信息，实时计算各节点组件中指定资源的资源容量，中心调度器在接收到容器组的调度请求时，可以根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件，并将该容器组调度至目标节点组件。这种情况下，可以利用各节点组件的实际资源使用信息，实时计算指定资源的资源容量，对节点组件的各类型资源中已分配、且未被使用的资源进行回收，重新用于容器组调度，为容器组调度提供更多的资源容量，满足各任务对于资源容量的需求；如此，在某任务需要使用更多资源的阶段，可以充分发掘集群内各节点组件的各类型资源中已分配、且未被使用的资源，无需对其他任务进行资源压缩，同时在该任务无需使用更多资源的阶段时，可以回收已分配、且未被使用的资源再用于其他任务调度，提供了一种更动态、灵活的资源容量计算方法，充分复用了节点组件的各类型资源中已分配、且未被使用的资源，更灵活地进行集群内各节点组件的资源调度，保证各任务对于资源的容量需求。
附图说明
图1是本说明书一个实施例提供的一种资源调度系统的结构框图；
图2是本说明书一个实施例提供的一种资源调度系统的交互流程图；
图3是本说明书一个实施例提供的一种资源容量示意图；
图4是本说明书一个实施例提供的一种当前资源使用信息的同步过程示意图；
图5是本说明书一个实施例提供的一种容器组配置示意图；
图6是本说明书一个实施例提供的一种资源调度方法的流程图；
图7是本说明书一个实施例提供的一种资源调度装置的结构示意图；
图8是本说明书一个实施例提供的一种计算设备的结构框图。
具体实施方式
在下面的描述中阐述了很多具体细节以便于充分理解本说明书。但是本说明书能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本说明书内涵的情况下做类似推广，因此本说明书不受下面公开的具体实施的限制。
在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本说明书一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
首先，对本说明书一个或多个实施例涉及的名词术语进行解释。
统一调度：集群管理和调度项目，旨在通过一套调度协议和一套系统架构来统一管理底层的计算、存储和网络资源，让超大规模、高效率、自动化的资源弹性成为可能。统一调度项目当前已在电商、搜索、云产品等核心任务中落地，集成了复杂的运维生态和技术架构，支持超大规模的在线任务和离线任务的混合部署。
节点组件：集群调度领域内的概念，节点组件是构成集群内机器集合的单位，也称作“单机”。节点组件可以指代集群内的单个物理上存在的机器，即物理机，也可能指代通过虚拟化等软件技术虚拟出来的逻辑概念上的机器单位。通常，节点组件上的物理资源包括了该机器可为应用程序分配和使用的处理器(CPU)和内存资源。
资源SLO：SLO即Service-Level Objective，统一调度项目下的资源SLO定义由资源的“优先级(Priority)”和“服务质量(Quality-of-Service，QoS)”组成。其中，优先级用于描述资源请求被满足的先后次序，QoS用于描述在节点组件上运行资源的质量。目前统一调度支持的优先级主要包括Prod、Mid、Batch、Free，支持的QoS级别主要包括LS(Latency-Sensitive)和BE(Bestefforts)。
在线任务：一般指存在实时人机交互的任务/程序，比如点击某应用程序中的按钮会调用到的服务，普遍需要应用程序能够实时响应。
离线任务：一般指不存在或较少有实时人机交互的任务/程序，比如非交互式的SQL查询任务、天级别的大数据报表任务。
Prod资源：指SLO中优先级为Prod的资源模型。这类资源有配额(Quota)预算，有最高优先级保障的资源，一般为在线高优任务使用，通常配合高优QoS级别LS使用。为了保障资源的可用性，Prod资源容量通常会使用节点资源总量的一部分。
Batch资源：指SLO中优先级为Batch的资源模型。这类资源有配额预算，是低于Prod优先级保障的资源，一般为离线任务等对延迟不敏感的任务使用。Batch资源的容量主要来自于节点可用但未向Prod优先级分配的资源，及一部分Prod资源已分配但实际未使用的资源。Batch资源的容量依赖Prod资源的使用，通常只保证一段时间内资源一定概率的可用性，通常配合低优QoS级别BE使用。
动态调度：相对于传统调度方法仅根据应用程序的请求资源量来计算节点可分配的资源容量，动态调度方法同时还会参考应用程序实时的资源使用量，将一部分应用程序分配了但未使用的资源回收，用于调度其他应用程序，从而优化节点的资源使用效率，降低机器成本。
混合部署：指将在线和离线等存在不同程序运行特征的任务部署在同一节点和同一集群的技术方案。常见的是在线任务和离线任务的混合部署，利用离线任务的延迟容忍和非实时性，回收利用在线任务闲时未使用的一部分资源，从而达到集群资源的时分复用。
水位：即节点组件上物理资源的实时利用率。
Flink：是一个开源流处理框架，其核心是用Java和Scala编写的分布式流数据流引擎，Flink以数据并行和流水线方式执行任意流数据程序，Flink的流水线运行时系统可以执行批处理和流处理程序，此外Flink的运行时本身也支持迭代算法的执行。也即，Flink是一个针对流数据和批数据的分布式处理引擎，可以说是实现真正意义上的实时流处理，大大降低了流计算的延迟，更能满足当下的大数据处理需求。
需要说明的是，高效的资源调度是云计算和集群调度领域内的一个热点问题，统一调度当前已经在电商、大数据、搜索等众多核心任务上落地，通过统一的调度协议和系统架构实现超大规模的资源弹性。传统的资源调度系统完全基于应用程序的资源请求来分配合适的节点组件，然而应用程序的实时资源利用率通常不能与请求量完全吻合，比如长时运行的应用服务可能存在天级的利用率潮汐，但即使节点利用率较低，这些服务依然可能占据满节点资源的可分配量，产生物理资源的浪费。
统一调度为了解决集群内各节点组件资源利用率不均的问题，提供了差异化的资源SLO模型，应用程序在执行任务时可以选择满足自身需求的资源模型，而统一调度系统则根据资源SLO模型为任务提供匹配的资源容量和质量保障。统一调度提供了资源差异化SLO能力，可以支持Prod、Mid和Batch等资源优先级，以及LS、BE等QoS。例如，电商等在线任务可以使用Prod资源、Batch资源稳定支持促销期间的流数据处理任务(即Flink集群作业)在电商平台上的平稳运行，Flink集群在非促销期间的资源水位偏低，但在促销期间可能会达到较高的资源水位，对此目前Flink集群可以采用对任务有损的解决方案，在促销压测期间对某些重要性较低的任务进行资源降级以让出资源，其他任务调度使用。
另外，Flink集群的促销压测任务对统一调度的资源模型提出了容量和质量两方面的挑战：一方面，促销压测任务用于促销作业中的资源容量规划，因此不存在预先确定好的资源请求量，类似Prod资源的静态调度模型难以适配不断变化的容量需求；另一方面，为了让促销压测作业准确模拟和检验促销任务的资源质量保障，需要避免采样低优的QoS级别，以保障压测任务运行时使用的物理资源不被挤占压缩。
实际应用中，促销压测任务对集群资源的容量需求很大，但Prod资源宝贵且有限，而采用Batch资源则一方面存在和原有Batch类任务间的干扰，另一方面难以满足促销任务的运行质量要求，因而需要一种可以保障促销压测任务的调度容量，同时满足任务的运行质量要求。另外，促销压测任务对集群资源的容量需求很大，目前需要对集群中的某些任务做降级来抽出资源给促销压测任务使用，但可能因此影响任务执行的稳定性、遭到用户投诉，因而需要尽量避免任务降级，同时保障促销压测任务对于资源容量和质量的调度需求。
具体实现时，目前存在四种SLO保障方案，简述如下：
方案一：采用Free、Batch(beb)、Mid、Production和Monitoring等几种资源层次，分别表示不同的资源优先级、定价模型和SLO级别。Free层次表示最低优先级，不计费且没有SLO保障，Batch层次使用较低的优先级，计费较低，有一定的SLO保障，使用单独的调度器。Free和Batch两种资源层次分别能对应不同的应用作业类型，比如测试作业和批处理作业，结合“低优、低价”的资源定价模型，这些低优的资源层次能够激励用户积极复用集群未分配资源，从而优化集群整体的资源利用率。然而，Free和Batch资源层次均采用了完全依据应用资源请求的资源调度方法，即根据请求使用的资源量，分配对应的节点组件，且并没有设置明确的节点资源利用率目标，Free和Batch层次均未具体考虑压测作业时应用程序的调度，压测作业时仍然需要牺牲资源容量或质量。
方案二：开源容器编排系统Kubernetes在资源模型上同样采用优先级和QoS级别的组合，优先级是一个整数，影响容器组(Pod)间的调度优先顺序、资源抢占顺序和容器驱逐顺序；QoS级别支持Guaranteed、Burstable、Bestefforts三种，由容器组设置资源的限制(limit)和请求(request)时隐式指定。其中，使用Bestefforts的容器组无需指定资源配额(quota)和用量配置(limit和request)，即可被调度运行。其中，隐式指定是指根据设置的限制(limit)和请求(request)之间的大小关系，可以确定出对应的QOS级别，限制(limit)可以是指容器组实际运行过程限制的资源量，即实际执行过程不能超过的资源上限，请求(request)可以是指请求使用的量，可以影响节点的公平性，调度过程参考，一般来说，Request小于等于Limit。
Kubernetes提供的QoS级别由容器组的资源用量配置隐式指定，分别描述了“保障”级别、“弹性”级别和“尽力”级别三个QoS等级。Kubernetes中Bestefforts级别(即尽力级别)的容器组会被调度到存在可用资源的节点，即使其未指定任何资源用量，能够最大限度地利用各节点的可用资源。然而，使用Bestefforts的QoS级别，要求了容器组必须不设任何资源用量，这限制了容器组在资源配置上的灵活度；而且，缺少资源请求量的设置，集群调度器和内核调度器也难以为Bestefforts任务之间提供公平性的保障。并且，尽力交付的调度能够最大程度发掘集群可用的资源容量，但没有考虑集群用量过高时带来的资源可用性下降问题，同时Besteffort容器组在节点上不设限的配置也为其他高优资源带来了严重性能干扰，降低了其他模型的资源质量。
方案三：提出一种基于实时负载感知的调度增强提案，由于目前开源版本的Kubernetes在调度阶段中缺乏对节点资源实时利用率的感知，因而调度器不支持基于资源利用率的负载均衡调度策略，也不支持基于资源负载目标的打包调度优化。因而该方案为了解决上述几点缺陷，设计了支持实时负载感知的调度器插件和配套方案：LoadWatcher模块持续从外部组件获取节点的实时资源负载/水位信息，调度器插件根据LoadWatcher提供的实时负载信息，结合装箱优化或负载均衡调度算法进行调度打分，辅助调度器决策。
也即是，该方案允许Kubernetes在调度时考虑节点组件的实时资源负载，是一种动态的资源调度方法。基于提案中两种可选的调度器插件，用户可以根据装箱优化或负载均衡调度的倾向，优化调度器决策，比如将更多容器组堆叠调度到已使用且有空闲资源的节点，以释放更多空闲节点，或是将容器组在各节点间打散调度，降低不同节点间的负载差异，减少热点。
集群节点的实时负载是不断变化的，在过去一段时间内负载满足要求的节点可能在容器组调度和启动后又不再满足，因而该方案在调度器插件中使用了资源容量的预估算法，计算资源容量的置信度，资源容量的置信度是整个节点的资源容量，不是分了不同优先级的资源，后续可以根据资源容量的置信度和实时负载信息，对调度结果进行打分，也即实时负载仅用于打分，无法保证单机上的质量，对于可能发生的资源不满足情况，本方案未考虑具体的单机保障方案，需要用户来处理具体的调度失败、资源竞争等问题。
方案四：容器成本管理系统ProphetPilot，针对Kubernetes集群的容器成本智能管理系统，该系统在Kubernetes基础上提供了资源画像推荐、成本分析、资源调度和资源计费等几方面的功能增强。在资源调度方面，ProphetPilot支持基于容器资源利用率的资源配置预估，结合Kubernetes原生的资源优先级，优化资源利用率的同时提供一定的资源质量保障。ProphetPilot基于容器资源画像的用量估计能力，提供容器组在填写资源配置(request、limit)时的推荐值，支持了用户根据推荐值更合理地规划工作负载的资源用量，从而提高集群资源使用效率。然而，ProphetPilot提供的资源配置预估，能够减少用户在声明工作负载时的资源浪费，但是对于利用率波动较大的容器，以及工作负载更复杂多样的混部集群，ProphetPilot难以根据容器和节点水位，实时更新匹配已调度容器组的资源配置或优化待调度容器组的调度决策。另外，ProphetPilot依然采用Kubernetes原生的资源优先级和QoS保障资源质量，因此不支持压测作业的资源容量和质量需求。
因而，为了保障压测作业的资源容量和质量需求，本说明书提出了一种“Free资源模型”，“Free资源模型”是统一调度提供的一种基于利用率的资源调度和SLO保障方法，它被用于解决Flink集群在促销压测作业时对于资源容量和运行质量的调度需求，“Free资源模型”采用了完全基于利用率的资源动态调度方法，该动态调度方法可以参考应用程序实时的资源使用量，将一部分应用程序分配了但未使用的资源回收，用于调度其他应用程序，从而优化节点的资源使用效率，降低机器成本；也即是，在线任务和离线任务可以混合部署，利用离线任务的延迟容忍和非实时性，回收利用在线任务闲时未使用的一部分资源，从而达到集群资源的时分复用，使用更动态、灵活的资源容量计算方法，为促销压测作业提供更多的资源容量，同时依据资源的SLO模型保证资源运行质量，形成了一种资源调度和SLO保障方法。
在本说明书中，提供了一种资源调度系统，本说明书同时涉及一种资源调度方法，一种资源调度装置，一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。
图1示出了根据本说明书一个实施例提供的一种资源调度系统的结构框图，如图1所示，该资源调度系统包括中心调度器106、管控组件104和至少一个节点组件102。
节点组件102，被配置为检测本地的资源使用信息；
管控组件104，被配置为根据各个节点组件检测到的资源使用信息，分别计算各个节点组件中指定资源的资源容量，其中，指定资源为节点组件的各类型资源中已分配、且未被使用的资源；
中心调度器106，被配置为接收容器组的调度请求，在调度请求中携带的资源类型为指定类型的情况下，根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件，并将容器组调度至目标节点组件，指定类型为指定资源所属类型。
具体的，资源使用信息可以是指节点组件中各类型资源的使用情况，该各类型资源可以为节点组件中各个优先级类型的资源，如节点组件中Prod、Mid、Batch、Free资源的使用情况。另外，指定资源可以是指节点组件的各类型资源中已分配、且未被使用的资源，如已分配的Prod资源中未被使用的资源、已分配的Mid资源中未被使用的资源和已分配的Batch资源中未被使用的资源；也就是说，指定资源可以是指节点组件中已使用的Prod资源、已使用的Mid资源和已使用的Batch资源之外未被使用的资源，本说明书实施例中以指定资源为Free资源进行说明，即指定资源用于表示Free资源。
一种可能的实现方式中，图2是本说明书一个实施例提供的一种资源调度系统的交互流程图，节点组件102可以检测本地的资源使用信息，即实时收集本地各个容器组的资源使用信息，即各个优先级类别的资源的使用情况(包括Prod、Mid、Batch和Free等)，管控组件104可以获取资源使用信息，根据资源使用信息中各个优先级类别的资源的使用情况，计算出当前指定资源(Free资源)的资源容量，即当前有多少资源已分配、且未被使用，可以作为指定资源。之后，中心调度器106在接收到容器组的调度请求，需要将该容器组调度至对应的节点组件时，可以基于各个节点组件中指定资源的资源容量，确定哪个节点组件可以满足该容器组的调度需求，从而将该容器组调度至对应的节点组件，执行相应的任务。其中，实时可以是指每隔较短的预设时间执行一次操作，即每隔较短的预设时间进行一次资源使用信息的检测、指定资源的资源容量的计算等操作，较短的预设时间可以为0.01秒、0.05秒等。
实际应用中，指定资源通常不设置配额预算，不保障资源可用性，可以被压制和抢占，当节点资源的实时资源使用率低于某个水位时，中心调度器可以认为这部分资源是一个比较不稳定、不记账但可以调度的资源，这部分资源就是指定资源(即Free)的容量。其中，配额预算可以是指同时请求使用指定资源的容器组的总量不能超过的上限值，也就是说，容器组在请求调度指定资源时，可以随意请求，没有上限值，后续中心调度器在进行调度时，可以根据各个节点组件中指定资源的实时容量进行调度。
需要说明的是，为了满足压测作业的资源容量和资源质量需求，可以使用静态超卖后的Prod资源，从而直接复用Prod资源的单机内核设置等资源质量保障能力，且静态超卖不需要顾虑账本滞后和账本双算的难题，但是可能无法充分满足压测作业的资源总量要求。并且，对于压测作业，在发起容器组的调度请求时用户填写的容器组request(请求量)和limit(实际使用限制量)不一定能精确匹配实际的使用情况，为了在不扩机器的情况下满足更多作业调度需求，超卖系数的设置依赖于专家经验，同时依然可能要考虑不同节点水位来优化调度质量。除此之外，压测作业使用超卖的Prod资源，需要排除作业对在线Prod业务资源的干扰。
另外，还可以使用基于Prod利用率超卖的Batch资源，Batch资源使用了基于Prod资源利用率计算的动态超卖资源，由于Prod资源利用率相对稳定，因此Batch资源总量/账本的波动是可容忍的，目前被用于跑一些对单机运行质量要求不高的离线作业，但是当前直接使用Batch资源也存在对其他离线作业的预期外干扰。除此之外，当前Batch资源提供的单机运行质量是不匹配压测作业需求的，Batch作业会持续遭受不同预设策略下的资源压制。
再者，还可以使用基于Prod利用率超卖的Mid资源，Mid资源是源于Batch的一部分较稳定资源，资源压制时的保障等级也要高于Batch，但仍低于Prod。相比Batch资源，采用Mid资源的优势在于既不会对其他Batch作业做出预期外的干扰，也能提供相比Batch资源更稳定的单机运行质量。然而，Mid资源因为是从单机未分配资源中根据画像划分的相对稳定部分，因此容量也相对有限，用户对容器组request和limit的估计精确与否影响着最终资源总量能否满足，因此也存在着难以满足压测作业资源用量的风险。
因而，本说明书实施例中可以采用动态超卖资源，将节点组件中各类型资源已分配、且未被使用的资源作为Free资源，实时计算Free资源的资源容量，后续在接收到容器组的调度请求时，根据实时计算得到的Free资源的资源容量进行容器组调度，从而通过动态调度将一部分应用程序分配了但未使用的资源回收，用于调度其他应用程序，从而优化节点的资源使用效率，降低机器成本。
本说明书实施例中可以将节点组件的各类型资源中已分配、且未被使用的资源作为指定资源，节点组件可以实时检测本地的资源使用信息，管控组件可以完全基于各节点组件的实际资源使用信息，实时计算各节点组件中指定资源的资源容量，中心调度器在接收到容器组的调度请求时，可以根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件，并将该容器组调度至目标节点组件。这种情况下，可以利用各节点组件的实际资源使用信息，实时计算指定资源的资源容量，对节点组件的各类型资源中已分配、且未被使用的资源进行回收，重新用于容器组调度，为容器组调度提供更多的资源容量，满足各任务对于资源容量的需求；如此，在某任务需要使用更多资源的阶段，可以充分发掘集群内各节点组件的各类型资源中已分配、且未被使用的资源，无需对其他任务进行资源压缩，同时在该任务无需使用更多资源的阶段时，可以回收节点组件的各类型资源中已分配、且未被使用的资源用于其他任务调度，提供了一种更动态、灵活的资源容量计算方法，充分复用了节点组件的各类型资源中已分配、且未被使用的资源，更灵活地进行集群内各节点组件的资源调度，保证各任务对于资源的容量需求。
本实施例一个可选的实施方式中，管控组件104进一步被配置为：
从第一节点组件检测到的资源使用信息中确定已使用资源量，第一节点组件为至少一个节点组件中的任一个；
确定第一节点组件的资源总量、预留资源量和指定资源上限；
根据资源总量、预留资源量、已使用资源量和指定资源上限，计算第一节点组件中指定资源的资源容量。
具体的，资源总量可以是指第一节点组件中各个优先级类别的资源的数量总和，预留资源量可以是指资源调度系统预先设置的、固定的、安全预留空间，已使用资源量可以是指第一节点组件中已经被使用的资源的数量总和，指定资源上限可以是指预先设置的限制计算出的指定资源的资源容量的约束值，一般设置的较大，计算出的指定资源的资源容量不能超过这个值。
实际实现时，可以基于如下公式(1)计算第一节点组件中指定资源的资源容量：
Free＝min(CapacityNode-ReservedSystem-UsageNode,HardLimitFree) (1)
其中，Free是指第一节点组件中指定资源的资源容量，CapacityNode是指第一节点组件的资源总量，ReservedSystem是指第一节点组件的预留资源量，UsageNode是指第一节点组件的各类型资源的已使用资源量，如Prod资源、Mid资源、Batch资源和Free资源等的已使用资源量，HardLimitFree可以为指定资源上限。
也就是说，可以使用第一节点组件的资源总量减去预留资源量再减去已使用资源量，得到第一节点组件中指定资源的参考容量，然后可以确定计算得到的参考容量是否超过了指定资源上限，若未超过指定资源上限，则将该参考容量确定为第一节点组件中指定资源的资源容量，若超过指定资源上限，则将该指定资源上限确定为第一节点组件中指定资源的资源容量。
实际应用中，管控组件104可以根据第一节点组件的资源总量、预留资源量、已使用资源量和指定资源上限，计算得到第一节点组件中指定资源的资源容量，资源调度系统包括的至少一个节点组件中的任一个均可以作为该第一节点组件，计算得到指定资源的资源容量，从而获得资源调度系统中的各个节点组件中指定资源的资源容量。
一种可能的实现方式中，图3是本说明书一个实施例提供的一种资源容量示意图，如图3所示，第一节点组件的资源总量包括已使用资源量、指定资源的资源容量和预留资源量，其中，已使用资源量可以包括各个优先级类别的资源的已使用数量，如Prod、Mid、Batch和Free等的已使用数量。
另外，指定资源为节点组件的各类型资源中已分配、且未被使用的资源，即超卖资源，CPU和内存维度上往往会产生较多的超卖资源，也即指定资源可以主要来自于CPU和内存维度产生的超卖资源。实际实现时，CPU可以使用更高优先级(Prod、Mid、Batch)的资源，分为的CPU资源往往较多，但是会存在一部分资源未被使用，即分配的CPU资源产生的超卖资源可以作为指定资源(即Free资源)；内存/Disk可以使用一部分预保留资源和一部分更高优先级的超卖资源，相比于其他静态调度或基于请求的动态超卖资源，调度指定资源时，只需要确保当前容量满足容器组(Pod)的指定资源请求，指定资源的资源容量并不计算节点组件上已调度的指定资源，也即节点组件上已调度的指定资源算在已使用资源中。
本说明书实施例中可以利用节点组件的实际资源使用信息，实时计算指定资源的资源容量，对节点组件的各类型资源中已分配、且未被使用的资源进行回收，重新用于容器组调度，为容器组调度提供更多的资源容量，满足各任务对于资源容量的需求，提供了一种更动态、灵活的资源容量计算方法，充分复用了节点组件的各类型资源中已分配、且未被使用的资源，更灵活地进行集群内各节点组件的资源调度，保证各任务对于资源的容量需求。
本实施例一个可选的实施方式中，节点组件102进一步被配置为：
回收各类型资源中已分配、且未被使用的资源，将回收到的资源作为指定资源；
将回收的指定资源分配给新调度的容器组。
需要说明的是，指定资源是指节点组件中各类型资源已分配、且未被使用的资源，也即是指定资源是已经分配的资源，因而中心调度器可以回收各类型资源中已分配、且未被使用的资源作为指定资源(即Free资源)，将回收的指定资源重新分配给新调度的容器组，以执行相应的任务。
本说明书实施例中可以通过回收节点组件中各类型资源已分配、且未被使用的资源，即回收指定资源，用于其他容器组的运行调度，实现资源的时分复用，节点组件中各类型资源已分配、且未被使用的资源。
本实施例一个可选的实施方式中，中心调度器106进一步被配置为：
根据各个节点组件检测到的资源使用信息，分别确定各个节点组件中指定资源的资源利用率；
根据各个节点组件中指定资源的资源容量和资源利用率，确定调度请求对应的目标节点组件。
具体的，指定资源的资源利用率可以为指定资源在过去一段时间内的使用比例，即已使用的指定资源占指定资源的资源容量的比例。需要说明的是，由于指定资源的资源容量是实时根据节点组件上的资源使用信息计算得到，也即指定资源的资源容量是动态变化的，指定资源的资源容量可能会波动频繁，在运行质量上可能会有干扰高优先级资源的风险，因而本说明书实施例中可以在中心调度器中对调度过程进行优化，一种可能的实现方式中，中心调度器可以将容器组的调度请求进行打散处理，也即将容器组的调度请求分散到不同的节点组件上，从而保证各个节点组件中指定资源的资源利用率趋近相同。
实际应用中，节点组件可以实时检测并上报本地的资源使用情况，管控组件可以实时计算得到节点组件中指定资源的资源容量，因而中心调度器可以实时获取到各个节点组件检测到的资源使用信息，并获取到管控组件实时计算得到的指定资源的资源容量，然后分别确定各个节点组件中指定资源的资源利用率，在接收到的容器组的调度请求时，可以根据各个节点组件中指定资源的资源容量和资源利用率，确定调度请求对应的目标节点组件，从而可以将该调度请求分配给指定资源的资源容量充足、且资源利用率较低的节点组件。
另外，在将容器组的调度请求进行打散处理时，还可以参考容器组的调度请求的任务类型，将该容器组调度至相应的节点组件，且保证调度后的各个节点组件中指定资源的资源利用率趋近相同，具体实现时，还可以通过其他分组维度将容器组的调度请求分配至不同的节点组件，以均衡各个节点组件中指定资源的资源利用率，本说明书实施例对此不进行限制。
本说明书一实施例中心调度器可以分别确定各个节点组件中指定资源的资源利用率，结合指定资源的资源利用率对容器组进行调度，从而可以将容器组的调度请求分配给指定资源的资源容量充足、且资源利用率较低的节点组件，均衡调度后的指定资源的资源利用率，保证各个节点组件中指定资源的资源利用率趋近相同，避免了请求指定资源的容器组形成热点，导致扎堆被驱逐或干扰其他应用的任务运行。
本实施例一个可选的实施方式中，该资源调度系统还包括中间组件108；
节点组件102，进一步被配置为将检测到的资源使用信息上报给中间组件108；
管控组件104，进一步被配置为从中间组件108获取各个节点组件102的资源使用信息，并将计算得到的各个节点组件中指定资源的资源容量返回给中间组件108；
中心调度器106，进一步被配置为从中间组件108获取各个节点组件102中指定资源的资源容量。
需要说明的是，如图2所示，节点组件102检测本地的资源使用信息之后，可以将上报资源使用信息给中间组件108，中间组件108可以进行记录存储。当管控组件104需要获取该资源使用信息时，可以直接与中间组件108交互，获取资源使用信息；并且，管控组件104计算得到各个节点组件中指定资源的资源容量后，还可以将该资源容量写回给中间组件，即管控组件104可以向中间组件108返回指定资源的资源容量，中间组件108进行记录，以供中心调度器106在对容器组进行调度时获取。中心调度器106可以从中间组件108中获取各个节点组件的节点信息，该节点信息可以包括资源总容量、指定资源的资源容量、是否被设置调度标识等信息。
本说明书实施例中心调度器、管控组件与节点组件之间均可以通过中间组件进行交互，中间组件可以维护、记录其他组件产生的信息，以供获取、查询等操作，通过引入中间组件，简化了中心调度器、管控组件与节点组件之间的交互过程，方便了信息的记录和存储。
本实施例一个可选的实施方式中，节点组件102进一步被配置为：
从中间组件获取指定资源对应的预设资源限制策略；
获取指定资源的当前资源利用率，并根据预设资源限制策略和当前资源利用率，确定是否对容器组进行资源压制处理或容器组终止处理；
在确定对容器组进行资源压制处理或容器组终止处理的情况下，基于预设资源限制策略和各个容器组的资源配置参数，从运行的各个容器组中筛选出目标容器组，进行资源压制处理或容器组终止处理，并将进行资源压制处理或容器组终止处理的处理信息上报给中间组件。
具体的，预设资源限制策略可以是指预先设置的、对节点组件中的容器组进行资源压制处理或容器组终止处理的规则，用于表示指定资源的当前资源利用率满足什么条件时，对哪些容器组进行处理、进行资源压制处理还是容器组终止处理等，如预设资源限制策略可以为指定资源的当前资源利用率超过利用率阈值时，对资源优先级最低的容器组进行资源压制处理或者容器组终止处理。
需要说明的是，中间组件中可以预先存储有指定资源对应的预设资源限制策略，用于指示什么情况对容器组进行资源压制处理或容器组终止处理，因而节点组件可以从中间组件中获取该预设资源限制策略，之后，节点组件可以检测确定本地指定资源的当前资源利用率，然后确定当前资源利用率是否满足预设资源限制策略中对容器组进行资源压制处理或容器组终止处理的条件，若满足，则确定对容器组进行资源压制处理或容器组终止处理，若不满足，则确定不对容器组进行资源压制处理或容器组终止处理。如图1所示，在需要对容器组进行资源压制处理或容器组终止处理时，节点组件可以控制本地的容器组，以对容器组进行资源压制处理或容器组终止处理。
实际应用中，在确定出需要对容器组进行资源压制处理或容器组终止处理时，可以确定预设资源限制策略中指示的需要对哪一类容器组进行处理，并结合各个容器组的资源配置参数，从运行的各个容器组中筛选出目标容器组，进行资源压制处理或容器组终止处理，该目标容器组就是预设资源限制策略中指示的需要进行资源压制处理或容器组终止处理的容器组。
本说明书实施例中节点组件可以根据指定资源的当前资源利用率以及预设资源限制策略，确定是否需要对容器组进行资源压制处理或容器组终止处理，并在需要对容器组进行资源压制处理或容器组终止处理时，筛选出目标容器组进行资源压制处理或容器组终止处理，之后还可以将资源压制处理或容器组终止处理的处理信息上报给中间组件进行记录。如此，可以根据节点组件的资源利用率，对某些容器组进行资源压制处理或容器组终止处理，从而避免资源利用率过高导致的资源可用性下降问题，保证了单个节点组件的资源运行质量。
本实施例一个可选的实施方式中，节点组件102进一步被配置为：
在指定资源的质量等级为预设等级的情况下，将各个容器组中资源优先级为预设优先级范围内的容器组作为目标容器组进行容器组终止处理；
在指定资源的质量等级不为预设等级的情况下，将指定资源对应的容器组作为目标容器组进行资源压制处理或容器组终止处理。
具体的，质量等级可以是指运行过程中的资源等级，即QOS等级。预设等级可以是预先设置的、较高的质量等级，如LS等级。容器组终止处理可以是指直接让整个容器组终止运行，资源压制处理可以是指能够容忍一部分资源竞争，设置容器组的资源使用上限，减少可以使用的资源，容器组可以使用的资源量会被压缩，但是不会终止，如通过调低容器组进程可用资源的时间片，来压缩容器组资源利用量的手段，比如调低Linux CFS调度器的CPU配置预算。
需要说明的是，对于指定资源来说，可以基于CPU和内存两种资源类型设置预设资源限制策略，考虑到CPU资源水位波动频繁，但带来的性能影响是可容忍的，而内存资源水位变化较慢，但一旦超出则很可能导致处理器内核的内存被耗尽，因此默认使用实时的内存资源水位触发容器组终止处理(即容器组驱逐)，而使用一段时间内的CPU资源水位来选择进行容器组终止处理或资源压制处理。
实际应用中，CPU资源和内存资源往往会具有不同的质量等级，对于指定资源为内存资源来说，该指定资源的质量等级为预设等级，此时可以直接按照各个容器组的资源优先级顺序，进行容器组终止处理；对于指定资源为CPU资源来说，该指定资源的质量等级不为预设等级，此时可以对指定资源对应的容器组进行资源压制处理或者容器组终止处理。
也即是说，指定资源对应的容器组可以根据质量等级的不同，在质量等级为预设等级(如LS)时，不被其他级别的资源压制，即仅按优先级顺序处理节点组件上的容器组驱逐，但不对请求指定资源的容器组进行压制，以在保障更高优先级资源质量的同时，不压缩指定资源的运行时质量。这种方案适合压测型作业，这类工作负载希望尽量精确地获取压测中的性能表现和系统资源损耗，以便于容量规划，如果指定资源在运行中被压制，则可能导致压测结果失真。
另外，在质量等级不为预设等级(如BE)时，优先保障更高优先级的资源质量，也即当触发节点组件上的资源限制(容器组终止处理或资源压制处理)时，优先对指定资源对应的容器组进行终止处理或资源压制处理，这种方案适合日常的低优先级作业使用，比如日常的测试任务。
本说明书实施例中节点组件可以在指定资源的质量等级为预设等级的情况下，使指定资源使用预设质量级别，不被其他级别的资源压制，此时仅按照容器组的资源优先级来确定对哪个容器组进行终止处理，而在指定资源的质量等级不为预设等级的情况下，使指定资源不使用预设质量级别，可以优先被指定终止处理或资源压制处理，优先保障更高优先级的资源质量。如此，对于不同质量等级的指定资源，可以采取不同的资源限制策略，可以更灵活地保证单个节点组件上的资源运行质量。
本实施例一个可选的实施方式中，节点组件102进一步被配置为：
若各个容器组的资源优先级相同，则确定各个容器组中资源使用量超过资源请求量的超量比值；
将各个容器组中超量比值大于超量阈值的容器组作为目标容器组进行容器组终止处理。
需要说明的是，超量阈值可以是指预先设置的数值，用于判断资源使用量超过资源请求量的超量比值是否过大。
本说明书实施例中，在根据各个容器组的资源优先级来确定进行进行容器组终止处理的目标容器组时，若各个容器组的资源优先级相同，则可以考虑确定各个容器组中资源使用量超过资源请求量的超量比值，将超量比值过大的容器组作为目标容器组进行容器组终止处理，从而可以优先驱逐资源超量过多的容器组，保障资源运行质量。
本实施例一个可选的实施方式中，节点组件102进一步被配置为：
在当前资源利用率超过第一资源利用率阈值的情况下，确定进行资源压制处理；
在当前资源利用率超过第二资源利用率阈值的情况下，确定进行容器组终止处理。
具体的，第一资源利用率阈值和第二资源利用率阈值可以是指预先设置的、用于判断当前资源利用率的大小的数值，第一资源利用率阈值可以设置的小于第二资源利用率阈值。
需要说明的是，在当前资源利用率超过第一资源利用率阈值，但未超过第二利用率阈值的情况下，说明当前资源利用率较高，为了保证资源运行质量，可以进行资源压制处理，即缩减目标容器组使用的资源量；而在当前资源利用率超过第二资源利用率阈值的情况下，则说明当前资源利用率过高，进行资源压制已经不能满足资源质量的需求，此时可以对容器组进行终止处理，直接终止目标容器组的运行。
本说明书实施例中在当前资源利用率超过相应的资源利用率阈值时，可以进行对应的资源限制，如资源压制处理或者容器组终止处理，不会出现资源利用率过高导致的资源可用性下降问题，从而可以持续保障节点组件的资源利用率不超出资源利用率阈值，保障运行过程中的资源质量，不对其他资源的质量造成非预期的干扰。
本实施例一个可选的实施方式中，管控组件104进一步被配置为：
从中间组件中获取节点组件上报的处理信息；
确定处理信息中包括容器组终止处理的目标处理信息；
在目标处理信息对应的节点组件的节点信息中添加调度标识，调度标识用于指示目标处理信息对应的节点组件在预设时间段内不参与新调度；
将节点信息返回给中间组件。
需要说明的是，节点组件对目标容器组进行资源压制处理或容器组终止处理后，可以将进行资源压制处理或容器组终止处理的处理信息上报给中间组件，以供其他组件获取使用。其中，节点组件上报的处理信息中可以包括对哪个容器组进行了处理，进行的是容器组终止处理还是资源压制处理等信息。
实际应用中，管控组件可以从中间组件中获取节点组件上报的处理信息，并从获取到的各个处理信息中筛选出进行了容器组终止处理的目标处理信息，在该目标处理信息对应的节点组件的节点信息中添加调度标识，也即对于进行过容器组终止处理的节点组件添加调度标识，以指示该节点组件在预设时间段内不参与新调度。其中，预设时间段可以是指预先设置的时间段，如1分钟、5分钟、10分钟等。
本说明书实施例中可以针对由于资源利用率触发容器组终止处理的节点组件添加调度标识，使该节点组件在一段时间内不参与新的调度，从而避免高资源利用率的节点组件上连续出现容器组资源不足导致的创建失败。
本实施例一个可选的实施方式中，调度请求中还携带请求资源量；中心调度器106进一步被配置为：
确定目标节点组件的资源总量，并根据目标节点组件的资源总量和预设比例系数，确定目标节点组件中指定资源的资源约束值；
在调度请求中携带的请求资源量小于资源约束值的情况下，执行将容器组调度至目标节点组件的操作步骤。
具体的，预设比例系数可以是指预先设置的约束系数，用于约束指定资源的请求量，一般设置的小于1。
需要说明的是，在发起容器组的调度请求时，还可以在该调度请求中指定要使用的指定资源的请求资源量，以通知中心调度器想要使用多少指定资源。实际应用中，可以基于如下公式(2)确定指定资源的资源约束值：
sum(RequestFree)≤ε×CapacityNode (2)
其中，sum(RequestFree)可以是指调度请求中携带的请求资源量的最大值，ε是指预设比例系数，CapacityNode是指目标节点组件的资源总量，ε×CapacityNode表示指定资源的资源约束值。上述公式(2)表示，调度请求中携带的请求资源量最大不能超过指定资源的资源约束值，在调度请求中携带的请求资源量小于资源约束值的情况下，说明满足资源约束条件，可以正常调度，即执行将容器组调度至目标节点组件的操作步骤，若调度请求中携带的请求资源量不小于资源约束值的情况下，则说明不满足资源约束条件，调度失败。
本说明书实施例中考虑到节点组件的资源利用率信息同步存在一定延迟，因而可以在中心调度器的节点组件过滤逻辑中设置指定资源的总量约束(即指定资源的资源约束值)，在调度请求中携带的请求资源量小于资源约束值的情况下，再将容器组调度至目标节点组件，以避免指定资源在某个节点组件提前分配过度。
需要说明的是，本说明书实施例中QoS级别和资源用量不绑定，即对于指定资源来说，支持统一调度所有的QoS级别(如LS和BE)，且未做QoS级别和调度请求之间的限制，提交的容器组的调度请求可以指定request(请求资源量)和limit(实际使用上限)的用量配置，提升了资源的易用性，从而可以基于request配置控制指定资源的容器组之间的公平性。
本实施例一个可选的实施方式中，中心调度器106进一步被配置为：
获取各个节点组件的资源使用信息；
从资源使用信息中确定指定资源的当前资源利用率；
在当前资源利用率为预设冷却期内的资源利用率的情况下，确定参考资源请求量是否大于当前资源利用率，若大于，则将参考资源请求量作为指定资源更新后的当前资源利用率，参考资源请求量为根据指定资源的请求资源量和利用率预估系数确定；
根据指定资源更新后的当前资源利用率，对至少一个节点组件进行调度打分。
具体的，冷却期可以是指预先设置的时间段，也即资源利用率滞后的时间段。利用率预估系数可以是指预先设置的小于1的数值，用于预估冷却期内的资源利用率。
需要说明的是，指定资源的容量计算取决于节点组件上的资源利用率，但由于容器组应用的特点，刚调度的容器组的利用率往往难以反映其长期稳定的利用率。因此，本说明书实施例可以在中心调度器中对近期调度容器组的资源利用率计算设置“冷却期”，在“冷却期”内的容器组的资源利用率使用其请求资源量替代计算。
实际应用中，可以基于如下公式(3)确定指定资源更新后的当前资源利用率：
Figure BDA0003309385230000151
其中，Usage(Pod)Free可以为指定资源更新后的当前资源利用率，α可以是指利用率预估系数，Request(Pod)Free可以为指定资源的请求资源量，α×Request(Pod)Free可以是指参考资源请求量，Usage(Pod)Free可以是指当前资源利用率，max可以是指选两个数中的较大值，startTime可以是指获取到的当前资源利用率的时间，now可以是指当前时间，w可以是指冷却期。
上述公式(3)表示，对于处于冷却期内获取到的当前资源利用率，可以将参考资源请求量和当前资源利用率中最大的值确定为指定资源更新后的当前资源利用率，对于不处于冷却期内获取到的当前资源利用率，直接将获取到的当前资源利用率确定为指定资源更新后的当前资源利用率。
实际应用中，可以根据指定资源更新后的当前资源利用率，对至少一个节点组件进行调度打分，从而可以根据修改后的资源利用率评估各个节点组件适合被调度的分值，作为接收到容器组的调度请求时，确定将容器组调度至哪个节点组件的参考信息。
本说明书实施例中可以在中心调度器中对近期调度容器组的资源利用率计算设置“冷却期”，在“冷却期”内的容器组的资源利用率使用其请求资源量替代计算，从而规避指定资源对应的容器组刚启动时资源利用率上报偏低或偏高导致的调度偏差。
本实施例一个可选的实施方式中，中心调度器106进一步被配置为：
在获取到目标节点组件的当前资源使用信息的情况下，根据当前资源使用信息的接收时间之前的指定资源请求量之和，对累计请求值进行初始化；
接收到指定资源的调度请求的情况下，将调度请求对应的指定资源请求值与初始化后的累计请求值进行累加；
在接收到下一资源使用信息时，从当前的累计请求值中扣除预设时间之前的指定资源请求量总和，获得目标节点组件的延迟请求量。
需要说明的是，指定资源的调度完全基于指定资源的资源容量进行调度，而指定资源的资源容量完全基于资源使用信息进行计算，上述指定资源的调度方法可能存在“账本滞后”和“账本双算”两方面的问题。
账本滞后：指定资源的资源容量完全基于资源使用信息进行计算，资源使用信息通过节点组件和管控组件配合获得。因此，中心调度器获取到的资源使用信息通常存在滞后问题。由于在线任务(Prod)通常的资源使用信息变化频率较低，这种“账本滞后”问题对基于在线任务的资源使用信息超卖的Batch资源影响较小，但对完全基于节点组件的资源使用信息的指定资源(即Free资源)则影响较大。中心调度器拿到滞后的账本和真实结果可能相差较大，存在较多的“inflight Pods(即飘在空中的容器组，调度器认为调度出去了，但是节点组件实际还没有运行)”，容量计算的偏差可能导致调度和单机资源质量的下降。
账本双算：中心调度器在同步两次资源使用信息之间，通常需要维护部分最近已调度的容器组的请求信息，在处理新的调度请求时进行扣除，以计算出暂态(transient)的节点账本。但由于指定资源的资源容量不包含已调度的容器组的部分，如果依然对新调度的指定资源量进行扣除，则会导致这些容器组的资源用量被扣除了两次，即发生了“双算”问题，导致可调度的指定资源的资源容量相比真实结果偏小。
实际应用中，本说明书实施例在同步得到的两次资源使用信息之间引入了累计请求值，具体的，在获取到目标节点组件的当前资源使用信息的情况下，可以根据当前资源使用信息的接收时间之前的指定资源请求量之和，对累计请求值进行初始化；之后，每接收到一个指定资源的调度请求，就将该调度请求对应的指定资源请求值与初始化后的累计请求值进行累加；直至接收到下一资源使用信息时，从当前的累计请求值中扣除预设时间之前的指定资源请求量总和，获得目标节点组件的延迟请求量。
示例的，图4是本说明书一个实施例提供的一种当前资源使用信息的同步过程示意图，如图4所示，假设t-t0之前的指定资源请求量之和为0，此时可以将累计请求值初始化为0，即当前累计请求值为0，假设之后接收到了容器组A的调度请求，该调度请求对应的指定资源请求值为A，此时累计请求值更新为A，即当前累计请求值为A；之后，又接收到了容器组B的调度请求，该调度请求对应的指定资源请求值为B，此时累计请求值更新为A+B，即当前累计请求值为A+B；之后，又接收到了容器组C的调度请求，该调度请求对应的指定资源请求值为C，此时累计请求值更新为A+B+C，即当前累计请求值为A+B+C。假设时间t时，接收到了下一资源使用信息，此时可以从当前的累计请求值中扣除t-t1(预设时间)之前的指定资源请求量总和：A+B，获得目标节点组件的延迟请求量为C。
需要说明的是，计算得到的延迟请求量即为“inflight Pods(即飘在空中的容器组，调度器认为调度出去了，但是节点组件实际还没有运行)”请求使用的资源量，在根据当前计算得到的指定资源的资源容量进行容器组调度时，可以结合该延迟请求量，将已经调度、但是节点组件中未运行的容器组考虑在内，避免账本滞后问题带来的容量计算的偏差，从而避免调度和单机资源质量的下降。
另外，在维护部分最近已调度的容器组的请求信息，在处理新的调度请求时进行扣除时，由于该延迟请求量是中心调度器已调度的容器组的部分，因而不对计算得到的延迟请求量进行扣除，避免这些容器组的资源用量被扣除两次，从而避免可调度的指定资源的资源容量相比真实结果偏小。
本说明书实施例中可以选取每次资源使用信息更新的前预设时间作为对“飘在空中(inflight)”的新调度的容器组的窗口估计，作为一个比账本同步周期更稳定的链路延迟估计，从而一定程度上避免账本滞后和账本双算问题。
本实施例一个可选的实施方式中，中心调度器106进一步被配置为：
接收到指定资源的调度请求的情况下，确定调度请求对应的指定资源请求值与当前的累计请求值之和；
在指定资源请求值与当前的累计请求值之和小于目标节点组件中指定资源的资源容量的情况下，将容器组调度至目标节点组件；
在指定资源请求值与当前的累计请求值之和不小于目标节点组件中指定资源的资源容量的情况下，确定目标节点组件调度失败，并选择其他节点组件进行调度。
需要说明的是，当前的累计请求值可以表示当前时间之前目标节点组件累计被分配了多少数量的指定资源，因而在接收到指定资源的调度请求的情况下，可以确定调度请求对应的指定资源请求值与当前的累计请求值之和是否小于目标节点组件中指定资源的资源容量，若小于，则说明目标节点组件可以满足该容器组的调度请求对于指定资源的需求，此时可以将该容器组调度至目标节点组件；若不小于，则说明当前请求使用的指定资源的数量已经超过目标节点组件可以满足的需求，此时可以确定目标节点组件调度失败，并选择其他节点组件进行调度。
本说明书实施例中可以根据当前的累计请求值，对指定资源的调度请求中指定资源请求值进行约束限制，避免由于资源使用信息滞后问题导致的调度失败。
本实施例一个可选的实施方式中，调度请求还携带资源质量等级；中心调度器106进一步被配置为：
根据目标节点组件中指定资源的资源容量，向容器组分配资源质量等级对应的指定资源。
需要说明的是，为了使指定资源能够同时支持两种可选的单机运行质量保障方案，本说明书实施例中设置了针对节点组件和容器组粒度的QoS配置策略，也即在请求调度容器组时，可以设置其请求调度的容器组的QOS级别，在后续进行容器组调度时，可以根据目标节点组件中指定资源的资源容量，向容器组分配该资源质量等级对应的指定资源。后续，当节点组件的资源利用率超过阈值时，节点组件可以根据节点组件和容器组的QOS级别配置，选择对容器组进行容器组终止处理或资源压制处理，使用不同QOS级别的容器组可以在同一节点组件上共存。
另外，指定资源的容器组的结构配置取决于其QOS级别，即资源质量等级。在CPUcgroup方面，指定资源的容器组可以根据其QOS级别是LS或是BE，存在对应的两种配置，也即可以存在QOS级别为LS的容器组，可以存在QOS级别为BE的容器组，其他配置则可以复用开源代码中设置好的参数。对于Memory cgroup的结构来说相对简单，可以保持资源调度系统的默认配置，基本与社区Kubernetes设置一致，比如，Free(QOS＝LS)和Free(QOS＝BE)两种容器组都依据填写的memory limit设置memory.limit_in_bytes。再者，对于oom_score_adj的设置则依据资源优先级(priority)，保证OOM(内存资源被耗尽)时Free资源(指定资源)的容器组比Prod、Mid、Batch更优先被终止。
示例的，图5是本说明书一个实施例提供的一种容器组配置示意图，如图5所示，某节点组件上可以包括4个容器组：容器组1、容器组2、容器组3和容器组4，容器组1未限制资源优先级类别、QOS＝LS，容器组2的资源优先级类别为Prod/Free、QOS＝LS，容器组3的资源优先级类别为Mid、未限制QOS级别，容器组4的资源优先级类别为Batch/Free，QOS＝BE。
另外，为了保障节点组件上资源的可用性，避免内核级别的OOM(Out-of-Memory)Kill，即内核级别的资源耗尽，当集群资源使用率达到一定阈值时(比如80％)，可以提前通过其他组件在用户态将使用指定资源(非Prod资源)的容器组进行终止处理。
本说明书实施例中可以基于资源调度系统的资源调度，容器组可以设置请求使用指定资源，即可按照指定资源请求调度对应的容器组至目标节点组件。另外，还可以根据所需要的QOS级别，针对指定资源的容器组可以选择LS或BE作为其QOS级别，最终影响其容器组在节点组件上的结构配置。
本实施例一个可选的实施方式中，中心调度器106进一步被配置为：
在容器组中添加目标节点组件的调度字段，通过调度字段，将容器组调度至目标节点组件；
记录容器组和目标节点组件的对应关系，并将对应关系同步给中间组件。
需要说明的是，中心调度器把某个容器组调度到某个节点组件时，可以给容器组中写一个调度字段，说明该容器组被调度在哪个节点组件，从而可以将该容器组调度到对应的节点组件，调度后，还可以记录容器组和节点组件之间的调度结果，也即如图2所示，中心调度器106记录容器组和目标节点组件的对应关系后，可以将同步对应关系给中间组件108，以进行记录。
本说明书一个实施例中可以将节点组件的各类型资源中已分配、且未被使用的资源作为指定资源，节点组件可以实时检测本地的资源使用信息，管控组件可以完全基于各节点组件的实际资源使用信息，实时计算各节点组件中指定资源的资源容量，中心调度器在接收到容器组的调度请求时，可以根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件，并将该容器组调度至目标节点组件。这种情况下，可以利用各节点组件的实际资源使用信息，实时计算指定资源的资源容量，对节点组件的各类型资源中已分配、且未被使用的资源进行回收，重新用于容器组调度，为容器组调度提供更多的资源容量，满足各任务对于资源容量的需求；如此，在某任务需要使用更多资源的阶段，可以充分发掘集群内各节点组件的各类型资源中已分配、且未被使用的资源，无需对其他任务进行资源压缩，同时在该任务无需使用更多资源的阶段时，可以回收节点组件的各类型资源中已分配、且未被使用的资源用于其他任务调度，提供了一种更动态、灵活的资源容量计算方法，充分复用了节点组件的各类型资源中已分配、且未被使用的资源，更灵活地进行集群内各节点组件的资源调度，保证各任务对于资源的容量需求。
另外，本说明书实施例提供的资源调度系统同时也支持两种节点组件上的资源质量保障策略，资源调度系统对于请求指定资源的容器组，能够实时地更新可用的资源容量，也能根据节点组件的水位，通过可选的压制和终止策略，及时调控容器组的物理资源使用，从容量和质量两方面保障资源的SLO。
图6示出了根据本说明书一个实施例提供的一种资源调度方法的流程图，应用于上述资源调度系统中包括的中心调度器，如图6所示，该资源调度方法包括：
步骤602：接收容器组的调度请求。
步骤604：在调度请求中携带的资源类型为指定类型的情况下，根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件，其中，指定类型为指定资源所属类型，指定资源为节点组件的各类型资源中已分配、且未被使用的资源，各个节点组件中指定资源的资源容量为管控组件根据各个节点组件检测到的资源使用信息分别计算得到。
需要说明的是，中心调度器可以从中间组件获取各个节点组件中指定资源的资源容量，然后在调度请求中携带的资源类型为指定类型的情况下，根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件，从而将该容器组调度至对应的节点组件。
本说明书实施例中可以利用节点组件的实际资源使用信息，实时计算指定资源的资源容量，对节点组件的各类型资源中已分配、且未被使用的资源进行回收，重新用于容器组调度，为容器组调度提供更多的资源容量，满足各任务对于资源容量的需求，充分复用了节点组件的各类型资源中已分配、且未被使用的资源，更灵活地进行集群内各节点组件的资源调度，保证了各任务对于资源的容量需求。
本实施例一个可选的实施方式中，根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件，具体实现过程可以如下：
根据各个节点组件检测到的资源使用信息，分别确定各个节点组件中指定资源的资源利用率；
根据各个节点组件中指定资源的资源容量和资源利用率，确定调度请求对应的目标节点组件。
本说明书一实施例中心调度器可以分别确定各个节点组件中指定资源的资源利用率，结合指定资源的资源利用率对容器组进行调度，从而可以将容器组的调度请求分配给指定资源的资源容量充足、且资源利用率较低的节点组件，均衡调度后的指定资源的资源利用率，保证各个节点组件中指定资源的资源利用率趋近相同，避免了请求指定资源的容器组形成热点，导致扎堆被驱逐或干扰其他应用的任务运行。
本实施例一个可选的实施方式中，根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件之前，还可以包括：
获取各个节点组件的资源使用信息；
从资源使用信息中确定指定资源的当前资源利用率；
在当前资源利用率为预设冷却期内的资源利用率的情况下，确定参考资源请求量是否大于当前资源利用率，若大于，则将参考资源请求量作为指定资源更新后的当前资源利用率，参考资源请求量为根据指定资源的请求资源量和利用率预估系数确定；
根据指定资源更新后的当前资源利用率，对至少一个节点组件进行调度打分。
实际应用中，对于处于冷却期内获取到的当前资源利用率，可以将参考资源请求量和当前资源利用率中最大的值确定为指定资源更新后的当前资源利用率，对于不处于冷却期内获取到的当前资源利用率，直接将获取到的当前资源利用率确定为指定资源更新后的当前资源利用率。如此，在中心调度器中对近期调度容器组的资源利用率计算设置“冷却期”，在“冷却期”内的容器组的资源利用率使用其请求资源量替代计算。
另外，可以根据指定资源更新后的当前资源利用率，对至少一个节点组件进行调度打分，从而可以根据修改后的资源利用率评估各个节点组件适合被调度的分值，作为接收到容器组的调度请求时，确定将容器组调度至哪个节点组件的参考信息。也即，根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件时，结合根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件和各个节点组件的得分，确定调度请求对应的目标节点组件时。
本说明书实施例中可以在中心调度器中对近期调度容器组的资源利用率计算设置“冷却期”，在“冷却期”内的容器组的资源利用率使用其请求资源量替代计算，从而规避指定资源对应的容器组刚启动时资源利用率上报偏低或偏高导致的调度偏差。
本实施例一个可选的实施方式中，根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件之前，还可以包括：
在获取到目标节点组件的当前资源使用信息的情况下，根据当前资源使用信息的接收时间之前的指定资源请求量之和，对累计请求值进行初始化；
接收到指定资源的调度请求的情况下，将调度请求对应的指定资源请求值与初始化后的累计请求值进行累加；
在接收到下一资源使用信息时，从当前的累计请求值中扣除预设时间之前的指定资源请求量总和，获得目标节点组件的延迟请求量。
实际应用中，本说明书实施例在同步得到的两次资源使用信息之间引入了累计请求值，具体的，在获取到目标节点组件的当前资源使用信息的情况下，可以根据当前资源使用信息的接收时间之前的指定资源请求量之和，对累计请求值进行初始化；之后，每接收到一个指定资源的调度请求，就将该调度请求对应的指定资源请求值与初始化后的累计请求值进行累加；直至接收到下一资源使用信息时，从当前的累计请求值中扣除预设时间之前的指定资源请求量总和，获得目标节点组件的延迟请求量。
本说明书实施例中可以选取每次资源使用信息更新的前预设时间作为对“飘在空中(inflight)”的新调度的容器组的窗口估计，作为一个比账本同步周期更稳定的链路延迟估计，从而一定程度上避免账本滞后和账本双算问题。
本实施例一个可选的实施方式中，获得目标节点组件的延迟请求量之后，还可以包括：
接收到指定资源的调度请求的情况下，确定调度请求对应的指定资源请求值与当前的累计请求值之和；
在指定资源请求值与当前的累计请求值之和小于目标节点组件中指定资源的资源容量的情况下，将容器组调度至目标节点组件；
在指定资源请求值与当前的累计请求值之和不小于目标节点组件中指定资源的资源容量的情况下，确定目标节点组件调度失败，并选择其他节点组件进行调度。
需要说明的是，当前的累计请求值可以表示当前时间之前目标节点组件累计被分配了多少数量的指定资源，因而在接收到指定资源的调度请求的情况下，可以确定调度请求对应的指定资源请求值与当前的累计请求值之和是否小于目标节点组件中指定资源的资源容量，若小于，则说明目标节点组件可以满足该容器组的调度请求对于指定资源的需求，此时可以将该容器组调度至目标节点组件；若不小于，则说明当前请求使用的指定资源的数量已经超过目标节点组件可以满足的需求，此时可以确定目标节点组件调度失败，并选择其他节点组件进行调度。如此，可以根据当前的累计请求值，对指定资源的调度请求中指定资源请求值进行约束限制，避免由于资源使用信息滞后问题导致的调度失败。
本实施例一个可选的实施方式中，根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件之后，还可以包括：
在容器组中添加目标节点组件的调度字段，通过调度字段，将容器组调度至目标节点组件；
记录容器组和目标节点组件的对应关系，并将对应关系同步给中间组件。
需要说明的是，中心调度器把某个容器组调度到某个节点组件时，可以给容器组中写一个调度字段，说明该容器组被调度在哪个节点组件，从而可以将该容器组调度到对应的节点组件，调度后，还可以记录容器组和节点组件之间的调度结果，返回给中间组件，以进行记录。
步骤606：将容器组调度至目标节点组件。
需要说明的是，中心调度器在根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件的基础上，进一步地，可以将容器组调度至目标节点组件，以执行对应的任务。
本实施例一个可选的实施方式中，调度请求中还携带请求资源量，此时将容器组调度至目标节点组件之前，还可以包括：
确定目标节点组件的资源总量，并根据目标节点组件的资源总量和预设比例系数，确定目标节点组件中指定资源的资源约束值；
在调度请求中携带的请求资源量小于资源约束值的情况下，执行将容器组调度至目标节点组件的操作步骤。
本说明书实施例中考虑到节点组件的资源利用率信息同步存在一定延迟，因而可以在中心调度器的节点组件过滤逻辑中设置指定资源的总量约束(即指定资源的资源约束值)，在调度请求中携带的请求资源量小于资源约束值的情况下，再将容器组调度至目标节点组件，以避免指定资源在某个节点组件提前分配过度。
本实施例一个可选的实施方式中，调度请求还携带资源质量等级；将容器组调度至目标节点组件，具体实现过程可以如下：
根据目标节点组件中指定资源的资源容量，向容器组分配资源质量等级对应的指定资源。
需要说明的是，为了使指定资源能够同时支持两种可选的单机运行质量保障方案，本说明书实施例中设置了针对节点组件和容器组粒度的QoS配置策略，也即在请求调度容器组时，可以设置其请求调度的容器组的QOS级别，在后续进行容器组调度时，可以根据目标节点组件中指定资源的资源容量，向容器组分配该资源质量等级对应的指定资源。后续，当节点组件的资源利用率超过阈值时，节点组件可以根据节点组件和容器组的QOS级别配置，选择对容器组进行容器组终止处理或资源压制处理，使用不同QOS级别的容器组可以在同一节点组件上共存。
本说明书实施例中可以基于资源调度系统的资源调度，容器组可以设置请求使用指定资源，即可按照指定资源请求调度对应的容器组至目标节点组件。另外，还可以根据所需要的QOS级别，针对指定资源的容器组可以选择LS或BE作为其QOS级别，最终影响其容器组在节点组件上的结构配置。
本说明书一个实施例中可以将节点组件的各类型资源中已分配、且未被使用的资源作为指定资源，节点组件可以实时检测本地的资源使用信息，管控组件可以完全基于各节点组件的实际资源使用信息，实时计算各节点组件中指定资源的资源容量，中心调度器在接收到容器组的调度请求时，可以根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件，并将该容器组调度至目标节点组件。这种情况下，可以利用各节点组件的实际资源使用信息，实时计算指定资源的资源容量，对节点组件的各类型资源中已分配、且未被使用的资源进行回收，重新用于容器组调度，为容器组调度提供更多的资源容量，满足各任务对于资源容量的需求；如此，在某任务需要使用更多资源的阶段，可以充分发掘集群内各节点组件的各类型资源中已分配、且未被使用的资源，无需对其他任务进行资源压缩，同时在该任务无需使用更多资源的阶段时，可以回收节点组件的各类型资源中已分配、且未被使用的资源用于其他任务调度，提供了一种更动态、灵活的资源容量计算方法，充分复用了节点组件的各类型资源中已分配、且未被使用的资源，更灵活地进行集群内各节点组件的资源调度，保证各任务对于资源的容量需求。
与上述方法实施例相对应，本说明书还提供了资源调度装置实施例，图7示出了本说明书一个实施例提供的一种资源调度装置的结构示意图，应用于上述资源调度系统中包括的中心调度器，如图7所示，该装置包括：
接收模块702，被配置为接收容器组的调度请求；
确定模块704，被配置为在调度请求中携带的资源类型为指定类型的情况下，根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件，其中，指定类型为指定资源所属类型，指定资源为节点组件的各类型资源中已分配、且未被使用的资源，各个节点组件中指定资源的资源容量为管控组件根据各个节点组件检测到的资源使用信息分别计算得到；
调度模块706，被配置为将容器组调度至目标节点组件。
可选地，确定模块704进一步被配置为：
根据各个节点组件检测到的资源使用信息，分别确定各个节点组件中指定资源的资源利用率；
根据各个节点组件中指定资源的资源容量和资源利用率，确定调度请求对应的目标节点组件。
可选地，该装置还包括打分模块，被配置为：
获取各个节点组件的资源使用信息；
从资源使用信息中确定指定资源的当前资源利用率；
在当前资源利用率为预设冷却期内的资源利用率的情况下，确定参考资源请求量是否大于当前资源利用率，若大于，则将参考资源请求量作为指定资源更新后的当前资源利用率，参考资源请求量为根据指定资源的请求资源量和利用率预估系数确定；
根据指定资源更新后的当前资源利用率，对至少一个节点组件进行调度打分。
可选地，该装置还包括获得模块，被配置为：
在获取到目标节点组件的当前资源使用信息的情况下，根据当前资源使用信息的接收时间之前的指定资源请求量之和，对累计请求值进行初始化；
接收到指定资源的调度请求的情况下，将调度请求对应的指定资源请求值与初始化后的累计请求值进行累加；
在接收到下一资源使用信息时，从当前的累计请求值中扣除预设时间之前的指定资源请求量总和，获得目标节点组件的延迟请求量。
可选地，获得模块进一步被配置为：
接收到指定资源的调度请求的情况下，确定调度请求对应的指定资源请求值与当前的累计请求值之和；
在指定资源请求值与当前的累计请求值之和小于目标节点组件中指定资源的资源容量的情况下，将容器组调度至目标节点组件；
在指定资源请求值与当前的累计请求值之和不小于目标节点组件中指定资源的资源容量的情况下，确定目标节点组件调度失败，并选择其他节点组件进行调度。
可选地，该装置还包括记录模块，被配置为：
在容器组中添加目标节点组件的调度字段，通过调度字段，将容器组调度至目标节点组件；
记录容器组和目标节点组件的对应关系，并将对应关系同步给中间组件。
可选地，该装置还包括执行模块，被配置为：
确定目标节点组件的资源总量，并根据目标节点组件的资源总量和预设比例系数，确定目标节点组件中指定资源的资源约束值；
在调度请求中携带的请求资源量小于资源约束值的情况下，执行调度模块。
可选地，调度请求还携带资源质量等级；调度模块706进一步被配置为：
根据目标节点组件中指定资源的资源容量，向容器组分配资源质量等级对应的指定资源。
本说明书一个实施例中可以将节点组件的各类型资源中已分配、且未被使用的资源作为指定资源，节点组件可以实时检测本地的资源使用信息，管控组件可以完全基于各节点组件的实际资源使用信息，实时计算各节点组件中指定资源的资源容量，中心调度器在接收到容器组的调度请求时，可以根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件，并将该容器组调度至目标节点组件。这种情况下，可以利用各节点组件的实际资源使用信息，实时计算指定资源的资源容量，对节点组件的各类型资源中已分配、且未被使用的资源进行回收，重新用于容器组调度，为容器组调度提供更多的资源容量，满足各任务对于资源容量的需求；如此，在某任务需要使用更多资源的阶段，可以充分发掘集群内各节点组件的各类型资源中已分配、且未被使用的资源，无需对其他任务进行资源压缩，同时在该任务无需使用更多资源的阶段时，可以回收节点组件的各类型资源中已分配、且未被使用的资源用于其他任务调度，提供了一种更动态、灵活的资源容量计算方法，充分复用了节点组件的各类型资源中已分配、且未被使用的资源，更灵活地进行集群内各节点组件的资源调度，保证各任务对于资源的容量需求。
上述为本实施例的一种资源调度装置的示意性方案。需要说明的是，该资源调度装置的技术方案与上述的资源调度方法的技术方案属于同一构思，资源调度装置的技术方案未详细描述的细节内容，均可以参见上述资源调度方法的技术方案的描述。
图8示出了根据本说明书一个实施例提供的一种计算设备800的结构框图。该计算设备800的部件包括但不限于存储器810和处理器820。处理器820与存储器810通过总线830相连接，数据库850用于保存数据。
计算设备800还包括接入设备840，接入设备840使得计算设备800能够经由一个或多个网络860通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备840可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。
在本说明书的一个实施例中，计算设备800的上述部件以及图8中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图8所示的计算设备结构框图仅仅是出于示例的目的，而不是对本说明书范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。
计算设备800可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备800还可以是移动式或静止式的服务器。
其中，处理器820用于执行如下计算机可执行指令：
接收容器组的调度请求；
在调度请求中携带的资源类型为指定类型的情况下，根据各个节点组件中指定资源的资源容量，确定调度请求对应的目标节点组件，其中，指定类型为指定资源所属类型，指定资源为节点组件的各类型资源中已分配、且未被使用的资源，各个节点组件中指定资源的资源容量为管控组件根据各个节点组件检测到的资源使用信息分别计算得到；
将容器组调度至目标节点组件。
上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的资源调度方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述资源调度方法的技术方案的描述。
本说明书一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时以用于实现任意一项资源调度方法的步骤。
上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的资源调度方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述资源调度方法的技术方案的描述。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
计算机指令包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccess Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本说明书实施例并不受所描述的动作顺序的限制，因为依据本说明书实施例，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本说明书实施例所必须的。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。
以上公开的本说明书优选实施例只是用于帮助阐述本说明书。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书实施例的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本说明书实施例的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本说明书。本说明书仅受权利要求书及其全部范围和等效物的限制。

Claims (14)

1.一种资源调度系统，包括：中心调度器、管控组件和至少一个节点组件；
所述节点组件，被配置为检测本地的资源使用信息；
所述管控组件，被配置为根据各个节点组件检测到的资源使用信息，分别计算所述各个节点组件中指定资源的资源容量，其中，所述指定资源为节点组件的各类型资源中已分配、且未被使用的资源；
所述中心调度器，被配置为接收容器组的调度请求，在所述调度请求中携带的资源类型为指定类型的情况下，根据所述各个节点组件中指定资源的资源容量，确定所述调度请求对应的目标节点组件，并将所述容器组调度至所述目标节点组件，所述指定类型为所述指定资源所属类型。
2.根据权利要求1所述的资源调度系统，所述管控组件进一步被配置为：
从第一节点组件检测到的资源使用信息中确定已使用资源量，所述第一节点组件为所述至少一个节点组件中的任一个；
确定所述第一节点组件的资源总量、预留资源量和指定资源上限；
根据所述资源总量、预留资源量、已使用资源量和指定资源上限，计算所述第一节点组件中指定资源的资源容量。
3.根据权利要求1所述的资源调度系统，所述节点组件进一步被配置为：
回收各类型资源中已分配、且未被使用的资源，将回收到的资源作为指定资源；
将回收的指定资源分配给新调度的容器组。
4.根据权利要求1所述的资源调度系统，所述中心调度器进一步被配置为：
根据所述各个节点组件检测到的资源使用信息，分别确定所述各个节点组件中指定资源的资源利用率；
根据所述各个节点组件中指定资源的资源容量和资源利用率，确定所述调度请求对应的目标节点组件。
5.根据权利要求1-4任一项所述的资源调度系统，所述系统还包括中间组件；
所述节点组件，进一步被配置为将检测到的资源使用信息上报给所述中间组件；
所述管控组件，进一步被配置为从所述中间组件获取所述各个节点组件的资源使用信息，并将计算得到的所述各个节点组件中指定资源的资源容量返回给所述中间组件；
所述中心调度器，进一步被配置为从所述中间组件获取所述各个节点组件中指定资源的资源容量。
6.根据权利要求5所述的资源调度系统，所述节点组件进一步被配置为：
从所述中间组件获取所述指定资源对应的预设资源限制策略；
获取所述指定资源的当前资源利用率，并根据所述预设资源限制策略和所述当前资源利用率，确定是否对容器组进行资源压制处理或容器组终止处理；
在确定对容器组进行资源压制处理或容器组终止处理的情况下，基于所述预设资源限制策略和各个容器组的资源配置参数，从运行的各个容器组中筛选出目标容器组，进行资源压制处理或容器组终止处理，并将进行资源压制处理或容器组终止处理的处理信息上报给所述中间组件。
7.根据权利要求6所述的资源调度系统，所述节点组件进一步被配置为：
在所述指定资源的质量等级为预设等级的情况下，将所述各个容器组中资源优先级为预设优先级范围内的容器组作为所述目标容器组进行容器组终止处理；
在所述指定资源的质量等级不为预设等级的情况下，将所述指定资源对应的容器组作为所述目标容器组进行资源压制处理或容器组终止处理。
8.根据权利要求7所述的资源调度系统，所述节点组件进一步被配置为：
若所述各个容器组的资源优先级相同，则确定所述各个容器组中资源使用量超过资源请求量的超量比值；
将所述各个容器组中超量比值大于超量阈值的容器组作为所述目标容器组进行容器组终止处理。
9.根据权利要求1-4任一项所述的资源调度系统，所述调度请求中还携带请求资源量；所述中心调度器进一步被配置为：
确定所述目标节点组件的资源总量，并根据所述目标节点组件的资源总量和预设比例系数，确定所述目标节点组件中指定资源的资源约束值；
在所述调度请求中携带的请求资源量小于所述资源约束值的情况下，执行所述将所述容器组调度至所述目标节点组件的操作步骤。
10.根据权利要求1-4任一项所述的资源调度系统，所述中心调度器进一步被配置为：
获取各个节点组件的资源使用信息；
从所述资源使用信息中确定所述指定资源的当前资源利用率；
在所述当前资源利用率为预设冷却期内的资源利用率的情况下，确定参考资源请求量是否大于所述当前资源利用率，若大于，则将所述参考资源请求量作为所述指定资源更新后的当前资源利用率，所述参考资源请求量为根据所述指定资源的请求资源量和利用率预估系数确定；
根据所述指定资源更新后的当前资源利用率，对所述至少一个节点组件进行调度打分。
11.根据权利要求1-4任一项所述的资源调度系统，所述中心调度器进一步被配置为：
在获取到所述目标节点组件的当前资源使用信息的情况下，根据所述当前资源使用信息的接收时间之前的指定资源请求量之和，对累计请求值进行初始化；
接收到指定资源的调度请求的情况下，将所述调度请求对应的指定资源请求值与初始化后的累计请求值进行累加；
在接收到下一资源使用信息时，从当前的累计请求值中扣除预设时间之前的指定资源请求量总和，获得所述目标节点组件的延迟请求量。
12.根据权利要求11所述的资源调度系统，所述中心调度器进一步被配置为：
接收到指定资源的调度请求的情况下，确定所述调度请求对应的指定资源请求值与当前的累计请求值之和；
在所述指定资源请求值与当前的累计请求值之和小于所述目标节点组件中指定资源的资源容量的情况下，将所述容器组调度至所述目标节点组件；
在所述指定资源请求值与当前的累计请求值之和不小于所述目标节点组件中指定资源的资源容量的情况下，确定所述目标节点组件调度失败，并选择其他节点组件进行调度。
13.一种资源调度方法，应用于上述权利要求1-12任一项所述的资源调度系统中包括的中心调度器，所述方法包括：
接收容器组的调度请求；
在所述调度请求中携带的资源类型为指定类型的情况下，根据各个节点组件中指定资源的资源容量，确定所述调度请求对应的目标节点组件，其中，所述指定类型为所述指定资源所属类型，所述指定资源为节点组件的各类型资源中已分配、且未被使用的资源，所述各个节点组件中指定资源的资源容量为管控组件根据各个节点组件检测到的资源使用信息分别计算得到；
将所述容器组调度至所述目标节点组件。
14.一种计算设备，包括：
存储器和处理器；
所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令：
接收容器组的调度请求；
在所述调度请求中携带的资源类型为指定类型的情况下，根据各个节点组件中指定资源的资源容量，确定所述调度请求对应的目标节点组件，其中，所述指定类型为所述指定资源所属类型，所述指定资源为节点组件的各类型资源中已分配、且未被使用的资源，所述各个节点组件中指定资源的资源容量为管控组件根据各个节点组件检测到的资源使用信息分别计算得到；
将所述容器组调度至所述目标节点组件。
CN202111212405.8A 2021-10-18 2021-10-18 资源调度系统、方法以及计算设备 Pending CN114035941A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111212405.8A CN114035941A (zh) 2021-10-18 2021-10-18 资源调度系统、方法以及计算设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111212405.8A CN114035941A (zh) 2021-10-18 2021-10-18 资源调度系统、方法以及计算设备

Publications (1)

Publication Number Publication Date
CN114035941A true CN114035941A (zh) 2022-02-11

Family

ID=80135316

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111212405.8A Pending CN114035941A (zh) 2021-10-18 2021-10-18 资源调度系统、方法以及计算设备

Country Status (1)

Country Link
CN (1) CN114035941A (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114706596A (zh) * 2022-04-11 2022-07-05 中国电信股份有限公司 容器部署方法、资源调度方法、装置、介质和电子设备
CN114840304A (zh) * 2022-04-15 2022-08-02 中兴通讯股份有限公司 一种容器调度方法、电子设备和存储介质
CN115168057A (zh) * 2022-09-02 2022-10-11 浙江大华技术股份有限公司 基于k8s集群的资源调度方法及装置
CN115309507A (zh) * 2022-08-08 2022-11-08 科东(广州)软件科技有限公司 一种cpu资源占用率的计算方法、装置、设备及介质
US20230012021A1 (en) * 2021-07-08 2023-01-12 EMC IP Holding Company LLC Feature Resource Self-Tuning and Rebalancing
WO2023174037A1 (zh) * 2022-03-14 2023-09-21 抖音视界有限公司 资源调度方法、装置、系统、设备、介质和程序产品
CN117041356A (zh) * 2023-10-09 2023-11-10 成都新希望金融信息有限公司 指标分发方法、指标计算方法、装置、电子设备及系统

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230012021A1 (en) * 2021-07-08 2023-01-12 EMC IP Holding Company LLC Feature Resource Self-Tuning and Rebalancing
US11928517B2 (en) * 2021-07-08 2024-03-12 EMC IP Holding Company LLC Feature resource self-tuning and rebalancing
WO2023174037A1 (zh) * 2022-03-14 2023-09-21 抖音视界有限公司 资源调度方法、装置、系统、设备、介质和程序产品
CN114706596A (zh) * 2022-04-11 2022-07-05 中国电信股份有限公司 容器部署方法、资源调度方法、装置、介质和电子设备
CN114706596B (zh) * 2022-04-11 2023-12-01 中国电信股份有限公司 容器部署方法、资源调度方法、装置、介质和电子设备
CN114840304A (zh) * 2022-04-15 2022-08-02 中兴通讯股份有限公司 一种容器调度方法、电子设备和存储介质
CN115309507A (zh) * 2022-08-08 2022-11-08 科东(广州)软件科技有限公司 一种cpu资源占用率的计算方法、装置、设备及介质
CN115168057A (zh) * 2022-09-02 2022-10-11 浙江大华技术股份有限公司 基于k8s集群的资源调度方法及装置
CN117041356A (zh) * 2023-10-09 2023-11-10 成都新希望金融信息有限公司 指标分发方法、指标计算方法、装置、电子设备及系统
CN117041356B (zh) * 2023-10-09 2023-12-05 成都新希望金融信息有限公司 指标分发方法、指标计算方法、装置、电子设备及系统

Similar Documents

Publication Publication Date Title
CN114035941A (zh) 资源调度系统、方法以及计算设备
CN110096349B (zh) 一种基于集群节点负载状态预测的作业调度方法
WO2020024442A1 (zh) 资源分配方法、装置、计算机设备及计算机可读存储介质
CN110888714B (zh) 容器的调度方法、装置和计算机可读存储介质
CN111399986B (zh) Pod资源配额配置方法及装置
CN110069341B (zh) 边缘计算中结合功能按需配置的有依赖关系任务的调度方法
CN109672709B (zh) 一种混合云业务调度系统及方法
CN110532086B (zh) 资源复用方法、设备、系统及存储介质
CN106095569B (zh) 一种基于sla的云工作流引擎资源调度与控制方法
WO2019024445A1 (zh) 地理分布交互服务云资源协同优化方法
CN106789118B (zh) 基于服务等级协议的云计算计费方法
CN113110914A (zh) 一种基于微服务架构的物联网平台构建方法
CN105718316A (zh) 一种作业调度的方法及装置
Luo et al. Erms: Efficient resource management for shared microservices with SLA guarantees
CN111355606A (zh) 面向web应用的容器集群自适应扩缩容系统和方法
CN110086726A (zh) 一种自动切换Kubernetes主节点的方法
CN111861412A (zh) 面向完成时间优化的科学工作流调度方法及系统
Ghasemzadeh et al. Deadline-budget constrained scheduling algorithm for scientific workflows in a cloud environment
CN107317836A (zh) 一种混合云环境下时间可感知的请求调度方法
Wu et al. Dynamically adjusting scale of a kubernetes cluster under qos guarantee
CN113672391A (zh) 一种基于Kubernetes的并行计算任务调度方法与系统
WO2019116083A1 (en) Dynamic adjustment of workload forecast
CN111385142A (zh) 基于Kubernetes的自适应伸缩web容器的方法
CN107203256B (zh) 一种网络功能虚拟化场景下的节能分配方法与装置
CN113886086A (zh) 云平台计算资源分配方法、系统、终端及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40067479

Country of ref document: HK