CN109471725A - 资源分配方法、装置和服务器 - Google Patents

Abstract

本公开提供了一种资源分配方法、装置和服务器，其中，该方法包括：确定容器管理集群中的资源总量；确定容器管理集群中每个应用的已分配资源量和资源总量的比值；确定比值最小的应用；为该比值最小的应用分配预设数量Pod的资源量，更新该比值最小的应用的已分配资源量；判断所有应用的已分配资源量之和是否大于资源总量；若判断结果为否，继续通过上述步骤分配资源；若判断结果为是，根据每个应用的已分配资源量为每个应用分配相应量的资源，其中，比值最小的应用的已分配资源量为更新后的该比值最小的应用的已分配资源量减去预设数量Pod的资源量。本公开可以公平地为集群中的多个应用分配资源，同时保证被分配的资源能够被有效合理地利用。

Description

资源分配方法、装置和服务器

技术领域

本公开涉及虚拟化技术领域，尤其是涉及一种资源分配方法、装置和服务器。

背景技术

容器是一种轻量级、可移植、自包含的软件打包技术，容器可以使应用程序在几乎任何地方都能以相同的方式运行。与传统的虚拟化技术不同，容器运行在操作***的某一用户空间中，与操作***的其他进程隔离，在体积上比虚拟机小很多。启动容器不需要启动整个操作***，因此容器的部署和启动速度更快、开销更小，也更容易迁移。

Kubernetes是一种自动化容器操作的开源平台，通过该平台可以对容器进行自动化的部署和复制，扩展或收缩容器规模，将容器组织成组并提供容器间的负载均衡，形成容器管理集群；同时还可以很容易地实现对集群中各类应用程序容器进行版本升级，对容器进行弹性伸缩等功能。

在对容器管理集群(也可以简称集群)进行部署或更新过程中，Kubernetes可以提供多种资源分配管理方法，例如，根据容器的历史数据为容器的资源需求值进行预测，根据预测结果设置各容器的资源限额等。但这些方法基本都是通过手动方式为每个容器配置具体的资源限额，且资源限额的大小根据历史数据或工程师经验设置。如果容器管理集群中运行有多个应用，这种根据历史数据或工程师经验设置的资源限额方式，很难在整体上为各个应用间合理地分配资源，易导致有的应用资源利用率低，而有的应用资源不足无法正常运行。

发明内容

有鉴于此，本公开的目的在于提供一种资源分配方法、装置和服务器，以实现集群中的为多个应用的资源分配，同时保证被分配的资源能够被有效合理地利用。

为了实现上述目的，本公开采用的技术方案如下：

第一方面，本公开提供了一种资源分配方法，该方法应用于容器管理集群的主节点；方法包括：确定容器管理集群中的资源总量；确定容器管理集群中每个应用的已分配资源量和资源总量的比值；每个应用对应至少一个Pod，每个应用的已分配资源量为至少一个Pod的资源量之和；确定比值最小的应用；为该比值最小的应用分配预设数量Pod的资源量，更新该比值最小的应用的已分配资源量；判断所有应用的已分配资源量之和是否大于资源总量；若判断结果为否，返回执行确定容器管理集群中每个应用的已分配资源和资源总量的比值的操作；若判断结果为是，根据每个应用的已分配资源量为每个应用分配相应量的资源，其中，比值最小的应用的已分配资源量为更新后的该比值最小的应用的已分配资源量减去预设数量Pod的资源量。

第二方面，本公开提供了一种资源分配装置，该装置设置于容器管理集群的主节点；装置包括：第一确定模块，用于确定容器管理集群中的资源总量；第二确定模块，用于确定容器管理集群中每个应用的已分配资源量和资源总量的比值；每个应用对应至少一个Pod，每个应用的已分配资源量为至少一个Pod的资源量之和；应用确定模块，用于确定比值最小的应用；资源量分配模块，用于为该比值最小的应用分配预设数量Pod的资源量，更新该比值最小的应用的已分配资源量；判断模块，用于判断所有应用的已分配资源量之和是否大于资源总量；返回模块，用于若判断结果为否，返回执行确定容器管理集群中每个应用的已分配资源和资源总量的比值的操作；资源分配模块，用于若判断结果为是，根据每个应用的已分配资源量为每个应用分配相应量的资源，其中，比值最小的应用的已分配资源量为更新后的该比值最小的应用的已分配资源量减去预设数量Pod的资源量。

第三方面，本公开提供了一种服务器，包括处理器和机器可读存储介质，机器可读存储介质存储有能够被处理器执行的机器可执行指令，处理器执行机器可执行指令以实现上述资源分配方法。

第四方面，本公开提供了一种机器可读存储介质，机器可读存储介质存储有机器可执行指令，机器可执行指令在被处理器调用和执行时，机器可执行指令促使处理器实现上述资源分配方法。

上述资源分配方法、装置、服务器和机器可读存储介质，在为集群中的各个应用分配资源的过程中，首先确定每个应用的已分配资源量和资源总量的比值，以及比值最小的应用；为该比值最小的应用分配预设数量Pod的资源量，更新该比值最小的应用的已分配资源量；如果所有应用的已分配资源量之和小于或等于资源总量，则重新确定每个应用的已分配资源量和资源总量的比值，继续进行分配；如果所有应用的已分配资源量之和大于资源总量，根据每个应用的已分配资源量为每个应用分配相应量的资源。这种方式基于每个应用的已分配资源量和资源总量的比值，优先选择比值最小的应用分配预设数量Pod的资源量，可以公平地为集群中的多个应用分配资源，同时保证被分配的资源能够被有效合理地利用，避免了因资源分配不合理导致资源闲置或因资源不足而使应用无法正常运行的情况。

本公开的其他特征和优点将在随后的说明书中阐述，或者，部分特征和优点可以从说明书推知或毫无疑义地确定，或者通过实施本公开的上述技术即可得知。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施方式，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本公开具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本公开的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本公开实施方式提供的一种容器管理集群的结构示意图；

图2为本公开实施方式提供的一种资源分配方法的流程图；

图3为本公开实施方式提供的另一种资源分配方法的流程图；

图4为本公开实施方式提供的一种资源分配装置的结构示意图；

图5为本公开实施方式提供的服务器的结构示意图。

具体实施方式

为使本公开实施方式的目的、技术方案和优点更加清楚，下面将结合附图对本公开的技术方案进行清楚、完整地描述，显然，所描述的实施方式是本公开一部分实施方式，而不是全部的实施方式。基于本公开中的实施方式，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施方式，都属于本公开保护的范围。

为了便于理解，首先描述一种基于容器操作管理平台Kubernetes构建的容器管理集群(简称Kubernetes集群)的架构，如图1所示。该Kubernetes集群支持Docker和Rocket(图1中以Docker为例进行说明)两种容器技术，Kubernetes集群包含一个主节点(Kubernetes Master)和其它节点(Node)(例如节点A和节点B)，其它节点均与主节点连接，Kubernetes集群中的节点可以是物理服务器，也可以为虚拟机。

主节点中包含有API Server和复制控制器(Replication Controller，简称RC)；其中，API Server是集群管理的API接口，也是集群内部各个模块之间的通信枢纽，同时，API Server还可以对用户登录进行验证和授权，实现对集群进行安全控制。为了提高性能或实现高可用性，当某个应用的用户增加时，可以通过RC指定该应用需要复制的份数，需要复制的份数与用户增加的数量相匹配，并为每份复制创建一个Pod，每个用户可在对应的Pod中操作应用；同时确保任意时刻实际运行的Pod数量始终与复制的数量相等，如果用户减少时，也可通过RC收回减少的用户操作的Pod。因而，通过RC可以解决Pod的扩容缩容问题。

其他节点用于运行Pod，图1中以两个节点为例进行说明，分别为节点A和节点B；每个节点可以运行多个Pod；Pod是Kubernetes基本的部署调度单元，其中包含一组容器和数据卷(也可以称为volume)；由上述可知，容器用于运行应用程序；而数据卷中保存有与该组容器相关联的特定文件或文件夹；在容器创建期间，数据卷进行初始化；容器在运行期间可以使用数据卷中的文件。

Pod是实际运行应用并提供具体功能和服务的地方；不同应用的架构是不同的。对于较为简单的应用，一个Pod即可完成该应用所有的功能，当用户使用该应用时，可以为每个用户分配一个复制的Pod，复制的Pod上运行有该应用，用户在对应的Pod上操作。但对于较为复杂的应用，一个应用包含很多具体的功能和服务，需要多个Pod共同完成这些功能和服务，每个Pod用于完成不同的功能和服务；所有提供同一应用的各项功能和服务的Pod组合到一起为完整的应用。因此，当用户需要该应用的哪项功能和服务时，即为该用户复制对应的Pod，复制的Pod上运行有该功能和服务，用户在该Pod上进行操作。

另外，图1中，每个Pod设置有一个键值对(Labels)，该键值对用于标记Pod，以传递Pod的属性。Service或者主节点中的RC可以通过键值对识别并选择特定的Pod。另外，节点中还包含kubelet、kube-proxy和docker等组件；其中，kubelet是主节点代理；Service通过kube-proxy可以将链接路由到指定的Pod；docker是Kubernetes使用的容器技术，也可以换为rocket。Service是Pod的路由代理抽象，Pod的Labels就可以找到符合要求的Pod。

Kubernetes可以支持分配和管理Pod的多种资源，但是在实际生产环境中，每个容器管理集群的资源通常是有限的，当集群中存在多个应用时，难以确定具体分配给每个应用多少资源才最公平合理，既能满足每个应用的资源需求，同时又可以避免资源浪费。基于上述问题，本发明实施例提供了一种资源分配方法、装置和服务器；该技术可以应用于容器管理集群、或其他容器管理平台、***中；下面通过实施例进行具体描述。

首先，本公开实施方式提供了一种资源分配方法，该方法应用于容器管理集群的主节点；在容器管理集群(也可以称为Kubernets集群)运行的应用中，各用户的操作空间是通过Pod生成的，该操作空间就是用户在应用中获取到的服务；例如，对于web应用，用户在web页面上执行的各种操作都是应用提供的服务，这些服务由Pod中运行的应用程序提供。

由上述可知，Pod一般是根据RC中定义的模板创建的，对于同一应用或同一服务，通常为每个用户分配的Pod的资源量是固定的。而对于不同的应用或不同的服务对应的Pod的资源量是不同的，因而在容器管理集群部署应用时，通常会预先对应用进行测试，根据测试结果得到该应用或应用中各种服务对应的Pod的资源量。

由于容器管理集群可分配的资源通常是有限的，在每个应用或服务对应的一个Pod的资源量确定的情况下，当应用的在线人数无法预知时，可以采用下述资源分配方法确定分配给每个应用的资源量，从而实现基于应用实际需求的资源的公平分配。如图2所示，该资源分配方法具体包括如下步骤：

步骤S202，确定容器管理集群中的资源总量；

上述容器管理集群中各类资源通常包括CPU资源和内存资源，当然还可以包含其他资源，例如上下行带宽等；对于一个容器管理集群可以仅包含一类资源的资源总量，也可以包含多类资源的资源总量；其中，CPU资源可以按照CPU的个数或核数分配；内存资源可以按照内存的单位分配，例如，GB、MB等。CPU资源主要用于运算控制，内存资源主要用于存储数据。通常，容器管理集群的硬件资源是固定的，因此，基于该硬件资源的CPU资源和内存资源也是固定的；通过统计该容器管理集群的硬件资源中，各个物理服务器的硬件配置，可以得到上述容器管理集群中各类资源的总资源量。

步骤S204，确定容器管理集群中每个应用的已分配资源量和资源总量的比值；每个应用对应至少一个Pod，每个应用的已分配资源量为该至少一个Pod的资源量之和；

在初始阶段，容器管理集群中每个应用的已分配资源量均包括指定数量Pod的资源量，如该应用对应的一个Pod的资源量；例如，如果该应用对应的一个Pod的CPU资源的资源量为1CPU，则在初始阶段，该应用的已分配资源量包括1CPU。如果应用已被分配了多个Pod的资源量，则该应用的已分配资源量是多个Pod的资源量之和；例如，该应用已分配了三个Pod的资源量，每个Pod的资源量为1CPU，则该应用的已分配资源量为3CPU。

以CPU资源为例，如果应用A的已分配资源量为10CPU，而集群中CPU的资源总量为50CPU，此时该应用A的已分配资源量和资源总量的比值为10CPU/50CPU＝0.2。

步骤S206，确定比值最小的应用；

得到容器管理集群中每个应用的已分配资源量和资源总量的比值后，比较各个应用对应的比值的数值大小，将数值最小的比值对应的应用，确定为比值最小的应用。

步骤S208，为该比值最小的应用分配预设数量Pod的资源量，更新该比值最小的应用的已分配资源量；

上述比值最小的应用可以理解为当前占有资源量最小的应用，为了保持各应用间资源分配的公平性，将当前比值最小的应用确定为当前轮分配中的目标应用，并为该应用分配资源量。为了保证分配给应用的资源被合理利用，不被闲置，可以按照该应用对应的Pod的资源量为该目标应用分配资源。具体可以为该应用分配对应的一个Pod的资源量，也可以分配多个Pod的资源量；上述步骤S208中，为该比值最小的应用分配的预设数量Pod的资源量，与该应用在初始阶段已分配资源量中包含的指定数量Pod的资源量，其中的预设数量与指定数量可以相同，也可以不同。分配完毕后，更新该比值最小的应用的已分配资源量。

例如，该比值最小的应用的已分配资源量为10CPU，该应用对应的一个Pod的资源量为1CPU，如果为该应用分配两个Pod的资源量，则分配完毕后，该应用已分配资源量更新为12CPU。

步骤S210，判断所有应用的已分配资源量之和是否大于资源总量；若判断结果为否，执行步骤S212；若判断结果为是，执行步骤S214；

步骤S212，返回执行确定容器管理集群中每个应用的已分配资源和资源总量的比值的操作；

当容器管理集群中同时运行有多个应用时，为了将集群中的资源的总资源量较为公正地分配给各个应用，同时又保证分配的资源不被闲置，可以采用循环的方式为各个应用分配资源。在每轮分配中，可以为其中一个应用分配资源，当前轮分配完毕后，或者在当前轮循环之前，可以查看待分配的资源总量是否还能够支持继续分配，或者已分配的资源量是否超出该集群的各类资源的总资源量，以确定是否要继续为应用分配资源。

具体而言，如果更新后的所有应用的已分配资源总量之和没有到达集群中的总资源量，说明还可以继续为应用分配资源，此时则进行下一轮的分配；如果更新后的所有应用的已分配资源总量之和已经到达集群中的总资源量，说明已无法再继续为应用分配资源，将每个应用分配的资源量确定为该应用应分配的资源量。

步骤S214，根据每个应用的已分配资源量为每个应用分配相应量的资源，其中，比值最小的应用的已分配资源量为更新后的该比值最小的应用的已分配资源量减去预设数量Pod的资源量。

例如，该比值最小的应用的上一轮分配后的已分配资源量为9CPU；该比值最小的应用对应的预设数量Pod的资源量为3CPU；经当前轮分配后，比值最小的应用的已分配资源量为12CPU，所有应用的已分配资源量之和为30CPU，而集群的总资源量为28CPU，此时，说明经当前轮分配后，所有应用的已分配资源量已经超出该集群的总资源量中的CPU，集群的总资源量不能满足当前轮的资源分配，此时，则结束资源分配过程，上述比值最小的应用的已分配资源量为更新后的该比值最小的应用的已分配资源量(即12CPU)减去预设数量Pod的资源量(即3CPU)，等于9CPU。

本公开实施方式提供的一种资源分配方法，在为集群中的各个应用分配资源的过程中，首先确定每个应用的已分配资源量和资源总量的比值，以及比值最小的应用；为该比值最小的应用分配预设数量Pod的资源量，更新该比值最小的应用的已分配资源量；如果所有应用的已分配资源量之和小于或等于资源总量，则重新确定每个应用的已分配资源量和资源总量的比值，继续进行分配；如果所有应用的已分配资源量之和大于资源总量，根据每个应用的已分配资源量为每个应用分配相应量的资源。这种方式基于每个应用的已分配资源量和资源总量的比值，优先选择比值最小的应用分配预设数量Pod的资源量，可以公平地为集群中的多个应用分配资源，同时保证被分配的资源能够被有效合理地利用，避免了因资源分配不合理导致资源闲置或因资源不足而使应用无法正常运行的情况。

本公开实施方式还提供另一种资源分配方法，该方法在上述实施方式的基础上实现；本实施方式中具体描述当容器管理集群中包括多类资源时，资源的分配方法；如图3所示，该资源分配方法包括如下步骤：

步骤S302，确定容器管理集群中每类资源的资源总量；

该容器管理集群中可以包含至少一类资源，也可以包含多类资源，如CPU资源和内存资源，当然还可以包含带宽资源等。如果需要同时对多种应用分配多种类型的资源，则需要分别确定该容器管理集群中每个类型的资源总量。

步骤S304，确定每个应用对应的每类资源的已分配资源量和相应类型资源的资源总量的比值；每个应用对应至少一个Pod，每个应用的已分配资源量为该至少一个Pod的资源量之和；

如果容器管理集群中包含两类资源，分别为CPU资源和内存资源，在大多情况下，应用通常都会同时用到CPU资源和内存资源，因此每种应用对应的一个Pod的资源量中同时包含预设数量的CPU资源和内存资源，只是对于不同的应用，一个Pod的资源量中的CPU资源和内存资源的数量、比例有所不同。例如，游戏类的应用可能需要较多的CPU资源，则该应用的资源配额中CPU资源可能多于内存资源，该应用的资源配额可以设置为3CPU、1GB内存；对于信息记录类的应用可能需要较多的内存资源，则该应用的资源配额中内存资源可能多于CPU资源，该应用的资源配额可以设置为1CPU、3GB内存。

例如，对于某一应用，该应用对应的一个Pod的资源量为1CPU和3GB内存，已为该应用分配了三个Pod的资源量，则该应用的已分配资源量为3CPU和9GB；假设该容器管理集群中，CPU资源的资源总量为30CPU，内存资源的资源总量为45GB；此时，该应用的CPU资源的已分配资源量和资源总量的比值为3CPU/30CPU＝0.1；该应用的内存资源的已分配资源量和资源总量的比值为9GB/45GB＝0.2。

步骤S306，对于每个应用：将该应用的每类资源的已分配资源量和该类型资源的资源总量的比值中的最大值，确定为该应用的比值；

对于不同的应用，有些应用可能需要CPU资源的资源量较大，而有些应用可能需要内存资源的资源量较大；因此，应用的每类资源的已分配资源量和该类型资源的资源总量的比值中，哪个比值为最大值，则说明该最大值对应的资源是该应用需求量较大的资源；将该应用需求量较大的资源确定为该应用的比值，并基于该比值为各类应用进行资源分配，可以在公平分配资源的同时，满足各应用对主要资源的需求。

例如，如果某一应用的CPU资源的已分配资源量和资源总量的比值为0.1，该应用的内存资源的已分配资源量和资源总量的比值为0.2，说明该应用对内存的资源需求较大，将内存对应的比值确定为该应用的比值。

步骤S308，为该比值最小的应用分配预设数量Pod的资源量，更新该比值最小的应用的已分配资源量；

通常，应用对应的一个Pod的资源量中CPU和内存的资源量可以支持一个用户的基本服务，使应用在Pod中运行时，CPU或内存均不被闲置；因此，上述步骤S308在为上述比值最小的应用分配资源量时，以Pod为单位进行分配；具体可以分配一个Pod的资源量，也可以分配多个Pod的资源量，该方式可以在资源公平分配的过程中，有效地扩展目标应用的资源，不使分配的资源被浪费。

分配完毕后，则更新该比值最小的应用的已分配资源量，例如，该比值最小的应用在当前轮分配之前，已分配资源量为8CPU和4GB；该比值最小的应用对应的一个Pod的资源量为2CPU和1GB；如果为该比值最小的应用分配两个Pod的资源量，则该比值最小的应用的已分配资源量更新为12CPU和6GB。

步骤S310，针对每类资源：计算所有应用的已分配资源量之和；若针对每类资源的已分配资源量之和均小于或等于相应类资源的资源总量，则执行步骤S304；若针对任一类资源的已分配资源量之和大于该类资源的资源总量，则执行步骤S312。

可以理解，每个应用对应的一个Pod的资源量包括每类资源的预设资源量；如上文所述，对于CPU需求较大的应用，该应用对应的一个Pod的资源量包含较多的CPU，如一个Pod的资源量包括3CPU和1GB；对于内存需求较大的应用，该应用对应的一个Pod的资源量包含较多的内存，如一个Pod的资源量包括1CPU和3GB。

若针对每类资源的已分配资源量之和均小于或等于相应类资源的资源总量，说明容器管理集群中的各类资源都没有被分完毕，则继续执行上述步骤S304；而由于对应用的资源分配都是以Pod为单位的，Pod通常都包含所有类型的资源；因此如果集群中各类资源中只要其中一类资源(具体哪类不做限定，任一类即可)的已分配资源量之和大于该类资源的资源总量，说明该集群中的资源则不能再继续分配，此时需要停止分配过程。

步骤S312，根据每个应用的已分配资源量为每个应用分配相应量的资源，其中，比值最小的应用的已分配资源量为更新后的该比值最小的应用的已分配资源量减去预设数量Pod的资源量。

由于任一类资源的已分配资源量之和大于该类资源的资源总量，说明经当前轮分配后，至少一类资源已经超出该类资源的资源总量；则说明该轮为比值最小的应用的分配的预设数量Pod的资源量无法实现，需要减去当前轮分配的预设数量Pod的资源量，减去后的结果作为该比值最小的应用的最终的已分配资源量。

在上述步骤S312中，各应用得到已分配资源量后，为了将每个应用的已分配资源量真正地分配给每个应用，可以通过将不同应用部署在不同的命名空间实现。在容器管理集群中部署应用时，为了便于统一管理，避免不同应用之间相互影响，通常可以将应用部署在单独的命名空间中，通过命名空间来管理整个应用的资源量。不同的命令空间可以理解为不同的命名格式，即对应用采用不同的命名格式进行命名。具体可以通过命名空间的ResourceQuota对象限制该命名空间内的应用能够获取的资源。该ResourceQuota对象中设置有限额参数，集群根据该限额参数管理各个应用的资源。通过上述步骤为每个应用分配资源后，可以将应用应分配的已分配资源量设置为对应应用所在命名空间中资源配额对象ResourceQuota中的限额参数，以使通过上述方式为每个应用分配的资源总额能够在应用实际运行过程中真正发挥资源管理的作用。

上述方式中，每轮分配完毕后，如果各类资源的已分配资源总量中存在等于或大于对应类资源的总资源量，则停止资源分配，否则继续进行下一轮分配；进而再将最终的各应用应分配的资源总额设置为应用应分配的资源量；该方式可以将集群中各类资源较为公平地分配给多个应用中，同时，保证被分配的资源能够被有效合理地利用。

为了进一步理解上述实施方式中的资源分配方法，本公开实施方式还提供了另一种资源分配方法；该实施方式提供了一种上述资源分配方法的具体计算方式；该方法基于下述假设条件实现：

条件a：容器管理集群中包含n个应用，分别为A1、A2、…、An。

条件b：应用Ai(1≤i≤n，i是自然数)当前需求的资源总量为Ui＝<Ui-cpu,Ui-mem>，其中，Ui-cpu为应用Ai的CPU资源总量，Ui-mem应用Ai的内存资源总量；Ui的初始值为0，即当应用Ai没有用户时，应用Ai的CPU和内存的资源配额为0。

条件c：应用Ai的一个Pod的资源量为：ci个CPU和miGB内存，可以表示为<ciCPU,miGB>。

条件d：集群中可分配的CPU总核数为C。

条件e：可分配的内存总数为MGB。

条件f：集群中已分配的CPU核数为Rcpu，已分配的内存总数为Rmem。

条件g：应用Ai当前已获得的各类资源分别占集群中对应资源总量百分比的最大值Si，Si＝max{Ui-cpu/C，Ui-mem/M}，Si的初始值为0。

基于上述假设条件，上述资源分配方法包括下述步骤：

步骤11，在首轮分配过程中，计算集群中各个应用的Si＝max{ci/C，mi/M}，将Si值最小的应用确定为目标应用；

步骤12，为该目标应用分配该目标应用对应的一个Pod的资源量；

步骤13，计算集群中各个应用的Si＝max{Ui-cpu/C，Ui-mem/M}，将Si值最小的应用确定为目标应用；

步骤14，判断如果对目标应用Ai新增该应用对应的一个Pod的资源量，是否超过集群的资源总量；即判断Rcpu+ci≤C且Rmem+mi≤M是否成立；

步骤15，如果成立，更新目标应用Ai的Ui值，即Ui-cpu＝Ui-cpu+ci，Ui-mem＝Ui-mem+mi；更新Rcpu＝Rcpu+ci，Rmem＝Rmem+mi；

步骤16，继续循环执行步骤3至步骤5，直至步骤4中，Rcpu+ci≤C且Rmem+mi≤M不成立，跳出循环，结束分配过程；

步骤17，将每个应用的已分配资源总量设置为对应应用所在命名空间中资源配额对象ResourceQuota中的限额参数。

基于上述实施方式，本公开实施方式还提供了一种资源分配方法的计算用例，假设当前集群中资源总量为36CPU，64GB内存，在该集群中部署三个应用，分别为应用A、应用B和应用C；其中，应用A的一个Pod的资源量为<1CPU，1GB>，应用B的一个Pod的资源量为<2CPU，4GB>，应用C的一个Pod的资源量为<3CPU，1GB>。

下述表1展示了资源分配的过程，此次资源分配一共经22轮分配完成；其中，表1中的主资源可以理解为该应用需求量较大的资源，主资源占比可以理解为已分配给该应用的需求量较大的资源的资源量占据该资源的总资源量的比值；在首轮分配过程中，由于应用A的一个Pod的资源量中的主资源(CPU或内存)最小，所以将应用A作为目标对象进行资源分配，分配后，应用A的主资源占比为1/36；在后续的分配轮中，将主资源占比最小的应用作为目标应用，如第5轮分配结束后，应用B的主资源占比最小，为4/64，则在第6轮中，将应用B作为目标应用进行资源分配，为应用B分配应用B的一个Pod的资源量，即<2CPU，4GB>。

经上述多轮分配后，最终该集群的资源分配方案为：分配给应用A的资源为12CPU和12GB内存；分配给应用B的资源为12CPU和24GB内存；分配给应用B的资源为12CPU和4GB内存。

上述资源分配方法中，使用DRF(Dominant Resource Fairness，优势资源公平)算法计算集群中各应用的资源，可以将集群中各类资源较为公平地分配给多个应用中，同时，保证被分配的资源能够被有效合理地利用。

表1

上述实施方式所述的资源分配方法，可以应用于容器管理集群创建时期，为该集群将要运行的应用进行资源分配，也可以应用于向该集群新增应用时，为新增应用和该集群中的原始应用再次统一分配资源；上述资源分配方法中，可以公平的给Kubernetes集群中部署的应用分配资源，优化初始分配方案，提高资源的利用率，避免给某一应用分配过多需求较少的资源或者分配过少需求较多的资源。

需要说明的是，上述各方法实施方式均采用递进的方式描述，每个实施方式重点说明的都是与其他实施方式的不同之处，各个实施方式之间相同相似的部分互相参见即可。

对应于上述方法实施方式，参加图4所示的资源分配装置，该装置设置于容器管理集群的主节点；该装置包括：

第一确定模块40，用于确定容器管理集群中的资源总量；

第二确定模块41，用于确定容器管理集群中每个应用的已分配资源量和资源总量的比值；每个应用对应至少一个Pod，每个应用的已分配资源量为至少一个Pod的资源量之和；

应用确定模块42，用于确定比值最小的应用；

资源量分配模块43，用于为该比值最小的应用分配预设数量Pod的资源量，更新该比值最小的应用的已分配资源量；

判断模块44，用于判断所有应用的已分配资源量之和是否大于资源总量；

返回模块45，用于若判断结果为否，返回执行确定容器管理集群中每个应用的已分配资源和资源总量的比值的操作；

资源分配模块46，用于若判断结果为是，根据每个应用的已分配资源量为每个应用分配相应量的资源，其中，比值最小的应用的已分配资源量为更新后的该比值最小的应用的已分配资源量减去预设数量Pod的资源量。

本公开实施方式提供的一种资源分配装置，通过多轮分配的方式为集群中的各个应用分配资源；在每轮分配过程中，首先确定容器管理集群中的资源总量、每个应用的已分配资源量和资源总量的比值，以及比值最小的应用；为该比值最小的应用分配预设数量Pod的资源量，更新该比值最小的应用的已分配资源量；如果所有应用的已分配资源量之和小于或等于资源总量，则继续进行下一轮分配，如果所有应用的已分配资源量之和大于资源总量，根据每个应用的已分配资源量为每个应用分配相应量的资源。该方式可以公平地为集群中的多个应用分配资源，同时保证被分配的资源能够被有效合理地利用，避免了因资源分配不合理导致资源闲置或因资源不足而使应用无法正常运行的情况。

进一步地，初始阶段，容器管理集群中每个应用的已分配资源量均包括指定数量Pod的资源量。

进一步地，上述容器管理集群中包括多类资源；第一确定模块，还用于：确定容器管理集群中每类资源的资源总量；第二确定模块，还用于：确定每个应用对应的每类资源的已分配资源量和相应类型资源的资源总量的比值。

进一步地，上述应用确定模块，还用于：对于每个应用：将该应用的每类资源的已分配资源量和该类型资源的资源总量的比值中的最大值，确定为该应用的比值；从每个应用的比值中选择最小值，将最小值对应的应用确定比值最小的应用。

进一步地，上述每个应用对应的一个Pod的资源量包括：每类资源的预设资源量；判断模块，还用于：针对每类资源：计算所有应用的已分配资源量之和；若针对任一类资源的已分配资源量之和大于该类资源的资源总量，则确定判断结果为是；若针对每类资源的已分配资源量之和均小于或等于相应类资源的资源总量，则判断结果为否。

本实施方式提供了一种与上述方法实施方式相对应的服务器。图5为该服务器的结构示意图，如图5所示，该设备包括处理器501和存储器502；其中，存储器502用于存储一条或多条计算机指令，一条或多条计算机指令被处理器执行，以实现上述资源分配方法。

图5所示的服务器还包括总线503和转发芯片504，处理器501、转发芯片504和存储器502通过总线503连接。该服务器可以是网络边缘设备。

其中，存储器502可能包含高速随机存取存储器(RAM，Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。总线503可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

转发芯片504用于通过网络接口与至少一个用户终端及其它网络单元连接，将封装好的IPv4报文或IPv6报文通过网络接口发送至用户终端。

处理器501可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器501中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器501可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DigitalSignal Processing，简称DSP)、专用集成电路(Application Specific IntegratedCircuit，简称ASIC)、现成可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施方式中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施方式所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器502，处理器501读取存储器502中的信息，结合其硬件完成前述实施方式的方法的步骤。

本发明实施方式还提供了一种机器可读存储介质，该机器可读存储介质存储有机器可执行指令，该机器可执行指令在被处理器调用和执行时，机器可执行指令促使处理器实现上述资源分配方法，具体实现可参见方法实施方式，在此不再赘述。

本发明实施方式所提供的服务器，其实现原理及产生的技术效果和前述方法实施方式相同，为简要描述，装置实施方式部分未提及之处，可参考前述方法实施方式中相应内容。

在本申请所提供的几个实施方式中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施方式仅仅是示意性的，例如，附图中的流程图和框图显示了根据本发明的多个实施方式的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的***来实现，或者可以用专用硬件与计算机指令的组合来实现。

最后应说明的是：以上所述实施方式，仅为本公开的具体实施方式，用以说明本公开的技术方案，而非对其限制，本公开的保护范围并不局限于此，尽管参照前述实施方式对本公开进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，其依然可以对前述实施方式所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本公开实施方式技术方案的精神和范围，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应所述以权利要求的保护范围为准。

Claims (12)

1.一种资源分配方法，其特征在于，所述方法应用于容器管理集群的主节点；所述方法包括：

确定容器管理集群中的资源总量；

确定容器管理集群中每个应用的已分配资源量和所述资源总量的比值；所述每个应用对应至少一个Pod，每个应用的已分配资源量为所述至少一个Pod的资源量之和；

确定所述比值最小的应用；

为该比值最小的应用分配预设数量Pod的资源量，更新该比值最小的应用的已分配资源量；

判断所有应用的已分配资源量之和是否大于所述资源总量；

若判断结果为否，返回执行所述确定容器管理集群中每个应用的已分配资源和所述资源总量的比值的操作；

若判断结果为是，则根据所述每个应用的已分配资源量为所述每个应用分配相应量的资源，其中，所述比值最小的应用的已分配资源量为所述更新后的该比值最小的应用的已分配资源量减去所述预设数量Pod的资源量。

2.根据权利要求1所述的方法，其特征在于，初始阶段，所述容器管理集群中每个应用的已分配资源量均包括指定数量Pod的资源量。

3.根据权利要求1或2所述的方法，其特征在于，所述容器管理集群中包括至少一类资源；

所述确定容器管理集群中的资源总量，包括：确定容器管理集群中每类资源的资源总量；

所述确定容器管理集群中每个应用的已分配资源量和所述资源总量的比值，包括：确定每个应用对应的每类资源的已分配资源量和相应类型资源的资源总量的比值。

4.根据权利要求3所述的方法，其特征在于，所述确定所述比值最小的应用，包括：

对于每个应用：将该应用的每类资源的已分配资源量和该类型资源的资源总量的比值中的最大值，确定为该应用的比值；

从所述每个应用的比值中选择最小值，将所述最小值对应的应用确定所述比值最小的应用。

5.根据权利要求3所述的方法，其特征在于，所述每个应用对应的一个Pod的资源量包括：所述每类资源的预设资源量；

所述判断所有应用的已分配资源量之和是否大于所述资源总量，包括：

针对所述每类资源：计算所有应用的已分配资源量之和；

若针对任一类资源的所述已分配资源量之和大于该类资源的资源总量，则确定所述判断结果为是；

若针对每类资源的所述已分配资源量之和均小于或等于相应类资源的资源总量，则所述判断结果为否。

6.一种资源分配装置，其特征在于，所述装置设置于容器管理集群的主节点；所述装置包括：

第一确定模块，用于确定容器管理集群中的资源总量；

第二确定模块，用于确定容器管理集群中每个应用的已分配资源量和所述资源总量的比值；所述每个应用对应至少一个Pod，每个应用的已分配资源量为所述至少一个Pod的资源量之和；

应用确定模块，用于确定所述比值最小的应用；

资源量分配模块，用于为该比值最小的应用分配预设数量Pod的资源量，更新该比值最小的应用的已分配资源量；

判断模块，用于判断所有应用的已分配资源量之和是否大于所述资源总量；

返回模块，用于若判断结果为否，返回执行所述确定容器管理集群中每个应用的已分配资源和所述资源总量的比值的操作；

资源分配模块，用于若判断结果为是，根据所述每个应用的已分配资源量为所述每个应用分配相应量的资源，其中，所述比值最小的应用的已分配资源量为所述更新后的该比值最小的应用的已分配资源量减去所述预设数量Pod的资源量。

7.根据权利要求6所述的装置，其特征在于，初始阶段，所述容器管理集群中每个应用的已分配资源量均包括指定数量Pod的资源量。

8.根据权利要求6或7所述的装置，其特征在于，所述容器管理集群中包括至少一类资源；

所述第一确定模块，还用于：确定容器管理集群中每类资源的资源总量；

所述第二确定模块，还用于：确定每个应用对应的每类资源的已分配资源量和相应类型资源的资源总量的比值。

9.根据权利要求8所述的装置，其特征在于，所述应用确定模块，还用于：

对于每个应用：将该应用的每类资源的已分配资源量和该类型资源的资源总量的比值中的最大值，确定为该应用的比值；

从所述每个应用的比值中选择最小值，将所述最小值对应的应用确定所述比值最小的应用。

10.根据权利要求8所述的装置，其特征在于，所述每个应用对应的一个Pod的资源量包括：所述每类资源的预设资源量；

所述判断模块，还用于：针对所述每类资源：计算所有应用的已分配资源量之和；

若针对任一类资源的所述已分配资源量之和大于该类资源的资源总量，则确定所述判断结果为是；

若针对每类资源的所述已分配资源量之和均小于或等于相应类资源的资源总量，则所述判断结果为否。

11.一种服务器，其特征在于，包括处理器和机器可读存储介质，所述机器可读存储介质存储有能够被所述处理器执行的机器可执行指令，所述处理器执行所述机器可执行指令以实现权利要求1至5任一项所述的方法。

12.一种机器可读存储介质，其特征在于，所述机器可读存储介质存储有机器可执行指令，所述机器可执行指令在被处理器调用和执行时，所述机器可执行指令促使所述处理器实现权利要求1至5任一项所述的方法。