CN106027643B - 一种基于Kubernetes容器集群管理系统的资源调度方法 - Google Patents

Abstract

本发明提供了一种基于Kubernetes容器集群管理系统的资源调度方法，包括以下步骤S1、遍历所有可用Node，并计算每个可用Node的计算资源得分；S2、通过日志系统采集每个可用Node的网络存储平均传输速率与所有可用Node的网络存储平均传输速率总和；S3、计算每个可用Node的网络存储平均传输速率得分；S4、根据步骤S1中的每个可用Node的计算资源得分与步骤S3中的网络存储平均传输速率得分，计算出可用Node的优先级，并在优先级最高的Node上创建并运行Pod。在本发明中，调度器加入了网络存储平均传输速率得分，并结合可用Node的计算资源得分计算得到可用Node的优先级，将新Pod调度到具有最高优先级的可用Node上，从而提高了新建Pod的速率并提高了容器运行的效率与稳定性。

Description

一种基于Kubernetes容器集群管理系统的资源调度方法

技术领域

本发明涉及云计算技术领域，尤其涉及一种Kubernetes容器集群管理系统的资源调度方法。

背景技术

Docker是一个开源的应用容器引擎，让开发者可以打包应用以及依赖包到一个可移植的容器中，然后发布到Linux机器上。容器使用沙箱机制，相互之间不会有任何接口，几乎没有性能开销，可以很容易地在主机和数据中心中运行。

Kubernetes容器集群管理系统的主要功能包括：使用Docker对应用程序进行打包、实例化及运行；以集群的方式运行及管理跨主机的容器；解决位于不同主机之间所运行的容器之间的通信问题等等。其中，Scheduler(调度器)是Kubernetes容器集群管理系统中加载并运行的调度程序，其负责收集、统计分析容器集群管理系统中所有Node的资源使用情况，然后以此为依据将新建的Pod发送到优先级最高的可用Node上去建立。

现有的Scheduler在选择优先级最高的可用Node时，使用的策略是：比较“新建Pod需要的CPU和内存+正在运行的Pod请求的CPU和内存”和“Node可提供的CPU和内存”，比较结果值最小的可用Node作为运行Pod的节点。

但是现有Kubernetes容器集群管理系统的资源调度没有考虑下面的情况：当调度结束以后，还需要进行两个基本的步骤，才能确保容器集群的基本运行：其一：Node需要到镜像库中下载“Pod中包含的容器所需要的镜像”，而镜像的下载速率直接影响到业务的启动速度。其二：当Pod成功运行后，Pod中的容器需要挂载持久化存储，从而来存取数据，持久化存储与Node之间的网络速率，直接影响到容器中所运行的应用的IO速率。

发明内容

本发明的目的在于公开一种基于Kubernetes容器集群管理系统的资源调度方法，用以完善Kubernetes容器集群管理系统的资源调度策略，加速Pod的建立，使Pod中的一个或者多个容器能够高效、稳定的运行。

为实现上述目的，本发明提供了一种基于Kubernetes容器集群管理系统的资源调度方法，所述容器集群管理系统加载并运行有若干个Node，包括以下步骤：

S1、遍历所有可用Node，并计算每个可用Node的计算资源得分；

S2、通过日志系统采集每个可用Node的网络存储平均传输速率与所有可用Node的网络存储平均传输速率总和，并以时间戳和数据的形式记录于日志系统；

S3、计算每个可用Node的网络存储平均传输速率得分；

S4、根据步骤S1中的每个可用Node的计算资源得分与步骤S3中的网络存储平均传输速率得分，计算出可用Node的优先级，并在优先级最高的Node上创建并运行Pod。

在实施方式中，步骤S2中的“网络存储平均传输速率”包括：

每个可用Node与镜像存储系统之间所形成的镜像网络存储平均传输速率，以及，

每个可用Node与持久化存储系统之间所形成的持久化网络存储平均传输速率。

在实施方式中，步骤S1中的“计算资源”包括Memory资源及CPU资源。

在实施方式中，步骤S1具体为：

S11、遍历所有可用Node，对每个可用Node上已经调度运行的所有Pod请求所需的Memory资源和CPU资源进行求和；

S12、对待创建的Pod请求所需的Memory资源和CPU资源进行求和，加上S11中得出的对应的Memory和CPU的值，并以int64型的整数totalMemory和int64型的整数totalMilliCPU进行返回；

S13、再次遍历所有可用Node，并计算每个可用Node的Memory资源和CPU资源的总量，并以int64型的整数capacityMemory和int64型的整数capacityMilliCPU进行返回；

S14、分别计算每个可用Node的CPU得分和Memory得分；其中，CPU得分＝int(((capacityMilliCPU-totalMilliCPU)*10)/capacityMilliCPU)；Memory得分＝int(((capacityMemory-totalMemory)*10)/capacityMemory)；如果totalMilliCPU的值大于capacityMilliCPU或者totalMemory的值大于capacityMemory的值，则直接返回CPU得分为0或者Memory得分为0。

与现有技术相比，本发明的有益效果是：调度器加入了网络存储平均传输速率得分，并与可用Node的计算资源得分共同计算得到可用Node的优先级，将Pod调度到优先级最高的Node上，从而提高了新建Pod的速率并提高了容器运行的效率与稳定性，增强了调度器对基于Kubernetes容器集群管理系统中的资源调度效率。

附图说明

图1为本发明一种基于Kubernetes容器集群管理系统的资源调度方法的流程图；

图2为获取每个可用Node与镜像存储系统之间的网络存储平均传输速率的逻辑组件的示意图；

图3为获取每个可用Node与持久化存储系统之间的网络存储平均传输速率的逻辑组件的示意图；

图4为将iSCSI Target作为后端的存储装置中获取网络存储平均传输速率的具体实施方式中的逻辑组件的示意图；

图5为将GlusterFS作为后端的存储装置中获取网络存储平均传输速率的具体实施方式中逻辑组件的示意图。

具体实施方式

下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。

本说明书中的各个实施例示出了本发明一种基于Kubernetes容器集群管理系统的资源调度方法的具体实现方法。该资源调度方法基于开源的容器集运管理系统，其可改善现有的Kubernetes系统中的调度器的调度策略，使Pod能够被调度到优先级最高的可用节点(Node)上，从而改善Kubernetes容器集群的整体性能，尤其是能够增强Pod中的容器(Container)在实际运行时的IO读写速率，消除存储瓶颈。Pod是Kubernetes容器集群管理系统能调度的最小单位，Kubernetes将具体应用抽象为Pod，一个Pod包含一个或多个容器。具体的，请参图2至图5所示，容器211至容器21i中的一个或者多个容器可以组成一个Pod。其中，“i”在本说明书实施例中指代为复数，并不具体的限定容器数量的上限。

实施例一：

如图1至图4所示出的本发明的第一种具体实施方式。

在本实施方式中通过iSCSI的方式建立了位于后端的存储系统40，该存储系统40包括镜像存储系统11与持久化存储系统12，并通过iSCSI Target端42与iSCSI Initiator端41a通信。iSCSI Target端42为磁盘阵列或其他装有磁盘的主机。通过iSCSI Target端42将磁盘空间映射到网络上，iSCSI Initiator 41a就可以寻找发现并使用该磁盘。iSCSITarget端42是位于iSCSI服务器上的存储资源，提供服务器上的存储资源共享。

Kubernetes容器集群管理系统的资源调度方法，为简化表示，本说明书附图均仅示出一个Node20，其运行有容器21。如图3及图4所示，Node20上运行有i个容器，即容器211至容器21i。在本说明书中“i”代表多个并不具体限定容器21数量的上限。

如图1所示，该基于Kubernetes容器集群管理系统的资源调度方法包括以下步骤：

首先执行步骤S1、遍历所有可用Node，并计算每个可用Node的计算资源得分。其中，步骤S1中的“计算资源”包括Memory资源及CPU资源。

结合图2至图4所示，该步骤S1具体为：

S11、调度器101遍历所有可用Node，对每个可用Node上已经调度运行的所有Pod请求所需的Memory资源和CPU资源这些计算资源进行求和。调度器101位于Master10。Master又称为“主节点”，而图2及图3中的Node20均称之为“从节点”(Slaver)。调度器101向Kubelet202发送请求操作，从而去确定Memory资源和CPU资源。

为了克服现有技术中的调度器101所采用的传统的三种调度策略(即LeastRequestedPriority调度策略、ServiceSpreadingPriority调度策略和EqualPriority调度策略)所存在缺陷，在本发明中，加入了网络存储平均传输速率的策略。该网络存储平均传输速率包括：每个可用Node20与镜像存储系统11之间所形成的镜像网络存储平均传输速率，以及，每个可用Node20与持久化存储系统12之间所形成的持久化网络存储平均传输速率。容器21在正常运行之后，容器中的数据需要保持在持久化存储系统12上，容器21与持久化存储系统12之间的网络存储传输速率决定了容器21所含应用的读写速率。

S12、对待创建的Pod请求所需的Memory资源和CPU资源进行求和，加上S11中得出的对应的Memory和CPU的值，并以int64型的整数totalMemory和int64型的整数totalMilliCPU进行返回；

S13、再次遍历所有可用Node，并计算每个可用Node的Memory资源和CPU资源的总量，并以int64型的整数capacityMemory和int64型的整数capacityMilliCPU进行返回；

S14、分别计算每个可用Node的CPU得分和Memory得分；其中，CPU得分＝int(((capacityMilliCPU-totalMilliCPU)*10)/capacityMilliCPU)；Memory得分＝int(((capacityMemory-totalMemory)*10)/capacityMemory)；如果totalMilliCPU的值大于capacityMilliCPU或者totalMemory的值大于capacityMemory的值，则直接返回CPU得分为0或者Memory得分为0。

然后执行步骤S2、通过日志系统201采集每个可用Node20的网络存储平均传输速率与所有可用Node的网络存储平均传输速率总和，并以时间戳和数据的形式记录于日志系统201。

如图2所示，Client22与镜像存储系统11通信，日志系统201通过资源管理器(例如Kubelet202)采集可用Node20在获取镜像时，所形成的Client22与后端镜像存储系统11之间的网络存储平均传输速率与网络存储平均传输速率总和。同理如图3所示，在本实施方式中，也可采用相同方法，日志系统201通过资源管理器(例如Kubelet202)采集可用Node20中所形成的容器21与后端的存储系统40中所形成的持久化存储系统12之间的网络存储平均传输速率与网络存储平均传输速率总和。

具体的，可通过日志系统201统计出每个Node 20与镜像存储系统11之间的镜像网络存储平均传输速率，记作：imageNetAverageRate；统计出每个Node 20与持久化存储系统12之间的持久化网络存储平均传输速率，记作：dataNetAverageRate。然后，通过日志系统201统计出所有Node的镜像网络存储平均传输速率总和，记作：totalImageNetAverageRate；统计出所有Node持久化网络存储平均传输速率总和，记作：totalDataNetAverageRate。

然后，执行步骤S3、计算每个可用Node的网络存储平均传输速率得分。其中，步骤S3具体为：每个Node的镜像网络存储的平均传输速率得分，计作：imageRateScore，每个Node的持久化网络存储的平均传输速率得分，计作dataRateScore；其中，imageRateScore＝int((imageNetAverageRate*10)/totalImageNetAverageRate)；dataRateScore＝int((dataNetAverageRate)*10)/totalDataNetAverageRate)。

最后，执行步骤S4、根据步骤S1中的每个可用Node的计算资源得分与步骤S3中的网络存储平均传输速率得分，计算出可用Node的优先级，并在优先级最高的Node上创建并运行Pod。具体的，该可用Node的优先级得分计作score。

该score＝int((cpuScore+memoryScore+imageRateScore+dataRateScore)/2)。

综上所述，最终确定被创建并运行新Pod的优先级的得分score按照下述计算公式(1)得到：

公式(1)

如图4所示，在本实施方式中，首先在Master10中部署调度器101，并在Node20中部署iSCSI Initiator41a、日志系统201、Kubelet202以及容器21。其中，调度器101与Kubelet202相通信，iSCSI Initiator41a与后端的存储系统40中的iSCSI Target端42相通信。Kubelet202是一种资源管理器，其主要执行容器管理、镜像管理及Volume管理。Node20上运行有多个容器21。iSCSI Initiator 41a与iSCSI Target端42之间的网络存储平均传输速率被记录在日志系统201中。在本实施方式中，iSCSI Initiator41a的作用相当于图2或者图3中的Client22。iSCSI Target端42的作用相当于图2或者图3中的主机30。

在新增Pod的过程中，调度器101的调度策略被分成两个阶段：Predicates阶段和Priorities阶段。其中，Predicates阶段回答“能不能”的问题，即能否将Pod调度到特定的Node上运行，这一阶段输出的所有满足要求的Node将被记录并作为第二阶段的输入。

Predicates阶段包括五个调度策略：PodFitsPorts、PodFitsResources、NoDiskConflict、MatchNodeSelector和HostName，即需要经过上述5个Predicates的检验，才能确定为“能被调度到的Node”。如其中的PodFitsPorts规则，它所评估的依据就是端口是否冲突，即检测待调度的Pod中所有容器要用到的端口集对应的HostPort集与Node上已使用的端口是否冲突。而Priorities则是在Predicates的基础上回答“哪个可用Node最优先”的问题。

Priorities阶段包括三个调度策略：LeastRequestedPriority(最少请求资源优先调度策略)、ServiceSpreadingPriority(最小相同服务优先调度策略)和EqualPriority(平等优先调度策略)。即按照LeastRequestedPriority、ServiceSpreadingPriority和EqualPriority三个调度策略，给Predicates阶段筛选出来的所有Node打分，并评出优先级，优先级最高的Node作为Pod被调度的目的节点。

具体如下：LeastRequestedPriority的计算原则是尽量将需要新创建的Pod调度到计算资源占用比较小的Node上，这里的“计算资源”指CPU资源和Memory资源；ServiceSpreadingPriority的计算原则是使同一个Node上属于相同服务的Pod数量尽量少，这样调度的Pod能够尽可能地实现服务的高可用性和流量负载均衡；EqualPriority的计算原则是平等对待Predicates阶段筛选出来的每一个可用Node。

当调度器101完成Predicates阶段的计算资源调度后根据上述计算公式(1)计算得到所有能被使用的Node20的score(得分)。最后，根据得分最高的Node作为新增并运行Pod的机器。

在本实施方式中，在调度器101中增加镜像存储系统11的网络存储平均传输速率的调度策略可以提高新建Pod的速率，而在调度器101中增加持久化存储系统12的网络存储平均传输速率的调度策略可以提高被创建的Pod中所包含的一个或者多个容器运行时的效率与稳定性。

实施例二：

请参图1至图3及图5所示出的本发明所示出的一种基于Kubernetes容器集群管理系统的资源调度方法的第二种具体实施方式。

在本实施方式中，Fuse Mount41b的作用相当于图2或者图3中的Client22。GlusterFS43的作用相当于图2或者图3中的主机30。

在本实施方式中，Fuse Mount41b与后端的存储系统40中的GlusterFS43相通信。Fuse是“file system in user space”的缩写，其代表一个用户空间的文件系统框架，允许非特权用户建立功能完备的文件系统，而不需要重新编译内核。

在本实施方式中，首先，在Master10中部署调度器101，并在Node20中部署FuseMount41b。Node20上部署并运行有多个容器21、Kubelet202及日志系统201。Fuse Mount41b与GlusterFS43之间的网络存储传输速率被记录在日志系统201中。当调度器101完成Predicates阶段的调度后，选出所有能被GlusterFS43调用的Node20(即可用Node)。然后，根据实施例一中的计算公式(1)计算得到所有能被使用的Node20的score(得分)。最后，根据得分最高的Node作为新增并运行Pod的机器。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (2)

1.一种基于Kubernetes容器集群管理系统的资源调度方法，所述Kubernetes容器集群管理系统加载并运行有若干个Node，其特征在于，包括以下步骤：

S1、遍历所有可用Node，并计算每个可用Node的计算资源得分；

S2、通过日志系统采集每个可用Node的网络存储平均传输速率与所有可用Node的网络存储平均传输速率总和，并以时间戳和数据的形式记录于日志系统；

S3、计算每个可用Node的网络存储平均传输速率得分；

S4、根据步骤S1中的每个可用Node的计算资源得分与步骤S3中的网络存储平均传输速率得分，计算出可用Node的优先级，并在优先级最高的Node上创建并运行Pod；

所述步骤S1中的“计算资源”包括Memory资源及CPU资源；

所述步骤S3具体为：每个Node的镜像网络存储的平均传输速率得分，计作：imageRateScore，每个Node的持久化网络存储的平均传输速率得分，计作dataRateScore；其中，imageRateScore＝int((imageNetAverageRate*10)/totalImageNetAverageRate)；dataRateScore＝int((dataNetAverageRate)*10)/totalDataNetAverageRate)；

可用Node的优先级得分计作score，

该score＝int((cpuScore+memoryScore+imageRateScore+dataRateScore)/2)，最终确定被创建并运行新Pod的优先级的得分score按照下式得到：

所述步骤S2中的“网络存储平均传输速率”包括：

每个可用Node与镜像存储系统之间所形成的镜像网络存储平均传输速率，以及，

每个可用Node与持久化存储系统之间所形成的持久化网络存储平均传输速率。

2.根据权利要求1所述的Kubernetes容器集群管理系统的资源调度方法，其特征在于，所述步骤S1具体为：

S11、遍历所有可用Node，对每个可用Node上已经调度运行的所有Pod请求所需的Memory资源和CPU资源进行求和；

S12、对待创建的Pod请求所需的Memory资源和CPU资源进行求和，加上S11中得出的对应的Memory和CPU的值，并以int64型的整数totalMemory和int64型的整数totalMilliCPU进行返回；

S13、再次遍历所有可用Node，并计算每个可用Node的Memory资源和CPU资源的总量，并以int64型的整数capacityMemory和int64型的整数capacityMilliCPU进行返回；

S14、分别计算每个可用Node的CPU得分和Memory得分；其中，CPU得分＝int(((capacityMilliCPU-totalMilliCPU)*10)/capacityMilliCPU)；Memory得分＝int(((capacityMemory-totalMemory)*10)/capacityMemory)；如果totalMilliCPU的值大于capacityMilliCPU或者totalMemory的值大于capacityMemory的值，则直接返回CPU得分为0或者Memory得分为0。