CN109783218A - 一种基于Kubernetes容器集群的与时间相关联的容器调度方法 - Google Patents

Abstract

本发明公开了一种基于Kubernetes容器集群的与时间相关联的容器调度方法，属于云计算技术领域。本发明在Kubernetes集群的调度器的预选策略和优选策略这两个阶段之间加入是否在时间范围内的判断，并通过对预选过后的可使用的Node进行平均负载得分的计算，将其与预设定得分进行比对，可以决定是否进行进一步的调度操作，这不仅保证了现有业务应用的正常运行，也使得某些具有时间相关性的任务能够更好的利用集群内的资源。例如在深夜凌晨时段，是大部分业务应用负载不那么重的时段，这时是很适合一些大数据离线计算任务的，在这个时段内将这些任务分配到前述业务应用所在Node上，将会有助于提升大数据任务的运行效率，还能提高集群内的硬件资源利用率。

Description

一种基于Kubernetes容器集群的与时间相关联的容器调度 方法

技术领域

本发明涉及一种软件资源调度方法，特别是一种基于Kubernetes容器集群的与时间相关联的容器调度方法，属于云计算技术领域。

背景技术

Kubernetes，简称K8s，是用8代替8个字符“ubernete”而成的缩写，是一个基于容器技术的分布式架构平台。Kubernetes为容器应用提供了服务注册、负载均衡、服务部署和运行、服务滚动升级、在线扩容和缩容、资源调度、资源配额管理等功能，可以说Kubernetes具备完备的集群管理能力，贯串分布式系统开发、测试、部署、运维监控各个环节。

基于Kubernetes对软件资源调度管理的方法一般为：

1)通过人工操作进行资源的伸缩管理，如手动将pod进行扩容或缩容，对人依赖性强，已逐渐被淘汰；

2)基于软件性能指标的资源管理HPA，如根据当前运行的pod的cpu占用和内存占用来调整pod的数量，实现了自动扩容和缩容功能，但其无法将pod精确安排到特定Node上，因此不能根据具体业务的特性和时间对pod资源进行有效地调度。

例如：业务应用的pod是计算密集型的，先根据HPA的配置将应用的pod自动进行扩展，再根据集群本身的调度策略将pod平均分布到调度得分较高的Node上。与此同时，若有一个I/O密集型的应用也同时进行自动扩展时，通过kubernetes集群的默认调度系统，其会更容易调度到得分较高的Node上。意味着后者的密集型应用没有运行前者计算密集型应用的pod的Node，不仅无法对pod资源进行有效地调度，还会导致CPU、内存和I/O等资源均未能够较适宜地分配给需要的应用，导致某些硬件资源的浪费。

发明内容

本发明的发明目的是，针对上述问题，提供一种基于Kubernetes容器集群的与时间相关联的容器调度方法，该调度方法能够根据软件应用的具体业务特性和软件性能与时间相关性来自动进行硬件资源的控制，以使硬件资源能够得到充分利用。

为达到上述目的，本发明所采用的技术方案是：

一种基于Kubernetes容器集群的与时间相关联的容器调度方法，所述Kubernetes包括应用程序接口服务器、控制器管理控制中心、调度器、节点管理进程和分布式数据库，在所述Kubernetes加载并运行有若干个Node，容器调度方法包括如下步骤：

S1、在预设定的时间段内，先从Kubernetes集群获得调度器经过预选策略后剩下的Node的负载情况，然后计算出每个Node的平均负载得分；

S2、将步骤S1中计算得到的平均负载得分与预设目标得分进行比对，若低于预设目标得分，则不对该资源进行调度，退出调度流程且间隔预定时间后执行步骤S1；反之，对该资源进行调度，并执行步骤S3；

S3、通过执行Kubernetes集群内调度器默认的优选策略，以对该应用的pod进行调度，直至达到预设定的目标pod数；

S4、在执行步骤S1～S3过程，若超出步骤S1预定的时间时，对该应用的pod进行缩容操作，且将步骤S3中新增的pod进行销毁并回收资源。

作为优选实施方式，步骤S1中的预设定的时间段具体是从deployment配置里的annotations的timeRange字段获得的一个时间范围。

作为优选实施方式，步骤S2和步骤S3中的预设目标得分具体是从deployment配置里的annotations的targetScore字段获得的一个数字。

作为优选实施方式，步骤S3中的预设定的目标pod数具体是从deployment配置里的annotations的targetReplica字段获得的一个数字。

作为优选实施方式，步骤S1具体包括如下执行步骤：

S11、对Kubernetes集群内的每个Node执行Kubernetes集群内的调度器中的预选策略，即得到若干个可进行调度的Node列表；

S12、遍历步骤S11得到的若干个可进行调度的Node列表，计算出每个Node的负载得分；其中，Node得分＝cpu{[capacity–sum(requested)]*10/capacity}+memory{[capacity–sum(requested)]*10/capacity}/2，每个Node的平均负载得分通过将所有Node得分相加后求平均值得到。

作为优选实施方式，步骤S3具体包括如下执行步骤：

S31、首先通过调度器将步骤S1计算得到的平均负载得分与预设目标得分进行比对后，得到大于目标得分的结果，并显示出该平均负载得分；

S32、然后调度器向应用程序接口服务器发出请求信号，应用程序接口服务器将该状态信息记录至分布式数据库中；

S33、调度器继续执行后续默认的优选策略，对能调度到的Node依次计算出一个分数，选取得分最高的Node和pod进行绑定操作，并向应用程序接口服务器发送请求，应用程序接口服务器将该信息写入分布式数据库；

S34、节点管理进程通过和应用程序接口服务器的Watch机制，获得绑定到其所在Node的pod列表，并在该Node上创建容器。

作为优选实施方式，步骤S4具体包括如下执行步骤：

S41、调度器调取预设定的时间段，并根据该时间段的起止时间点来自动判断现在的时间是否在范围内；

S42、当超出配置中预设定的时间范围市，调度器向应用程序接口服务器发送缩容请求，将pod数量缩减为deloyment初始配置的replica字段配置的数量，应用程序接口服务器对应将该状态信息记录至分布式数据库中。

作为优选实施方式，所述预设目标得分取0～10之间的数值。

由于采用上述技术方案，本发明具有以下有益效果：

1.本发明在Kubernetes集群的调度器的预选策略(Predicates)和优选策略(Priorities)这两个阶段之间加入是否在时间范围内的判断，并通过对预选过后的可使用的Node进行平均负载得分的计算，将其与预设定得分进行比对，可以决定是否进行进一步的调度操作，这不仅保证了现有业务应用的正常运行，也使得某些具有时间相关性的任务能够更好的利用集群内的资源。例如在深夜凌晨时段，是大部分业务应用负载不那么重的时段，这时是很适合一些大数据离线计算任务的，在这个时段内将这些任务分配到前述业务应用所在Node上，将会有助于提升大数据任务的运行效率，还能提高集群内的硬件资源利用率。

2.本发明在步骤S1中预设定的时间段的设置，使系统在调度过程可根据自身业务应用情况规划一些定时任务的运行时间，步骤S2预设目标得分的设置能够保证现有正在运行的业务应用有足够资源运行，步骤S3预设定的目标pod数设置，即Kubernetes集群在调度时，只有满足步骤S1和步骤S2这两个设置条件后，应用pod才会自动扩展数量并调度到集群内。这样使得Kubernetes集群能自动根据软件应用的具体业务特性和软件性能与时间关联性来对pod资源进行有效地调度，避免浪费资源的情况。

3.采用本发明的调度方法在调度时，即使Kubernetes集群内整体的负载较高的情况下，也不会影响运行中的现有应用pod性能，整个Kubernetes容器管理集群的运行稳定性高。

附图说明

图1是本发明一种基于Kubernetes容器管理集群的时间相关容器调度方法的步骤流程图。

图2是Kubernetes容器管理集群的一种集成框架示意图。

图3是图1中步骤3的执行示意框图。

具体实施方式

以下结合附图对发明的具体实施进一步说明。

如图2所示，本领域技术人员应该知晓，Kubernetes组件由两类节点组成，分别为Master和Node。这两类节点由五种主要的组件构成，这五种组件分别为应用程序接口服务器(API Server)、控制器管理控制中心(Controller Manager)、调度器(Scheduler)、Kubelet(节点管理进程)、分布式数据库(Etcd)，它们之间协同工作从而完成整个集群的管理。其中，Master节点用于控制整个集群大脑，它包括Apiserver、Scheduler、ControllerManager、Etcd组件。而Node节点包含2个组件，分别为Kubelet和Kubeproxy；且Node节点是Kubernetes集群中真正的工作负载节点。即Kubernetes集群由多个Node共同承担工作负载(即图2中的WorkerNode)，pod被分配到某个具体的node上执行。

本实施例中，具体采用3个Master Node(即Master Node1、Master Node2和MasterNode3)作为控制节点，控制节点不负责运行工作负载，只有部分的Kubernetes组件以容器的形式运行在所述控制节点上。所述的部分的Kubernetes组件具体包括应用程序接口服务器(API Server)、控制器管理控制中心(Controller Manager)和调度器(Scheduler)。每个MasterNode上的应用程序接口服务器(APIServer)均与分布式数据库(Etcd)连接，用于集群内各种资源配置和状态存储。

如图2所示，每个Kubernetes集群包含n个WorkerNode，其上运行有n个pod，每个pod有n个容器，n代表多个并不具体限定数量。所述多个具体是指2个以上。

如图1所示，一种基于Kubernetes容器管理集群的时间相关容器调度方法，由以下步骤组成:

执行步骤S1，在预设定的时间段内，从Kubernetes集群获得调度器(Scheduler)经过预选策略(Predicates)后剩下的Node的负载情况，计算得到每个Node的平均负载得分。其中预设定的时间段是从deployment配置里的annotations的timeRange字段获得的一个时间范围。

在上述步骤中，本领域技术人员应当知晓：annotation是k8s原生带有的特性，annotation相当于一些需要特别存储的数据。本发明对于预设定的时间段的实现，具体是通过修改controllermanager内的deploymentcontroller代码，在部署pod阶段就将该数值作为一个定时调度的任务的调度周期使用，当检测到进入该时段时，任务将会被拉起，执行扩容pod到指定的预设定的目标pod数即可。所述预设定的时间段应当设定为业界通用的cron表达式的形式，有个起始时间和结束时间，例如“0 0 8**？*-0 0 9**？*”，表示每天的8点至9点的时段。

结合图2和图3所述，上述步骤S1具体包括如下执行步骤：

S11、对Kubernetes集群内的每个Node执行集群内默认的调度器(Scheduler)的预选策略，得到可进行调度的Node列表；

本实施例中，调度器默认的预选策略(即Predicates)有13种，分别为NoDiskConflict、NoVolumeZoneConflict、PodFitsResources、PodFitsHostPorts、HostName、MatchNodeSelector、MaxEBSVolumeCount、MaxGCEPDVolumeCount、MaxAzureDiskVolumeCount、CheckNodeMemoryPressure、CheckNodeDisckPressure、PodToleratesNodeTaints、MatchInterPodAffinit，通过上述13种预选策略检测的Node，作为可进行调度的Node列表。

S12.遍历可进行调度的Node列表，计算出每个Node的负载得分；其中，Node得分＝cpu{[capacity–sum(requested)]*10/capacity}+memory{[capacity–sum(requested)]*10/capacity}/2，每个Node的平均负载得分是通过将所有Node得分相加后所求的平均值而得到。

执行步骤S2，将步骤S1中计算得到的平均负载得分与预设目标得分进行比对，若低于目标得分，则不对该资源进行调度，并退出调度流程且间隔预定时间后执行上述步骤S1。反之，对该资源进行调度，并执行如下步骤S3。

步骤S2和步骤S3中的预设目标得分具体是从deployment配置里的annotations的targetScore字段获得的一个数字。调度器(Scheduler)在进行pod的调度时，能够通过工具取到该pod的annotation信息。所述预设目标得分应该取0～10之间的数字，所述可以是整数数值或带有小数部分的非整数数值。所述计算得到的平均负载得分表示的数字越大代表该节点的资源越充足，即节点的负载较低。若设定的目标的分越高，说明可以调度负载较高的应用到该节点。

步骤S3具体是：执行Kubernetes集群内调度器(Scheduler)默认的优选策略对该应用的pod进行调度，最终到达预设定的目标pod数。所述预设定的目标pod数只需要根据自身需要设定数量即可，步骤S31～S34的扩容操作最终的目标是能够达到预设定的目标pod数，以实现一种可控的状态，做到在预设定的时间段内，将预设定的目标pod数的pod，运行到符合预设目标得分的node上。

结合图2和图3，该步骤S3具体如下：

S31、首先通过调度器(Scheduler)将步骤S1计算得到的平均负载得分与预设目标得分进行比对后，得到大于目标得分的结果，并显示出该平均负载得分；

S32、然后调度器(Scheduler)向应用程序接口服务器(APIServer)发出请求信号，应用程序接口服务器(API Server)会将状态信息记录至分布式数据库(Etcd)中；

S33、调度器(Scheduler)继续执行后续默认的优选策略，对能调度到的Node依次计算出一个分数，选取得分最高的Node和pod进行绑定操作，并向应用程序接口服务器(APIServer)发送请求，应用程序接口服务器(APIServer)将信息写入分布式数据库(Etcd)；

S34、节点管理进程(Kubelet)通过和应用程序接口服务器(APIServer)的Watch机制，获得绑定到其所在Node的pod列表，并在该Node上创建容器。

执行步骤S4，当超出预定的时间段时，对该应用的pod进行缩容操作，将步骤S3中新增的pod进行销毁并回收资源。

对于时间段的实现如步骤S1所述，即通过deploymentcontroller拉起的定时任务，去设定当前时段应该运行的pod数量，当超出时段后，将pod数量设定为初始的状态，一般为缩容。所述缩容操作具体是通过apiserver去将数据存储到分布式数据库(Etcd)中，当kubeletwatch到pod数量的改变后即执行具体的删除容器的操作。

上述步骤S4具体的执行过程如下：

S41、调度器(Scheduler)会从deployment配置里的annotations选项的timeRange字段获得一个时间范围，并判断现在的时间是否在范围内；S42、当超出配置中预设定的时间范围，调度器(Scheduler)向应用程序接口服务器(APIServer)发送缩容请求，将pod数量缩减为deloyment初始配置的replica字段配置的数量，应用程序接口服务器(API Server)会将状态信息记录至分布式数据库(Etcd)中。

如图3所示，本发明在预选策略(即Predicates)和优选策略(即Priorities)之间插入了一个平均负载得分和预设目标得分这一比对过程，用以结合定时执行的任务，具体通过预设的时间段来完成，使得Kubernetes集群在调度时，在不影响现有业务应用的前提下，有效地利用集群的硬件资源。

并且采用本发明的Kubernetes集群容器调度方法，相对于现有技术能够有效提高Kubernetes容器管理集群的运行稳定性，理由为：

例如授权公告号为CN106027643B的中国发明专利公开的一种基于Kubernetes容器集群管理系统的资源调度方法，其所使用的方法是先计算每一个可调度到的Node的得分，通过对比每个node的得分，并将pod调度到获得最高分的node上。这一方法是存在一定的局限性，因为当集群整体负载较高时，系统仍会继续将pod调度到集群上，造成现有应用pod的性能降低，影响pod正常运行。而本发明通过步骤S1预设定时间段和步骤S2预设目标得分这两个指标，当满足这两个指标后，再通过步骤S3预设定的目标pod数这一指标来决定是否将该应用pod扩展到得分最高的Node上。即满足了才调度，否则不调度。即便集群整体负载较高时，也能合理对资源进行调度，不影响现行应用pod的运行速度，避免了容器集群出现崩溃或卡死的情况。因此，本集群调度方法能够在合适的时段将指定数量的pod运行到满足要求的节点上，达到保障现有业务的稳定运行，能充分利用系统资源运行定时任务的目的，从而大大改善现有的默认调度模式存在的缺陷。

上述说明是针对本发明较佳可行实施例的详细说明，但实施例并非用以限定本发明的专利申请范围，凡本发明所提示的技术精神下所完成的同等变化或修饰变更，均应属于本发明所涵盖专利范围。

Claims (8)

1.一种基于Kubernetes容器集群的与时间相关联的容器调度方法，所述Kubernetes包括应用程序接口服务器、控制器管理控制中心、调度器、节点管理进程和分布式数据库，在所述Kubernetes加载并运行有若干个Node，所述容器调度方法包括如下步骤：其特征在于：

S1、在预设定的时间段内，先从Kubernetes集群获得调度器经过预选策略后剩下的Node的负载情况，然后计算出每个Node的平均负载得分；

S2、将步骤S1中计算得到的平均负载得分与预设目标得分进行比对，若低于预设目标得分，则不对该资源进行调度，退出调度流程且间隔预定时间后执行步骤S1；反之，对该资源进行调度，并执行步骤S3；

S3、通过执行Kubernetes集群内调度器默认的优选策略，以对该应用的pod进行调度，直至达到预设定的目标pod数；

S4、在执行步骤S1～S3过程，若超出步骤S1预定的时间时，对该应用的pod进行缩容操作，且将步骤S3中新增的pod进行销毁并回收资源。

2.根据权利要求1所述的一种基于Kubernetes容器集群的与时间相关联的容器调度方法,其特征在于：步骤S1中的预设定的时间段具体是从deployment配置里的annotations的timeRange字段获得的一个时间范围。

3.根据权利要求1所述的一种基于Kubernetes容器集群的与时间相关联的容器调度方法,其特征在于：步骤S2和步骤S3中的预设目标得分具体是从deployment配置里的annotations的targetScore字段获得的一个数字。

4.根据权利要求1所述的一种基于Kubernetes容器集群的与时间相关联的容器调度方法,其特征在于：步骤S3中的预设定的目标pod数具体是从deployment配置里的annotations的targetReplica字段获得的一个数字。

5.根据权利要求1所述的一种基于Kubernetes容器集群的与时间相关联的容器调度方法,其特征在于，步骤S1具体包括如下执行步骤：

S11、对Kubernetes集群内的每个Node执行Kubernetes集群内的调度器中的预选策略，即得到若干个可进行调度的Node列表；

S12、遍历步骤S11得到的若干个可进行调度的Node列表，计算出每个Node的负载得分；其中，Nod得分＝cpu{[capacity–sum(requested)]*10/capacity}+memory{[capacity–sum(requested)]*10/capacity}/2，每个Node的平均负载得分通过将所有Node得分相加后求平均值得到。

6.根据权利要求1所述的一种基于Kubernetes容器集群的与时间相关联的容器调度方法,其特征在于，步骤S3具体包括如下执行步骤：

S31、首先通过调度器将步骤S1计算得到的平均负载得分与预设目标得分进行比对后，得到大于目标得分的结果，并显示出该平均负载得分；

S32、然后调度器向应用程序接口服务器发出请求信号，应用程序接口服务器将该状态信息记录至分布式数据库中；

S33、调度器继续执行后续默认的优选策略，对能调度到的Node依次计算出一个分数，选取得分最高的Node和pod进行绑定操作，并向应用程序接口服务器发送请求，应用程序接口服务器将该信息写入分布式数据库；

S34、节点管理进程通过和应用程序接口服务器的Watch机制，获得绑定到其所在Node的pod列表，并在该Node上创建容器。

7.根据权利要求1所述的一种基于Kubernetes容器集群的与时间相关联的容器调度方法,其特征在于，步骤S4具体包括如下执行步骤：

S41、调度器调取预设定的时间段，并根据该时间段的起止时间点来自动判断现在的时间是否在范围内；

S42、当超出配置中预设定的时间范围市，调度器向应用程序接口服务器发送缩容请求，将pod数量缩减为deloyment初始配置的replica字段配置的数量，应用程序接口服务器对应将该状态信息记录至分布式数据库中。

8.根据权利要求1所述的一种基于Kubernetes容器集群的与时间相关联的容器调度方法,其特征在于：所述预设目标得分取0～10之间的数值。