CN113342477B - 一种容器组部署方法、装置、设备及存储介质 - Google Patents

一种容器组部署方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN113342477B
CN113342477B CN202110771560.7A CN202110771560A CN113342477B CN 113342477 B CN113342477 B CN 113342477B CN 202110771560 A CN202110771560 A CN 202110771560A CN 113342477 B CN113342477 B CN 113342477B
Authority
CN
China
Prior art keywords
cluster
node
determining
scoring
nodes
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.)
Active
Application number
CN202110771560.7A
Other languages
English (en)
Other versions
CN113342477A (zh
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.)
Henan Xinghuan Zhongzhi Information Technology Co ltd
Original Assignee
Henan Xinghuan Zhongzhi Information Technology Co 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 Henan Xinghuan Zhongzhi Information Technology Co ltd filed Critical Henan Xinghuan Zhongzhi Information Technology Co ltd
Priority to CN202110771560.7A priority Critical patent/CN113342477B/zh
Publication of CN113342477A publication Critical patent/CN113342477A/zh
Application granted granted Critical
Publication of CN113342477B publication Critical patent/CN113342477B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/4557Distribution of virtual machine instances; Migration and load balancing

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了一种容器组部署方法、装置、设备及存储介质。该方法包括:在获取到对容器组的创建请求时,获取集群中每个节点的真实负载信息;根据集群中每个节点上已分配资源和占节点总资源的比例和真实负载信息确定集群状态;根据所述集群状态确定至少两个打分策略分别对应的权重;根据所述至少两个打分策略和所述至少两个打分策略分别对应的权重确定所述集群中每个节点的目标分数;在集群中目标分数最高的节点上部署所述容器组,通过本发明的技术方案,能够缓解集群节点资源利用率不均的问题。

Description

一种容器组部署方法、装置、设备及存储介质
技术领域
本发明实施例涉及计算机技术领域,尤其涉及一种容器组部署方法、装置、设备及存储介质。
背景技术
Kubernetes容器资源管理,Kubernetes是一个开源的,用于管理云平台中多个主机上的容器化的应用,提供了应用部署,规划,更新,维护的一种机制,目标是让部署容器化的应用简单并且高效。在Kubernetes中可以通过在定义容器组时选择性地为每个容器设定所需要的资源数量以管理容器资源,主要资源类型包括计算资源、存储资源和其他扩展资源。计算资源是可以被请求、分配和消耗的可测量数量,包括CPU和内存两种类型。Kubernetes中对CPU的资源约束和请求以cpu为单位,一个cpu等于云平台上的1个vCPU/核和裸机Intel处理器上的1个超线程。内存的资源约束和请求以字节(Byte)为单位,其他常用单位有M、Mi、G、Gi等,转换关系如下:1Mi=1024×1024Byte;1M=1000×1000Byte。存储资源包括但不限于本地临时存储卷、云存储等;其他扩展资源包括但不限于GPU资源等。
Kubernetes调度:当创建一个容器组时,可以定义容器组内容器各类资源的request和limit的资源量,分别表示该种资源在节点上最低要求使用资源量及最大可使用资源量。容器组为Kubernetes创建或部署的最小/最简单的基本单位,一个Pod代表集群上正在运行的一个进程。每个节点对每种资源类型(如CPU、内存等资源)都有一个容量上限。Kubernetes中默认调度器负责集群资源的调度,即以集群最终资源利用率最优为目标,根据特定的调度策略将容器组绑定到某个合适的节点上,并将绑定信息写入etcd中。其中,etcd是一个分布式键值对存储系统,内部采用raft协议作为一致性算法,用于可靠、快速地保存关键数据,并提供访问。调度过程主要分为预选和优选两个阶段,其中预选阶段会过滤掉不满足条件的节点,比如调度器会确保已调度容器组的容器资源请求总和不会超出节点的资源容量;优选阶段会对符合预选条件的节点进行打分排序,最终选出分数最高的节点作为待调度容器组的目标节点。在优选阶段的打分过程中会调用不同调度策略的打分算法对节点进行多维度考量,其中,节点资源是与集群资源利用率密切相关的维度,主要评价指标包括节点CPU利用率和节点内存利用率等。
默认调度器kube-scheduler基于容器组请求的资源(即Resources Request,下文简称Request)进行调度,而可调度资源又和每个Kubernetes Node(下文简称Node)上的Request配置上限有关(默认为Node上可识别的CPU和Memory资源),并且Request只是逻辑上的概念,在调度过程中分配出去并不意味着真的就被完全使用。而所谓节点真实负载是指在Node上通过系统命令如top等工具实时看到的CPU和Memory的使用情况。因此,调度分配出去的Request往往和Node上的真实负载存在一定差距。通常情况下,表示系统是否繁忙需要基于真实负载进行评价,因此在调度过程中能够感知真实负载才能够更进一步均衡Node(节点)的资源使用,使得对容器组进行更加合理的调度。这是当前默认调度器kube-scheduler所不具备的能力。
如图1a所示,各节点有各自的Request水位表示当前时刻已调度到该节点上容器所要求的资源之和占节点总资源的比例。而Request水位只是逻辑概念,节点上的任务负载真实使用多少资源(即节点真实负载)无法在调度过程中感知,这导致集群内各节点间的真实负载不均衡。
如图1b所示,部分节点剩余可调度资源比较多,Request水位较低但真实负载却比较高;部分节点剩余可调度资源较少,Request水位较高但真实负载却比较低。同时,kube-scheduler根据LeastRequestPriority策略优先将Pod调度到剩余可调度资源比较多的节点上进一步加剧了节点间资源负载不均的问题,在图1b所示的情况中kube-scheduler会优先把容器组调度到Request水位最低的Node2上即使该节点的真实负载是集群中最高的,这不符合集群节点间资源负载均衡和资源利用率高的需求。
另外,如果多数节点剩余少量资源形成了较多资源碎片,会使得其他需求资源比较大的任务无法完成调度。图1c即是节点资源碎片导致资源需求大的容器组无法调度的场景,待调度容器组需要的最低资源为10核CPU和20G内存,记(10C,20G)。单个节点剩余资源均小于该请求,导致容器组无法调度成功,但实际上集群总剩余资源为(15C,30G)能满足任务需求,即集群节点资源碎片化导致集群整体资源利用率下降。
发明内容
本发明实施例提供一种容器组部署方法、装置、设备及存储介质,能够利用节点真实负载信息和集群中每个节点上已分配资源和占节点总资源的比例确定集群节点状态,根据所述集群状态确定至少两个打分策略分别对应的权重;根据所述至少两个打分策略和所述至少两个打分策略分别对应的权重确定所述集群中每个节点的目标分数;在集群中目标分数最高的节点上部署所述容器组,缓解集群节点资源利用率不均的问题。
第一方面,本发明实施例提供了一种容器组部署方法,包括:
在获取到对容器组的创建请求时,获取集群中每个节点的真实负载信息;
根据集群中每个节点上已分配资源和占节点总资源的比例和真实负载信息确定集群状态;
根据所述集群状态确定至少两个打分策略分别对应的权重;
根据所述至少两个打分策略和所述至少两个打分策略分别对应的权重确定所述集群中每个节点的目标分数;
在集群中目标分数最高的节点上部署所述容器组。
第二方面,本发明实施例还提供了一种容器组部署装置,该装置包括:
获取模块,用于在获取到对容器组的创建请求时,获取集群中每个节点的真实负载信息;
第一确定模块,用于根据集群中每个节点上已分配资源和占节点总资源的比例和真实负载信息确定集群状态;
第二确定模块,用于根据所述集群状态确定至少两个打分策略分别对应的权重;
第三确定模块,用于根据所述至少两个打分策略和所述至少两个打分策略分别对应的权重确定所述集群中每个节点的目标分数;
部署模块,用于在集群中目标分数最高的节点上部署所述容器组。
第三方面,本发明实施例还提供了一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现如本发明实施例中任一所述的容器组部署方法。
第四方面,本发明实施例还提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现如本发明实施例中任一所述的容器组部署方法。
本发明实施例通过在获取到对容器组的创建请求时,获取集群中每个节点的真实负载信息;根据集群中每个节点上已分配资源和占节点总资源的比例和真实负载信息确定集群状态;根据所述集群状态确定至少两个打分策略分别对应的权重;根据所述至少两个打分策略和所述至少两个打分策略分别对应的权重确定所述集群中每个节点的目标分数;在集群中目标分数最高的节点上部署所述容器组,缓解集群节点资源利用率不均的问题。
附图说明
为了更清楚地说明本发明实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本发明的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1a是节点Request水位示意图;
图1b是节点真实负载不均衡示意图;
图1c是节点资源碎片示意图;
图1d是本发明实施例中的一种容器组部署方法的流程图;
图1e是本发明实施例中的主体架构示意图;
图2是本发明实施例中的一种容器组部署装置的结构示意图;
图3是本发明实施例中的一种电子设备的结构示意图;
图4是本发明实施例中的一种包含计算机程序的计算机可读存储介质的结构示意图。
具体实施方式
下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是,此处所描述的具体实施例仅仅用于解释本发明,而非对本发明的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与本发明相关的部分而非全部结构。此外,在不冲突的情况下,本发明中的实施例及实施例中的特征可以相互组合。
在更加详细地讨论示例性实施例之前应当提到的是,一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理,但是其中的许多操作可以被并行地、并发地或者同时实施。此外,各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止,但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。此外,在不冲突的情况下,本发明中的实施例及实施例中的特征可以相互组合。
本发明使用的术语“包括”及其变形是开放性包括,即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”。
应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。同时,在本发明的描述中,术语“第一”、“第二”等仅用于区分描述,而不能理解为指示或暗示相对重要性。
图1d为本发明实施例提供的一种容器组部署方法的流程图,本实施例可适用于容器组部署的情况,该方法可以由本发明实施例中的容器组部署装置来执行,该装置可采用软件和/或硬件的方式实现,如图1d所示,该方法具体包括如下步骤:
S110,在获取到对容器组的创建请求时,获取集群中每个节点的真实负载信息。
其中,所述容器组为Kubernetes创建或部署的最小/最简单的基本单位,一个容器组代表集群上正在运行的一个进程。
其中,所述节点的真实负载信息包括:节点在过去第一时间内CPU平均利用率,节点在过去第二时间内CPU平均利用率,节点在过去第一时间内存平均利用率,节点在过去第二时间内存平均利用率,其中,第一时间和第二时间可以为预先设定的时间,第一时间可以在第二时间之前,也可以在第二时间之后,本发明实施例对此不进行限制。
其中,节点为Kubernetes集群中的工作负载节点,可以是一个虚拟机或物理机,用来运行容器组。
S120,根据集群中每个节点上已分配资源和占节点总资源的比例和真实负载信息确定集群状态。
示例性的,根据集群中每个节点上已分配资源和占节点总资源的比例和真实负载信息确定集群状态的方式可以为:若集群中预设数量的节点上已分配资源和占节点总资源的比例小于需求阈值,则确定集群状态为第一状态;若集群中预设数量的节点上已分配资源和占节点总资源的比例大于或者等于所述需求阈值,且集群中预设数量的节点真实负载信息小于真实负载阈值,则确定集群状态为第二状态;若集群中预设数量的节点上已分配资源和占节点总资源的比例大于或者等于所述需求阈值,且集群中预设数量的节点真实负载信息大于或者等于真实负载阈值,则确定集群状态为第三状态。
S130,根据所述集群状态确定至少两个打分策略分别对应的权重。
其中,所述至少两个打分策略包括:第一打分策略、第二打分策略、第三打分策略和第四打分策略,其中,所述第一打分策略为优先调度到已分配资源份额较少的节点,所述第二打分策略为优先调度到单个节点多种资源不平衡的节点,所述第三打分策略为优先调度到已分配资源量较少的节点,所述第四打分策略为优先调度到真实负载较低的节点。
示例性的,根据所述集群状态确定至少两个打分策略分别对应的权重的方式可以为:若集群状态为第一状态,则获取第一打分策略的初始权重、第二打分策略的初始权重、第三打分策略的初始权重和第四打分策略的初始权重;若集群状态为第二状态,则提高所述第四打分策略的权重;若集群状态为第三状态,则提高所述第三打分策略的权重。
S140,根据所述至少两个打分策略和所述至少两个打分策略分别对应的权重确定所述集群中每个节点的目标分数。
示例性的,根据所述至少两个打分策略和所述至少两个打分策略分别对应的权重确定所述集群中每个节点的目标分数的方式可以为:根据第一打分策略确定所述集群中每个节点的第一分数,将所述第一分数和第一打分策略对应权重的乘积确定为第一数值;根据第二打分策略确定所述集群中每个节点的第二分数,将所述第二分数和第二打分策略对应权重的乘积确定为第二数值;根据第三打分策略确定所述集群中每个节点的第三分数,将所述第三分数和第三打分策略对应权重的乘积确定为第三数值;根据第四打分策略确定所述集群中每个节点的第四分数,将所述第四分数和第四打分策略对应权重的乘积确定为第四数值;根据所述第一数值、第二数值、第三数值和第四数值确定每个节点的目标分数。
S150,在集群中目标分数最高的节点上部署所述容器组。
可选的,根据集群中每个节点上已分配资源和占节点总资源的比例和真实负载信息确定集群状态,包括:
若集群中预设数量的节点上已分配资源和占节点总资源的比例小于需求阈值,则确定集群状态为第一状态;
若集群中预设数量的节点上已分配资源和占节点总资源的比例大于或者等于所述需求阈值,且集群中预设数量的节点真实负载信息小于真实负载阈值,则确定集群状态为第二状态;
若集群中预设数量的节点上已分配资源和占节点总资源的比例大于或者等于所述需求阈值,且集群中预设数量的节点真实负载信息大于或者等于真实负载阈值,则确定集群状态为第三状态。
可选的,所述至少两个打分策略包括:第一打分策略、第二打分策略、第三打分策略和第四打分策略,其中,所述第一打分策略为优先调度到已分配资源份额较少的节点,所述第二打分策略为优先调度到单个节点多种资源不平衡的节点,所述第三打分策略为优先调度到已分配资源量较少的节点,所述第四打分策略为优先调度到真实负载较低的节点。
可选的,根据所述集群状态信息确定至少两个打分策略分别对应的权重,包括:
若集群状态为第一状态,则获取第一打分策略的初始权重、第二打分策略的初始权重、第三打分策略的初始权重和第四打分策略的初始权重;
若集群状态为第二状态,则提高所述第四打分策略的权重;
若集群状态为第三状态,则提高所述第三打分策略的权重。
可选的,根据所述至少两个打分策略和所述至少两个打分策略分别对应的权重确定所述集群中每个节点的目标分数,包括:
根据第一打分策略确定所述集群中每个节点的第一分数,将所述第一分数和第一打分策略对应权重的乘积确定为第一数值;
根据第二打分策略确定所述集群中每个节点的第二分数,将所述第二分数和第二打分策略对应权重的乘积确定为第二数值;
根据第三打分策略确定所述集群中每个节点的第三分数,将所述第三分数和第三打分策略对应权重的乘积确定为第三数值;
根据第四打分策略确定所述集群中每个节点的第四分数,将所述第四分数和第四打分策略对应权重的乘积确定为第四数值;
根据所述第一数值、第二数值、第三数值和第四数值确定每个节点的目标分数。
本发明实施例能够利用节点真实负载的指标数据实现真实负载感知(RealLoadAware)策略,缓解集群节点资源利用率不均的问题。同时该方法可集成节点资源相关多种策略并支持扩展,默认兼容LeastRequestPriority策略、BalancedResourceAllocation策略和LeastAllocatable策略。在此基础上,该方法会根据节点资源真实负载状态划分集群节点资源状态并对不同状态下多种策略的权重进行动态控制,从而进一步改善集群节点资源利用率不均、节点资源碎片的状况。
综上所示,本发明实施例期望实现的目的为:基于节点真实负载数据实现节点真实负载感知策略,影响调度过程的打分,改善节点资源利用率不均的状况;兼容多种节点资源相关策略并支持策略扩展;根据节点资源划分集群节点资源状态并对不同状态下多种策略的权重进行动态控制,从而进一步均衡集群节点资源利用率、改善节点资源碎片状况。
本发明实施例相较于现有解决方法,提出一种支持节点真实负载感知、支持策略扩展、可动态控制策略权重的节点资源感知调度方法。本发明的核心创新具体由以下3部分组成:
引入节点真实负载指标数据作为调度打分的参考维度以改善集群节点资源利用率不均;
兼容原有策略并支持其他节点资源相关的策略扩展;
现有调度策略间的权重只能在调度器启动时静态配置,本发明根据真实负载指标数据将集群划分为3种状态,实现动态控制集群不同状态时的策略权重,进一步均衡集群节点资源利用率、改善节点资源碎片状况。
图1e是本发明技术方案的主体架构,其中,虚线内的NodeResourcesAware Plugin是本发明实现的方法插件,调度过程中会调用该插件以实现集群节点资源状态的划分。整体架构组成包括以下几个部分:
scheduler:自定义调度器。
scheduling cycle:为调度器内逻辑上的调度过程。
Metrics Provider:为获取节点真实负载信息的来源,包括但不限于Prometheus和Metric Server等。
NodeResourcesAware Plugin:本发明实现的调度方法插件。
NodeMetricCalculator:节点指标拉取计算模块,负责定期从Metric Provider拉取节点负载信息并根据自定义的划分集群划分依据对集群进行划分,将结果更新到Calculation Cache。
Calculation Cache:计算结果缓存,负责存储节点负载信息及集群状态信息以提高查询效率。
Preprocessor:预处理模块,负责在每个调度周期开始时提供当时的节点负载信息及集群状态信息的快照。
LeastRequestPriority、LeastAllocatable Strategy、BalancedResourceAllocation如表1所示:
表1
调度策略名 策略作用
LeastRequestPriority 优先调度到已分配资源份额较少的节点
BalancedResourceAllocation 优先调度到单个节点多种资源不平衡的节点
LeastAllocatable 优先调度到已分配资源量较少的节点
RealLoad Strategy:本发明实施例提供的基于节点真实负载数据的打分规则。
Mixed Strategy:兼容多种策略并支持策略扩展,可以动态控制各种策略间的权重关系。
整体流程如下:NodeMetricCalculator会定期从Metric Provider(如Prometheus)拉取节点相关metric指标,处理后更新到Calculation Cache中,Preprocessor会在每个调度周期开始时从Calculation Cache中获取当前的快照,依据此结果对集群节点资源状态进行划分,并根据划分好的集群状态获取到由用户提前配置的策略间权重关系。基于此策略权重关系,Mixed Strategy执行多个调度策略的打分逻辑,得到节点最终得分。
真实负载策略(RealLoad Strategy):
RealLoad Strategy会依赖拉取到的metric指标信息,NodeMetricCalculator会定期去指定的指标来源(如Prometheus)发出metric查询请求,查询的metric指标包括,其中,metric为量化的指标数据:
节点过去T1时间内CPU平均利用率:U1;
节点过去T2时间内CPU平均利用率:U2;
节点过去T1时间内存平均利用率:U3;
节点过去T2时间内存平均利用率:U4;
在对查询到的metric指标作规格化处理后,记RealLoad Strategy权重为WR,该策略得分计算公式为:
其中,Ui为节点的真实负载信息,Wi为Ui对应的权重,WR为真实负载策略对应的权重。
集群状态划分:
用户可以自定义设置的部分参数及其作用如表2所示:
表2
包括节点数参考比例ratioOfNodes、节点request阈值RequestThreshold、节点真实负载阈值RealLoadThreshold等,调度器启动前会获取调度插件的配置参数。节点根据NodeMetricCalculator从拉取到的节点真实负载相关的metric指标将集群划分为如下三种状态,具体请见表3:
表3
Origin:
当集群启动时,各节点负载较低,集群处于Origin状态。
ImproveRealLoad:
当集群中CPU或内存平均利用率超过节点资源请求阈值RequestThreshold的节点数占总节点数的比例超过节点数参考比例时,集群状态更改为ImproveRealLoad,在这个状态下会提高真实负载RealLoad策略的权重以提升低负载节点的资源利用率。
ReduceFragment:
当集群中CPU或内存平均利用率超过节点真实负载阈值RealLoadThreshold的节点数占总节点数的比例超过节点数参考比例时,集群状态更改为ReduceFragment,在这个状态下会提高LeastAllocatable策略的权重以改善节点资源碎片的状况。
动态控制策略权重及综合打分:
在每个调度周期开始时,调度器会根据处理好的metric指标数据及集群状态信息获取到该状态下合适的策略权重关系,通过Scheduling Framework将该信息传递给MixedStrategy,该混合策略会依次执行包含的多种策略并进行加权计算,得到最终的节点得分列表作为该算法下的调度结果返回,其中,Scheduling Framework为调度框架是Kubernetes默认调度器kube-scheduler的一种可插入架构,可以简化调度器的自定义过程。它向现有的调度器增加了一组新的插件式API,允许大多数调度功能以插件的形式实现,同时使调度核心代码保持简单且可维护。
本发明实施例实现了集群节点资源在不同状态下可以动态调节各策略间的权重,在兼容现有节点资源相关策略的基础上,实现了基于节点真实负载数据的RealLoad调度策略,相较于默认的调度方法,该方法突破了策略间权重只能在调度器启动时静态配置的限制且能根据集群节点资源状态动态调节各策略权重,能有效改善集群节点资源利用不均、节点资源碎片的状况。
本发明实施例实现了基于节点资源感知的调度方法,可以有效缓改善群节点资源利用不均、节点碎片资源的状况:基于节点真实负载数据实现节点真实负载感知策略对候选节点进行打分,缓解节点资源利用率不均的问题;兼容多种节点资源相关策略并支持策略扩展;根据节点资源划分集群节点资源状态并对不同状态下多种策略的权重进行动态控制,从而实现了策略权重的动态控制,进一步均衡集群节点资源利用率、改善节点资源碎片状况。
本实施例的技术方案,通过在获取到对容器组的创建请求时,获取集群中每个节点的真实负载信息;根据集群中每个节点上已分配资源和占节点总资源的比例和真实负载信息确定集群状态;根据所述集群状态确定至少两个打分策略分别对应的权重;根据所述至少两个打分策略和所述至少两个打分策略分别对应的权重确定所述集群中每个节点的目标分数;在集群中目标分数最高的节点上部署所述容器组,缓解集群节点资源利用率不均的问题。
图2为本发明实施例提供的一种容器组部署装置的结构示意图。本实施例可适用于容器组部署的情况,该装置可采用软件和/或硬件的方式实现,该装置可集成在任何提供容器组部署功能的设备中,如图2所示,所述容器组部署装置具体包括:获取模块210、第一确定模块220、第二确定模块230、第三确定模块240和部署模块250。
其中,获取模块,用于在获取到对容器组的创建请求时,获取集群中每个节点的真实负载信息;
第一确定模块,用于根据集群中每个节点上已分配资源和占节点总资源的比例和真实负载信息确定集群状态;
第二确定模块,用于根据所述集群状态确定至少两个打分策略分别对应的权重;
第三确定模块,用于根据所述至少两个打分策略和所述至少两个打分策略分别对应的权重确定所述集群中每个节点的目标分数;
部署模块,用于在集群中目标分数最高的节点上部署所述容器组。
可选的,所述第一确定模块具体用于:
若集群中预设数量的节点上已分配资源和占节点总资源的比例小于需求阈值,则确定集群状态为第一状态;
若集群中预设数量的节点上已分配资源和占节点总资源的比例大于或者等于所述需求阈值,且集群中预设数量的节点真实负载信息小于真实负载阈值,则确定集群状态为第二状态;
若集群中预设数量的节点上已分配资源和占节点总资源的比例大于或者等于所述需求阈值,且集群中预设数量的节点真实负载信息大于或者等于真实负载阈值,则确定集群状态为第三状态。
可选的,所述至少两个打分策略包括:第一打分策略、第二打分策略、第三打分策略和第四打分策略,其中,所述第一打分策略为优先调度到已分配资源份额较少的节点,所述第二打分策略为优先调度到单个节点多种资源不平衡的节点,所述第三打分策略为优先调度到已分配资源量较少的节点,所述第四打分策略为优先调度到真实负载较低的节点。
上述产品可执行本发明任意实施例所提供的方法,具备执行方法相应的功能模块和有益效果。
本实施例的技术方案,通过在获取到对容器组的创建请求时,获取集群中每个节点的真实负载信息;根据集群中每个节点上已分配资源和占节点总资源的比例和真实负载信息确定集群状态;根据所述集群状态确定至少两个打分策略分别对应的权重;根据所述至少两个打分策略和所述至少两个打分策略分别对应的权重确定所述集群中每个节点的目标分数;在集群中目标分数最高的节点上部署所述容器组,缓解集群节点资源利用率不均的问题。
图3为本发明实施例中的一种电子设备的结构示意图。图3示出了适于用来实现本发明实施方式的示例性电子设备12的框图。图3显示的电子设备12仅仅是一个示例,不应对本发明实施例的功能和使用范围带来任何限制。
如图3所示,电子设备12以通用计算设备的形式表现。电子设备12的组件可以包括但不限于:一个或者多个处理器或者处理单元16,系统存储器28,连接不同系统组件(包括系统存储器28和处理单元16)的总线18。
总线18表示几类总线结构中的一种或多种,包括存储器总线或者存储器控制器,外围总线,图形加速端口,处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说,这些体系结构包括但不限于工业标准体系结构(Industry StandardArchitecture,ISA)总线,微通道体系结构(Micro Channel Architecture,MCA)总线,增强型ISA总线、视频电子标准协会(Video Electronics Standards Association,VESA)局域总线以及外围组件互连(Peripheral Component Interconnect,PCI)总线。
电子设备12典型地包括多种计算机系统可读介质。这些介质可以是任何能够被电子设备12访问的可用介质,包括易失性和非易失性介质,可移动的和不可移动的介质。
系统存储器28可以包括易失性存储器形式的计算机系统可读介质,例如随机存取存储器(Random Access Memory,RAM)30和/或高速缓存存储器32。电子设备12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例,存储系统34可以用于读写不可移动的、非易失性磁介质(图3未显示,通常称为“硬盘驱动器”)。尽管图3中未示出,可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器,以及对可移动非易失性光盘(只读光盘(Compact Disc-Read Only Memory,CD-ROM)、数字视盘(Digital Video Disc-Read Only Memory,DVD-ROM)或者其它光介质)读写的光盘驱动器。在这些情况下,每个驱动器可以通过一个或者多个数据介质接口与总线18相连。系统存储器28可以包括至少一个程序产品,该程序产品具有一组(例如至少一个)程序模块,这些程序模块被配置以执行本发明各实施例的功能。
具有一组(至少一个)程序模块42的程序/实用工具40,可以存储在例如系统存储器28中,这样的程序模块42包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据,这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块42通常执行本发明所描述的实施例中的功能和/或方法。
电子设备12也可以与一个或多个外部设备14(例如键盘、指向设备、显示器24等)通信,还可与一个或者多个使得用户能与该电子设备12交互的设备通信,和/或与使得该电子设备12能与一个或多个其它计算设备进行通信的任何设备(例如网卡,调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口22进行。另外,本实施例中的电子设备12,显示器24不是作为独立个体存在,而是嵌入镜面中,在显示器24的显示面不予显示时,显示器24的显示面与镜面从视觉上融为一体。并且,电子设备12还可以通过网络适配器20与一个或者多个网络(例如局域网(Local Area Network,LAN),广域网Wide Area Network,WAN)和/或公共网络,例如因特网)通信。如图所示,网络适配器20通过总线18与电子设备12的其它模块通信。应当明白,尽管图中未示出,可以结合电子设备12使用其它硬件和/或软件模块,包括但不限于:微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、磁盘阵列(Redundant Arrays of Independent Disks,RAID)系统、磁带驱动器以及数据备份存储系统等。
处理单元16通过运行存储在系统存储器28中的程序,从而执行各种功能应用以及数据处理,例如实现本发明实施例所提供的容器组部署方法:
在获取到对容器组的创建请求时,获取集群中每个节点的真实负载信息;
根据集群中每个节点上已分配资源和占节点总资源的比例和真实负载信息确定集群状态;
根据所述集群状态确定至少两个打分策略分别对应的权重;
根据所述至少两个打分策略和所述至少两个打分策略分别对应的权重确定所述集群中每个节点的目标分数;
在集群中目标分数最高的节点上部署所述容器组。
图4为本发明实施例中的一种包含计算机程序的计算机可读存储介质的结构示意图。本发明实施例提供了一种计算机可读存储介质61,其上存储有计算机程序610,该程序被一个或多个处理器执行时实现如本申请所有发明实施例提供的容器组部署方法:
在获取到对容器组的创建请求时,获取集群中每个节点的真实负载信息;
根据集群中每个节点上已分配资源和占节点总资源的比例和真实负载信息确定集群状态;
根据所述集群状态确定至少两个打分策略分别对应的权重;
根据所述至少两个打分策略和所述至少两个打分策略分别对应的权重确定所述集群中每个节点的目标分数;
在集群中目标分数最高的节点上部署所述容器组。
可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于无线、电线、光缆、RF等等,或者上述的任意合适的组合。
在一些实施方式中,客户端、服务器可以利用诸如HTTP(Hyper Text TransferProtocol,超文本传输协议)之类的任何当前已知或未来研发的网络协议进行通信,并且可以与任意形式或介质的数字数据通信(例如,通信网络)互连。通信网络的示例包括局域网(“LAN”),广域网(“WAN”),网际网(例如,互联网)以及端对端网络(例如,ad hoc端对端网络),以及任何当前已知或未来研发的网络。
上述计算机可读介质可以是上述电子设备中所包含的;也可以是单独存在,而未装配入该电子设备中。
可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码,所述程序设计语言包括面向对象的程序设计语言诸如Java、Smalltalk、C++,还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络包括局域网(LAN)或广域网(WAN)连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
附图中的流程图和框图,图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
描述于本公开实施例中所涉及到的单元可以通过软件的方式实现,也可以通过硬件的方式来实现。其中,单元的名称在某种情况下并不构成对该单元本身的限定。
本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如,非限制性地,可以使用的示范类型的硬件逻辑部件包括:现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。
在本公开的上下文中,机器可读介质可以是有形的介质,其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备,或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
注意,上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解,本发明不限于这里所述的特定实施例,对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此,虽然通过以上实施例对本发明进行了较为详细的说明,但是本发明不仅仅限于以上实施例,在不脱离本发明构思的情况下,还可以包括更多其他等效实施例,而本发明的范围由所附的权利要求范围决定。

Claims (8)

1.一种容器组部署方法,其特征在于,包括:
在获取到对容器组的创建请求时,获取集群中每个节点的真实负载信息;
根据集群中每个节点上已分配资源和占节点总资源的比例和真实负载信息确定集群状态;
根据所述集群状态确定至少两个打分策略分别对应的权重;
根据所述至少两个打分策略和所述至少两个打分策略分别对应的权重确定所述集群中每个节点的目标分数;
在集群中目标分数最高的节点上部署所述容器组;
其中,根据集群中每个节点上已分配资源和占节点总资源的比例和真实负载信息确定集群状态,包括:
若集群中预设数量的节点上已分配资源和占节点总资源的比例小于需求阈值,则确定集群状态为第一状态;
若集群中预设数量的节点上已分配资源和占节点总资源的比例大于或者等于所述需求阈值,且集群中预设数量的节点真实负载信息小于真实负载阈值,则确定集群状态为第二状态;
若集群中预设数量的节点上已分配资源和占节点总资源的比例大于或者等于所述需求阈值,且集群中预设数量的节点真实负载信息大于或者等于真实负载阈值,则确定集群状态为第三状态。
2.根据权利要求1所述的方法,其特征在于,所述至少两个打分策略包括:第一打分策略、第二打分策略、第三打分策略和第四打分策略,其中,所述第一打分策略为优先调度到已分配资源份额较少的节点,所述第二打分策略为优先调度到单个节点多种资源不平衡的节点,所述第三打分策略为优先调度到已分配资源量较少的节点,所述第四打分策略为优先调度到真实负载较低的节点。
3.根据权利要求2所述的方法,其特征在于,根据所述集群状态信息确定至少两个打分策略分别对应的权重,包括:
若集群状态为第一状态,则获取第一打分策略的初始权重、第二打分策略的初始权重、第三打分策略的初始权重和第四打分策略的初始权重;
若集群状态为第二状态,则提高所述第四打分策略的权重;
若集群状态为第三状态,则提高所述第三打分策略的权重。
4.根据权利要求2所述的方法,其特征在于,根据所述至少两个打分策略和所述至少两个打分策略分别对应的权重确定所述集群中每个节点的目标分数,包括:
根据第一打分策略确定所述集群中每个节点的第一分数,将所述第一分数和第一打分策略对应权重的乘积确定为第一数值;
根据第二打分策略确定所述集群中每个节点的第二分数,将所述第二分数和第二打分策略对应权重的乘积确定为第二数值;
根据第三打分策略确定所述集群中每个节点的第三分数,将所述第三分数和第三打分策略对应权重的乘积确定为第三数值;
根据第四打分策略确定所述集群中每个节点的第四分数,将所述第四分数和第四打分策略对应权重的乘积确定为第四数值;
根据所述第一数值、第二数值、第三数值和第四数值确定每个节点的目标分数。
5.一种容器组部署装置,其特征在于,包括:
获取模块,用于在获取到对容器组的创建请求时,获取集群中每个节点的真实负载信息;
第一确定模块,用于根据集群中每个节点上已分配资源和占节点总资源的比例和真实负载信息确定集群状态;
第二确定模块,用于根据所述集群状态确定至少两个打分策略分别对应的权重;
第三确定模块,用于根据所述至少两个打分策略和所述至少两个打分策略分别对应的权重确定所述集群中每个节点的目标分数;
部署模块,用于在集群中目标分数最高的节点上部署所述容器组;
其中,所述第一确定模块具体用于:
若集群中预设数量的节点上已分配资源和占节点总资源的比例小于需求阈值,则确定集群状态为第一状态;
若集群中预设数量的节点上已分配资源和占节点总资源的比例大于或者等于所述需求阈值,且集群中预设数量的节点真实负载信息小于真实负载阈值,则确定集群状态为第二状态;
若集群中预设数量的节点上已分配资源和占节点总资源的比例大于或者等于所述需求阈值,且集群中预设数量的节点真实负载信息大于或者等于真实负载阈值,则确定集群状态为第三状态。
6.根据权利要求5所述的装置,其特征在于,所述至少两个打分策略包括:第一打分策略、第二打分策略、第三打分策略和第四打分策略,其中,所述第一打分策略为优先调度到已分配资源份额较少的节点,所述第二打分策略为优先调度到单个节点多种资源不平衡的节点,所述第三打分策略为优先调度到已分配资源量较少的节点,所述第四打分策略为优先调度到真实负载较低的节点。
7.一种电子设备,其特征在于,包括:
一个或多个处理器;
存储器,用于存储一个或多个程序;
当所述一个或多个程序被所述一个或多个处理器执行时,使得所述处理器实现如权利要求1-4中任一所述的容器组部署方法。
8.一种包含计算机程序的计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被一个或多个处理器执行时实现如权利要求1-4中任一所述的容器组部署方法。
CN202110771560.7A 2021-07-08 2021-07-08 一种容器组部署方法、装置、设备及存储介质 Active CN113342477B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110771560.7A CN113342477B (zh) 2021-07-08 2021-07-08 一种容器组部署方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110771560.7A CN113342477B (zh) 2021-07-08 2021-07-08 一种容器组部署方法、装置、设备及存储介质

Publications (2)

Publication Number Publication Date
CN113342477A CN113342477A (zh) 2021-09-03
CN113342477B true CN113342477B (zh) 2024-05-10

Family

ID=77483119

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110771560.7A Active CN113342477B (zh) 2021-07-08 2021-07-08 一种容器组部署方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN113342477B (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114090176A (zh) * 2021-11-19 2022-02-25 苏州博纳讯动软件有限公司 一种基于Kubernetes的容器调度方法
CN114840304B (zh) * 2022-04-15 2023-03-21 中兴通讯股份有限公司 一种容器调度方法、电子设备和存储介质
CN114942830A (zh) * 2022-06-30 2022-08-26 中国电信股份有限公司 容器调度方法、容器调度装置、存储介质和电子设备
CN116541134B (zh) * 2023-07-05 2023-09-19 苏州浪潮智能科技有限公司 多架构集群中容器的部署方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111625337A (zh) * 2020-05-28 2020-09-04 浪潮电子信息产业股份有限公司 一种任务调度方法、装置、电子设备和可读存储介质
CN111737003A (zh) * 2020-06-24 2020-10-02 重庆紫光华山智安科技有限公司 Pod均衡调度方法、装置、主节点及存储介质
CN112015536A (zh) * 2020-08-28 2020-12-01 北京浪潮数据技术有限公司 Kubernetes集群容器组调度方法、装置及介质
WO2020253266A1 (zh) * 2019-06-15 2020-12-24 华为技术有限公司 一种提供边缘服务的方法、装置和设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020253266A1 (zh) * 2019-06-15 2020-12-24 华为技术有限公司 一种提供边缘服务的方法、装置和设备
CN111625337A (zh) * 2020-05-28 2020-09-04 浪潮电子信息产业股份有限公司 一种任务调度方法、装置、电子设备和可读存储介质
CN111737003A (zh) * 2020-06-24 2020-10-02 重庆紫光华山智安科技有限公司 Pod均衡调度方法、装置、主节点及存储介质
CN112015536A (zh) * 2020-08-28 2020-12-01 北京浪潮数据技术有限公司 Kubernetes集群容器组调度方法、装置及介质

Also Published As

Publication number Publication date
CN113342477A (zh) 2021-09-03

Similar Documents

Publication Publication Date Title
CN113342477B (zh) 一种容器组部署方法、装置、设备及存储介质
US11175953B2 (en) Determining an allocation of computing resources for a job
CN110727512B (zh) 集群资源调度方法、装置、设备及储存介质
US20200287961A1 (en) Balancing resources in distributed computing environments
US10871998B2 (en) Usage instrumented workload scheduling
US9977689B2 (en) Dynamic scaling of management infrastructure in virtual environments
US9268394B2 (en) Virtualized application power budgeting
US10275277B2 (en) Job distribution within a grid environment using mega-host groupings of execution hosts
US8631410B2 (en) Scheduling jobs in a cluster having multiple computing nodes by constructing multiple sub-cluster based on entry and exit rules
US10333859B2 (en) Multi-tenant resource coordination method
US9110727B2 (en) Automatic replication of virtual machines
US20150295970A1 (en) Method and device for augmenting and releasing capacity of computing resources in real-time stream computing system
US9323580B2 (en) Optimized resource management for map/reduce computing
CN109117265A (zh) 在集群中调度作业的方法、装置、设备及存储介质
US20120136850A1 (en) Memory usage query governor
CN104503838A (zh) 一种虚拟cpu调度方法
CN112817728B (zh) 任务调度方法、网络设备和存储介质
CN104598426A (zh) 用于异构多核处理器系统的任务调度方法
US20230300086A1 (en) On-demand resource capacity in a serverless function-as-a-service infrastructure
US20200065415A1 (en) System For Optimizing Storage Replication In A Distributed Data Analysis System Using Historical Data Access Patterns
Shi et al. MapReduce short jobs optimization based on resource reuse
CN113255165A (zh) 一种基于动态任务分配的实验方案并行推演系统
US20150178115A1 (en) Optimal assignment of virtual machines and virtual disks using multiary tree
CN113703945B (zh) 微服务集群的调度方法、装置、设备及存储介质
Qu et al. Improving the energy efficiency and performance of data-intensive workflows in virtualized clouds

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
GR01 Patent grant
GR01 Patent grant