CN109656723A - 容器资源调度方法及装置 - Google Patents
容器资源调度方法及装置 Download PDFInfo
- Publication number
- CN109656723A CN109656723A CN201910187002.9A CN201910187002A CN109656723A CN 109656723 A CN109656723 A CN 109656723A CN 201910187002 A CN201910187002 A CN 201910187002A CN 109656723 A CN109656723 A CN 109656723A
- Authority
- CN
- China
- Prior art keywords
- abstract
- run
- application
- node
- container
- 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
Links
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
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本申请公开一种容器资源调度方法及装置,该方法可以获得多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力、以及待运行应用的第二抽象计算力;进而至少基于第一抽象计算力和第二抽象计算力,从多个容器工作节点中确定用于执行待运行应用的第一容器工作节点。由此可见,本申请可以为不同应用匹配不同的容器工作节点。
Description
技术领域
本申请属于云计算技术领域,尤其涉及一种容器资源调度方法及装置。
背景技术
容器化应用启动或扩容时,容器编排系统需将容器调度至容器工作节点,由容器工作节点通过容器引擎启动应用。
因此,如何为不同应用匹配容器工作节点就成为现阶段亟需解决的问题。
发明内容
为解决上述问题,本申请提供如下技术方案:
一种容器资源调度方法,所述方法包括:
获得多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力;其中,所述多个容器工作节点之间是异构的,所述多个容器工作节点中的每个容器工作节点包括多个内核,所述第一抽象计算力用于表征每个内核能够提供的用于执行所述待运行应用的最大物理资源;
获得所述待运行应用的第二抽象计算力;其中,所述第二抽象计算力用于表征执行所述待运行应用所需的物理资源;
至少基于所述第一抽象计算力和所述第二抽象计算力,从所述多个容器工作节点中确定用于执行所述待运行应用的第一容器工作节点。
优选的,所述获得多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力,包括:
获得参考工作节点中一个内核对应的针对所述待运行应用的标准指标参数;其中,所述标准指标参数用于表征所述参考工作节点中一个内核执行所述待运行应用的性能参数;
获得所述多个容器工作节点中每个内核对应的针对所述待运行应用的初始指标参数;其中,所述初始指标参数用于表征所述多个容器工作节点中每个内核执行所述待运行应用的性能参数;
基于所述标准指标参数对所述初始指标参数进行处理,得到所述多个容器工作节点中每个内核对应的针对所述待运行应用的第一抽象计算力。
优选的,所述基于所述标准指标参数对所述初始指标参数进行处理,得到所述多个容器工作节点中每个内核对应的针对所述待运行应用的第一抽象计算力,包括:
将所述初始指标参数与所述标准指标参数的比值作为所述多个容器工作节点中每个内核对应的针对所述待运行应用的第一抽象计算力。
优选的,所述获得所述待运行应用的第二抽象计算力,包括:
获得参考工作节点执行所述待运行应用所需的内核数量;
基于所述参考工作节点执行所述待运行应用所需的内核数量,获得所述待运行应用的第二抽象计算力。
优选的,所述基于所述参考工作节点执行所述待运行应用所需的内核数量,获得所述待运行应用的第二抽象计算力,包括:
将所述参考工作节点执行所述待运行应用所需的内核数量作为所述待运行应用的第二抽象计算力。
优选的,所述获得所述待运行应用的第二抽象计算力,包括:
获得所述多个容器工作节点中指定容器工作节点执行所述待运行应用所需的内核数量;
基于所述指定容器工作节点执行所述待运行应用所需的内核数量、以及所述指定容器工作节点中每个内核对应的第一抽象计算力,获得所述待运行应用的第二抽象计算力。
优选的,所述基于所述指定容器工作节点执行所述待运行应用所需的内核数量、以及所述指定容器工作节点中每个内核对应的第一抽象计算力,获得所述待运行应用的第二抽象计算力,包括:
将所述指定容器工作节点执行所述待运行应用所需的内核数量和所述指定容器工作节点中每个内核对应的第一抽象计算力的乘积作为所述待运行应用的第二抽象计算力。
优选的,所述至少基于所述第一抽象计算力和所述第二抽象计算力,从所述多个容器工作节点中确定用于执行所述待运行应用的第一容器工作节点,包括:
基于所述第二抽象计算力获得所述待运行应用对应的容器所需的抽象计算力;
基于所述容器所需的抽象计算力和所述第一抽象计算力的比值,从所述多个容器工作节点中确定所述第一容器工作节点。
优选的,所述基于所述容器所需的抽象计算力和所述第一抽象计算力的比值,从所述多个容器工作节点中确定所述第一容器工作节点,包括:
从所述多个容器工作节点中选取内核占用率最小的节点作为所述第一容器工作节点;其中,所述内核占用率是基于所述比值确定的。
优选的,所述至少基于所述第一抽象计算力和所述第二抽象计算力,从所述多个容器工作节点中确定用于执行所述待运行应用的第一容器工作节点,包括:
基于所述第一抽象计算力获得所述多个容器工作节点中每个内核对应的针对所述待运行应用的第三抽象计算力;其中,所述第三抽象计算力用于表征每个内核能够提供的用于执行所述待运行应用的空闲物理资源;
至少基于所述第二抽象计算力和所述第三抽象计算力,从所述多个容器工作节点中确定所述第一容器工作节点。
优选的,所述基于所述第一抽象计算力获得所述多个容器工作节点中每个内核对应的针对所述待运行应用的第三抽象计算力,包括:
获得所述多个容器工作节点中每个内核的可用率;
将所述可用率和所述第一抽象计算力的乘积作为所述多个容器工作节点中每个内核对应的针对所述待运行应用的第三抽象计算力。
优选的,所述至少基于所述第二抽象计算力和所述第三抽象计算力,从所述多个容器工作节点中确定所述第一容器工作节点,包括:
基于所述第二抽象计算力获得所述待运行应用对应的容器所需的抽象计算力;
在所述待运行应用的配置参数中不存在用于表征所述待运行应用由完全空闲的内核执行的参数的情况下,从所述多个容器工作节点中选取非空闲的内核的所述第三抽象计算力的迭加和大于所述容器所需的抽象计算力的节点作为所述第一容器工作节点。
优选的,所述至少基于所述第二抽象计算力和所述第三抽象计算力,从所述多个容器工作节点中确定所述第一容器工作节点,还包括:
在所述待运行应用的配置参数中存在用于表征所述待运行应用由完全空闲的内核执行的参数的情况下,从所述多个容器工作节点中选取完全空闲的内核的所述第三抽象计算力的迭加和大于所述容器所需的抽象计算力的节点作为所述第一容器工作节点。
优选的,所述方法还包括:
获得用于至少扩容或者缩容的指令;
基于所述指令从所述多个容器工作节点中确定用于执行所述待运行应用的第二容器工作节点。
优选的,所述指令是基于所述第一容器工作节点中用于执行所述待运行应用的每个内核的第四抽象计算力所生成的;其中,所述第四抽象计算力用于表征每个内核能够提供的用于执行所述待运行应用的实际物理资源。
一种容器资源调度装置,所述装置包括:
第一获得模块,用于获得多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力;其中,所述多个容器工作节点之间是异构的,所述多个容器工作节点中的每个容器工作节点包括多个内核,所述第一抽象计算力用于表征每个内核能够提供的用于执行所述待运行应用的最大物理资源;
第二获得模块,用于获得所述待运行应用的第二抽象计算力;其中,所述第二抽象计算力用于表征执行所述待运行应用所需的物理资源;
确定模块,用于至少基于所述第一抽象计算力和所述第二抽象计算力,从所述多个容器工作节点中确定用于执行所述待运行应用的第一容器工作节点。
优选的,所述第一获得模块,具体用于:
获得参考工作节点中一个内核对应的针对所述待运行应用的标准指标参数;其中,所述标准指标参数用于表征所述参考工作节点中一个内核执行所述待运行应用的性能参数;获得所述多个容器工作节点中每个内核对应的针对所述待运行应用的初始指标参数;其中,所述初始指标参数用于表征所述多个容器工作节点中每个内核执行所述待运行应用的性能参数;基于所述标准指标参数对所述初始指标参数进行处理,得到所述多个容器工作节点中每个内核对应的针对所述待运行应用的第一抽象计算力。
优选的,所述第二获得模块,具体用于:
获得所述多个容器工作节点中指定容器工作节点执行所述待运行应用所需的内核数量;基于所述指定容器工作节点执行所述待运行应用所需的内核数量、以及所述指定容器工作节点中每个内核对应的第一抽象计算力,获得所述待运行应用的第二抽象计算力。
优选的,所述确定模块,具体用于:
基于所述第二抽象计算力获得所述待运行应用对应的容器所需的抽象计算力;基于所述容器所需的抽象计算力和所述第一抽象计算力的比值,从所述多个容器工作节点中确定所述第一容器工作节点。
优选的,所述确定模块,具体用于:
基于所述第一抽象计算力获得所述多个容器工作节点中每个内核对应的针对所述待运行应用的第三抽象计算力;其中,所述第三抽象计算力用于表征每个内核能够提供的用于执行所述待运行应用的空闲物理资源;至少基于所述第二抽象计算力和所述第三抽象计算力,从所述多个容器工作节点中确定所述第一容器工作节点。
通过以上技术手段,可以实现以下有益效果:
经由上述的技术方案可知,本申请实施例提供了一种容器资源调度方法,该方法可以获得多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力、以及待运行应用的第二抽象计算力;进而至少基于第一抽象计算力和第二抽象计算力,从多个容器工作节点中确定用于执行待运行应用的第一容器工作节点。由此可见,本申请可以为不同应用匹配不同的容器工作节点。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据提供的附图获得其他的附图。
图1为本申请实施例一公开的一种容器资源调度方法的流程示意图;
图2为本申请实施例二公开的一种容器资源调度方法的流程示意图;
图3为本申请实施例三公开的一种容器资源调度方法的流程示意图;
图4为本申请实施例四公开的一种容器资源调度方法的流程示意图;
图5为本申请实施例五公开的一种容器资源调度方法的流程示意图;
图6为本申请实施例六公开的一种容器资源调度方法的流程示意图;
图7为本申请公开的一种容器资源调度装置的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
内核:又称核心,是处理器最重要的组成部分。处理器内所有的计算、接收/存储命令、处理数据都由核心,比如CPU核执行。
现阶段,应用部署时描述文件的资源需求项中,用户对于CPU需求项的填写主要为内核数量,也就是说容器编排节点(安装有编排软件的物理服务器)在调度容器时仅参考内核数量来调度,比如为某应用的一个容器分配容器工作节点(安装有容器引擎的物理服务器)上的2个内核。但是,一方面,对于节点间异构的容器工作节点,其服务器配置、CPU指令集设计和实现等配置信息不同,导致计算力存在显著差异;另一方面,不同类型应用所使用的指令序列、指令序列的频度、以及数据访问的粒度和频度也各不相同,同一个容器工作节点的单个内核对于不同类型应用输出的计算力也各不相同。因此,单纯使用内核数量来调度容器资源,很容易出现资源过载或浪费。
为方便理解,本申请首先对容器资源调度相关概念进行介绍:
容器技术:为软件和其依赖环境的标准化打包,可以解决开发与运维环境不一致的问题。
启动容器化应用:其本质是容器编排节点将容器调度到容器工作节点,由该容器工作节点通过容器引擎启动容器,来将应用的镜像加载到该容器中并运行。
本申请公开的一种容器资源调度方法实施例一中,如图1所示,该方法包括以下步骤:
步骤101:获得多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力;其中,多个容器工作节点之间是异构的,多个容器工作节点中的每个容器工作节点包括多个内核,第一抽象计算力用于表征每个内核能够提供的用于执行待运行应用的最大物理资源。
首先,本申请所公开的容器资源调度方法可以应用于容器编排节点,此时第一抽象计算力可以由容器工作节点将自身结果发送给容器编排节点、第二抽象计算力可以从CPU需求项中读取。当然,该方法还可以应用于多个容器工作节点中的任意一个节点,此时第一抽象计算力可以直接从自身缓存以及其他节点处获得、第二抽象计算力可以从CPU需求项中读取。本申请对于该方法的执行方并不做限定,可以理解的是,具有运算功能的节点均在本申请保护范围内。
其次,在获得多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力的过程中,对于多个容器工作节点中的每一个容器工作节点来说:可以按照该待运行应用所属的应用类型来确定该容器工作节点中每个内核的第一抽象计算力。也就是说,该容器工作节点中预先缓存有不同应用类型的第一抽象计算力,直接基于待运行应用的应用类型读取缓存结果即可。
为方便理解,以下以容器工作节点1和应用类型A为例来说明获得第一抽象计算力的过程:
容器工作节点1首次启动时运行应用类型A的benchmark基准测试程序,比如speccpu、spec-web、tpc-w、linpack等程序中具有代表性且运行时间较短的程序,以此获得容器工作节点1中每个内核对应的针对该应用类型A的第一benchmark分数。其中,benchmark程序指一组性能测试程序,它能刻画应用负载的计算处理、数据移动等行为特征,从而测试和预测系统的性能,并能对不同的系统的优缺点给出评价。
进而,利用应用类型A的benchmark程序运行于典型平台(该典型平台可以为多个容器工作节点中的一个节点,还可以是多个容器工作节点之外的参考工作节点)所获得的第二benchmark分数对第一benchmark分数进行处理,获得容器工作节点1中每个内核针对该应用类型A的第一抽象计算力,比如,将第一benchmark分数与第二benchmark分数的比值作为第一抽象计算力。
可以看出,所有应用类型的benchmark程序均运行于典型平台时,即可以为不同容器工作节点提供统一的计算力衡量单位。比如,应用类型A在典型平台的第二benchmark分数为5、在容器工作节点1的第一benchmark分数为10、在容器工作节点2的第一benchmark分数为20,此时容器工作节点1的第一抽象计算力为2、容器工作节点2的第一抽象计算力就为4。显而易见的,对于应用类型A的这类应用,相较于容器工作节点1,容器工作节点2中每个内核能够提供更多的用于执行应用类型A的最大物理资源,诸如内存、带宽等的最大限度。
步骤102:获得待运行应用的第二抽象计算力;其中,第二抽象计算力用于表征执行待运行应用所需的物理资源。
本申请中,待运行应用的第二抽象计算力主要通过在指定平台上评测来获得。而评测待运行应用的目的即为找到该指定平台执行该待运行应用所需的,也就是最佳的内核数量,进而利用该内核数量与该指定平台中每个内核对应的待运行应用的第一抽象计算力来获得第二抽象计算力,比如将内核数量与第一抽象计算力的乘积作为第二抽象计算力。这就可以统一待运行应用和容器工作节点的计算力衡量单位。
以下对在指定平台上评测待运行应用的过程做简单介绍:
用户获得资源需求的方式有多种,比如数学建模等,在此对常见的人工迭代优化方法做说明。
假设对于web服务类应用,用户期望支持的并发用户数量为200,可接受的最大延迟为200ms。在该指定平台上执行该web服务类应用,并为该web服务类应用设置初始资源。比如0.5个内核、500M内存,之后用合适的负载生成器,比如开源的httpperf模拟200个用户请求web服务。如果指定平台不能满足用户要求,则增加资源,比如1.2个内核、600M内存,再重新测试。如果指定平台能满足用户要求,且最大延迟远远小于200ms,则减少资源,比如0.4个内核、500M内存。直到能满足并发用户数量和最大延时的要求、同时没有过多资源浪费的情况时结束,比如最后确定的资源为0.8个内核、600M内存。
步骤103:至少基于第一抽象计算力和第二抽象计算力,从多个容器工作节点中确定用于执行待运行应用的第一容器工作节点。
本申请中,用户可以预先设置针对抽象计算力的节点确定规则,进而通过读取节点确定规则的内容,结合第一抽象计算力和第二抽象计算力从多个容器工作节点中确定第一容器工作节点。
为方便理解,以容器工作节点1、容器工作节点2和容器工作节点3为例进行说明:
容器工作节点1中有5个内核、每个内核针对待运行应用的第一抽象计算力为2;容器工作节点2中有3个内核、每个内核针对待运行应用的第一抽象计算力为4;容器工作节点3中有4个内核,每个内核针对待运行应用的第一抽象计算力为5。
本申请中,待运行应用所对应的容器由用户预先指定,也就是说,待运行应用确定后,其对应的容器也就确定。假设待运行应用的第二抽象计算力为15、对应的容器有3个,以每个容器所需的抽象计算力相同为例,则运行每个容器所需的抽象计算力为15/3=5。在为容器分配容器工作节点时,为方便理解以下以一个容器——容器1为例进行说明:
如果节点确定规则中要求容器由一个第一抽象计算力最小的节点运行,则此时将容器工作节点1作为运行容器1的第一容器工作节点,且第一容器工作节点运行容器1时由2.5个内核同时工作。
再如果节点确定规则中要求由一个第一抽象计算力最大的节点运行,则此时将容器工作节点2作为运行容器1的第一容器工作节点,且第一容器工作节点运行容器1时由1.25个内核同时工作。
再比如节点确定规则中要求由一个第一抽象计算力最接近运行容器所需的抽象计算力的节点运行,则此时将容器工作节点3作为运行容器1的第一容器工作节点,且第一容器工作节点运行容器1时由1个内核工作。
需要说明的是,节点确定规则中的内容可以由用户指定,上述举例内容仅为具体实现的一种方式,可以理解的是,其他未列举的方式也在本申请的保护范围内。
另外,在本申请中容器编排节点,比如kubernetes集群中的Controller-manager控制器管理节点可以结合第一容器工作节点中运行容器的内核的实际使用率来确定括扩容或者缩容。因此,在图1所示的容器资源调度方法的基础上,还可以包括如下步骤:
获得用于至少扩容或者缩容的指令;基于指令从多个容器工作节点中确定用于执行待运行应用的第二容器工作节点。
本申请中,指令中包含有扩容的数量或者缩容的数量。如果为扩容,比如上述待运行应用的容器由3个扩容为5个,则重新计算每个容器所需的抽象计算力15/5=3。并按照节点确定规则重新从多个容器工作节点中确定运行各容器的第二容器工作节点,确定过程在此不再赘述。
现阶段,指令是基于运行容器的内核的实际使用率所生成的,而运行容器的内核的实际使用率则主要是通过统计物理资源的使用情况,比如内存的使用量、带宽的使用量来确定的。本申请中,指令是基于第一容器工作节点中用于执行待运行应用的每个内核的第四抽象计算力所生成的;其中,第四抽象计算力用于表征每个内核能够提供的用于执行待运行应用的实际物理资源。
本申请中,第一容器工作节点在运行容器时,可以统计每个内核在一个运转周期内的运行时间和空转时间,从而利用运行时间、空转时间和第一抽象计算力来计算每个内核针对待运行应用的第四抽象计算力。具体的:
第四抽象计算力=第一抽象计算力*(运行时间/(运行时间+空转时间))
此时,比较第四抽象计算力和指定的抽象计算力阈值(扩容抽象计算力阈值和缩容抽象计算力阈值)。如果第四抽象计算力大于扩容抽象计算力阈值,则指令用于指示扩容;如果第四抽象计算力小于缩容抽象计算力阈值,则指令用于指示缩容。
由此可见,本申请提供的容器资源调度方法可以为待运行应用和容器工作节点之间统一计算力衡量单位,在容器编排调度时能够结合抽象计算力在节点间异构的容器工作节点和不同种类应用之间做出最佳匹配,从而减少甚至避免资源规则或浪费。
作为获得多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力的一种实现方式,本申请实施例二公开了一种容器资源调度方法,如图2所示,该方法包括如下步骤:
步骤201:获得参考工作节点中一个内核对应的针对待运行应用的标准指标参数;其中,标准指标参数用于表征参考工作节点中一个内核执行待运行应用的性能参数。
本申请中,由参考工作节点中任意或指定的一个内核执行待运行应用以获得标准指标参数,该标准指标参数对于不同应用类型具有不同内容。比如对于服务类应用,标准指标参数为单位时间内完成的请求数;再比如对于事物类应用,标准指标参数为单位时间内完成的事务数;再比如对于数据处理类应用,标准指标参数为单位时间内处理的数据量;再比如对于高性能计算类应用,标准指标参数为运行时间。
需要说明的是,参考工作节点执行时可以采用并行和串行两种方式中的任意一种。具体的,并行是指参考工作节点中所有内核同时工作,串行则是指同一时间下参考工作节点中单个内核工作。
因此,对于服务器类应用、事物类应用和数据处理类应用。参考工作节点采用并行方式时,标准指标参数为并行结果与内核数量的比值;参考工作节点采用串行方式时,标准指标参数为并行结果的值。
而对于高性能计算类应用。参考工作节点采用并行方式时,标准指标参数为并行结果与内核数量的乘积;参考工作节点采用串行方式时,标准指标参数为并行结果的值。
步骤202:获得多个容器工作节点中每个内核对应的针对待运行应用的初始指标参数;其中,初始指标参数用于表征多个容器工作节点中每个内核执行待运行应用的性能参数。
本申请中,由多个容器工作节点中每个节点的任意或指定一个内核分别执行待运行应用以获得初始指标参数,该初始标准参数对于不同应用类型具有不同内容,与标准指标参数相对应。比如,对于服务类应用,初始指标参数也为单位时间内完成的请求数;再比如对于事物类应用,初始指标参数也为单位时间内完成的事务数;再比如对于数据处理类应用,初始指标参数也为单位时间内处理的数据量;再比如对于高性能计算类应用,初始指标参数也为运行时间。
还需要说明的是,容器工作节点执行时可以采用串行和并行两种方式中的任意一种。具体的,并行是指容器工作节点中所有内核同时工作,串行则是指同一时间下容器工作节点中单个内核工作。
因此,对于服务器类应用、事物类应用和数据处理类应用。容器工作节点采用并行方式时,初始指标参数为并行结果与内核数量的比值;容器工作节点采用串行方式时,初始指标参数为并行结果的值。
而对于高性能计算类应用。容器工作节点采用并行方式时,初始指标参数为并行结果与内核数量的乘积;容器工作节点采用串行方式时,初始指标参数为并行结果的值。
步骤203:基于标准指标参数对初始指标参数进行处理,得到多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力。
本申请中,用户预先设置针对第一抽象计算力的处理规则,进而通过读取该处理规则的内容、利用标准指标参数和初始指标参数计算第一抽象计算力。
为方便理解,以下以服务器类的待运行应用为例进行说明:
假设参考工作节点中一个内核执行待运行应用时单位时间内完成的请求数为&、容器工作节点1中每个内核执行待运行应用时单位时间内完成的请求数为&’,则基于处理规则的内容执行对&’和&的运算。比如,先对&做一定处理(假设将&扩大1.5倍)、再将&’与1.5&的比值作为容器工作节点1中每个内核对应的针对待运行应用的第一抽象计算力。
更简单的,可以直接将初始指标参数与标准指标参数的比值作为多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力。继续以服务器类的待运行应用为例,则容器工作节点1中每个内核针对待运行应用的第一抽象计算力为&’和&的比值。
步骤204:获得待运行应用的第二抽象计算力;其中,第二抽象计算力用于表征执行待运行应用所需的物理资源。
步骤205:至少基于第一抽象计算力和第二抽象计算力,从多个容器工作节点中确定用于执行待运行应用的第一容器工作节点。
由此可见,本申请提供的容器资源调度方法可以利用内核的性能参数获得多个容器工作节点中每个内核针对待运行应用的第一抽象计算力,结合待运行应用的第二抽象计算力为待运行应用和容器工作节点之间统一计算力衡量单位, 在容器编排调度时能够结合抽象计算力在节点间异构的容器工作节点和不同种类应用之间做出最佳匹配,从而减少甚至避免资源规则或浪费。
作为获得待运行应用的第二抽象计算力的一种实现方式,本申请实施例三公开了一种容器资源调度方法,如图3所示,该方法包括如下步骤:
步骤301:获得多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力;其中,多个容器工作节点之间是异构的,多个容器工作节点中的每个容器工作节点包括多个内核,第一抽象计算力用于表征每个内核能够提供的用于执行待运行应用的最大物理资源。
步骤302:获得参考工作节点执行待运行应用所需的内核数量。
本申请中,参考工作节点执行待运行应用所需的内核数量主要通过在参考工作节点上评测待运行应用获得。而在参考工作节点上评测待运行应用的过程可以参见上述实施例一中在指定平台上评测待运行应用的过程,在此不再赘述。可以理解的是,对于本申请中未列举的其他评测方式也在本申请保护范围内。
步骤303:基于参考工作节点执行待运行应用所需的内核数量,获得待运行应用的第二抽象计算力。
本申请中,用户预先设置针对内核数量的处理规则,进而通过读取该处理规则的内容、利用步骤S302获得的内核数量计算第二抽象计算力。比如,对内核数量b做一定处理(假设将内核数量b扩大1.2倍),且由于参考工作节点中每个内核对应的针对待运行应用的第一抽象计算力为1,因此再将1.2b作为待运行应用的第二抽象计算力。
更简单的,由于评测获得的内核数量为最佳的,可以直接将将参考工作节点执行待运行应用所需的内核数量作为待运行应用的第二抽象计算力。
步骤304:至少基于第一抽象计算力和第二抽象计算力,从多个容器工作节点中确定用于执行待运行应用的第一容器工作节点。
由此可见,本申请提供的容器资源调度方法可以利用参考工作节点获得待运行应用的第二抽象计算力,结合多个容器工作节点中每个内核针对待运行应用的第一抽象计算力为待运行应用和容器工作节点之间统一计算力衡量单位, 在容器编排调度时能够结合抽象计算力在节点间异构的容器工作节点和不同种类应用之间做出最佳匹配,从而减少甚至避免资源规则或浪费。
作为获得待运行应用的第二抽象计算力的一种实现方式,本申请实施例四公开了一种容器资源调度方法,如图4所示,该方法包括如下步骤:
步骤401:获得多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力;其中,多个容器工作节点之间是异构的,多个容器工作节点中的每个容器工作节点包括多个内核,第一抽象计算力用于表征每个内核能够提供的用于执行待运行应用的最大物理资源。
步骤402:获得多个容器工作节点中指定容器工作节点执行待运行应用所需的内核数量。
本申请中,指定容器工作节点执行待运行应用所需的内核数量主要通过在指定容器工作节点上评测待运行应用获得。而在指定容器工作节点上评测待运行应用的过程可以参见上述实施例一中在指定平台上评测待运行应用的过程,在此不再赘述。可以理解的是,对于本申请中未列举的其他评测方式也在本申请保护范围内。
步骤403:基于指定容器工作节点执行待运行应用所需的内核数量、以及指定容器工作节点中每个内核对应的第一抽象计算力,获得待运行应用的第二抽象计算力。
本申请中,用户预先设置针对内核数量的处理规则,进而通过读取该处理规则的内容、利用步骤402获得的内核数量计算第二抽象计算力。比如对内核数量c做一定处理(假设将内核数量c扩大1.2倍)、指定容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力为d,因此可以将1.2c与d的乘积作为待运行应用的第二抽象计算力。
更简单的,由于评测获得的内核数量为最佳的,可以直接将指定容器工作节点执行待运行应用所需的内核数量和指定容器工作节点中每个内核对应的第一抽象计算力的乘积作为待运行应用的第二抽象计算力。
步骤404:至少基于第一抽象计算力和第二抽象计算力,从多个容器工作节点中确定用于执行待运行应用的第一容器工作节点。
由此可见,本申请提供的容器资源调度方法可以利用指定容器工作节点获得待运行应用的第二抽象计算力,结合多个容器工作节点中每个内核针对待运行应用的第一抽象计算力为待运行应用和容器工作节点之间统一计算力衡量单位, 在容器编排调度时能够结合抽象计算力在节点间异构的容器工作节点和不同种类应用之间做出最佳匹配,从而减少甚至避免资源规则或浪费。
作为至少基于第一抽象计算力和第二抽象计算力,从多个容器工作节点中确定用于执行待运行应用的第一容器工作节点的一种实现方式,本申请实施例五公开了一种容器资源调度方法,如图5所示,该方法包括如下步骤:
步骤501:获得多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力;其中,多个容器工作节点之间是异构的,多个容器工作节点中的每个容器工作节点包括多个内核,第一抽象计算力用于表征每个内核能够提供的用于执行待运行应用的最大物理资源。
步骤502:获得待运行应用的第二抽象计算力;其中,第二抽象计算力用于表征执行待运行应用所需的物理资源。
步骤503:基于第二抽象计算力获得待运行应用对应的容器所需的抽象计算力。
本申请中获得容器所需的抽象计算力的过程请参见上述实施例一,在此不再赘述。
步骤504:基于容器所需的抽象计算力和第一抽象计算力的比值,从多个容器工作节点中确定第一容器工作节点。
为方便理解,继续以容器工作节点1和容器工作节点2为例进行说明:
容器工作节点1中有5个内核、每个内核针对待运行应用的第一抽象计算力为2;容器工作节点2中有3个内核、每个内核针对待运行应用的第一抽象计算力为4。
假设容器2所需的抽象计算力为9。则对于容器工作节点1来说,容器2所需的抽象计算力和第一抽象计算力的比值为4.5;对于容器工作节点2来说,容器2所需的抽象计算力和第一抽象计算力的比值为2.25。也就是说,如果由容器工作节点1运行容器2需要4.5个内核同时工作,而如果由容器工作节点2运行容器2则需要2.25个内核同时工作。
为减少内核的占用量,可以从多个容器工作节点中选取比值最小的节点作为第一容器工作节点。举例来说,可以比较容器工作节点1和容器工作节点2各自对应的比值,从中选取比值最小的、也就是内核占有量为2.25的容器工作节点2作为运行容器2的第一容器工作节点。
需要说明的是,上述“选取比值最小的节点作为第一容器工作节点”仅作为具体实现方式的一种举例,可以理解的是,其他未列举的方式也在本申请的保护范围内。
当然,在其他一些实施例中,还可以结合用户预先设置的内核占用率条件从多个容器工作节点中选取第一容器工作节点,具体的,内核占用率为内核占有量和内核数量的比值。继续以容器工作节点1和容器工作节点2为例,容器工作节点1的内核占有率为4.5/5=90%、容器工作节点2的内核占有率为2.25/3=75%。
假设,内核占有率条件要求执行应用的节点的内核占用率小于80%,则此时将内核占用率为75%的容器工作节点2作为运行容器2的第一容器工作节点。
再假设,内核占有率条件要求执行应用的节点的内核占用率小于95%,则此时可以从内核占用率90%的容器工作节点1和内核占用率75%的容器工作节点2中随机或者按照其他条件(比如,第一抽象计算力最小)选取运行容器2的第一容器工作节点。
当然,更简单的,还可以从多个容器工作节点中选取内核占有率最小的节点作为第一容器工作节点。继续以容器工作节点1和容器工作节点2为例,也就是选取容器工作节点2作为运行容器2的第一容器工作节点。
由此可见,本申请提供的容器资源调度方法可以为待运行应用和容器工作节点之间统一计算力衡量单位,在容器编排调度时能够结合抽象计算力比值在节点间异构的容器工作节点和不同种类应用之间做出最佳匹配,从而减少甚至避免资源规则或浪费。
作为至少基于第一抽象计算力和第二抽象计算力,从多个容器工作节点中确定用于执行待运行应用的第一容器工作节点的一种实现方式,本申请实施例六公开了一种容器资源调度方法,如图6所示,该方法包括如下步骤:
步骤601:获得多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力;其中,多个容器工作节点之间是异构的,多个容器工作节点中的每个容器工作节点包括多个内核,第一抽象计算力用于表征每个内核能够提供的用于执行待运行应用的最大物理资源。
步骤602:获得待运行应用的第二抽象计算力;其中,第二抽象计算力用于表征执行待运行应用所需的物理资源。
步骤603:基于第一抽象计算力获得多个容器工作节点中每个内核对应的针对待运行应用的第三抽象计算力;其中,第三抽象计算力用于表征每个内核能够提供的用于执行待运行应用的空闲物理资源。
本申请中,对于多个容器工作节点中每个容器工作节点的每个内核来说,可以首先统计该内核的物理资源空闲情况,诸如内存、带宽等的空闲量,进而结合物理资源空闲情况确定第一抽象计算力对应的第三抽象计算力。
比如,内存空闲量为c、带宽空闲量为d时,第三抽象计算力为第一抽象计算力的10%;再比如,内存空闲量为e、带宽空闲量为f时,第三抽象计算力为第一抽象计算力的20%。
需要说明的是,上述举例内容仅作为具体实现的一种方式,可以理解的是,其他未列举的方式也在本申请的保护范围内。
在其他一些实施例中,基于第一抽象计算力获得第三抽象计算力的方式还可以采用如下实现方式:
获得多个容器工作节点中每个内核的可用率;将可用率和第一抽象计算力的乘积作为多个容器工作节点中每个内核对应的针对待运行应用的第三抽象计算力。
本申请中,对于多个容器工作节点中每个容器工作节点的每个内核来说,可以首先统计该内核执行其他应用所占用的抽象计算力,进而结合该内核针对该其他应用的第一抽象计算力来计算该内核的可用率,从而将该可用率和该内核针对待运行应用的第一抽象计算力的乘积作为该内核针对待运行应用的第三抽象计算力。
为方便理解,以下以容器工作节点中某一内核¢为例对计算可用率的过程进行说明:
内核¢针对待运行应用的第一抽象计算力为g、针对待运行应用之外的应用1的第一抽象计算力为h、针对待运行应用之外的应用2的第一抽象计算力为j。
假设,内核¢在执行应用1时实际占用的抽象计算力为k、执行应用2时实际占用的抽象计算力为m,则内核¢在执行应用1时的使用率为k/h、在执行应用2时的使用率为m/j。此时,内核¢的可用率即为1-k/h-m/j。
步骤604:至少基于第二抽象计算力和第三抽象计算力,从多个容器工作节点中确定第一容器工作节点。
本申请中,对于多个容器工作节点中的每个容器工作节点来说,可以首先计算该节点的第三抽象计算力的迭加和,再与容器所需的抽象计算力相比较,以此判断该节点是否可以运行该容器。其中,容器所需的抽象计算力是基于第二抽象计算力获得的,获得容器所需的抽象计算力的过程请参见上述实施例一,在此不再赘述。
对于某一个容器来说,如果可以运行该容器的容器工作节点为多个,则可以进一步从这些节点中随机或者按照一定条件(比如占用内核数量最少,再比如第一抽象计算力最小等)选取某一节点作为第一容器工作节点。
为方便理解,继续以容器工作节点1和容器工作节点2为例进行说明:
容器工作节点1中有5个内核、内核1~内核5的第三抽象计算力分别为0.5、0.6、0.8、1、2;容器工作节点2中有3个内核、内核1~内核3的第三抽象计算力分别为0.9、2、4。
假设容器3所需的抽象计算力为6.5。可以看出,容器工作节点1的第三抽象计算力的迭加和小于容器3所需的抽象计算力,也就是说,容器工作节点1无法运行容器3。而容器工作节点2的第三抽象计算力的迭加和大于容器3所需的抽象计算力,可以运行容器3。因此,可以将容器工作节点2作为运行容器3的第一容器工作节点。
再假设容器3所需的抽象计算力为4.5。可以看出,容器工作节点1和容器工作节点2均可以运行容器3。因此,可以从容器工作节点1和容器工作节点2中随机或者按照一定条件选取作为第一容器工作节点的节点。比如,筛选占用内核数量最少的节点作为第一容器工作节点时,容器工作节点1最少占用3个内核、容器工作节点2最少占用2个内核,此时选取容器工作节点2作为运行容器3的第一容器工作节点。
在其他一些实施例中,由于部分容器对于应用的隔离性能较差,因此应用部署时描述文件的资源需求项中,用户对于CPU需求项还可以填写“是否由完全空闲的内核执行”。
1)如果待运行应用的配置参数中不存在用于表征待运行应用由完全空闲的内核执行的参数,则表示该待运行应用的容器可以由完全空闲的内核执行,还可以由非空闲的内核执行,还可以由完全空闲的内核与非空闲内核共同执行。因此从多个容器工作节点中选取第一容器工作节点时,保证第一容器工作节点所有内核的第三抽象计算力的迭加和大于容器所需的抽象计算力即可。其中,容器所需的抽象计算力是基于第二抽象计算力获得的,获得容器所需的抽象计算力的过程请参见上述实施例一,在此不再赘述。
当然,为尽可能保证其他应用的资源需求,可以优先从多个容器工作节点中选取非空闲的内核的第三抽象计算力的迭加和大于容器所需的抽象计算力的节点作为第一容器工作节点,此时第一容器工作节点运行容器时由非空闲的内核工作。
当然,如果非空闲的内核的第三抽象计算力的迭加和大于容器所需的抽象计算力的节点为多个,则可以进一步从这些节点中随机或者按照一定条件(比如占用内核数量最少,再比如第三抽象计算力能够被容器所需的抽象计算力整除的内核最多,再比如第一抽象计算力最小等)选取某一节点作为第一容器工作节点。
2)如果待运行应用的配置参数中存在用于表征待运行应用由完全空闲的内核执行的参数,则表示该待运行应用的容器必须由完全空闲的内核执行。因此从多个容器工作节点中选取第一容器工作节点时,必须保证完全空闲的内核的第三抽象计算力(此时,第三抽象计算力等于第一抽象计算力)的迭加和大于容器所需的抽象计算力。其中,容器所需的抽象计算力是基于第二抽象计算力获得的,获得容器所需的抽象计算力的过程请参见上述实施例一,在此不再赘述。
当然,如果完全空闲的内核的第三抽象计算力的迭加和大于容器所需的抽象计算力的节点为多个,则可以进一步从这些节点中随机或者按照一定条件(比如占用内核数量少,再比如第三抽象计算力能够被容器所需的抽象计算力整除的内核最多,再比如第一抽象计算力最小等)选取某一节点作为第一容器工作节点。
为方便理解,以容器工作节点4和容器工作节点5为例进行说明:
容器工作节点4中有3个内核、内核1~内核3的第一抽象计算力为4、内核1~内核3的第三抽象计算力分别为4、4、3。容器工作节点5中有5个内核,内核1~内核5的第一抽象计算力为5、内核1~内核5的第三抽象计算力分别为5、5、5、2、3。
假设容器4所需的抽象计算力为14。可以看出,容器工作节点1的完全空闲的内核的第三抽象计算力的迭加和小于容器4所需的抽象计算力,也就是说,容器工作节点4无法运行容器4。而容器工作节点5的第三抽象计算力的迭加和大于容器4所需的抽象计算力,可以运行容器4。因此,可以将容器工作节点5作为运行容器4的第一容器工作节点。
再假设容器4所需的抽象计算力为5。可以看出,容器工作节点4和容器工作节点5均可以运行容器4。因此,可以从容器工作节点4和容器工作节点5中随机或者按照一定条件选取作为第一容器工作节点的节点。比如,筛选第三抽象计算力能够被容器所需的抽象计算力整除的内核最多的节点作为第一容器工作节点时,选取容器工作节点5作为运行容器4的第一容器工作节点。
由此可见,本申请提供的容器资源调度方法可以为待运行应用和容器工作节点之间统一计算力衡量单位,在容器编排调度时能够结合抽象计算力在节点间异构的容器工作节点和不同种类应用之间做出最佳匹配,从而减少甚至避免资源规则或浪费。
与上述容器资源调度方法对应的,本申请还公开了一种容器资源调度装置,如图7所示,容器资源调度装置包括:
第一获得模块10,用于获得多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力;其中,多个容器工作节点之间是异构的,多个容器工作节点中的每个容器工作节点包括多个内核,第一抽象计算力用于表征每个内核能够提供的用于执行待运行应用的最大物理资源。
第二获得模块20,用于获得待运行应用的第二抽象计算力;其中,第二抽象计算力用于表征执行待运行应用所需的物理资源。
确定模块30,用于至少基于第一抽象计算力和第二抽象计算力,从多个容器工作节点中确定用于执行待运行应用的第一容器工作节点。
由此可见,本申请提供的容器资源调度装置可以为待运行应用和容器工作节点之间统一计算力衡量单位,在容器编排调度时能够结合抽象计算力在节点间异构的容器工作节点和不同种类应用之间做出最佳匹配,从而减少甚至避免资源规则或浪费。
本申请公开的容器资源调度装置的另一个实施例中,第一获得模块10,具体用于:
获得参考工作节点中一个内核对应的针对待运行应用的标准指标参数;其中,标准指标参数用于表征参考工作节点中一个内核执行待运行应用的性能参数;获得多个容器工作节点中每个内核对应的针对待运行应用的初始指标参数;其中,初始指标参数用于表征多个容器工作节点中每个内核执行待运行应用的性能参数;基于标准指标参数对初始指标参数进行处理,得到多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力。
由此可见,本申请提供的容器资源调度装置可以利用内核的性能参数获得多个容器工作节点中每个内核针对待运行应用的第一抽象计算力,结合待运行应用的第二抽象计算力为待运行应用和容器工作节点之间统一计算力衡量单位, 在容器编排调度时能够结合抽象计算力在节点间异构的容器工作节点和不同种类应用之间做出最佳匹配,从而减少甚至避免资源规则或浪费。
本申请公开的容器资源调度装置的另一个实施例中,第二获得模块20,具体用于:
获得多个容器工作节点中指定容器工作节点执行待运行应用所需的内核数量;基于指定容器工作节点执行待运行应用所需的内核数量、以及指定容器工作节点中每个内核对应的第一抽象计算力,获得待运行应用的第二抽象计算力。
由此可见,本申请提供的容器资源调度装置可以利用指定容器工作节点获得待运行应用的第二抽象计算力,结合多个容器工作节点中每个内核针对待运行应用的第一抽象计算力为待运行应用和容器工作节点之间统一计算力衡量单位, 在容器编排调度时能够结合抽象计算力在节点间异构的容器工作节点和不同种类应用之间做出最佳匹配,从而减少甚至避免资源规则或浪费。
本申请公开的容器资源调度装置的另一个实施例中,确定模块30,具体用于:
基于第二抽象计算力获得待运行应用对应的容器所需的抽象计算力;基于容器所需的抽象计算力和第一抽象计算力的比值,从多个容器工作节点中确定第一容器工作节点。
由此可见,本申请提供的容器资源调度装置可以为待运行应用和容器工作节点之间统一计算力衡量单位,在容器编排调度时能够结合抽象计算力比值在节点间异构的容器工作节点和不同种类应用之间做出最佳匹配,从而减少甚至避免资源规则或浪费。
本申请公开的容器资源调度装置的另一个实施例中,确定模块30,具体用于:
基于第一抽象计算力获得多个容器工作节点中每个内核对应的针对待运行应用的第三抽象计算力;其中,第三抽象计算力用于表征每个内核能够提供的用于执行待运行应用的空闲物理资源;至少基于第二抽象计算力和第三抽象计算力,从多个容器工作节点中确定第一容器工作节点。
由此可见,本申请提供的容器资源调度装置可以为待运行应用和容器工作节点之间统一计算力衡量单位,在容器编排调度时能够结合抽象计算力在节点间异构的容器工作节点和不同种类应用之间做出最佳匹配,从而减少甚至避免资源规则或浪费。
需要说明的是,本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
为了描述的方便,描述以上系统或装置时以功能分为各种模块或单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
最后,还需要说明的是,在本文中,诸如第一、第二、第三和第四等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上所述仅是本申请的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。
Claims (20)
1.一种容器资源调度方法,所述方法包括:
获得多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力;其中,所述多个容器工作节点之间是异构的,所述多个容器工作节点中的每个容器工作节点包括多个内核,所述第一抽象计算力用于表征每个内核能够提供的用于执行所述待运行应用的最大物理资源;
获得所述待运行应用的第二抽象计算力;其中,所述第二抽象计算力用于表征执行所述待运行应用所需的物理资源;
至少基于所述第一抽象计算力和所述第二抽象计算力,从所述多个容器工作节点中确定用于执行所述待运行应用的第一容器工作节点。
2.根据权利要求1所述的方法,所述获得多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力,包括:
获得参考工作节点中一个内核对应的针对所述待运行应用的标准指标参数;其中,所述标准指标参数用于表征所述参考工作节点中一个内核执行所述待运行应用的性能参数;
获得所述多个容器工作节点中每个内核对应的针对所述待运行应用的初始指标参数;其中,所述初始指标参数用于表征所述多个容器工作节点中每个内核执行所述待运行应用的性能参数;
基于所述标准指标参数对所述初始指标参数进行处理,得到所述多个容器工作节点中每个内核对应的针对所述待运行应用的第一抽象计算力。
3.根据权利要求2所述的方法,所述基于所述标准指标参数对所述初始指标参数进行处理,得到所述多个容器工作节点中每个内核对应的针对所述待运行应用的第一抽象计算力,包括:
将所述初始指标参数与所述标准指标参数的比值作为所述多个容器工作节点中每个内核对应的针对所述待运行应用的第一抽象计算力。
4.根据权利要求1所述的方法,所述获得所述待运行应用的第二抽象计算力,包括:
获得参考工作节点执行所述待运行应用所需的内核数量;
基于所述参考工作节点执行所述待运行应用所需的内核数量,获得所述待运行应用的第二抽象计算力。
5.根据权利要求4所述的方法,所述基于所述参考工作节点执行所述待运行应用所需的内核数量,获得所述待运行应用的第二抽象计算力,包括:
将所述参考工作节点执行所述待运行应用所需的内核数量作为所述待运行应用的第二抽象计算力。
6.根据权利要求1所述的方法,所述获得所述待运行应用的第二抽象计算力,包括:
获得所述多个容器工作节点中指定容器工作节点执行所述待运行应用所需的内核数量;
基于所述指定容器工作节点执行所述待运行应用所需的内核数量、以及所述指定容器工作节点中每个内核对应的第一抽象计算力,获得所述待运行应用的第二抽象计算力。
7.根据权利要求6所述的方法,所述基于所述指定容器工作节点执行所述待运行应用所需的内核数量、以及所述指定容器工作节点中每个内核对应的第一抽象计算力,获得所述待运行应用的第二抽象计算力,包括:
将所述指定容器工作节点执行所述待运行应用所需的内核数量和所述指定容器工作节点中每个内核对应的第一抽象计算力的乘积作为所述待运行应用的第二抽象计算力。
8.根据权利要求1所述的方法,所述至少基于所述第一抽象计算力和所述第二抽象计算力,从所述多个容器工作节点中确定用于执行所述待运行应用的第一容器工作节点,包括:
基于所述第二抽象计算力获得所述待运行应用对应的容器所需的抽象计算力;
基于所述容器所需的抽象计算力和所述第一抽象计算力的比值,从所述多个容器工作节点中确定所述第一容器工作节点。
9.根据权利要求8所述的方法,所述基于所述容器所需的抽象计算力和所述第一抽象计算力的比值,从所述多个容器工作节点中确定所述第一容器工作节点,包括:
从所述多个容器工作节点中选取内核占用率最小的节点作为所述第一容器工作节点;其中,所述内核占用率是基于所述比值确定的。
10.根据权利要求1所述的方法,所述至少基于所述第一抽象计算力和所述第二抽象计算力,从所述多个容器工作节点中确定用于执行所述待运行应用的第一容器工作节点,包括:
基于所述第一抽象计算力获得所述多个容器工作节点中每个内核对应的针对所述待运行应用的第三抽象计算力;其中,所述第三抽象计算力用于表征每个内核能够提供的用于执行所述待运行应用的空闲物理资源;
至少基于所述第二抽象计算力和所述第三抽象计算力,从所述多个容器工作节点中确定所述第一容器工作节点。
11.根据权利要求10所述的方法,所述基于所述第一抽象计算力获得所述多个容器工作节点中每个内核对应的针对所述待运行应用的第三抽象计算力,包括:
获得所述多个容器工作节点中每个内核的可用率;
将所述可用率和所述第一抽象计算力的乘积作为所述多个容器工作节点中每个内核对应的针对所述待运行应用的第三抽象计算力。
12.根据权利要求10所述的方法,所述至少基于所述第二抽象计算力和所述第三抽象计算力,从所述多个容器工作节点中确定所述第一容器工作节点,包括:
基于所述第二抽象计算力获得所述待运行应用对应的容器所需的抽象计算力;
在所述待运行应用的配置参数中不存在用于表征所述待运行应用由完全空闲的内核执行的参数的情况下,从所述多个容器工作节点中选取非空闲的内核的所述第三抽象计算力的迭加和大于所述容器所需的抽象计算力的节点作为所述第一容器工作节点。
13.根据权利要求12所述的方法,所述至少基于所述第二抽象计算力和所述第三抽象计算力,从所述多个容器工作节点中确定所述第一容器工作节点,还包括:
在所述待运行应用的配置参数中存在用于表征所述待运行应用由完全空闲的内核执行的参数的情况下,从所述多个容器工作节点中选取完全空闲的内核的所述第三抽象计算力的迭加和大于所述容器所需的抽象计算力的节点作为所述第一容器工作节点。
14.根据权利要求1所述的方法,所述方法还包括:
获得用于至少扩容或者缩容的指令;
基于所述指令从所述多个容器工作节点中确定用于执行所述待运行应用的第二容器工作节点。
15.根据权利要求14所述的方法,所述指令是基于所述第一容器工作节点中用于执行所述待运行应用的每个内核的第四抽象计算力所生成的;其中,所述第四抽象计算力用于表征每个内核能够提供的用于执行所述待运行应用的实际物理资源。
16.一种容器资源调度装置,所述装置包括:
第一获得模块,用于获得多个容器工作节点中每个内核对应的针对待运行应用的第一抽象计算力;其中,所述多个容器工作节点之间是异构的,所述多个容器工作节点中的每个容器工作节点包括多个内核,所述第一抽象计算力用于表征每个内核能够提供的用于执行所述待运行应用的最大物理资源;
第二获得模块,用于获得所述待运行应用的第二抽象计算力;其中,所述第二抽象计算力用于表征执行所述待运行应用所需的物理资源;
确定模块,用于至少基于所述第一抽象计算力和所述第二抽象计算力,从所述多个容器工作节点中确定用于执行所述待运行应用的第一容器工作节点。
17.根据权利要求16所述的装置,所述第一获得模块,具体用于:
获得参考工作节点中一个内核对应的针对所述待运行应用的标准指标参数;其中,所述标准指标参数用于表征所述参考工作节点中一个内核执行所述待运行应用的性能参数;获得所述多个容器工作节点中每个内核对应的针对所述待运行应用的初始指标参数;其中,所述初始指标参数用于表征所述多个容器工作节点中每个内核执行所述待运行应用的性能参数;基于所述标准指标参数对所述初始指标参数进行处理,得到所述多个容器工作节点中每个内核对应的针对所述待运行应用的第一抽象计算力。
18.根据权利要求16所述的装置,所述第二获得模块,具体用于:
获得所述多个容器工作节点中指定容器工作节点执行所述待运行应用所需的内核数量;基于所述指定容器工作节点执行所述待运行应用所需的内核数量、以及所述指定容器工作节点中每个内核对应的第一抽象计算力,获得所述待运行应用的第二抽象计算力。
19.根据权利要求16所述的装置,所述确定模块,具体用于:
基于所述第二抽象计算力获得所述待运行应用对应的容器所需的抽象计算力;基于所述容器所需的抽象计算力和所述第一抽象计算力的比值,从所述多个容器工作节点中确定所述第一容器工作节点。
20.根据权利要求16所述的装置,所述确定模块,具体用于:
基于所述第一抽象计算力获得所述多个容器工作节点中每个内核对应的针对所述待运行应用的第三抽象计算力;其中,所述第三抽象计算力用于表征每个内核能够提供的用于执行所述待运行应用的空闲物理资源;至少基于所述第二抽象计算力和所述第三抽象计算力,从所述多个容器工作节点中确定所述第一容器工作节点。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910187002.9A CN109656723A (zh) | 2019-03-13 | 2019-03-13 | 容器资源调度方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910187002.9A CN109656723A (zh) | 2019-03-13 | 2019-03-13 | 容器资源调度方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN109656723A true CN109656723A (zh) | 2019-04-19 |
Family
ID=66123963
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910187002.9A Pending CN109656723A (zh) | 2019-03-13 | 2019-03-13 | 容器资源调度方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109656723A (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110231987A (zh) * | 2019-06-21 | 2019-09-13 | 深圳市网心科技有限公司 | 一种数据处理方法及相关装置 |
CN112199385A (zh) * | 2020-09-30 | 2021-01-08 | 北京百度网讯科技有限公司 | 用于人工智能ai的处理方法、装置、电子设备和存储介质 |
CN112631680A (zh) * | 2020-12-28 | 2021-04-09 | 南方电网数字电网研究院有限公司 | 微服务容器调度系统、方法、装置和计算机设备 |
CN114265703A (zh) * | 2022-03-02 | 2022-04-01 | 梯度云科技(北京)有限公司 | 云服务器跨区域算力调度方法、系统及设备 |
CN116991558A (zh) * | 2023-09-22 | 2023-11-03 | 苏州元脑智能科技有限公司 | 算力资源的调度方法及多架构集群、装置、存储介质 |
CN112199385B (zh) * | 2020-09-30 | 2024-05-10 | 北京百度网讯科技有限公司 | 用于人工智能ai的处理方法、装置、电子设备和存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105119952A (zh) * | 2015-07-07 | 2015-12-02 | 北京京东尚科信息技术有限公司 | 云平台下自动弹性地分配资源的方法和系统 |
CN105468362A (zh) * | 2015-11-17 | 2016-04-06 | 广州杰赛科技股份有限公司 | 应用部署方法和云计算系统 |
CN105677479A (zh) * | 2015-12-30 | 2016-06-15 | 北京奇艺世纪科技有限公司 | 并行运行gpu运算程序的实现方法及装置 |
CN107111519A (zh) * | 2014-11-11 | 2017-08-29 | 亚马逊技术股份有限公司 | 用于管理和调度容器的系统 |
-
2019
- 2019-03-13 CN CN201910187002.9A patent/CN109656723A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107111519A (zh) * | 2014-11-11 | 2017-08-29 | 亚马逊技术股份有限公司 | 用于管理和调度容器的系统 |
CN105119952A (zh) * | 2015-07-07 | 2015-12-02 | 北京京东尚科信息技术有限公司 | 云平台下自动弹性地分配资源的方法和系统 |
CN105468362A (zh) * | 2015-11-17 | 2016-04-06 | 广州杰赛科技股份有限公司 | 应用部署方法和云计算系统 |
CN105677479A (zh) * | 2015-12-30 | 2016-06-15 | 北京奇艺世纪科技有限公司 | 并行运行gpu运算程序的实现方法及装置 |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110231987A (zh) * | 2019-06-21 | 2019-09-13 | 深圳市网心科技有限公司 | 一种数据处理方法及相关装置 |
CN112199385A (zh) * | 2020-09-30 | 2021-01-08 | 北京百度网讯科技有限公司 | 用于人工智能ai的处理方法、装置、电子设备和存储介质 |
CN112199385B (zh) * | 2020-09-30 | 2024-05-10 | 北京百度网讯科技有限公司 | 用于人工智能ai的处理方法、装置、电子设备和存储介质 |
CN112631680A (zh) * | 2020-12-28 | 2021-04-09 | 南方电网数字电网研究院有限公司 | 微服务容器调度系统、方法、装置和计算机设备 |
CN114265703A (zh) * | 2022-03-02 | 2022-04-01 | 梯度云科技(北京)有限公司 | 云服务器跨区域算力调度方法、系统及设备 |
CN114265703B (zh) * | 2022-03-02 | 2022-05-20 | 梯度云科技(北京)有限公司 | 云服务器跨区域算力调度方法、系统及设备 |
CN116991558A (zh) * | 2023-09-22 | 2023-11-03 | 苏州元脑智能科技有限公司 | 算力资源的调度方法及多架构集群、装置、存储介质 |
CN116991558B (zh) * | 2023-09-22 | 2024-02-02 | 苏州元脑智能科技有限公司 | 算力资源的调度方法及多架构集群、装置、存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109656723A (zh) | 容器资源调度方法及装置 | |
CN109918198B (zh) | 一种基于用户特征预测的仿真云平台负载调度系统及方法 | |
CN107734052B (zh) | 面向组件依赖的负载均衡容器调度方法 | |
CN104050042B (zh) | Etl作业的资源分配方法及装置 | |
Goševa-Popstojanova et al. | Stochastic modeling formalisms for dependability, performance and performability | |
CN108920153A (zh) | 一种基于负载预测的Docker容器动态调度方法 | |
CN110740079B (zh) | 一种面向分布式调度系统的全链路基准测试系统 | |
CN107612886A (zh) | 一种Spark平台Shuffle过程压缩算法决策方法 | |
CN107562532B (zh) | 一种预测设备集群的硬件资源利用率的方法及装置 | |
CN103327072A (zh) | 一种集群负载均衡的方法及其系统 | |
CN109918182A (zh) | 虚拟化技术下的多gpu任务调度方法 | |
CN107402926A (zh) | 一种查询方法以及查询设备 | |
CN111752678A (zh) | 面向边缘计算中分布式协同学习的低功耗容器放置方法 | |
CN108509280A (zh) | 一种基于推送模型的分布式计算集群本地性调度方法 | |
CN114327829A (zh) | 一种多核实时任务调度分析与仿真系统及方法 | |
CN116700920A (zh) | 云原生混合部署集群资源调度方法及装置 | |
CN114356587A (zh) | 算力任务跨区域调度方法、系统及设备 | |
US20220300323A1 (en) | Job Scheduling Method and Job Scheduling Apparatus | |
CN100531070C (zh) | 网络资源调度仿真系统 | |
Ataie et al. | Modeling and evaluation of dispatching policies in IaaS cloud data centers using SANs | |
CN106649067B (zh) | 一种性能和能耗预测方法及装置 | |
CN111061547B (zh) | 一种异构系统的任务调度方法及系统 | |
US9111022B2 (en) | Simulation techniques for predicting in-memory database systems performance | |
Iglesias et al. | A methodology for online consolidation of tasks through more accurate resource estimations | |
WO2012026582A1 (ja) | シミュレーション装置、分散計算機システム、シミュレーション方法およびプログラム |
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 | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20190419 |
|
RJ01 | Rejection of invention patent application after publication |