CN113391913A - 一种基于预测的分布式调度方法和装置 - Google Patents

一种基于预测的分布式调度方法和装置 Download PDF

Info

Publication number
CN113391913A
CN113391913A CN202110782812.6A CN202110782812A CN113391913A CN 113391913 A CN113391913 A CN 113391913A CN 202110782812 A CN202110782812 A CN 202110782812A CN 113391913 A CN113391913 A CN 113391913A
Authority
CN
China
Prior art keywords
pod
utilization rate
node
cluster
resource
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
CN202110782812.6A
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.)
University of Science and Technology of China USTC
Original Assignee
University of Science and Technology of China USTC
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 University of Science and Technology of China USTC filed Critical University of Science and Technology of China USTC
Priority to CN202110782812.6A priority Critical patent/CN113391913A/zh
Publication of CN113391913A publication Critical patent/CN113391913A/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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • 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/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • 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
    • 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
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G06N5/04—Inference or reasoning models
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45583—Memory management, e.g. access or allocation

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Artificial Intelligence (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Evolutionary Computation (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Biophysics (AREA)
  • General Health & Medical Sciences (AREA)
  • Molecular Biology (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明公开了一种基于预测的分布式调度方法和装置。其中，该方法包括:获取当前调度Pod的历史资源利用率以及集群中可用节点的资源利用率；将当前调度Pod的历史资源利用率输入深度学习模型进行训练和推理，以获取当前调度Pod的资源预测利用率；根据当前调度Pod的资源预测利用率以及集群中可用节点的资源利用率，对集群中的可用节点进行筛选，以确定当前调度Pod的目标调度节点。本发明实施例通过利用深度学习模型对Pod的资源利用率进行预测，基于预测数据对集群中的节点进行打分，以实现对集群中由于集群偏载状态使得Pod一直处于异常状态的情况进行优化，来自动调整集群的偏载状态，从而优化集群的性能上限。

Description

一种基于预测的分布式调度方法和装置
技术领域
本发明实施例涉及集群资源调度技术领域，尤其涉及一种基于预测的分布式调度方法和装置。
背景技术
Kubernetes是一个非常流行的容器编排工具，它以先进的设计理念受到业界的关注，并被广泛应用于实际的生产环境中，Kubernetes一个重要的工作就是选择合适的节点(node)来运行Pod(Kubernetes中创建和部署的最小单位，是一个运行实例)，整个集群的负载由集群中各个节点的资源利用率决定，而各个节点的利用率与节点上运行的Pod息息相关。因此，关于集群的调度策略极大的影响了集群的负载状态和资源利用率。
通常情况下，针对资源需求偏差较大的计算任务在使用Kubernetes默认调度算法进行调度时，集群会出现服务器偏载现象。
现有技术中，一般通过扩展Kubernetes的调度器来解决集群状态问题，但该方法或未考虑时间的因素或忽略了低优先级的任务，都仍需改进。
发明内容
本发明提供一种基于预测的分布式调度方法和装置，以实现对集群中由于集群偏载状态使得Pod一直处于异常状态的情况进行优化，来自动调整集群的偏载状态，从而优化集群的性能上限。
第一方面，本发明实施例提供了一种基于预测的分布式调度方法，应用于Kubernetes集群中，包括：
获取当前调度Pod的历史资源利用率以及集群中可用节点的资源利用率；
将所述当前调度Pod的历史资源利用率输入深度学习模型进行训练和推理，以获取所述当前调度Pod的资源预测利用率；
根据所述当前调度Pod的资源预测利用率以及集群中可用节点的资源利用率，对集群中的可用节点进行筛选，以确定所述当前调度Pod的目标调度节点。
第二方面，本发明实施例还提供了一种基于预测的分布式调度装置，配置于Kubernetes集群中，包括：
获取模块，用于获取当前调度Pod的历史资源利用率以及集群中可用节点的资源利用率；
预测模块，用于将所述当前调度Pod的历史资源利用率输入深度学习模型进行训练和推理，以获取所述当前调度Pod的资源预测利用率；
确定模块，用于根据所述当前调度Pod的资源预测利用率以及集群中可用节点的资源利用率，对集群中的可用节点进行筛选，以确定所述当前调度Pod的目标调度节点。
本发明通过利用深度学习模型对Pod的资源利用率进行预测，基于预测数据对集群中的节点进行打分，来为当前调度的Pod确定最优的目标调度节点，以实现对集群中由于集群偏载状态使得Pod一直处于异常状态的情况进行优化，来自动调整集群的偏载状态，从而优化集群的性能上限。
附图说明
图1为本发明实施例一提供的一种基于预测的分布式调度方法的流程图；
图2为本发明实施例一提供的一种基于预测的分布式调度方法的处理过程图；
图3为本发明实施例一提供的一种节点打分的流程图；
图4为本发明实施例二提供的模型本地工作方式的工作时序图；
图5为本发明实施例三提供的现有技术中集群节点CPU和内存的利用率示意图；
图6为利用本发明实施例三提供的基于预测的分布式调度方法后的集群节点CPU和内存的利用率示意图；
图7为本发明实施例四提供的一种基于预测的分布式调度装置的结构示意图。
具体实施方式
下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。
实施例一
图1为本发明实施例一提供的一种基于预测的分布式调度方法的流程图，本实施例可适用于Kubernetes调度器对Pod进行调度情况，该方法可以由一种基于预测的分布式调度装置来执行。
本实施例提供的基于预测的分布式调度方法首先要获取Pod的资源使用情况，即需要实时地获取Pod级别的各项资源使用数据，在获取到数据后，将数据用于深度学习模型的训练，训练后的模型被部署到集群中，以service的形式进行Pod资源占用情况的预测，在进行调度时，Pod的资源使用情况也会参与到节点评分中，最后选出一个评分最高的节点用来绑定和运行Pod，具体的处理过程参见图2。
进一步的，本发明实施例提供的一种基于预测的分布式调度方法具体包括如下步骤：
S110、获取当前调度Pod的历史资源利用率以及集群中可用节点的资源利用率。
本实施例中，通过在集群中部署Prometheus+Grafana的集群资源监控策略来获取当前调度Pod的历史资源利用率以及集群中可用节点的资源利用率。
其中，资源具体包括三个指标：CPU利用率、内存利用率、IOwait率。具体的，本实施例可以通过下列三个公式来实时地从prometheus server暴露的数据接口中获取：
a)CPU利用率：
(1-sum(increase(node_cpu_seconds_total{mode＝"idle"}[10s]))by(instance)/sum(increase(no de_cpu_seconds_total[10s]))by(instance))*100；
b)内存利用率：
(1-((node_memory_Buffers_bytes+node_memory_Cached_bytes+node_memory_MemFree_bytes)/node_memory_MemTotal_bytes))*100；
c)IOwait率：
(sum(increase(node_cpu_seconds_total{mode＝"iowait"}[10s]))by(instance)/sum(increase(node_cpu_seconds_total[10s]))by(instance))*100。
由于本实施例可以使用NodePort方式进行服务暴露，所以上述数据获取过程可以在集群中的任何一个节点上完成，这样集群的每个节点都会暴露出一个端口，从指定的IP+Port就可以获取到数据。另一种方法是LoadBalancer，这种方法会将数据以一个域名的方式暴露出来，无论集群内还是集群外，都可以使用这个域名对数据进行访问。
S120、将所述当前调度Pod的历史资源利用率输入深度学习模型进行训练和推理，以获取所述当前调度Pod的资源预测利用率。
在获取到Pod的资源使用数据之后，将采集到的数据用于模型的训练。对于模型训练和推理的数据都可以通过S110提供的的方式来获取。
由于数据在采集后是单维度的，需要将数据进行预处理，具体的，将CPU的利用率和内存的利用率作为单个样本，可以根据实际情况进行数据长度预测。处理好的数据被放在指定的文件中，便于后续进行自动化训练。
对于数据预测，将采集到的实时数据送入模型并执行推理程序，得到每个节点的预测结果，并将预测结果以指定的端点暴露出去，用于后续Pod调度时对节点进行评分。
本实施例中的深度学习网络模型可以为RNN模型，LSTM模型或者改进的多注意力特征记忆(Multi-Attentional Characteristic Memory,M-ACM)模型。其中，M-ACM的工作单元由三个工作单元组成，每一个工作单元使用了添加了注意力机制的双向LSTM结构，最后添加全连接层进行数据输出。
S130、根据所述当前调度Pod的资源预测利用率以及集群中可用节点的资源利用率，对集群中的可用节点进行筛选，以确定所述当前调度Pod的目标调度节点。
本实施例中，在将获取到的数据用于深度学***衡的情况。在集群的资源分配过程中存在一些问题，即在新的服务进行部署时，集群中的资源有部分剩余，但是新服务无法进行部署。
通过监控查看集群的资源使用情况，发现集群资源满足某些Pod的资源请求，但是仍存在大量的Pod一直处于等待状态，即一直在进行节点申请前的准备，这种状态存在的原因有很多种，比如：镜像拉取失败、资源不足、Pod调度规则的限制、污点设置的问题等。但是最主要的原因是前两种，因此本实施例考虑在Pod第一次调度时保证CPU和内存的负载程度尽量地相近，在满足某些需求时，需要对Pod进行驱逐并重新调度时，通过将Pod之前的资源使用情况送入模型得到Pod的预测资源使用情况，基于预测数据进行节点打分。
具体的，根据所述当前调度Pod的资源预测利用率以及集群中可用节点的资源利用率，对集群中的可用节点进行筛选，以确定所述当前调度Pod的目标调度节点，包括：
基于Kubernetes的内置算法对所述可用节点进行预筛选，以得到候选可用节点；
根据所述当前调度Pod的资源预测利用率以及候选可用节点的资源利用率，对所述候选可用节点进行筛选，以确定所述当前调度Pod的目标调度节点。
本实施例中，在Scheduler调度的预选(Predicate)阶段,基于Kubernetes的内置算法对所述可用节点进行预筛选，来放宽节点入选的条件，即满足最基本的调度条件，就可以通过预选，成为候选可用节点。由于上述Kubernetes的内置算法为现有技术,故不再进行赘述。
进一步地，在对可用节点进行预筛选之后，再对通过预筛选的候选可用节点进行进一步评分筛选。具体的，根据所述当前调度Pod的资源预测利用率以及候选可用节点的资源利用率，对所述候选可用节点进行筛选，以确定所述当前调度Pod的目标调度节点，包括两部分：
a)服务器剩余资源率统计打分
即根据各候选可用节点的资源利用率，确定各候选可用节点的第一评分，所述第一评分的计算公式为：
Score1＝10-(Unc+Unm)*5；
其中，Score1表示第一评分，Unc表示候选可用节点的CPU利用率，Unm代表候选可用节点的内存利用率。
上述第一评分考虑尽量选择资源利用率低的节点，进而来保证各个节点的粗粒度负载均衡。基于节点的使用情况给节点进行基础评分，节点的资源利用率越低，得分越高。
b)CPU和内存的利用率之差统计打分
若所述当前调度Pod为首次运行，则根据各候选可用节点的资源利用率以及当前调度Pod的资源申请比例确定各候选可用节点的第二评分。具体的，获取Pod的CPU申请比例和内存的申请比例，和节点原有的资源利用率相加，分别得到CPU的预计利用率和内存的预计利用率，两者相差越小，评分越高，第二评分的计算公式如下：
Score2-1＝10-(Unc+Rpc-(Unm+Rpm))*10；
其中，Score2-1表示当前调度Pod为首次运行时的第二评分，Unc和Rpc分别代表候选可用节点的CPU利用率和当前调度Pod的CPU申请比例，Unm和Rpm分别代表候选可用节点的内存利用率和当前调度Pod的内存申请比例。
若所述当前调度Pod不是首次运行，则根据各候选可用节点的资源利用率以及当前调度Pod的资源预测利用率确定各候选可用节点的第二评分。即在某个节点上运行过一段时间，但是因为某种错误，或者被某种驱逐策略强制删除，又或者被用户手动删除，这种情况下可以基于之前的数据使用深度学习模型进行资源使用结果的预测，得到CPU和内存在未来一段时间内的预计占用率。对于这种情况,两者差值越小节点评分越高，此时对应的第二评分的计算公式如下：
Score2-2＝10-(Unc+Upcp-(Unm+Upmp))*10；
其中，Score2-2为当前调度不是首次运行时的第二评分，Unc和Rpcp分别代表候选可用节点的CPU利用率和当前调度Pod的CPU预测利用率；Unm和Rpmp分别代表候选可用节点的内存利用率和当前调度Pod内存预测利用率。
进一步的，在获取到各候选节点的第一评分和第二评分后，根据所述第一评分和第二评分对各候选可用节点进行排序，以确定所述当前调度Pod的目标调度节点，包括：将所述第一评分与所述第二评分的和作为各候选可用节点的目标评分；将目标评分最高的候选可用节点作为所述当前调度Pod的目标调度节点。
进一步的，在上述实施例的基础上，本实施例还考虑将提供同一个服务的Pod绑定在不同的物理节点上，也即利用反亲和性进行Pod分散部署，通过引入了一种Pod反亲和性(Anti-Affinity)算法，来尽量避免提供同一个service的Pod在同一个节点上运行，提高服务的高可用性。为了判断Pod之间的反亲和性，需要给Pod打上相应的标签。如果拥有相同标签，则称这些Pod之间具有反亲和性。然后计算与当前调度Pod具有相同标签的Pod越多，评分越低。使用下列进行该节点亲和程度的评分，其中AAPodi表示第i个带有反亲和标签的Pod。
ScoresA＝10-∑(AApodi)/10
在Kubernetes集群中，如果要进行Pod节点间互斥，还可用使用Matchlabel策略，但是这是一种硬性策略，如果不满足条件就直接将节点过滤掉，希望放宽Pod的可运行范围，也希望避免同一应用或者提供同一个服务的Pod一定要跨节点通信的情况，另一方面，使用硬性约束来对Pod进行节点选择的约束，如果Pod或者副本较多，或者节点数量不足，可能会造成部分Pod无法运行，所以以一种软性条件来对Pod进行反亲和性约束，只有条件得不到满足，才会将提供相同服务的Pod调度到同一个节点上。在该调度算法中，主要考虑的是节点的CPU和内存的实际使用情况和Pod被调度后资源使用情况的变化量。所以在评分时，优先选择那些负载较低，且Pod请求的资源量被分配后，CPU和内存的利用率差距较小的节点作为最佳调度节点。
图3展示了S130的工作流程，其中如果当前调度的Pod是第一次运行，将直接使用算法的Score1和Score2-1进行打分，如果Pod之前已经运行过，但是由于某种原因被删除，就可以基于查询到的Pod的预测资源利用率进行算法Score2-2部分的打分。
本发明实施例使用深度学习技术来预测pod资源的使用情况，进而提前将Pod调度到一个更加合适的节点上，而不是等到真正发生偏载再进行调整，实现了对集群中由于集群偏载状态使得Pod一直处于异常状态的情况进行优化，来自动调整集群的偏载状态，从而优化集群的性能上限。
实施例二
本实施例提供的基于预测的分布式调度方法可以以Extender的方式来扩展Kubernetes的Scheduler，将自定义算法内置在Extender中。可以实现在Extender客户端中从指定的端点获取数据，这个端点可以是一个URL，并且以Restful风格进行数据暴露。
1、算法工作流程：本实施例提出的基于预测的分布式调度方法通过扩展或者插件的形式加入Kubernetes平台的调度流程中，便于后续扩展或替换不同的算法。在查阅Kubernetes相关文档后，考虑使用Extender方式将算法嵌入到Kubernetes调度过程中，提出的基于预测的调度打分算法在Scheduler的优选(priority)阶段生效，在这个阶段需要当前调度Pod对象和可用节点的对象列表，并输出一个评分后的节点列表。
首先每个节点进行遍历，在遍历每个节点时，需要基于公式Kubernetes的内置算法对节点进行一个基础评分，从采集器中获取到该节点的CPU和内存利用率，经过公式Score1＝10-(Unc+Unm)*5计算后得到第一部分的评分，在这部分，负载越高的节点，得分越低，因为希望选择负载较低的服务器，来缩短不同服务器之间的负载差距。
对于第二部分的评分，需要先对当前调度轮次中的Pod进行判断，假如Pod是第一次创建，那么无法获取该Pod的资源使用预测结果，但是同样要尽量保持各项资源的均衡使用，基于公式Score2-1＝10-(Unc+Rpc-(Unm+Rpm))*10，将资源首先进行预分配，基于预分配的结果计算CPU和内存的负载差，希望在Pod调度到某个节点上后，该节点的CPU和内存负载差尽可能的小。
如果Pod不是首次运行，可以在ETCD中进行Pod name的前缀匹配，然后获取该Pod的资源预测结果，存储的数据时最近30分钟的CPU和内存的平均使用情况，以10秒为采集间隔，使用该Pod的CPU和内存利用率的平均值作为最后的预测结果，并使用公式Score2-2＝10-(Unc+Upcp-(Unm+Upmp))*10计算第二部分的最后评分。在这部分如果CPU和内存的资源使用量之差越高，就认为如果把当前Pod调度到这个节点上会造成较高程度的资源偏载，这种情况下，就会降低节点的评分，来保证多维资源的负载均衡。
在遍历所有节点后，基于Scheduler Extender对Pod的评分，获得每个可用节点的最终评分，并根据评分高低对节点进行排序，将评分结果发送给Sheduler，Scheduler将最佳节点的ID写入到Pod的NodeName域中，并通过API server将绑定信息写入ETCD中，Kubelet监控到Pod信息发生变化后，会调用Docker创建容器，并把容器的创建信息通过APIServer写入到ETCD中。当前调度轮次的Pod真正运行在了Kubernetes集群中的某一个服务器节点上，接着Pod调度队列中的下一个Pod会执行相同的流程来选择最佳调度节点。
2、模型嵌入
由于算法只需要获取模型的预测结果，所以可以考虑两种方法。
(1)本地运行模型
在这种方式下，可以在集群中的GPU服务器中进行模型训练、推理以及预测结果暴露。这种方式下，模型的工作过程如下：
1)数据获取：从Prometheus暴露的数据端点中获取并进行数据清洗。
2)模型训练：将清理后的数据进行预处理，然后将预处理后的数据送入模型进行训练，考虑将数据的预处理部分放在模型的训练代码中，这样只需要从Prometheus中获取清洗数据即可。在模型的预处理中，考虑到RNN家族模型可并行度较差的短板，在数据预处理时，将数据进行标准化，来加快模型的收敛速度，减少训练时间，并提高容纳特征存储的效率。
3)模型推理：将训练好的模型以权重文件的形式保存在GPU服务器的本地文件夹中，对于数据推理时，从Prometheus端点获取数据并送入模型进行推理。
4)预测结果暴露：对于模型的预测结果，以固定的端点通过一个客户端程序将最新的预测结果暴露出去。Extender程序只需要到指定的端点去拉取预测结果。
图4展示了模型本地工作方式的工作时序，这种方式可以通过一个客户端程序，将获取到的预测结果暴露在指定的端点，在Pod调度时，Extender程序中从指定的端点查询响应的预测结果记录，用于调度算法的打分操作。
这种方式的好处是模型的参数和训练状态是持久化存在的，不用申请PV卷或者其他Pod存储持久化操作，缺点是模型本身和数据暴露端点都在集群外部，在通信上存在一定的时延。
(2)在容器运行模型
可以先对模型进行训练，然后将模型权重文件、训练代码和推理代码打包到Docker容器中，然后以Pod形式进行模型推理以及重训。这种方式的模型工作方式如下：
1)数据获取：这种方式下，Prometheus不需要将采集到的数据暴露到集群外，运行在Pod中的客户端程序可以通过集群中服务器节点的IP地址加上Prometheus指定的端口便可以获取数据。
2)模型训练：在本地完成模型的训练工作，这部分流程和本地模型的工作方式相似。
3)模型打包：将训练好的模型打包到Docker镜像中，如果使用GPU进行推理，则需要在部署模型的Docker镜像时，将指定的Nvidia库文件挂载到指定容器中可以访问到的目录下，同时提前部署Nvidia-Device-Plugin。如果使用CPU进行推理，则不用进行GPU使用的配置。
4)模型推理：使用Pod方式运行训练好的模型，同样可以将数据以Service的形式向外暴露，但是由于在Pod中运行，可以以集群虚拟IP加端口的形式只在集群内部进行数据暴露。
5)预测结果暴露：在Extender中可以以IP+Port的形式来获取数据，如果需要在集群外部访问，需要使用NodePort或者LoadBalance的方式对包含预测数据的端点进行暴露。
这种模型工作方式和本地模型工作方式相似，但是需要将模型训练环境打包到Docker镜像中，并将预测结果通过PV或者PVC的方式持久化到磁盘中。
这两种方式都可以完成数据的获取、模型推理和结果暴露，如果需要定期人工优化代码或者需要安全方便地保留数据，可以考虑直接在本地完成数据采集、模型训练和推理、推理结果暴露这些工作。
3、算法嵌入
基于深度学习模型的预测结果，来干预集群调度过程，以选择相对较好的节点运行Pod，保证集群的负载均衡，在减少资源偏载情况的同时提高集群资源可用上限。
进一步的，在加入了的调度算法之后调度工作的整体工作过程如下：
(1)数据采集：首先在集群中部署Prometheus server，其内置的TSDB数据库可以用来存放采集到的集群数据，其中最新的两小时内的数据存放在内存中，其他旧数据会被持久化到本地磁盘中，但是和Prometheus Server Pod的生命周期保持一致。PrometheusServer重启后，所有数据丢失。所以考虑将Pod资源使用的预测结果写入ETCD键值对存储***中。
(2)数据清洗：在获取到数据后，以步长为3对数据进行采样，这在一定程度上增加了特征变换频率，更早地预测异常情况的发生。对于采集数据为零值或者很接近零的样本，认为这段时间Pod的工作量几乎为0，所以把小于0.1％的样本过滤掉。然后以一维二元素数组，将样本写入本地文件中。
(3)模型训练：在获取到资源使用数据后，模型可以从指定的路径中读取，有两种方法可以实现这种方法，一种将采集模块和代码训练模块放在Pod中运行，采集到的数据放在容器中的虚拟文件夹中，模型训练时可以像读取本地文件一样读取采集到的数据。另一种方法是将数据存储在本地，在将模型部署时将本地的文件夹挂载到容器中的指定位置。获取到数据后，使用数据生成器模块生成180:60的数据样本，送入模型进行训练，如果要在GPU上训练或者推理，需要将使用的到的Nvidia库挂载到容器中，这种方式在挂载后只能在指定的GPU服务器上训练和推理，会给集群中GPU服务器带来一定的压力。训练完成后将模型保存到指定目录下，在推理模块中配置好路径即可。
(4)资源使用情况推理：从数据采集模块写入的文件中读取最近的CPU和内存使用情况，加载训练好的模型，并进行推理，这部分只需要写好预测模块的定时预测功能，在实验中，进行10000个样本的推理只需不到40秒时间，所以180长度的单个样本花费时间不足1秒。在完成所有Pod的资源使用情况推理时，将推理结果的平均值写入ETCD中，以键值对的形式存储，其中key使用Pod name去掉生成的随机数后缀后剩下的部分作为标识，对于value值，我使用CPU和内存利用率的平均值，作为一个一维二项数组存入ETCD，如果同质Pod运行了多次，会生成多个预测结果，为了尽可能的避免偏载状态的发生，使用CPU和内存利用率平均值之差最大的记录来覆盖当前记录。
(5)Scheduler调度：Scheduler会通过API Server不断扫描ETCD中node name为空的Pod，这些Pod会被组织成一个队列，和可用节点列表一起被送入Scheduler中，其中Pod和可用节点队列的元素都是对应的对象指针。Scheduler进入预选阶段，这个阶段主要是选出哪些资源充足而能够支持Pod运行，或者一些selector控制器严格规定只能运行到指定类型的节点上，可用节点必须满足这些硬性条件。根据内置算法将不可用节点过滤掉，生成可用节点列表和不可用节点及其不可用原因。在设置了Extender配置，这些信息会被发送到Extender指定的入口地址上，由Extender做二次过滤，在这部分，不做额外处理，可用节点只需要满足Kubernetes规定的指标条件。所以在预选阶段返回Scheduler基于内置预选算法计算后产生的原始预选结果。Scheduler进入优选阶段，执行完内置算法后，将节点评分或排序结果以及Pod对象指针发送给Extender的入口地址中。在这部分如果Pod之前存在运行记录，使用需要先从ETCD中查找当前Pod的ID前缀的key值记录。然后送入Extender中Priority模块中，基于每个节点的实际CPU和内存利用率和模型预测预测结果对节点进行打分，更新并发送打分结果。
(6)节点绑定和Pod运行：Scheduler收到Extender的评分结果后，Pod的Node name域被写入评分最高的节点ID，然后将绑定结果通过API Server将Pod和node的绑定结果写入ETCD中。然后进行下一轮的Pod调度。
本实施例提供技术方案，针对Kubernetes集群资源偏载问题，通过多注意力特征记忆模型来预测资源利用率，并通过预测资源利用率的模型来设计Kubernetes分布式调度策略。
实施例三
本实施例提供一种基于预测的分布式调度方法的实验验证方法及验证结果。
1、实验环境
本实施例中的实验环境是在一个26个节点上的Kubernetes分布式集群上进行的。
2、测试工具介绍
本实施例使用PowerfulSeal作为测试用例调试工具，该工具的功能包括：
(1)这个工具可以获取到每个运行的容器对象的详细信息，以便于在测试的时候手动修改或者删除一些需要的配置，来进行故障模拟。
(2)停止、启动、删除集群中的服务器节点
(3)杀死指定节点上的某个容器。
(4)通过API Server找到指定的Pod，deploys和namespace。
(5)提供交互模式，便于即时查看操作后的集群变化。
实验中使用PowerfulSeal来集群中的Pod进行随机删除操作，来模拟多个Pod的随机调度场景，下面将对集群性能测试的过程进行介绍。
3、集群优化测压性能及分析
在集群性能测试时，使用Kube-Stresscheck作为的基础测试用例，通过调整测试用例Pod运行时的容器资源上限，来模拟不同偏载程度的六个测试应用，并以多个副本的形式在集群中运行，直到添加新Pod后，该Pod一直处于等待状态，来模拟集群资源使用达到上限的情况。然后使用Powerseal删除指定数量的Pod，由于副本控制器的存在，集群会重新创建Pod并进行调度，但是基于当前的资源使用情况，Pod可能不会调度到第一次绑定的节点上。需要使用PowerfulSeal删除Pod的原因是在创建Pod时，通过同一个deployment或者daemonset配置文件启动的不同Pod副本，可能会使Pod处于调度队列的连续位置，如果资源允许，这些Pod将立即被绑定到指定的节点上开始运行。需要手动删除不同质Pod的一些副本，来模拟拥有不同CPU和内存申请比例Pod的随机调度情况。
使用下表拥有不同资源申请比例的六个示例应用来测试集群的性能上限:
Figure BDA0003157651380000111
在日常的计算任务的运行过程中，由于中间计算操作的不同，会导致Pod对不同资源的使用情况不断发生变化，这种变化可能会导致一种使用CPU资源较多的任务在执行时的某一时刻占用的内存比例比CPU比例更多，这就会影响对计算任务类型的判断。为了便于验证算法的性能，使用的测试用例会始终占用接近资源分配上限的资源数量，避免计算任务在不同计算阶段产生不同资源占用率不同时产生的任务性质改变而影响实验结果。本实验中使用三类应用作为测试用例，CPU和内存比例使用相当、CPU使用较多、内存使用较多的应用各占两个，对于同类应用实验中使用不同的粒度级别，以此保证实验结果的准确性，其中1000m代表Pod申请使用一个核心的CPU，1Gi表示Pod申请使用1GB的内存空间，1Mi表示申请1MB的内存空间。
在将集群中节点的Pod运行上限设置为200，并在部署时将Pod部署时，在配置文件中设置示例应用的副本数量为90个。所有应用都开始运行时，随机删除一半左右的示例应用副本，直到能够有新的Pod能够重新被调度，以此来进行尽量打乱调度顺序。在原始的集群中，使用Prometheus获取各个节点服务器的CPU利用率和内存利用率，得到节点的CPU利用率和内存利用率如图5，通过计算得到CPU的平均剩余率为11.4％，内存的剩余闲置率为10.8％。
在加入本发明实施例中提出的基于预测的分布式调度算法之后，再次使用示例Pod将集群状态置为满载状态，所得到集群中所有节点的CPU和内存利用率如图6，通过计算得到CPU的平均剩余率为5.1％，内存的平均剩余率为4.9％。可以看到，相比于原始调度策略，加入本文中调度算法后的数据对CPU和内存的利用率可用上限有一定的提升，并且CPU和内存使用的偏载程度也有所减轻，这允许剩余的资源容纳资源要求更加苛刻的任务。
本实施例中使用各个节点的CPU和内存利用率之差的平均值来衡量节点的偏载程度，并使用内存和CPU利用率的方差来衡量节点负载均衡的程度。对于优化前的集群，CPU和内存平均偏载程度3.89％，节点CPU的利用率方差为10.30，内存利用率的方差为10.97。对于加入本发明实施例提出算法后的集群，平均偏载程度为2.27％，节点CPU的利用率方差为6.41，内存利用率的方差为3.94。可以看到，优化后的集群资源使用更加均衡。
4、实验优化效果总结
在本发明实施例中，主要针对集群数据对传统模型进行改进和优化，并基于的模型来实现自定义调度评分算法。完成了对集群中由于集群偏载状态使得Pod一直处于异常状态的情况进行优化，来自动调整集群的偏载状态，从而优化集群的性能上限。
本发明实施例提供的技术方案，在确定目标调度节点时，同时考虑服务器的实际资源使用情况和Pod的资源使用情况预测结果，并把CPU和内存利用率之差作为打分标准之一。调度分为预选和优选两个阶段，本文提出的调度策略不对可用节点的范围进行二次限制，只要能够满足基本的Pod运行条件，就将节点加入到可用节点列表中，但是在优选阶段，那些之前运行过Pod，可以使用之前采集到的信息进行预测，基于预测结果来指导Scheduler进行Pod的调度决策。本发明实施例中提出的调度算法主要考虑的是将集群中的各个节点尽可能的保持平稳状态，以此来减少多个申请比例不同的任务连续进行调度时造成的服务器偏载状态。经过实验验证，利用本发明实施例提供的基于预测的分布式调度方法，Kubernetes集群的CPU平均闲置率减少了6.3％，内存平均闲置率减少了5.9％，CPU利用率偏载方差减少了3.90％，内存利用率偏载方差减少了7.02％。
实施例四
参见图7，本发明实施了提供一种基于预测的分布式调度装置，该装置包括：
获取模块210，用于获取当前调度Pod的历史资源利用率以及集群中可用节点的资源利用率；
预测模块220，用于将所述当前调度Pod的历史资源利用率输入深度学习模型进行训练和推理，以获取所述当前调度Pod的资源预测利用率；
确定模块230，用于根据所述当前调度Pod的资源预测利用率以及集群中可用节点的资源利用率，对集群中的可用节点进行筛选，以确定所述当前调度Pod的目标调度节点。
其中，所示确定模块210包括预筛选单元和优选单元，所述预筛选单元用于基于Kubernetes的内置算法对所述可用节点进行预筛选，以得到候选可用节点；
所述优选单元用于根据所述当前调度Pod的资源预测利用率以及候选可用节点的资源利用率，对所述候选可用节点进行筛选，以确定所述当前调度Pod的目标调度节点。
进一步的，所述优选单元具体用于：根据各候选可用节点的资源利用率，确定各候选可用节点的第一评分；
若所述当前调度Pod为首次运行，则根据各候选可用节点的资源利用率以及当前调度Pod的资源申请比例确定各候选可用节点的第二评分；
若所述当前调度Pod不是首次运行，则根据各候选可用节点的资源利用率以及当前调度Pod的资源预测利用率确定各候选可用节点的第二评分；
根据所述第一评分和第二评分对各候选可用节点进行排序，以确定所述当前调度Pod的目标调度节点。
其中，所述第一评分的计算公式为：
Score1＝10-(Unc+Unm)*5；
其中，Score1表示第一评分，Unc表示候选可用节点的CPU利用率，Unm代表候选可用节点的内存利用率。
若所述当前调度Pod为首次运行，第二评分的计算公式如下：
Score2-1＝10-(Unc+Rpc-(Unm+Rpm))*10；
其中，Score2-1表示当前调度Pod为首次运行时的第二评分，Unc和Rpc分别代表候选可用节点的CPU利用率和当前调度Pod的CPU申请比例，Unm和Rpm分别代表候选可用节点的内存利用率和当前调度Pod的内存申请比例。
若所述当前调度不是首次运行，第二评分的计算公式如下：
Score2-2＝10-(Unc+Upcp-(Unm+Upmp))*10；
其中，Score2-2为当前调度不是首次运行时的第二评分，Unc和Rpcp分别代表候选可用节点的CPU利用率和当前调度Pod的CPU预测利用率；Unm和Rpmp分别代表候选可用节点的内存利用率和当前调度Pod内存预测利用率。
具体的，根据所述第一评分和第二评分对各候选可用节点进行排序，以确定所述当前调度Pod的目标调度节点，包括：
将所述第一评分与所述第二评分的和作为各候选可用节点的目标评分；
将目标评分最高的候选可用节点作为所述当前调度Pod的目标调度节点。
进一步的，所述获取模块具体包括：
通过在集群中部署Prometheus和Grafana的集群资源监控策略来获取当前调度Pod的历史资源利用率以及集群中可用节点的资源利用率。
本发明实施例所提供的基于预测的分布式调度装置可执行本发明任意实施例所提供的基于预测的分布式调度方法，具备执行方法相应的功能模块和有益效果，不再进行赘述。
注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (10)

1.一种基于预测的分布式调度方法，其特征在于，应用于Kubernetes集群中，包括：
获取当前调度Pod的历史资源利用率以及集群中可用节点的资源利用率；
将所述当前调度Pod的历史资源利用率输入深度学习模型进行训练和推理，以获取所述当前调度Pod的资源预测利用率；
根据所述当前调度Pod的资源预测利用率以及集群中可用节点的资源利用率，对集群中的可用节点进行筛选，以确定所述当前调度Pod的目标调度节点。
2.根据权利要求1所述的方法，其特征在于，根据所述当前调度Pod的资源预测利用率以及集群中可用节点的资源利用率，对集群中的可用节点进行筛选，以确定所述当前调度Pod的目标调度节点，包括：
基于Kubernetes的内置算法对所述可用节点进行预筛选，以得到候选可用节点；
根据所述当前调度Pod的资源预测利用率以及候选可用节点的资源利用率，对所述候选可用节点进行筛选，以确定所述当前调度Pod的目标调度节点。
3.根据权利要求2所述的方法，其特征在于，根据所述当前调度Pod的资源预测利用率以及候选可用节点的资源利用率，对所述候选可用节点进行筛选，以确定所述当前调度Pod的目标调度节点，包括：
根据各候选可用节点的资源利用率，确定各候选可用节点的第一评分；
若所述当前调度Pod为首次运行，则根据各候选可用节点的资源利用率以及当前调度Pod的资源申请比例确定各候选可用节点的第二评分；
若所述当前调度Pod不是首次运行，则根据各候选可用节点的资源利用率以及当前调度Pod的资源预测利用率确定各候选可用节点的第二评分；
根据所述第一评分和第二评分对各候选可用节点进行排序，以确定所述当前调度Pod的目标调度节点。
4.根据权利要求3所述的方法，其特征在于，所述第一评分的计算公式为：
Score1＝10-(Unc+Unm)*5；
其中，Score1表示第一评分，Unc表示候选可用节点的CPU利用率，Unm代表候选可用节点的内存利用率。
5.根据权利要求3所述的方法，其特征在于，若所述当前调度Pod为首次运行，第二评分的计算公式如下：
Score2-1＝10-(Unc+Rpc-(Unm+Rpm))*10；
其中，Score2-1表示当前调度Pod为首次运行时的第二评分，Unc和Rpc分别代表候选可用节点的CPU利用率和当前调度Pod的CPU申请比例，Unm和Rpm分别代表候选可用节点的内存利用率和当前调度Pod的内存申请比例。
6.根据权利要求3所述的方法，其特征在于，若所述当前调度不是首次运行，第二评分的计算公式如下：
Score2-2＝10-(Unc+Upcp-(Unm+Upmp))*10；
其中，Score2-2为当前调度不是首次运行时的第二评分，Unc和Rpcp分别代表候选可用节点的CPU利用率和当前调度Pod的CPU预测利用率；Unm和Rpmp分别代表候选可用节点的内存利用率和当前调度Pod内存预测利用率。
7.根据权利要求3所述的方法，其特征在于，根据所述第一评分和第二评分对各候选可用节点进行排序，以确定所述当前调度Pod的目标调度节点，包括：
将所述第一评分与所述第二评分的和作为各候选可用节点的目标评分；
将目标评分最高的候选可用节点作为所述当前调度Pod的目标调度节点。
8.根据权利要求1所述的方法，其特征在于，获取当前调度Pod的历史资源利用率以及集群中可用节点的资源利用率，包括：
通过在集群中部署Prometheus和Grafana的集群资源监控策略来获取当前调度Pod的历史资源利用率以及集群中可用节点的资源利用率。
9.一种基于预测的分布式调度装置，其特征在于，配置于Kubernetes集群中，包括：
获取模块，用于获取当前调度Pod的历史资源利用率以及集群中可用节点的资源利用率；
预测模块，用于将所述当前调度Pod的历史资源利用率输入深度学习模型进行训练和推理，以获取所述当前调度Pod的资源预测利用率；
确定模块，用于根据所述当前调度Pod的资源预测利用率以及集群中可用节点的资源利用率，对集群中的可用节点进行筛选，以确定所述当前调度Pod的目标调度节点。
10.根据权利要求9所述的装置，其特征在在于，所述确定模块具体用于：
基于Kubernetes的内置算法对所述可用节点进行预筛选，以得到候选可用节点；
根据所述当前调度Pod的资源预测利用率以及候选可用节点的资源利用率，对所述候选可用节点进行筛选，以确定所述当前调度Pod的目标调度节点。
CN202110782812.6A 2021-07-12 2021-07-12 一种基于预测的分布式调度方法和装置 Pending CN113391913A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110782812.6A CN113391913A (zh) 2021-07-12 2021-07-12 一种基于预测的分布式调度方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110782812.6A CN113391913A (zh) 2021-07-12 2021-07-12 一种基于预测的分布式调度方法和装置

Publications (1)

Publication Number Publication Date
CN113391913A true CN113391913A (zh) 2021-09-14

Family

ID=77625785

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110782812.6A Pending CN113391913A (zh) 2021-07-12 2021-07-12 一种基于预测的分布式调度方法和装置

Country Status (1)

Country Link
CN (1) CN113391913A (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113886055A (zh) * 2021-12-07 2022-01-04 中国电子科技集团公司第二十八研究所 一种基于容器云技术的智能模型训练资源调度方法
CN115297112A (zh) * 2022-07-31 2022-11-04 南京匡吉信息科技有限公司 一种基于Kubernetes的动态资源配额及调度组件
CN115550371A (zh) * 2022-12-05 2022-12-30 安超云软件有限公司 基于Kubernetes的Pod调度方法、***及云平台
US11916807B2 (en) 2022-01-31 2024-02-27 Microsoft Technology Licensing, Llc Evaluation framework for cloud resource optimization

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113886055A (zh) * 2021-12-07 2022-01-04 中国电子科技集团公司第二十八研究所 一种基于容器云技术的智能模型训练资源调度方法
CN113886055B (zh) * 2021-12-07 2022-04-15 中国电子科技集团公司第二十八研究所 一种基于容器云技术的智能模型训练资源调度方法
US11916807B2 (en) 2022-01-31 2024-02-27 Microsoft Technology Licensing, Llc Evaluation framework for cloud resource optimization
CN115297112A (zh) * 2022-07-31 2022-11-04 南京匡吉信息科技有限公司 一种基于Kubernetes的动态资源配额及调度组件
CN115550371A (zh) * 2022-12-05 2022-12-30 安超云软件有限公司 基于Kubernetes的Pod调度方法、***及云平台
CN115550371B (zh) * 2022-12-05 2023-03-21 安超云软件有限公司 基于Kubernetes的Pod调度方法、***及云平台

Similar Documents

Publication Publication Date Title
CN113391913A (zh) 一种基于预测的分布式调度方法和装置
Mahgoub et al. {OPTIMUSCLOUD}: Heterogeneous configuration optimization for distributed databases in the cloud
Ramakrishnan et al. Scheduling data-intensiveworkflows onto storage-constrained distributed resources
Soualhia et al. Task scheduling in big data platforms: a systematic literature review
Tian et al. Towards optimal resource provisioning for running mapreduce programs in public clouds
CN104050042B (zh) Etl作业的资源分配方法及装置
Sethi et al. RecShard: statistical feature-based memory optimization for industry-scale neural recommendation
CN110740079B (zh) 一种面向分布式调度***的全链路基准测试***
Zheng et al. Deploying high throughput scientific workflows on container schedulers with makeflow and mesos
CN113110914A (zh) 一种基于微服务架构的物联网平台构建方法
Overeinder et al. A dynamic load balancing system for parallel cluster computing
CN109614227A (zh) 任务资源调配方法、装置、电子设备及计算机可读介质
Mateescu Quality of service on the grid via metascheduling with resource co-scheduling and co-reservation
Ding et al. Kubernetes-oriented microservice placement with dynamic resource allocation
CN113806018A (zh) 基于神经网络和分布式缓存的Kubernetes集群资源混合调度方法
CN113157421A (zh) 一种基于用户作业流程的分布式集群资源调度方法
Gandomi et al. Designing a MapReduce performance model in distributed heterogeneous platforms based on benchmarking approach
Javanmardi et al. An architecture for scheduling with the capability of minimum share to heterogeneous Hadoop systems
Gopalakrishna et al. Untangling cluster management with Helix
Ghazali et al. CLQLMRS: improving cache locality in MapReduce job scheduling using Q-learning
Guo et al. Handling data skew at reduce stage in Spark by ReducePartition
CN111367632B (zh) 一种基于周期特征的容器云调度方法
Yang et al. Deep reinforcement agent for failure-aware job scheduling in high-performance computing
Mehra et al. Population-based learning of load balancing policies for a distributed computer system
Mao et al. FiGMR: A fine-grained mapreduce scheduler in the heterogeneous cloud

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