CN113760549B - 一种pod部署方法及装置 - Google Patents
一种pod部署方法及装置 Download PDFInfo
- Publication number
- CN113760549B CN113760549B CN202111002609.9A CN202111002609A CN113760549B CN 113760549 B CN113760549 B CN 113760549B CN 202111002609 A CN202111002609 A CN 202111002609A CN 113760549 B CN113760549 B CN 113760549B
- Authority
- CN
- China
- Prior art keywords
- pod
- service node
- service
- node
- load
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 40
- 238000012544 monitoring process Methods 0.000 claims description 26
- 238000012545 processing Methods 0.000 claims description 11
- 230000006870 function Effects 0.000 description 12
- 238000010586 diagram Methods 0.000 description 9
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 238000004590 computer program Methods 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000003068 static effect Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000006386 memory function Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000004321 preservation Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
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/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
- G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
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)
- Multi Processors (AREA)
Abstract
本申请公开了一种pod部署方法及装置，用于解决分配的业务节点准确度低的问题。本申请中提供的方法包括：管理节点监测管理节点所在的集群中业务节点的负载情况，以获取每个业务节点的负载量，以及监测集群中的业务节点的可分配资源的剩余情况，以获得每个节点的可分配资源剩余量；管理节点确定待创建的第一pod；管理节点在确定集群中业务节点的可分配资源剩余量均小于第一pod的请求资源量时，根据集群中业务节点的负载量在集群中的业务节点中选择用于创建第一pod的第一业务节点。
Description
技术领域
本申请涉及计算机技术领域，特别涉及一种pod部署方法及装置。
背景技术
在云平台集群环境，例如基于Kubernetes(k8s)的容器云集群下，资源编排调度使用的是静态调度，静态调度带来的问题是，集群资源很快被业务容器分配完，但是集群的整体负载非常低，各个业务节点的负载也不均衡。目前通过动态调整可分配资源的值来让业务节点的可分配资源变得"虚高"，在动态调整可分配资源的值时，通过预配置调整值自主调整，并未考虑业务节点的实际情况。后续调度器在基于调整后的可分配资源的值来为pod分配业务节点，准确度较低。
发明内容
本申请实施例提供了一种pod部署方法及装置，用以解决分配的业务节点准确度低的问题。
第一方面，本申请实施例提供了一种pod部署方法，包括：
管理节点监测所述管理节点所在的集群中业务节点的负载情况，以获取每个业务节点的负载量，以及监测所述集群中的业务节点的可分配资源的剩余情况，以获得每个节点的可分配资源剩余量；
所述管理节点确定待创建的第一pod；
所述管理节点在确定所述集群中业务节点的可分配资源剩余量均小于所述第一pod的请求资源量时，根据所述集群中业务节点的负载量在所述集群中的业务节点中选择用于创建所述第一pod的第一业务节点。
基于上述方案，在进行pod部署时，管理节点实时监控管理节点所在的集群中各个业务节点的可分配剩余资源量和负载量，实现资源调度的动态调整。具体结合负载量为调度的pod分配业务节点，能够均衡集群中业务节点的负载。此外，并非仅根据业务节点的请求的资源来确定可分配资源剩余量来为pod分配业务节点，而是进一步结合负载量来为pod分配业务节点，可以提高业务节点的资源利用率，并且不会导致节点pod过多而出现资源抢占的问题。
在一些实施例中，所述业务节点的负载量包括业务节点的CPU利用率和/或内存占用率。
在一些实施例中，所述第一业务节点的负载量小于负载量阈值。
基于上述方案，当业务节点的可分配资源不满足第一pod请求资源时，通过业务节点的负载量为第一pod分配业务节点，提高了业务节点的资源利用率。
在一些实施例中，所述第一业务节点为所述集群中负载量小于负载量阈值的多个业务节点中负载量最小的业务节点，所述第一业务节点的负载量为确定待创建的第一pod之前的设定时长内多次监测到的第一业务节点的最大负载量。
基于上述方案，为第一pod分配的第一业务节点为多个节点中负载量最小的业务节点，这样有利于集群中各个业务节点的负载更均衡。
在一些实施例中，所述第一业务节点的负载量为确定待创建的第一pod之前的设定时长内多次监测到的第一业务节点的平均负载量。
基于上述方案，通过获取多次监测负载量并求取平均值作为第一节点的负载量，使得管理节点检测到的结果更加准确，提高pod创建任务的调度效率。
在一些实施例中，在所述集群中业务节点的负载量均满足第一条件时，在确定待创建的第一pod之前的设定时长内多次监测到的第一业务节点的负载量大小与监测时间成反比；其中，第一条件为确定待创建的第一pod之前的设定时长内多次监测到的业务节点的最大负载量大于负载量阈值且最小负载量小于负载量阈值。
在一些实施例中，管理节点所在集群中所有业务节点的可分配资源剩余量均不满足pod请求资源量，且在确定待创建的第一pod之前的设定时长内多次监测到的业务节点的负载量均大于负载量阈值时，管理节点不能将第一pod的创建任务调度到业务节点上。管理节点将第一pod的创建任务放回pod列表中，等待下一次调度。
基于上述方案，在业务节点的可分配资源剩余量及负载量均不能满足第一pod请求资源时，将第一pod创建任务添加到pod列表中，等待下一次调度，有效避免了业务节点上pod过多造成的资源抢占问题及业务节点达到驱逐阈值造成业务节点上pod被驱逐的问题。
在一些实施例中，所述管理节点确定待创建的第一pod，包括：
所述管理节点从pod列表中调度所述第一pod的创建任务，所述pod列表中包括所述第一pod在内的至少一个pod的创建任务。
在一些实施例中，所述管理节点接收到创建请求，所述创建请求用于请求创建第二pod；
所述管理节点将所述第二pod的创建任务添加到所述pod列表中。
在一些实施例中，管理节点可以实时的监控集群中各个业务节点的可分配资源及负载，也可以周期性的监控集群中各个业务节点的可分配资源及负载。管理节点可以向集群中各个业务节点订阅各个业务节点的可分配资源情况和负载情况，各个业务节点周期性的向管理节点上报可分配资源剩余量和负载量。
基于上述方案，管理节点实时监控集群中各个业务节点的可分配资源剩余量与负载量，当接收到pod创建请求后，将pod创建任务添加到pod列表中，确定pod列表中待调度的第一pod创建任务，为第一pod分配第一业务节点，将第一pod的创建任务调度到第一节点上。
第二方面，本申请实施例提供了一种pod部署装置，包括控制器及调度器；
所述控制器，用于监测所述管理节点所在的集群中业务节点的负载情况，以获取每个业务节点的负载量，以及监测所述集群中的业务节点的可分配资源的剩余情况，以获得每个节点的可分配资源剩余量；
所述调度器，用于确定待创建的第一pod；
所述调度器，还用于在确定所述集群中业务节点的可分配资源剩余量均小于所述第一pod的请求资源量时，根据所述集群中业务节点的负载量在所述集群中的业务节点中选择用于创建所述第一pod的第一业务节点。
在一些实施例中，所述业务节点的负载量包括业务节点的CPU利用率和/或内存占用率。
在一些实施例中，所述第一业务节点的负载量小于负载量阈值。
在一些实施例中，所述第一业务节点为所述集群中负载量小于负载量阈值的多个业务节点中负载量最小的业务节点，所述第一业务节点的负载量为确定待创建的第一pod之前的设定时长内多次监测到的第一业务节点的最大负载量。
在一些实施例中，所述第一业务节点的负载量为确定待创建的第一pod之前的设定时长内多次监测到的第一业务节点的平均负载量。
在一些实施例中，在所述集群中业务节点的负载量均满足第一条件时，在确定待创建的第一pod之前的设定时长内多次监测到的第一业务节点的负载量大小与监测时间成反比；其中，第一条件为确定待创建的第一pod之前的设定时长内多次监测到的业务节点的最大负载量大于负载量阈值且最小负载量小于负载量阈值，所述调度器将第一pod的创建请求调度到第一业务节点上。
在一些实施例中，管理节点所在集群中所有业务节点的可分配资源剩余量均不满足pod请求资源量，且在确定待创建的第一pod之前的设定时长内多次监测到的业务节点的负载量均大于负载量阈值时，调度器不再将第一pod的创建任务调度到业务节点上。调度器将第一pod的创建任务放回pod列表中，等待下一次调度。
在一些实施例中，所述调度器，具体用于从pod列表中调度所述第一pod的创建任务，所述pod列表中包括所述第一pod在内的至少一个pod的创建任务。
在一些实施例中，装置还可以包括服务接口，用于接收到创建请求，所述创建请求用于请求创建第二pod；将所述第二pod的创建任务添加到所述pod列表中。
第三方面，本申请实施例提供了一pod部署系统，包括管理节点和多个业务节点；
所述管理节点，用于监测所述管理节点所在的集群中业务节点的负载情况，以获取每个业务节点的负载量，以及监测所述集群中的业务节点的可分配资源的剩余情况，以获得每个业务节点的可分配资源剩余量；
所述管理节点，还用于确定待创建的第一pod，调度第一pod的创建任务，在确定所述控制器监测的所述集群中业务节点的可分配资源剩余量均小于所述第一pod的请求资源量时，根据所述集群中业务节点的负载量在所述集群中的业务节点中选择用于创建所述第一pod的第一业务节点；
第一业务节点，用于创建所述第一pod。
第四方面，本申请实施例提供了另一种pod部署装置，包括存储器以及处理器；
存储器，用于存储程序指令；
处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行第一方面的方法。
第五方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行上述方法。
另外，第二方面至第五方面中任一种实现方式所带来的技术效果可参见第一方面不同实现方式所带来的技术效果，此处不再赘述。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种pod部署的业务系统的架构示意图；
图2为本申请实施例提供的一种pod占用业务节点资源的示意图；
图3为本申请实施例提供的一种pod部署方法流程图；
图4为本申请实施例提供的一种pod部署方法的架构示意图；
图5为本申请实施例提供的一种pod部署方法流程图示意图；
图6为本申请实施例提供的一种用于实现pod部署的装置示意图；
图7为本申请实施例提供的另一种用于实现pod部署的装置示意图；
图8为本申请实施例提供的另一种用于实现pod部署的装置示意图。
具体实施方式
为使本申请的目的、实施方式和优点更加清楚，下面将结合本申请示例性实施例中的附图，对本申请示例性实施方式进行清楚、完整地描述，显然，所描述的示例性实施例仅是本申请一部分实施例，而不是全部的实施例。需要说明的是，本申请中对于术语的简要说明，仅是为了方便理解接下来描述的实施方式，而不是意图限定本申请的实施方式。除非另有说明，这些术语应当按照其普通和通常的含义理解。
图1示出了本申请提供的一种业务系统的架构示意图。业务系统也可以称为业务集群系统，还可以简称为集群。应理解，本申请实施例并不限于图1所示的系统中，此外，图1中的装置可以是硬件，也可以是从功能上划分的软件或者以上二者结合后的结构。如图1所示，本申请提供的业务系统中包括管理节点和多个业务节点。图1中以包括N个业务节点为例。
首先，管理节点的功能包括：管理和维护系统中的至少一个pod、系统中的pod任务调配(即根据业务节点的资源剩余情况和负载情况，完成pod创建任务，以实现系统中各个业务节点负载均衡)、提供服务接口(API Server)以及保存系统中各个节点的配置信息和负载变化情况等等。本申请提出的管理节点的功能可以由服务器来实现，也可以由服务器集群来实现，本申请对此不作具体限定。可选地，管理节点中还可以包含多种组件，用以实现上述功能，例如：
(1)服务接口：可选地，服务接口可以是API server，后续将以API server为例进行介绍。负责对外提供Restful接口服务，管理节点中的其他组件可以通过API server实现各自的功能，例如，通过API server实现监控各个业务节点的负载情况，或者通过APIserver实现pod或者容器的删除、新增或者查看等操作。
(2)状态存储(ETCD)：一个采用键值对的方式存储数据的数据库，用于保存系统中所有的网络配置和资源对象的状态信息(例如，某一个业务节点的剩余资源情况)，也就是保存了整个系统的状态。
(3)调度器(scheduler)：用于监控新建pod副本信息，并通过资源调度算法为需要部署的该新建pod选择一个最合适的业务节点进行部署。部署成功之后，会将pod的信息与其部署的业务节点的信息进行绑定，并存储在ETCD中。
(4)控制器管理组件(Controller Manager)：负责管理执行各种功能的控制器(controller)。controller负责维护系统的状态，例如故障检测、自动扩展或者滚动升级等。例如，当系统中某个节点上部署的某一个pod的状态发生变化，controller是可以监测到的。
其次，业务节点，用于为多个pod(或者可以说多个容器)提供运行环境，主要的功能包括：负责pod的创建、启停等操作，负责将接收到的请求转发到具体地某一个pod上。需要说明的是，业务节点的功能也可以由一个服务器或者服务器集群来实现。可选地，业务节点中还可以包括用于实现上述功能的组件，例如：
(1)代理组件(比如可以是kubelet)：负责监听和管理各个pod的生命周期，还用于实现pod的创建、删除、启动或者停止等操作。
(2)请求转发组件(kube-proxy)：负责将接收到的请求转发到具体的某一个pod上。
进一步地，pod为系统中的最小运行单元，一个pod中可以包含一个容器，也可以包含多个容器。一些实施例中，每一个pod都会被分配一个唯一的IP地址。一个pod中的所有容器共享网络空间(包括IP地址和端口)。
需要说明的是，图1仅作为一种示例，本申请对于pod部署系统中包含的管理节点、业务节点、pod的数量不作具体限定。
目前，pod的部署方法没有考虑业务节点的负载情况，静态调度使业务节点的负载低且不均衡。如图2所示为pod请求资源量与业务节点可分配剩余资源量的关系，其中podusage表示pod的使用资源量，pod request表示pod的请求资源量。在请求创建pod时，一般pod的资源请求量配置较高，而实际pod的资源使用量小于资源请求量，而当pod调度到业务节点上时，是将pod请求资源量与业务节点的可分配资源剩余量进行比较来决定是否可以将该pod调度到所述业务节点上，而由于pod的资源请求量较高，从而导致业务节点的可分配剩余资源量很快被各个pod的请求资源量占满，导致新的pod无法调度到该业务节点上，但是该业务节点的实际资源占用率很低。为解决上述问题，一种可能的方式是采用Kubernetes MutatingAdmissionWehook动态调整方法主要是通过调整可分配资源的值，并非根据实际的pod的资源请求量来更新可分配资源的值，而是通过预配置调整值自主调整，使得可分配资源变得虚高，骗过k8s的调度器，使得调度器以为该节点可分配资源很大，让尽可能多的pod调度到该节点上。该方案通过Kubernetes MutatingAdmissionWehook功能监听集群中业务节点的状态(status)数据，并根据状态数据向API server提交的更新操作，将业务节点的状态数据进行修改后再提交给API server，实现调整可分配资源值。该方案一律修改业务节点的可分配资源值，不考虑业务节点当前负载，当业务节点的当前负载高时，继续分配pod容易造成业务节点上pod因抢占资源发生问题，还可能由于业务节点资源占用率达到驱逐阈值，造成业务节点上pod被驱逐。本申请提供了一种pod部署方法，通过管理节点中的控制器，实时监控集群中业务节点的资源与负载，与管理节点中的调度器结合，实现动态调整，更好的提高业务节点的资源利用率且不会导致业务节点pod过多导致出现资源抢占问题。
参见图3，本申请实施例提供了一种pod部署方法流程图，具体包括：
301，管理节点监控集群内各个业务节点的可分配资源及负载。
管理节点监控所述管理节点所在的集群中各个业务节点的负载情况，来获取每个业务节点的负载量或者负载剩余量，以及监控所述集群中的业务节点的可分配资源的剩余情况，以获得每个节点的可分配资源剩余量。可分配资源也可以称为allocatable资源。
所述负载量包括业务节点的CPU利用率和/或内存占用率。负载剩余量可以包括CPU剩余占用率和/或内存剩余占用率。可以理解的是，负载剩余量等于1-负载量。
一些示例中，管理节点可以实时的监控集群中各个业务节点的可分配资源及负载，也可以周期性的监控集群中各个业务节点的可分配资源及负载。比如，管理节点可以向集群中各个业务节点订阅各个业务节点的可分配资源情况和负载情况。各个业务节点周期性的向管理节点上报可分配资源情况信息(比如包括可分配资源剩余量)和负载情况信息(比如负载量或者负载剩余量)。例如，各个业务节点每间隔5分钟向管理节点可分配资源情况信息和负载情况信息。再比如，管理节点可以周期性地向集群中各个业务节点获取各个业务节点的分配资源情况信息和负载请求信息。
302，管理节点确定待创建的第一pod。
示例性地，管理节点在确定待创建的第一pod时，可以通过如下方式实现：
管理节点从pod列表中调度第一pod的创建任务，pod列表中包括第一pod在内的至少一个pod的创建任务，所述pod列表为所有待调度pod的集合，所述第一pod为待调度列表中的一个pod。
管理节点调度第一pod的创建任务；其中，创建任务指示该第一pod所需的资源。资源，比如可以包括处理资源、存储资源等等。处理资源也可以称为中央处理单元(CentralProcess Unit，CPU)资源。
一些实施例中，管理节点每次在接收到pod创建请求后，pod创建请求也可以简称为创建请求。该创建请求用于请求创建某个pod。可选地，该pod创建请求可以是用户触发服务滚动升级时产生的，或者用户手动创建产生的。
管理节点在接收到创建请求后，将该pod的创建任务添加到的pod列表中。管理节点可以按照先进先出的原则调度pod列表中的各个pod的创建任务。本申请实施例中以调度pod列表中的第一pod的创建任务，实现创建第一pod为例，其它pod的创建与第一pod的创建类似，不再过多描述。
303，管理节点根据集群中各个业务节点的可分配资源剩余量，或者可分配资源剩余量和负载量选择用于创建第一pod的业务节点。
一种可能的实施例中，所述管理节点在确定所述集群中业务节点的可分配资源剩余量均小于所述第一pod的请求资源量时，根据所述集群中业务节点的负载量在所述集群中的业务节点中选择用于创建所述第一pod的业务节点。以选择的用于创建第一pod的业务节点为第一业务节点为例。以图1为例，第一业务节点为业务节点1-业务节点N中的一个。
在另一种可能的实施例中，所述第一业务节点为所述集群中负载量小于负载量阈值的多个业务节点中负载量最小的业务节点。以图1所示的业务系统为例，管理节点在确定业务节点1-业务节点N的可分配资源剩余量均不满足第一pod的请求资源量，管理节点进一步根据业务节点1-业务节点N的负载量来为第一pod选择业务节点。管理节点从所述集群中负载量小于负载量阈值的多个业务节点中选择负载量最小的业务节点作为第一业务节点。
一种示例中，管理节点在根据各个业务节点的负载量为第一pod选择业务节点时，可以根据最近一次监测到各个业务节点的负载量为第一pod选择业务节点，具体可以从满足负载量小于负载量阈值的多个业务节点选择第一业务节点。
另一种示例中，管理节点在根据各个业务节点的负载量为第一pod选择业务节点时，可以根据确定待创建的第一pod之前(或者说从pod列表中调度第一pod之前)的设定时长内多次监测的各个业务节点的负载量为第一pod选择业务节点。比如从多次监测到的满足负载量小于负载量阈值的业务节点中为第一pod选择第一业务节点。例如，三次监测到的负载量均满足负载量小于负载量阈值的业务节点包括业务节点1和业务节点2，进而从业务节点1和业务节点2中选择一个业务节点作为第一业务节点。
具体地，管理节点可以根据多次监测到的业务节点的最大负载量来判断该业务节点是否满足负载量小于负载量阈值。示例性地，管理节点为第一pod选择的第一业务节点的负载量小于负载量阈值，可以理解为第一业务节点的负载量为确定待创建的第一pod之前的设定时长内多次监测到的第一业务节点的最大负载量。
在又一种可能的实施例中，当管理节点所在的集群中所有业务节点的可分配资源剩余量均小于所述第一pod请求资源量，并且所有的业务节点的负载量均大于负载量阈值时，管理节点可以将所述第一pod的创建任务重新放入pod列表，后续待调度到该第一pod的创建任务时，再为该第一pod分配业务节点。
在又一种可能的实施例中，当管理节点所在的集群中所有业务节点的可分配资源剩余量均小于所述第一pod请求资源量，可以根据确定待创建的第一pod之前(或者说从pod列表中调度第一pod之前)的设定时长内多次监测的各个业务节点的负载量为第一pod选择业务节点。如果没有业务节点满足多次监测到的负载量均小于负载量阈值，管理节点可以获取多次监测到的负载量连续下降的业务节点分配给第一pod，以用于部署第一pod。基于此，管理节点为第一pod选择的所述第一业务节点为在确定待创建的第一pod之前的设定时长内多次监测到的业务节点的负载量大小与监测时间成反比，且该业务节点的最大负载量大于负载量阈值且最小负载量小于负载量阈值的业务节点。负载量大小与监测时间成反比，可以理解为负载量越小，监测时间越晚，负载量越大，监测时间越早。
以图1所示的业务系统为例，管理节点确定业务节点1-业务节点N的可分配资源剩余量均不满足第一pod的请求资源量，且业务节点1-业务节点N中没有业务节点在最近三次监测到负载量小于负载量阈值，进而管理节点根据业务节点的负载量的变化情况为第一pod选择业务节点。具体地，当管理节点所在的集群中所有业务节点的可分配资源量均小于所述第一pod请求资源量时，三次监测到的业务节点的负载量随时间逐渐降低，且该业务节点的最大负载量大于负载量阈值及最小负载量小于负载量阈值时，管理节点将该业务节点作为创建第一pod的第一业务节点。
进一步地，管理节点在选择用于创建第一pod的第一业务节点后，可以指示第一业务节点创建第一pod。比如将创建第一pod所需的资源指示给第一业务节点，还可以包括其它用于部署第一pod的配置信息。
304，第一业务节点创建第一pod。
在一种可能的实施例中，第一业务节点创建所述第一pod时，根据所述第一pod所需的资源以及配置信息，创建所述第一pod。
基于上述方案，在进行pod部署时，管理节点实时监控管理节点所在的集群中各个业务节点的可分配剩余资源量和负载量，实现资源调度的动态调整。具体结合负载量为调度的pod分配业务节点，能够均衡集群中业务节点的负载。此外，并非仅根据业务节点的请求的资源来确定可分配资源剩余量来为pod分配业务节点，而是进一步结合负载量来为pod分配业务节点，可以提高业务节点的资源利用率，并且不会导致节点pod过多而出现资源抢占的问题。
在一些实施例中，用于执行上述监控各个pod并调度pod创建任务指令的可以是管理节点中的调度器(scheduler)，后续为了方便描述，将其称为scheduler进行介绍。用于执行上述接收创建指令操作的也可以是管理节点中的API server组件，用于执行上述创建指令操作的也可以是业务节点中的代理组件kubelet。可选地，在管理节点的API server组件接收到创建指令之后，管理节点中的scheduler确定pod列表中待创建的第一pod。用于执行上述监控各个业务节点的可分配剩余资源量和负载量指令的也可以是管理节点中的控制器，可选地，也可以将执行上述操作的控制器称为NodeStatus-controller，后续为了方便描述，将其称为controller进行介绍。controller监控各个业务节点的可分配剩余资源量和负载量，并与scheduler进行交互，scheduler获取业务节点的可分配剩余资源量和负载量。当业务节点的可分配资源剩余量和/或负载量(或负载剩余量)满足第一pod的请求资源量时，代理组件(kubelet)在业务节点上创建第一pod。
作为一种举例，上述过程可以参见图4示出的架构图，具体包括：API server接收pod创建指令，scheduler监控集群中的pod并确定待创建的第一pod，controller实时监控集群中业务节点的可分配剩余资源量和负载量，将获取的监控各个业务节点的可分配剩余资源量和负载量与scheduler进行交互，scheduler根据获取的业务节点的可分配资源剩余量和/或负载量将第一pod的创建任务调度到第一业务节点上，kubelet根据第一pod的创建指令在第一业务节点上创建第一pod。
下面，为了便于理解本申请提出的pod部署方法，将结合具体地实施例进行介绍。参见图5，为本申请实施例提供的一种pod部署方法流程图，具体包括：
501，controller实时监听集群内各个业务节点的可分配资源剩余量及负载量。
controller实时监控集群中的各个业务节点的资源使用情况，获取各个业务节点的可分配资源剩余量，以及监控业务节点在确定待创建第一pod之前的五分钟、十分钟、十五分钟的负载量，包括业务节点的CPU利用率和内存利用率。
此处的五分钟，十分钟，十五分钟是为了更清楚阐述具体实施例的一种表述，不作为本申请的限定。
502，scheduler与controller进行交互，scheduler从controller获取业务节点的可分配剩余资源量与负载量。
503，管理节点中的API server接收pod创建请求。
API server接收pod创建请求，所述pod创建请求为用户触发服务滚动升级时创建的，或者用户手动触发创建产生的。
504，API server接收pod创建请求后，将该pod的创建任务添加到的pod列表中。
505，管理节点中的scheduler从pod列表中调度第一pod的创建任务。pod列表中包括所述第一pod在内的至少一个pod的创建任务，所述pod列表为所有待创建pod的集合。
506，scheduler从集群的各个业务节点中为第一pod分配业务节点，此实施例中以为第一pod分配第一业务节点为例。
scheduler在执行为第一pod分配第一业务节点时，结合从controller中获取的业务节点的可分配资源剩余量以及负载量实现，具体方式如下：
如果scheduler确定某个业务节点的剩余资源量满足第一pod请求资源量，管理节点将第一pod创建任务调度到该业务节点上。此处以该业务节点为第一业务节点为例。所述第一业务节点为所有业务节点可分配资源剩余量最大的业务节点。
如果scheduler确定没有业务节点满足第一pod请求资源量，则根据节点负载量进行判断，如果发现某个业务节点在确定待创建第一pod之前的设定时间内多次检测到的最近负载量均低于设定阈值，表示该业务节点可以继续调度pod。此实施例中以该业务节点为第一业务节点为例。
如果scheduler确定没有业务节点满足第一pod请求资源量，同时所有业务节点在确定待创建的第一pod之前的设定时间内多次检测到的负载量均高于负载量阈值，scheduler不能将第一pod的创建任务调度到集群中的任一业务节点上，可以将该pod重新放入待调度列表。
如果scheduler确定集群中所有业务节点均不满足第一pod请求资源量，且三次负载情况不均低于负载量阈值时，若存在某个业务节点三次负载情况一直在降低且至少最近一次的负载量小于负载量阈值，管理节点可以将第一pod的创建任务调度到该业务节点上。此实施例中该业务节点为第一业务节点为例。
507，scheduler将第一pod的创建任务指示给第一业务节点。
scheduler为第一pod分配第一业务节点后，将第一pod的创建任务调度到第一业务节点上；其中，创建任务指示所述pod所需的资源，比如可以包括处理资源、存储资源等等。
508，第一业务节点的代理组件kubelet在第一业务节点上创建第一pod。
基于与上述方法的同一构思，参见图6所示，本申请实施例提供了一种pod部署装置600。装置600能够执行上述方法中的各个步骤，为了避免重复，在此不再详述。装置600包括：处理单元602和监控单元603。
监控单元603，用于监测所述管理节点所在的集群中业务节点的负载情况，以获取每个业务节点的负载量，以及监测所述集群中的业务节点的可分配资源的剩余情况，以获得每个节点的可分配资源剩余量；
处理单元602，用于确定待创建的第一pod；在确定所述集群中业务节点的可分配资源剩余量均小于所述第一pod的请求资源量时，根据所述集群中业务节点的负载量在所述集群中的业务节点中选择用于创建所述第一pod的第一业务节点。
在一些实施例中，所述业务节点的负载量包括业务节点的CPU利用率和/或内存占用率。
在一些实施例中，所述第一业务节点的负载量小于负载量阈值。
在一些实施例中，所述第一业务节点为所述集群中负载量小于负载量阈值的多个业务节点中负载量最小的业务节点，所述第一业务节点的负载量为确定待创建的第一pod之前的设定时长内多次监测到的第一业务节点的最大负载量。
在一些实施例中，所述第一业务节点的负载量为确定待创建的第一pod之前的设定时长内多次监测到的第一业务节点的平均负载量。
在一些实施例中，在所述集群中业务节点的负载量均满足第一条件时，在确定待创建的第一pod之前的设定时长内多次监测到的第一业务节点的负载量大小与监测时间成反比；其中，第一条件为确定待创建的第一pod之前的设定时长内多次监测到的业务节点的最大负载量大于负载量阈值且最小负载量小于负载量阈值，所述调度器将第一pod的创建请求调度到第一业务节点上。
在一些实施例中，处理单元602，具体用于从pod列表中调度所述第一pod的创建任务，所述pod列表中包括所述第一pod在内的至少一个pod的创建任务。
在一些实施例中，装置还可以包括收发单元601，用于接收到创建请求，所述创建请求用于请求创建第二pod；将所述第二pod的创建任务添加到所述pod列表中。
基于与上述方法的同一构思，参见图7，本申请实施例提供了一种pod部署装置700。装置700能够执行上述方法中管理节点所执行的各个步骤，为了避免重复，在此不再详述。装置700包括：控制器701，调度器702及服务接口703。
所述控制器701，用于监测所述管理节点所在的集群中业务节点的负载情况，以获取每个业务节点的负载量，以及监测所述集群中的业务节点的可分配资源的剩余情况，以获得每个节点的可分配资源剩余量；
所述调度器702，用于确定待创建的第一pod；
所述调度器702，还用于在确定所述集群中业务节点的可分配资源剩余量均小于所述第一pod的请求资源量时，根据所述集群中业务节点的负载量在所述集群中的业务节点中选择用于创建所述第一pod的第一业务节点。
在一些实施例中，所述业务节点的负载量包括业务节点的CPU利用率和/或内存占用率。
在一些实施例中，所述第一业务节点的负载量小于负载量阈值。
在一些实施例中，所述第一业务节点为所述集群中负载量小于负载量阈值的多个业务节点中负载量最小的业务节点，所述第一业务节点的负载量为确定待创建的第一pod之前的设定时长内多次监测到的第一业务节点的最大负载量。
在一些实施例中，所述第一业务节点的负载量为确定待创建的第一pod之前的设定时长内多次监测到的第一业务节点的平均负载量。
在一些实施例中，在所述集群中业务节点的负载量均满足第一条件时，在确定待创建的第一pod之前的设定时长内多次监测到的第一业务节点的负载量大小与监测时间成反比；其中，第一条件为确定待创建的第一pod之前的设定时长内多次监测到的业务节点的最大负载量大于负载量阈值且最小负载量小于负载量阈值，所述调度器702将第一pod的创建请求调度到第一业务节点上。
在一些实施例中，管理节点所在集群中所有业务节点的可分配资源剩余量均不满足pod请求资源量，且在确定待创建的第一pod之前的设定时长内多次监测到的业务节点的负载量均大于负载量阈值时，调度器702不再将第一pod的创建任务调度到业务节点上。调度器702将第一pod的创建任务放回pod列表中，等待下一次调度。
在一些实施例中，所述调度器702，具体用于从pod列表中调度所述第一pod的创建任务，所述pod列表中包括所述第一pod在内的至少一个pod的创建任务。
在一些实施例中，装置还可以包括服务接口703，用于接收到创建请求，所述创建请求用于请求创建第二pod；将所述第二pod的创建任务添加到所述pod列表中。
本申请实施例还提供另一种pod部署装置800，参见图8所示，包括存储器801以及处理器802。可选地，装置800还可以包括通信接口803。其中，装置800通过所述通信接口803与其它设备进行通信，比如接收pod创建指令，通信接口803可以用于实现上述图6中的收发单元601或者图7中的服务接口703所能够实现的功能。存储器801，用于存储程序指令。处理器802，用于调用所述存储器801中存储的程序指令，按照获得的程序执行上述实施例中提出的任一方法。例如，处理器802可以用于实现上述图6中的处理单元602和监控单元603或者图7中的控制器701所实现的功能。
本申请实施例中不限定上述存储器801、处理器802以及通信接口803之间的具体连接介质，比如总线，总线可以分为地址总线、数据总线、控制总线等。
在本申请实施例中，处理器可以是通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
在本申请实施例中，存储器可以是非易失性存储器，比如硬盘(hard disk drive，HDD)或固态硬盘(solID-state drive，SSD)等，还可以是易失性存储器(volatilememory)，例如随机存取存储器(random-access memory，RAM)。存储器还可以是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。
本申请实施例还提供一种计算机可读存储介质，包括程序代码，当程序代码在计算机上运行时，程序代码用于使计算机执行上述本申请实施例上述提供的方法的步骤。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。
Claims (7)
1.一种pod部署方法，应用于业务集群系统，所述业务集群系统包括管理节点和业务节点，其特征在于，包括：
所述管理节点实时监测所述管理节点所在的集群中业务节点的负载情况，以获取各业务节点的负载量，以及实时监测所述各业务节点的可分配资源的剩余情况，以获得各节点的可分配资源剩余量；其中，负载量包括业务节点的CPU利用率和/或内存占用率；
所述管理节点确定待创建的第一pod，以及所述第一pod所需的第一请求资源量，所述第一请求资源量包括处理资源和/或存储资源；
所述管理节点在确定所述集群中各业务节点的可分配资源剩余量均小于所述第一pod的请求资源量时，比较各业务节点中负载量和负载量阈值；
在存在负载量小于负载量阈值的业务节点时，在第一业务节点创建所述第一pod，其中，所述第一业务节点为各业务节点中负载量小于负载量阈值的一个业务节点；
在不存在负载量小于负载量阈值的业务节点时，在第二业务节点创建所述第一pod，所述第二业务节点为在确定待创建的第一pod之前的设定时长内多次监测到的负载量大小与监测时间成反比的业务节点。
2.如权利要求1所述的方法，其特征在于，所述第一业务节点为所述集群中负载量小于负载量阈值的多个业务节点中负载量最小的业务节点。
3.如权利要求1所述的方法，其特征在于，所述第一业务节点的负载量为确定待创建的第一pod之前的设定时长内多次监测到的第一业务节点的最大负载量；或者，
所述第一业务节点的负载量为确定待创建的第一pod之前的设定时长内多次监测到的第一业务节点的平均负载量。
4.一种pod部署装置，其特征在于，应用于业务集群系统，所述业务集群系统包括管理节点和业务节点，所述管理节点包括控制器和调度器；
所述控制器，用于实时监测所述管理节点所在的集群中业务节点的负载情况，以获取各业务节点的负载量，以及实时监测所述各业务节点的可分配资源的剩余情况，以获得各节点的可分配资源剩余量；其中，负载量包括业务节点的CPU利用率和/或内存占用率；
所述调度器，用于确定待创建的第一pod，以及所述第一pod所需的第一资源，所述第一资源包括处理资源和/或存储资源；
所述调度器，还用于调度第一pod的创建任务，在确定所述控制器监测的所述集群中业务节点的可分配资源剩余量均小于所述第一pod的请求资源量时，比较各业务节点中负载量和负载量阈值；
在存在负载量小于负载量阈值的业务节点时，在第一业务节点创建所述第一pod，其中，所述第一业务节点为各业务节点中负载量小于负载量阈值的一个业务节点；
在不存在负载量小于负载量阈值的业务节点时，在第二业务节点创建所述第一pod，所述第二业务节点为在确定待创建的第一pod之前的设定时长内多次监测到的负载量大小与监测时间成反比的业务节点。
5.如权利要求4所述的装置，其特征在于，所述第一业务节点为所述集群中负载量小于负载量阈值的多个业务节点中负载量最小的业务节点。
6.一种pod部署装置，其特征在于，包括：
存储器以及处理器；
存储器，用于存储程序指令；
处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行权利要求1～3任一项所述的方法。
7.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行权利要求1～3中任一项所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111002609.9A CN113760549B (zh) | 2021-08-30 | 2021-08-30 | 一种pod部署方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111002609.9A CN113760549B (zh) | 2021-08-30 | 2021-08-30 | 一种pod部署方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113760549A CN113760549A (zh) | 2021-12-07 |
| CN113760549B true CN113760549B (zh) | 2024-03-15 |
Family
ID=78791723
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111002609.9A Active CN113760549B (zh) | 2021-08-30 | 2021-08-30 | 一种pod部署方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113760549B (zh) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117113416B (zh) * | 2023-10-17 | 2024-01-23 | 北京数牍科技有限公司 | 基于隐私计算的任务执行方法、装置、设备及存储介质 |
| CN117785446B (zh) * | 2023-12-18 | 2024-08-02 | 慧之安信息技术股份有限公司 | 基于弹性资源分配策略的K8s存储资源分配方法和系统 |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102096602A (zh) * | 2009-12-15 | 2011-06-15 | 中国移动通信集团公司 | 一种任务调度方法及其系统和设备 |
| CN103246550A (zh) * | 2012-02-09 | 2013-08-14 | 深圳市腾讯计算机系统有限公司 | 一种基于容量的多任务调度方法及系统 |
| CN106302211A (zh) * | 2016-07-18 | 2017-01-04 | 网易无尾熊（杭州）科技有限公司 | 一种网络资源的请求量控制方法和装置 |
| WO2018001004A1 (zh) * | 2016-06-27 | 2018-01-04 | 中兴通讯股份有限公司 | 一种基于Docker的云平台控制方法及装置 |
| CN110727512A (zh) * | 2019-09-30 | 2020-01-24 | 星环信息科技（上海）有限公司 | 集群资源调度方法、装置、设备及储存介质 |
| CN111641522A (zh) * | 2020-05-25 | 2020-09-08 | 杭州安恒信息技术股份有限公司 | 节点切换的方法、系统和计算机设备 |
| CN112269641A (zh) * | 2020-11-18 | 2021-01-26 | 网易（杭州）网络有限公司 | 一种调度方法、装置、电子设备及存储介质 |
| CN112783607A (zh) * | 2021-01-29 | 2021-05-11 | 上海哔哩哔哩科技有限公司 | 容器集群中任务部署方法及装置 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20170139872A (ko) * | 2016-06-10 | 2017-12-20 | 삼성에스디에스 주식회사 | 멀티 테넌트 기반의 서비스 제공 시스템 및 방법 |
| US20190377604A1 (en) * | 2018-06-11 | 2019-12-12 | Nuweba Labs Ltd. | Scalable function as a service platform |
-
2021
- 2021-08-30 CN CN202111002609.9A patent/CN113760549B/zh active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102096602A (zh) * | 2009-12-15 | 2011-06-15 | 中国移动通信集团公司 | 一种任务调度方法及其系统和设备 |
| CN103246550A (zh) * | 2012-02-09 | 2013-08-14 | 深圳市腾讯计算机系统有限公司 | 一种基于容量的多任务调度方法及系统 |
| WO2018001004A1 (zh) * | 2016-06-27 | 2018-01-04 | 中兴通讯股份有限公司 | 一种基于Docker的云平台控制方法及装置 |
| CN106302211A (zh) * | 2016-07-18 | 2017-01-04 | 网易无尾熊（杭州）科技有限公司 | 一种网络资源的请求量控制方法和装置 |
| CN110727512A (zh) * | 2019-09-30 | 2020-01-24 | 星环信息科技（上海）有限公司 | 集群资源调度方法、装置、设备及储存介质 |
| CN111641522A (zh) * | 2020-05-25 | 2020-09-08 | 杭州安恒信息技术股份有限公司 | 节点切换的方法、系统和计算机设备 |
| CN112269641A (zh) * | 2020-11-18 | 2021-01-26 | 网易（杭州）网络有限公司 | 一种调度方法、装置、电子设备及存储介质 |
| CN112783607A (zh) * | 2021-01-29 | 2021-05-11 | 上海哔哩哔哩科技有限公司 | 容器集群中任务部署方法及装置 |
Non-Patent Citations (2)
| Title |
|---|
| Geo-distributed efficient deployment of containers with Kubernetes;Fabiana等;《Computer Communications》;第159卷;161-174 * |
| 面向容器云平台的集群资源调度管理器的设计与实现;何思玫;《中国优秀硕士学位论文 信息科技辑》(第12期);I139-177 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113760549A (zh) | 2021-12-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112199194B (zh) | 基于容器集群的资源调度方法、装置、设备和存储介质 | |
| CN109302483B (zh) | 一种应用程序的管理方法及系统 | |
| US11526434B1 (en) | Network-level garbage collection in an on-demand code execution system | |
| CN110647394B (zh) | 一种资源分配方法、装置及设备 | |
| CN107547596B (zh) | 一种基于Docker的云平台控制方法及装置 | |
| US11231955B1 (en) | Dynamically reallocating memory in an on-demand code execution system | |
| US7627618B2 (en) | System for managing data collection processes | |
| US20170031622A1 (en) | Methods for allocating storage cluster hardware resources and devices thereof | |
| CN114930295A (zh) | 利用预留容量而不抑制缩放的无服务器调用分配 | |
| JP6881575B2 (ja) | 資源割当システム、管理装置、方法およびプログラム | |
| CN113760549B (zh) | 一种pod部署方法及装置 | |
| CN111104208B (zh) | 进程调度管理方法、装置、计算机设备及存储介质 | |
| US20220329651A1 (en) | Apparatus for container orchestration in geographically distributed multi-cloud environment and method using the same | |
| US20190014059A1 (en) | Systems and methods for allocating computing resources in distributed computing | |
| US20240073298A1 (en) | Intelligent scheduling apparatus and method | |
| CN108681484A (zh) | 一种任务的分配方法、装置及设备 | |
| CN112214288B (zh) | 基于Kubernetes集群的Pod调度方法、装置、设备和介质 | |
| US20230266999A1 (en) | Resource scheduling method, resource scheduling system, and device | |
| US20230037293A1 (en) | Systems and methods of hybrid centralized distributive scheduling on shared physical hosts | |
| CN115396377B (zh) | 对象存储的服务质量优化方法、装置、设备及存储介质 | |
| US20230315531A1 (en) | Method of creating container, electronic device and storage medium | |
| CN114416355A (zh) | 资源调度方法、装置、系统、电子设备及介质 | |
| CN112860442A (zh) | 资源配额调整方法、装置、计算机设备和存储介质 | |
| US10956228B2 (en) | Task management using a virtual node | |
| WO2017018978A1 (en) | Scheduling jobs in a computing cluster |
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 |