CN114968566A - 一种面向共享式gpu集群下的容器调度方法及装置 - Google Patents
一种面向共享式gpu集群下的容器调度方法及装置 Download PDFInfo
- Publication number
- CN114968566A CN114968566A CN202210535352.1A CN202210535352A CN114968566A CN 114968566 A CN114968566 A CN 114968566A CN 202210535352 A CN202210535352 A CN 202210535352A CN 114968566 A CN114968566 A CN 114968566A
- Authority
- CN
- China
- Prior art keywords
- pod
- node
- gpu
- schedulable
- scheduled
- 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
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/5083—Techniques for rebalancing the load in a distributed system
-
- 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/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/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
-
- 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/45591—Monitoring or debugging support
-
- 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/45595—Network integration; Enabling network access in virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5021—Priority
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种面向共享式GPU集群下的容器调度方法及装置,获取Pod创建请求,根据Pod创建请求中Pod创建信息对Pod进行校验获得Pod标记,并根据Pod创建信息获取Pod总的所需资源信息;根据Pod创建信息中Pod业务优先级标签和Pod总的所需资源信息对Pod进行排序,获得调度队列队头的待调度Pod;根据待调度Pod的Pod创建信息中Pod所需的CPU标签、内存标签与GPU标签,Pod标记和集群节点状态信息,对节点进行过滤,获得Pod可调度节点;根据Pod可调度节点的数量和待调度Pod的Pod标记,计算Pod对应可调度节点的得分,根据得分待调度Pod匹配最优的Pod可调度节点。本发明提高任务处理效率及节点内资源的利用率。既考虑负载均衡,又提高资源利用率,且避免出现CPU、内存消耗不均衡。
Description
技术领域
本发明涉及一种面向共享式GPU集群下的容器调度方法及装置,属于集群调度技术领域。
背景技术
分布式计算集群Kubernetes(以下简称为k8s)下层节点主要由GPU(图像运算工作的微处理器,同CPU是重要的计算引擎)服务器构成,结合CPU、存储等为深度学***台在各行各业应用更加广泛,其对GPU计算资源也在逐渐增加。
分布式集群的容器调度需要基于当前业务指标需要及资源池状态分配调度容器,传统的K8s集群依靠GPU数量而非颗粒度的使用GPU实现共享,导致分布式集群调度针对复杂多样的计算场景及资源需求适配性能差;相关技术中,基于调度容器的需求选择最适配的节点进行容器调度,对调度队列及GPU资源打分处理不够合理,导致整个分布式集群任务分配效率降低与GPU资源利用率低问题,影响集群性能。
为解决多样化的计算业务中调度不合理、GPU资源利用率低的问题,本发明提出一种面向共享式GPU集群下的容器调度方法。
发明内容
目的:为了克服现有技术中存在的多样化的计算业务中调度不合理、GPU资源利用率低的问题,本发明提供一种面向共享式GPU集群下的容器调度方法及装置。
技术方案:为解决上述技术问题,本发明采用的技术方案为:
第一方面,一种面向共享式GPU集群下的容器调度方法,包括如下步骤:
获取Pod创建请求,根据Pod创建请求中Pod创建信息对Pod进行校验获得Pod标记,并根据Pod创建信息获取Pod总的所需资源信息。
根据Pod创建信息中Pod业务优先级标签和Pod总的所需资源信息对Pod进行排序,获得调度队列队头的待调度Pod。
根据待调度Pod的Pod创建信息中Pod所需的CPU标签、内存标签与GPU标签,Pod标记和集群节点状态信息,对节点进行过滤,获得Pod可调度节点。
根据Pod可调度节点的数量和待调度Pod的Pod标记,计算Pod对应可调度节点的得分,根据得分待调度Pod匹配最优的Pod可调度节点。
第二方面,一种面向共享式GPU集群下的容器调度装置,包括如下模块:
Pod标记及资源信息获取模块,用于获取Pod创建请求,根据Pod创建请求中Pod创建信息对Pod进行校验获得Pod标记,并根据Pod创建信息获取Pod总的所需资源信息。
Pod排序模块,用于根据Pod创建信息中Pod业务优先级标签和Pod总的所需资源信息对Pod进行排序,获得调度队列队头的待调度Pod。
Pod可调度节点获取模块,用于根据待调度Pod的Pod创建信息中Pod所需的CPU标签、内存标签与GPU标签,Pod标记和集群节点状态信息,对节点进行过滤,获得Pod可调度节点。
最佳节点获取模块,用于根据Pod可调度节点的数量和待调度Pod的Pod标记,计算Pod对应可调度节点的得分,根据得分待调度Pod匹配最优的Pod可调度节点。
作为优选方案,所述获取Pod创建请求,根据Pod创建请求中Pod创建信息对Pod进行校验获得Pod标记,并根据Pod创建信息获取Pod总的所需资源信息,包括:
获取Pod创建请求中Pod创建信息的GPU标签,若Pod不包含GPU标签,则Pod标记为非需求GPU资源Pod;若Pod包含GPU标签,则Pod标记为需要GPU资源Pod。
根据Pod创建信息的各个容器运行所需的资源信息,对所有容器中同类资源进行累加,得出Pod总的所需资源信息。
作为优选方案,所述Pod总的所需资源信息包括:GUP资源申请量、CPU资源申请量、内存资源申请量、GPU显存申请量。
作为优选方案,所述根据Pod创建信息中Pod业务优先级标签和Pod总的所需资源信息对Pod进行排序,获得调度队列队头的待调度Pod,包括:
根据Pod业务优先级标签数值对Pod进行从高到底排序。
如果n个待调度Pod中存在m个Pod之间Pod业务优先级标签数值差小于预设阈值,m<n,对m个Pod筛选GPU资源申请量,将GPU资源申请量少的Pod优先排序。
如果GPU资源申请量相同时,筛选CPU资源申请量,将CPU资源申请量少的Pod优先排序。
如果CPU资源申请量相同时,筛选内存资源申请量,将内存资源申请量少的Pod优先排序。
如果GPU、CPU、内存资源申请量都相同,不变动排序顺序。
排序最高的Pod为调度队列队头的待调度Pod。
作为优选方案,所述根据待调度Pod的Pod创建信息中Pod所需的CPU标签、内存标签与GPU标签,Pod标记和集群节点状态信息,对节点进行过滤,获得Pod可调度节点,包括:
获取待调度Pod的Pod所需的CPU标签、内存标签与GPU标签。
获取当前集群下所有节点状态,并获取空闲节点资源信息,空闲节点资源信息包括:节点所持有的CPU时钟频率、CPU使用率、可用内存、GPU核心数、GPU时钟频率、GPU使用率。
遍历集群中的所有空闲节点,当节点所持有的CPU时钟频率大于待调度Pod的CPU时钟频率标签值时,则将该节点标记为可调度节点,节点可调度标签值标记为1,否则标记为0。
遍历所有可调度节点标签值为1的节点,当节点所持有的可用内存值大于待调度Pod的内存标签值,则持续将该节点可调度标签值标记为1,否则将其标记为0。
若待调度Pod为非需求GPU资源Pod,则将所有可调度节点标签值为1的节点作为Pod可调度节点。
若待调度Pod为需求GPU资源Pod,则遍历所有可调度节点标签值为1的节点,当节点所持有的GPU核心数大于GPU数量标签值,且节点GPU可用显存总值大于GPU显存标签值时,将节点作为Pod可调度节点。
作为优选方案,还包括:
检查所有Pod可调度节点的请求卷和节点上其他Pod使用的卷是否冲突,如果存在冲突,则过滤该Pod可调度节点。
作为优选方案,所述根据Pod可调度节点的数量和待调度Pod的Pod标记,计算Pod对应可调度节点的得分,根据得分待调度Pod匹配最优的Pod可调度节点,包括:
当Pod可调度节点数量等于1,将该可调度节点作为最佳节点。
当Pod可调度节点数量大于1,若待调度Pod的Pod标记为非需要GPU资源Pod,计算非需求GPU资源Pod对应可调度节点的得分Score1,选择得分最高节点作为最佳节点,并将待调度Pod与最佳节点进行绑定。
非需求GPU资源Pod对应可调度节点的得分Score1计算公式如下:
当Pod可调度节点数量大于1,若待调度Pod的Pod标记为需要GPU资源Pod,计算需求GPU资源Pod对应可调度节点的得分Score2,选择得分最高节点作为最佳节点,并将待调度Pod与最佳节点进行绑定。
需求GPU资源Pod对应可调度节点的得分Score2计算公式如下:
其中,表示为可调度节点中每个GPU得分之和,表示可调度节点GPU时钟频率,表示可调度节点中满足待调度Pod请求的所有GPU中时钟频率最大值,表示可调度节点GPU功率,表示可调度节点中满足待调度Pod请求的所有GPU中功率最大值,表示可调度节点中每个GPU的空闲显存,表示可调度节点中所有空闲显存总量,表示可调度节点GPU显存总量,表示可调度节点中满足待调度Pod请求的显存总量。
其中,2为CPU、内存资源均衡第二得分,表示为可调度节点CPU空闲度,表示为可调度节点内存空闲度,表示为可调度节点CPU资源最大容量,表示为待调度Pod的CPU申请总量,表示为可调度节点内存资源最大容量,表示为待调度Pod的内存申请总量。
作为优选方案,如果最佳节点为多个,随机选择一个最佳节点与待调度Pod进行绑定。
作为优选方案,所述根据Pod可调度节点的数量和待调度Pod的Pod标记,计算Pod对应可调度节点的得分,根据得分待调度Pod匹配最优的Pod可调度节点,包括:
当pod可调度节点数量为0,将调度失败时间和对应的待调度Pod信息写入事件日志,并重新选取调度队列队头Pod,并将调度失败的Pod重新放入待调度队列。
有益效果:本发明提供的一种面向共享式GPU集群下的容器调度方法及装置,在分布式集群下对Pod创建事件的监听、所需资源进行筛选、检验时,依据任务属性打上标签,后续节点打分依照标签属性使用不同的打分标准,按照最后的结果对其分配适合的节点,使得非需要GPU资源的Pod可以优先分配至GPU资源缺乏的节点,提升节点各资源的利用率,达到负载均衡。其优点如下:
1、针对调度队列排列问题,在业务优先级排列中引入申请资源量阈值进行二次排序,以避免集群节点上GPU、CPU等资源被优先级预设高的Pod长时间占用,从而避免业务优先级低的Pod长时间等待,提高任务处理效率及节点内资源的利用率。
2、针对Pod创建后进入调度队列进行调度中,对所有Pod使用同种打分机制进行节点分配,面向共享式GPU集群下,将非需求GPU资源Pod优先放在CPU与内存资源空闲、GPU空闲资源较少的节点,便于其他需要GPU的Pod更好的选择最佳节点,既考虑负载均衡,又提高资源利用率,且避免出现CPU、内存消耗不均衡。
附图说明
图1为本发明中调度方法的***拓扑图。
图2为本发明中调度方法的步骤流程图。
图3为本发明中调度方法的调度队列更新流程图。
图4为本发明中调度方法的节点过滤与选择操作流程图。
具体实施方式
下面结合具体实施例对本发明作更进一步的说明。
本发明为实现上述发明目的采用如下技术方案。
如图1所示,本发明的执行调度方法的***包括:etcd、Master API-Server、***、调度器和执行器,etcd是高可用的键值存储***,用于存储所有需要持久化的数据。Master API-Server是K8s中云端的master节点。***用于监听Pod创建事件。调度器用于承载集群资源的调度功能,根据特定的调度算法及策略将Pod调度到指定节点上。执行器用于执行绑定好节点的Pod,将其运行在绑定的节点上。
如图2所示,一种面向共享式GPU集群下的容器调度方法,包括如下步骤:
(1)获取Pod创建请求,根据Pod创建请求中Pod创建信息对Pod进行校验获得Pod标记,并根据Pod创建信息获取Pod总的所需资源信息。
(2)根据Pod创建信息中Pod业务优先级标签和Pod总的所需资源信息对Pod进行排序,获得调度队列队头的待调度Pod。
(3)根据待调度Pod的Pod创建信息中Pod所需的CPU标签、内存标签与GPU标签,Pod标记和集群节点状态信息,对节点进行过滤,获得Pod可调度节点。
(4)根据Pod可调度节点的数量和待调度Pod的Pod标记,计算Pod对应可调度节点的得分,根据得分待调度Pod匹配最优的Pod可调度节点。
优选的,所述步骤(1)具体步骤如下:
(1-1):通过Master API-Server实时监听服务器中Pod创建请求,用户可以通过kubectl(命令行)向Master API-Server发送请求创建所需Pod,创建前用户可根据任务需求创建Yaml文件,并对Yaml文件中Pod创建信息进行配置,Pod创建信息包括:Pod镜像名、Pod调度任务优先级标签、启动命令、启动参数、Pod所需的CPU标签、内存标签与GPU标签,其中GPU标签包括GPU数量标签、GPU显存标签、GPU时钟频率标签;当监听到新的Pod创建请求后,通过Yaml文件获取该Pod创建信息,并根据Pod创建信息对Pod进行校验,获得Pod标记。根据Pod创建信息获取Pod总的所需资源信息,并将Pod标记与Pod总的所需资源信息进行存储,以此对后续节点打分作为依据。
(1-2):对创建的Pod进行校验和获取Pod总的所需资源信息,其具体过程如下:
判断Pod中是否包含GPU标签:若Pod不包含GPU标签,则代表Pod所需环境不需要GPU资源,将此Pod标记为非需求GPU资源Pod;若Pod包含GPU标签,则代表Pod所需环境需要GPU资源,将Pod标记为需要GPU资源Pod。
根据Pod创建信息获取所包含的各个容器运行所需的资源信息,如CPU数量、运行内存、GPU数量、GPU显存、GPU时钟频率,并对Pod内所有容器中同类资源进行累加,得出此Pod总的所需资源信息,包括GUP资源申请量、CPU资源申请量、内存资源申请量、GPU显存申请量。
(1-3):存储校验结果和Pod总的所需资源信息,为后续节点打分并分配节点提供依据。
如图3所示,优选的,所述步骤(2)具体步骤如下:
(2-1)将步骤(1)中校验后的Pod送入调度队列Scheduling queue中,生成新的调度队列,并进行调度队列更新。
(2-2)获取当前队列信息,获取新送入的Pod业务优先级标签,根据当前调度队列中每个Pod业务优先级标签数值进行从高到底排序,如果n个待调度Pod中存在m个Pod之间Pod业务优先级标签数值差小于预设阈值,则根据Pod总的所需资源信息,包括GPU、CPU、内存资源申请量大小进行进一步的排序:筛选GPU资源申请量,将GPU资源申请量最少的Pod优先排序;当GPU资源申请量相同时,筛选CPU资源申请量,将CPU资源申请量最少的Pod优先排序;当CPU资源申请量相同时,筛选内存资源申请量,将内存资源申请量最少的Pod优先排序;如果GPU、CPU、内存资源申请量都相同,不变动排序顺序。以此避免Pod业务优先级高的Pod不断进入队列并排到队头,导致低优先级Pod长时间等待,使得集群GPU资源被业务优先级预设过高的Pod长时间占用,影响节点内资源的负载均衡,从而提高任务处理效率及节点内资源的利用率。
如图4所示,所述步骤(3)具体步骤如下:
(3-1)实时监听调度队列是否为空,当调度队列不为空时,读取队列队头的待调度Pod,将该Pod送入调度器中,并获取Pod所需的CPU标签、内存标签与GPU标签。
(3-2)向Master API-Server发起集群节点状态请求,获取当前Kubernetes集群下所有节点状态,并获取空闲节点资源信息,包括:节点所持有的CPU时钟频率、CPU使用率、可用内存、GPU核心数、GPU时钟频率、GPU使用率(即GPU显存总量与可用显存总量)。
(3-3)根据待调度Pod所携带标签信息及集群节点状态信息进行节点过滤,获取符合待调度Pod运行的节点,具体包括以下4个步骤:
S301:根据CPU时钟频率标签进行节点筛选:遍历集群中的所有空闲节点,当节点所持有的CPU时钟频率大于待调度Pod的CPU时钟频率标签值时,则将该节点标记为可调度节点,节点可调度标签值标记为1,否则标记为0;
S302:在S301基础上根据内存标签进行节点筛选:遍历S301过滤后的所有可调度节点标签值为1的节点,当节点所持有的可用内存值大于待调度Pod的运行内存标签值,则持续将该节点可调度标签值标记为1,否则将其标记为0;
S303:在S302基础上根据校验结果、GPU数量标签值和GPU显存标签值进行节点筛选:若待调度Pod为非需求GPU资源Pod,则将S302过滤后的所有可调度节点标签值仍为1的节点作为Pod可调度节点;若待调度Pod为需求GPU资源Pod,则遍历S302过滤后的所有可调度节点标签值仍为1的节点,当节点所持有的GPU核心数大于GPU数量标签值,且节点可用GPU显存值大于GPU显存标签值时,将节点作为Pod可调度节点。
S304:在S303基础上筛选出的所有Pod可调度节点,使用NoDiskConflict检查Pod请求卷和节点上其他Pod使用的卷是否冲突,如果存在冲突,则过滤该Pod可调度节点。
所述步骤(4)具体步骤如下::
(4-1)根据步骤(3-3)筛选后Pod可调度节点的数量,对Pod可调度节点进一步进行选择。
S401:当pod可调度节点数量为0,将调度失败时间和对应的Pod信息写入事件日志,并重新选取待调度队列队头Pod并将调度失败的Pod重新放入待调度队列,重复步骤(3-1)至(3-3)过滤出可调度节点。
S402:当Pod可调度节点数量等于1,将该可调度节点作为最佳节点。
S403:当Pod可调度节点数量大于1,基于校验结果和Pod总的所需资源信息计算每个可调度节点的得分,选取最高得分节点作为最佳节点。
(4-2)若步骤S403中得分最高的节点不唯一,则随机选取一个得分最高的节点作为最佳节点,将待调度Pod与最佳节点进行绑定。使得非需要GPU资源的Pod可以优先分配至GPU资源缺乏的节点,提升节点各资源的利用率,达到负载均衡;并重复上述步骤直至待调度队列为空。
步骤S403中筛选出的可调度节点进行打分,选择得分最高节点作为最佳节点,并将Pod与最佳节点进行绑定,完成Pod调度。
所述打分具体考虑集群负载均衡情况,节点得分主要基于待调度Pod是否使用共享式GPU资源、节点GPU得分以及CPU与内存得分,具体步骤如下:
根据S101中标记的Pod类别对当前可调度节点进行打分,若标记为非需要GPU资源Pod,则节点不需要GPU资源,对可调度节点打分主要分为2个部分:1、CPU、内存资源均衡得分;2、GPU空闲率得分;若标记为需要GPU资源Pod则节点需要共享式GPU资源,对可调度节点打分主要分为3个部分:1、节点内GPU得分;2、Pod配额得分;3、节点CPU、内存资源得分。
S411:在共享式GPU集群下GPU使用率会比其他集群高,而CPU与内存使用率相对较低;将非需要GPU资源Pod优先放在CPU与内存资源空闲、GPU空闲资源较少的节点,便于其他需要GPU的Pod可以更好的选择最佳节点,既考虑了负载均衡,又提高了资源利用率,且避免出现CPU、内存消耗不均衡。其得分主要分为2个部分:1、第一CPU、内存资源均衡得分;2、GPU空闲率得分。
CPU、内存资源均衡第一得分的计算公式如下:
GPU空闲率得分计算公式如下:
满足非需求GPU资源Pod对应可调度节点的得分Score1计算公式如下:
S412:满足需要GPU资源Pod对应可调度节点的得分主要分为3个部分:1、节点内GPU得分;2、Pod配额得分;3、CPU、内存资源均衡第二得分。
节点内GPU得分的计算公式如下:
其中,表示为可调度节点中每个GPU得分之和,表示可调度节点GPU时钟频率,表示可调度节点中满足待调度Pod请求的所有GPU中时钟频率最大值,表示可调度节点GPU功率,表示可调度节点中满足待调度Pod请求的所有GPU中功率最大值,表示可调度节点中每个GPU的空闲显存,表示可调度节点中所有空闲显存总量,表示可调度节点GPU显存申请量,表示可调度节点中满足待调度Pod请求的显存总量。
Pod配额得分的计算公式如下:
节点CPU、内存资源均衡第二得分的计算公式如下:
其中,2为CPU、内存资源均衡第二得分,表示为可调度节点CPU空闲度,表示为可调度节点内存空闲度,表示为可调度节点CPU资源最大容量,表示为待调度Pod的CPU申请总量,表示为可调度节点内存资源最大容量,表示为待调度Pod的内存资源申请总量。
需要GPU资源Pod对应可调度节点的得分Score2计算公式如下:
实施实例一:
构建待调度队列,其存在待调度任务Pod1-Pod4,且其Pod调度任务优先级标签数值分别为Pod1:10000;Pod2:9500;Pod3:14000;Pod4:9200;预设阈值为1000;向队尾增加校验结束的调度任务Pod5,其Pod调度任务优先级标签数值为12500。
步骤1:获取调度队列信息,获取Pod5的Pod调度任务优先级标签数值,根据当前调度队列中每个Pod预设的Pod调度任务优先级标签数值进行从高到底排序,则其排序为Pod3→Pod5→Pod1→Pod2→Pod4。
步骤2:获取预设阈值1000,得到二次排列调度任务Pod1、Pod2、Pod4,根据其校验结果和记录的所申请的资源,进行进一步的排序,参见表1,为Pod1、Pod2、Pod4的申请资源情况:
Pod标号 | GPU资源 | CPU资源 | 内存资源 |
Pod1 | 1m | 2m | 2Gi |
Pod2 | 0.5m | 2m | 512Mi |
Pod4 | 1m | 1m | 1Gi |
表1为待调度Pod资源申请总量
步骤3:根据表1中各Pod申请资源情况进行重新排序:由表1可知Pod2的GPU资源申请量最小,Pod1、Pod4申请量相同,则将Pod2排在Pod1、Pod4之前;比较Pod1、Pod4申请的CPU资源量,可知Pod4的CPU资源申请量最小,则将Pod4排在Pod1之前。基于二次排序最新的业务优先级排序为:Pod3→Pod5→Pod2→Pod4→Pod1。
实施实例二:
构建待调度队列,其存在待调度任务Pod1-Pod4,且其Pod调度任务优先级标签数值分别为Pod1:10000;Pod2:9500;Pod3:14000;Pod4:9200;预设阈值为1000;向队尾增加校验成功的调度任务Pod5,其Pod调度任务优先级标签数值为12500。
步骤1:获取调度队列信息,获取Pod5的Pod调度任务优先级标签数值,根据当前调度队列中每个Pod预设的Pod调度任务优先级标签数值进行从高到底排序,则其排序为Pod3→Pod5→Pod1→Pod2→Pod4;
步骤2:获取预设阈值1000,得到二次排列调度任务Pod1、Pod2、Pod4,根据其校验过程记录所申请的资源进行进一步的排序,参见表2,为Pod1、Pod2、Pod4的申请资源情况:
Pod标号 | GPU资源 | CPU资源 | 内存资源 |
Pod1 | 1m | 2m | 2Gi |
Pod2 | 0.5m | 1m | 1Gi |
Pod4 | 0.5m | 1m | 512Mi |
表2为待调度Pod资源申请总量
步骤3:根据表2中各Pod申请资源情况进行重新排序:由表2可知Pod1的GPU资源申请量最大,Pod2、Pod4申请量相同,则将Pod2、Pod4排在Pod1之前;比较Pod2、Pod4申请的CPU资源量,可知其CPU申请量相同;再比较Pod2、Pod4申请的内存资源量,可知Pod4申请的内存资源最小,则将Pod4排在Pod2之前。基于二次排序最新的业务优先级排序为:Pod3→Pod5→Pod4→Pod2→Pod1。
实施实例三:
在共享式GPU集群下,根据预设的yaml文件申请一个无需GPU资源的Pod。
步骤1:Master API-Server监听到Pod创建请求,获取该Pod创建的所有信息,并进行Pod的校验并将所需资源信息进行存储;校验得知Pod不包含GPU标签,为其添加是否需要GPU资源的属性标签并置0,表示此Pod不需要GPU资源。
步骤2:将步骤1中校验成功的Pod送入调度队列,通过预设Pod调度任务优先级标签及阈值进行二次排序(此处排序参考实施实例一、二)。
步骤3:实时监听调度队列是否为空,当调度队列不为空时,读取队列队头的待调度Pod,将该Pod送入调度器中;获取当前Kubernetes集群下所有节点状态,并获取空闲节点资源信息,根据送入的Pod标签信息及集群节点状态信息过滤不符合Pod运行的节点。
步骤4:当容器可调度节点数量为0,将调度失败时间和对应的Pod信息写入事件日志,并重新选取待调度队列队首Pod并将调度失败的Pod重新放入待调度队列;当容器可调度节点数量等于1,将该可调度节点作为最佳节点;当容器可调度节点数量大于1,基于Pod标签信息及节点资源情况计算每个可调度节点的得分。
步骤5:根据步骤1所添加的标签得知此Pod不需要GPU资源,故使用以下公式进行对各节点进行打分:
步骤6:根据步骤5得分情况,选取最高得分节点作为最佳节点;若最高得分的节点不唯一,则随机选取一个节点作为最佳节点,将待调度Pod与最佳节点进行绑定。
实施实例四:
在共享式GPU集群下,根据预设的yaml文件申请一个需要GPU资源的Pod。
步骤1:Master API-Server监听到Pod创建请求,获取该Pod创建的所有信息,并进行Pod的校验并将所需资源信息进行存储;校验得知Pod包含GPU标签,为其添加是否需要GPU资源的属性标签并置1,表示此Pod需要GPU资源。
步骤2:将步骤1中校验成功的Pod送入调度队列,通过预设Pod调度任务优先级标签及阈值进行二次排序(此处排序参考实施实例一、二)。
步骤3:实时监听调度队列是否为空,当调度队列不为空时,读取队列队头的待调度Pod,将该Pod送入调度器中;获取当前Kubernetes集群下所有节点状态,并获取空闲节点资源信息,根据送入的Pod标签信息及集群节点状态信息过滤不符合Pod运行的节点。
步骤4:当容器可调度节点数量为0,将调度失败时间和对应的Pod信息写入事件日志,并重新选取待调度队列队首Pod并将调度失败的Pod重新放入待调度队列;当容器可调度节点数量等于1,将该可调度节点作为最佳节点;当容器可调度节点数量大于1,基于Pod标签信息及节点资源情况计算每个可调度节点的得分。
步骤5:根据步骤1所添加的标签得知此Pod需要GPU资源,故使用以下公式进行对各节点进行打分:
步骤6:根据步骤5得分情况,选取最高得分节点作为最佳节点;若最高得分的节点不唯一,则随机选取一个节点作为最佳节点,将待调度Pod与最佳节点进行绑定。
本领域内的技术人员应明白,本发明的实施例可提供为方法、***、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上所述仅是本发明的优选实施方式,应当指出:对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。
Claims (10)
1.一种面向共享式GPU集群下的容器调度方法,其特征在于:包括如下步骤:
获取Pod创建请求,根据Pod创建请求中Pod创建信息对Pod进行校验获得Pod标记,并根据Pod创建信息获取Pod总的所需资源信息;
根据Pod创建信息中Pod业务优先级标签和Pod总的所需资源信息对Pod进行排序,获得调度队列队头的待调度Pod;
根据待调度Pod的Pod创建信息中Pod所需的CPU标签、内存标签与GPU标签,Pod标记和集群节点状态信息,对节点进行过滤,获得Pod可调度节点;
根据Pod可调度节点的数量和待调度Pod的Pod标记,计算Pod对应可调度节点的得分,根据得分待调度Pod匹配最优的Pod可调度节点。
2.根据权利要求1所述的一种面向共享式GPU集群下的容器调度方法,其特征在于:所述获取Pod创建请求,根据Pod创建请求中Pod创建信息对Pod进行校验获得Pod标记,并根据Pod创建信息获取Pod总的所需资源信息,包括:
获取Pod创建请求中Pod创建信息的GPU标签,若Pod不包含GPU标签,则Pod标记为非需求GPU资源Pod;若Pod包含GPU标签,则Pod标记为需要GPU资源Pod;
根据Pod创建信息的各个容器运行所需的资源信息,对所有容器中同类资源进行累加,得出Pod总的所需资源信息。
3.根据权利要求2所述的一种面向共享式GPU集群下的容器调度方法,其特征在于:所述Pod总的所需资源信息包括:GUP资源申请量、CPU资源申请量、内存资源申请量、GPU显存申请量。
4.根据权利要求1所述的一种面向共享式GPU集群下的容器调度方法,其特征在于:所述根据Pod创建信息中Pod业务优先级标签和Pod总的所需资源信息对Pod进行排序,获得调度队列队头的待调度Pod,包括:
根据Pod业务优先级标签数值对Pod进行从高到底排序;
如果n个待调度Pod中存在m个Pod之间Pod业务优先级标签数值差小于预设阈值,m<n,对m个Pod筛选GPU资源申请量,将GPU资源申请量少的Pod优先排序;
如果GPU资源申请量相同时,筛选CPU资源申请量,将CPU资源申请量少的Pod优先排序;
如果CPU资源申请量相同时,筛选内存资源申请量,将内存资源申请量少的Pod优先排序;
如果GPU、CPU、内存资源申请量都相同,不变动排序顺序;
排序最高的Pod为调度队列队头的待调度Pod。
5.根据权利要求1所述的一种面向共享式GPU集群下的容器调度方法,其特征在于:所述根据待调度Pod的Pod创建信息中Pod所需的CPU标签、内存标签与GPU标签,Pod标记和集群节点状态信息,对节点进行过滤,获得Pod可调度节点,包括:
获取待调度Pod的Pod所需的CPU标签、内存标签与GPU标签;
获取当前集群下所有节点状态,并获取空闲节点资源信息,空闲节点资源信息包括:节点所持有的CPU时钟频率、CPU使用率、可用内存、GPU核心数、GPU时钟频率、GPU使用率;
遍历集群中的所有空闲节点,当节点所持有的CPU时钟频率大于待调度Pod的CPU时钟频率标签值时,则将该节点标记为可调度节点,节点可调度标签值标记为1,否则标记为0;
遍历所有可调度节点标签值为1的节点,当节点所持有的可用内存值大于待调度Pod的内存标签值,则持续将该节点可调度标签值标记为1,否则将其标记为0;
若待调度Pod为非需求GPU资源Pod,则将所有可调度节点标签值为1的节点作为Pod可调度节点;
若待调度Pod为需求GPU资源Pod,则遍历所有可调度节点标签值为1的节点,当节点所持有的GPU核心数大于GPU数量标签值,且节点GPU可用显存总值大于GPU显存标签值时,将节点作为Pod可调度节点。
6.根据权利要求5所述的一种面向共享式GPU集群下的容器调度方法,其特征在于:还包括:
检查所有Pod可调度节点的请求卷和节点上其他Pod使用的卷是否冲突,如果存在冲突,则过滤该Pod可调度节点。
7.根据权利要求1所述的一种面向共享式GPU集群下的容器调度方法,其特征在于:所述根据Pod可调度节点的数量和待调度Pod的Pod标记,计算Pod对应可调度节点的得分,根据得分待调度Pod匹配最优的Pod可调度节点,包括:
当Pod可调度节点数量等于1,将该可调度节点作为最佳节点;
当Pod可调度节点数量大于1,若待调度Pod的Pod标记为非需要GPU资源Pod,计算非需求GPU资源Pod对应可调度节点的得分Score1,选择得分最高节点作为最佳节点,并将待调度Pod与最佳节点进行绑定;
非需求GPU资源Pod对应可调度节点的得分Score1计算公式如下:
当Pod可调度节点数量大于1,若待调度Pod的Pod标记为需要GPU资源Pod,计算需求GPU资源Pod对应可调度节点的得分Score2,选择得分最高节点作为最佳节点,并将待调度Pod与最佳节点进行绑定;
需求GPU资源Pod对应可调度节点的得分Score2计算公式如下:
其中,表示为可调度节点中每个GPU得分之和,表示可调度节点GPU时钟频率,表示可调度节点中满足待调度Pod请求的所有GPU中时钟频率最大值,表示可调度节点GPU功率,表示可调度节点中满足待调度Pod请求的所有GPU中功率最大值,表示可调度节点中每个GPU的空闲显存,表示可调度节点中所有空闲显存总量,表示可调度节点GPU显存总量,表示可调度节点中满足待调度Pod请求的显存总量;
8.根据权利要求7所述的一种面向共享式GPU集群下的容器调度方法,其特征在于:如果最佳节点为多个,随机选择一个最佳节点与待调度Pod进行绑定。
9.根据权利要求7所述的一种面向共享式GPU集群下的容器调度方法,其特征在于:所述根据Pod可调度节点的数量和待调度Pod的Pod标记,计算Pod对应可调度节点的得分,根据得分待调度Pod匹配最优的Pod可调度节点,包括:
当pod可调度节点数量为0,将调度失败时间和对应的待调度Pod信息写入事件日志,并重新选取调度队列队头Pod,并将调度失败的Pod重新放入待调度队列。
10.一种面向共享式GPU集群下的容器调度装置,其特征在于:包括如下模块:
Pod标记及资源信息获取模块,用于获取Pod创建请求,根据Pod创建请求中Pod创建信息对Pod进行校验获得Pod标记,并根据Pod创建信息获取Pod总的所需资源信息;
Pod排序模块,用于根据Pod创建信息中Pod业务优先级标签和Pod总的所需资源信息对Pod进行排序,获得调度队列队头的待调度Pod;
Pod可调度节点获取模块,用于根据待调度Pod的Pod创建信息中Pod所需的CPU标签、内存标签与GPU标签,Pod标记和集群节点状态信息,对节点进行过滤,获得Pod可调度节点;
最佳节点获取模块,用于根据Pod可调度节点的数量和待调度Pod的Pod标记,计算Pod对应可调度节点的得分,根据得分待调度Pod匹配最优的Pod可调度节点。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210535352.1A CN114968566A (zh) | 2022-05-17 | 2022-05-17 | 一种面向共享式gpu集群下的容器调度方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210535352.1A CN114968566A (zh) | 2022-05-17 | 2022-05-17 | 一种面向共享式gpu集群下的容器调度方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114968566A true CN114968566A (zh) | 2022-08-30 |
Family
ID=82983617
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210535352.1A Pending CN114968566A (zh) | 2022-05-17 | 2022-05-17 | 一种面向共享式gpu集群下的容器调度方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114968566A (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115460075A (zh) * | 2022-09-14 | 2022-12-09 | 深圳前海环融联易信息科技服务有限公司 | 基于云原生的多网络模式实现方法、装置、设备及介质 |
CN117112239A (zh) * | 2023-10-23 | 2023-11-24 | 合肥综合性国家科学中心人工智能研究院(安徽省人工智能实验室) | 一种异构推理后端上的可扩展负载均衡方法及*** |
CN117170811A (zh) * | 2023-09-07 | 2023-12-05 | 中国人民解放军国防科技大学 | 一种基于volcano的节点分组作业调度方法及*** |
CN118069379A (zh) * | 2024-04-24 | 2024-05-24 | 麒麟软件有限公司 | 一种基于gpu资源的调度实现方法 |
WO2024119930A1 (zh) * | 2022-12-07 | 2024-06-13 | 京东科技信息技术有限公司 | 调度方法、装置、计算机设备和存储介质 |
-
2022
- 2022-05-17 CN CN202210535352.1A patent/CN114968566A/zh active Pending
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115460075A (zh) * | 2022-09-14 | 2022-12-09 | 深圳前海环融联易信息科技服务有限公司 | 基于云原生的多网络模式实现方法、装置、设备及介质 |
WO2024119930A1 (zh) * | 2022-12-07 | 2024-06-13 | 京东科技信息技术有限公司 | 调度方法、装置、计算机设备和存储介质 |
CN117170811A (zh) * | 2023-09-07 | 2023-12-05 | 中国人民解放军国防科技大学 | 一种基于volcano的节点分组作业调度方法及*** |
CN117112239A (zh) * | 2023-10-23 | 2023-11-24 | 合肥综合性国家科学中心人工智能研究院(安徽省人工智能实验室) | 一种异构推理后端上的可扩展负载均衡方法及*** |
CN117112239B (zh) * | 2023-10-23 | 2024-02-09 | 合肥综合性国家科学中心人工智能研究院(安徽省人工智能实验室) | 一种异构推理后端上的可扩展负载均衡方法及*** |
CN118069379A (zh) * | 2024-04-24 | 2024-05-24 | 麒麟软件有限公司 | 一种基于gpu资源的调度实现方法 |
CN118069379B (zh) * | 2024-04-24 | 2024-06-18 | 麒麟软件有限公司 | 一种基于gpu资源的调度实现方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN114968566A (zh) | 一种面向共享式gpu集群下的容器调度方法及装置 | |
CN107038069B (zh) | Hadoop平台下动态标签匹配DLMS调度方法 | |
CN100527119C (zh) | 信息处理设备和信息处理方法 | |
CN110413412B (zh) | 一种基于gpu集群资源分配的方法和装置 | |
CN111506404A (zh) | 一种基于Kubernetes的共享GPU调度方法 | |
CN112416585B (zh) | 面向深度学习的gpu资源管理与智能化调度方法 | |
CN111045795A (zh) | 资源调度方法及装置 | |
CN105892996A (zh) | 一种批量数据处理的流水线作业方法及装置 | |
CN102929707A (zh) | 并行任务动态分配方法 | |
CN112214319B (zh) | 一种计算资源感知的任务调度方法 | |
CN114356543A (zh) | 一种基于Kubernetes的多租户机器学习任务资源调度方法 | |
CN107515781B (zh) | 一种基于多处理器的确定性任务调度及负载均衡*** | |
JP2022539955A (ja) | タスクスケジューリング方法及び装置 | |
CN111274021B (zh) | 一种gpu集群任务调度分配方法 | |
CN113391914A (zh) | 任务调度方法和装置 | |
CN116560860A (zh) | 一种基于机器学习的资源优先级的实时优化调整方法 | |
CN106775975B (zh) | 进程调度方法及装置 | |
CN114911613A (zh) | 一种云际计算环境中跨集群资源高可用调度方法及*** | |
CN110912967A (zh) | 一种服务节点调度方法、装置、设备及存储介质 | |
CN111143063B (zh) | 任务的资源预约方法及装置 | |
CN111796932A (zh) | 一种gpu资源调度方法 | |
CN107402812A (zh) | 集群资源调度方法、装置、设备及存储介质 | |
CN116010051A (zh) | 一种联邦学习多任务调度方法及装置 | |
CN107229519B (zh) | 任务调度方法和装置 | |
CN111796934B (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 |