CN111522639B - Kubernetes集群架构系统下多维资源调度方法 - Google Patents

Abstract

本发明提供一种Kubernetes集群架构系统下多维资源调度方法，对于计算密集型服务根据资源空闲度给集群内各个服务器节点打分，对于普通型服务，则根据调度任务的资源需求，服务器节点的资源优先级以及服务器节点的资源均衡度给集群内各个服务器节点打分，选取分值最高的服务器节点绑定pod调度任务并执行。本发明的调度方法满足各类服务的多样化资源请求，增加系统的灵活性和可扩展性。

Description

Kubernetes集群架构系统下多维资源调度方法

技术领域

本发明涉及一种Kubernetes集群架构系统下多维资源调度方法，属于互联网通信技术领域。

背景技术

随着云计算，分布式存储等各类技术的蓬勃发展，由于成本低、效率高以及测试轻量级的特点，Kubernetes集群架构系统的研究已经成为了互联网通信技术领域的大热方向，Kubernetes容器集群管理工具主要应用于管理云计算环境下计算密集型的大规模任务应用，然而容器资源请求是动态变化的，存在着除CPU、内存之外还包括存储、网络带宽等其他资源，类型是多样的，所对应的资源类型也是多维资源类型，但是Kubernetes的静态调度算法输入参数单一，对资源的占用情况分析粗糙，存在非常大的局限性，并不能充分利用各个服务器中的多种资源(包括架构中边缘节点上的异构资源)，也不能针对容器多维资源请求提供相应的帮助。现有的调度算法无法满足需要调度多维资源类型的需求。

发明内容

本发明目的在于提出了一种Kubernetes集群架构系统下多维资源调度方法，能够动态地为云系统中的每个任务寻找最优的工作节点分配，解决了现阶段调度算法输入参数单一，无法满足任务对节点多样的资源类型需求的问题。

为了实现上述目标，本发明采用如下的技术方案：

Kubernetes集群架构系统下多维资源调度方法，包括：

发起Pod创建请求；

获取Pod所需要参数生成Pod调度任务；

将Pod调度任务序列化为对象送入调度器；

将调度器内Pod调度任务绑定到目标Node节点上执行。

进一步的，所述发起Pod创建请求包括：

通过kubectl客户端命令行发起的请求；

控制器为补足副本而创建的Pod请求；

通过Api Server发起的外部请求。

进一步的，还包括：

Pod创建请求需要通过鉴权认证后传入集群主节点的Api Server中，由ApiServer创建相应的Pod。

进一步的，还包括：

所有的Pod创建信息都将被持久化存储在分布式存储数据库etcd中。

进一步的，所述将Pod调度任务序列化为对象送入调度器，包括：

计算Pod调度任务的优先级指数，将Pod调度任务按优先级指数作降序排序，形成先入先出队列，按照队列顺序传入调度器；

所述优先级指数计算如下：

其中，α_i表示第i个Pod调度任务的优先级指数，D_i表示第i个Pod调度任务的截止期约束，A_i表示第i个Pod调度任务的提交时间，CP_i表示第i个Pod调度任务的关键路径长度。

进一步的，所述将调度器内Pod调度任务绑定到目标服务器节点上执行，包括：

对服务器节点进行可行性检查，筛选出Pod调度任务能够运行的服务器节点；

为能够运行的服务器节点进行打分；

将Pod调度任务绑定到打分最高的服务器节点上。

进一步的，采用kubernetes默认的过滤算法筛选服务器节点：

过滤掉Pod所需端口已经被占用服务器节点，

过滤掉Pod所需资源无法满足的服务器节点，

过滤掉与Pod中的磁盘卷标存在冲突的服务器节点，

筛选出与Pod NodeSelector属性匹配以及HostName匹配的服务器节点。

进一步的，所述为能够运行的服务器节点进行优先级打分，包括：

判定此次Pod调度任务事件是计算密集型服务还是普通型服务，如果是计算密集型服务则根据资源空闲度给集群内各个服务器节点打分；如果是普通型服务，则根据Pod调度任务的资源需求，服务器节点的资源优先级以及服务器节点的资源均衡度给集群内各个服务器节点打分。

进一步的，所述根据资源空闲度给集群内各个服务器节点打分，包括：

其中，score表示服务器节点分值，cpu表示CPU空闲度，memory表示内存空闲度，capacity表示服务器节点对应资源的资源总量，requested表示服务器节点其他运行的任务占用的资源量。

进一步的，所述根据Pod调度任务的资源需求，服务器节点的资源优先级以及服务器节点的资源均衡度给集群内各个服务器节点打分，包括：

计算服务器节点的资源优先级：

其中，T_ij代表集群内部第i个服务器节点的第j类资源的资源总量，W_ij代表集群内部第i个服务器节点的第j类资源的优先级，T_ijused集群内部第i个服务器节点已部署的Pod和其他应用消耗的第j类资源总量，T_ijreq代表当前待调度Pod任务请求的第j类资源量，G_i表示第i个服务器节点的资源优先级，C_i表示第i个服务器节点的资源比重系数，i＝1,2,…k，j＝1,2,…s，k表示服务器节点数，s表示服务器节点中资源类型总数，所述资源类型包括cpu、内存、i/o读写速率、网络带宽、显卡和硬盘；

计算服务器节点的资源均衡度：

其中，B_i表示第i个服务器节点的资源均衡度；

计算服务器节点打分：

s_corei＝K(G_i+B_i)

其中，s_corei表示第i个服务器节点分值，K为+1或者-1表示经过过滤流程后的结果，通过过滤阶段K＝+1，未通过过滤阶段K＝-1，s_corei为负值时，表示此服务器节点不可用，s_corei为正时表示此服务器节点可用。

本发明所达到的有益效果为：

本发明提供一种基于Kubernetes集群系统下多维资源的调度方法，能够针对集群内节点的各类资源进行调度，满足各类服务的多样化资源请求，增加系统的灵活性和可扩展性。

附图说明

图1为本发明的Kubernetes集群架构系统框架图；

图2为本发明的Kubernetes集群系统下多维资源调度物理流程图；

图3为本发明的Kubernetes集群系统下多维资源调度算法流程图。

具体实施方式

下面对本发明作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本发明的保护范围。

参见图1，本发明的Kubernetes集群架构系统如下：

集群主节点(Master)：它是整个集群的核心节点，所有对于Kubernetes集群的执行命令操作都是由它执行，它负责整个集群的调度和管理工作，一般是集群中独立的服务器。Master包括非常多的组件，主要包括Api Server、控制器以及调度器。Api Server是整个系统的数据总线和数据中心，提供了集群系统的各类资源对象的增删改查，集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更)以及其他模块之间的数据交互和通信。其他模块通过Api Server查询或修改数据，只有Api Server才直接操作etcd。控制器是集群内部管理和控制中心，负责获取用户所需要的开发依赖库、系统配置等相关参数并将这些参数生成任务发送至调度器。调度器接受控制器发送的任务，监测Pod合法性并将Pod根据调度策略找到一个合适的节点运行，并将绑定的信息通过API Server发送到etcd中存储。

节点(Node)：Kubernetes集群中除了集群主节点(Master)以外，其余的节点都称为节点(Node)，Node节点都是工作节点，每一个Node节点都会被Master节点按照调度规则分配到合理的工作负载，是任务的执行者。每个Node节点上都运行一个kubelet服务进程，监听端口，接收并执行Master发来的指令，管理Pod以及Pod中的容器。每个kubelet进程会在Api Server上注册节点自身信息，定期向Master节点汇报资源使用情况，并通过cAdvisor监控节点和容器的资源。

命令行工具(kubectl)：kubectl一般安装在客户端，它能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署。kubectl作为Kubernetes的命令行工具，主要的职责就是对集群中的资源的对象进行操作，这些操作包括对资源对象的创建、删除和查看等，从而实现对kebernetes集群的管理。

分布式存储数据库(etcd)：etcd是Kubernetes集群中的一个十分重要的组件，用于保存集群所有的网络配置和所有对象的状态信息。

基于上述Kubernetes集群架构系统，本发明提供一种Kubernetes集群架构系统下多维资源调度方法，包括：

步骤1)，发起Pod创建请求，包括：a、通过kubectl客户端命令行发起的请求；b、控制器为补足副本而创建的Pod请求；c、通过Api Server发起的外部请求。

所有的Pod创建请求需要通过鉴权认证后传入集群主节点的Api Server中，经过鉴权认证后确认该创建请求是否通过，若Pod创建请求合法，Api server则创建相应的Pod，与此同时，所有的Pod创建信息都将被持久化存储在分布式存储数据库etcd中。集群主节点(Master)中的控制器以及调度器通过实时访问Api Server来查询Pod创建信息，当有新的创建对象时，控制器负责获取Pod所需要的开发依赖库、系统配置等相关参数并生成Pod调度任务发送至调度器，同时将Pod调度任务添加到挂起队列当中。控制器将Pod调度任务序列化为对象送入调度器中。调度器接受到控制器发送的任务，监测任务合法性并且调度程序异步的扫描这些任务。

步骤2)调度器通过访问Api Server查询是否存在待调度的Pod任务。若存在，则获取待调度的Pod资源信息和集群中所有的Node节点资源使用情况。然后根据制定的调度策略进行调度，将Pod任务绑定到目标Node节点上，并将绑定信息写入etcd中；若不存在，则不执行任何操作，继续等待下一轮通知查询。

Pod在提交时会携带Pod的创建信息以及需要的资源信息，前者是为了Pod在具体部署的时候搭建环境，后者是为了完成调度任务所需要的资源，例如cpu、内存等计算资源，还包括i/o读写速率、网络带宽、显卡、硬盘等多样化的资源。这些信息通常在Pod的yaml文件中设置。

调度策略包括两个部分：

预选阶段，主要进行可行性检查，具体为，

调度器用过滤规则过滤掉不符合要求的服务器节点，找出任务可以运行的服务器节点。

优选阶段，为可以运行的服务器节点进行优先级打分，具体为，

将上一阶段过滤出来的服务器节点进行打分，选择打分最高的服务器节点和Pod任务进行绑定操作，并在相应节点上部署容器运行任务。如果有足够的可用资源满足作业的约束，调度程序就将任务分配给节点。从高优先级到低优先级的扫描，通过一个优先级内的循环方案进行调整，以确保用户之间的公平性，并避免在大型作业之后的前端阻塞。

调度策略的具体实施过程为：

在先入先出调度队列中弹出调度事件即待调度的Pod任务，进入调度流程；

根据调度事件对运行端口、资源要求(例如cpu、内存、I/O读写速度等)以及一系列个性化的自定义需求；

调用一组过滤算法进行可行性检查，通过对调度器缓存区内集群中所有节点的节点信息进行过滤，得到符合要求的一组节点，就是所有可以运行该调度事件的服务器节点列表。在这一过程中，可用资源比任务需要的资源少的服务器节点就会被过滤掉；

然后为可以运行的服务器节点列表中的各个服务器节点进行打分。

本发明的调度策略考虑到每个Pod的不同的资源类型请求，为每个调度任务提供特定的调度服务。最终的调度结果，就是根据任务的需求并考虑一些整体的优化策略，选择得分最高的那个服务器节点，进而将该服务器节点与调度任务进行绑定，在该服务器节点上部署容器环境运行任务。

步骤3)位于Node节点上的kubelet进行定期的访问，接收从调度器传来的调度任务并执行这些调度任务，当有新的Pod绑定时，则下载Pod所需要的容器镜像并申请相应的资源进行Pod的部署，执行完毕将结果返回至调度器。同时，目标节点中的kubelet会监听调度信息以及负责节点的具体创建工作。

步骤4)kubelet通过容器启动时间取得Pod的最新状态，并将新的状态通过ApiServer更新到etcd中。

调度过程中，Kubernetes集群系统工作流程如图2所示。

作为本发明的一个优选实施例，具体实施过程参见图3，如下：

步骤1)，kublectl向Kubernetes集群发送Pod创建请求，经过鉴权认证后确认该创建请求是否通过，若Pod创建请求合法，Api server则创建相应的Pod。与此同时，所有的创建信息都将被持久化存储在分布式存储数据库etcd中。

Master中的控制器以及调度器通过访问Api Server来查询Pod创建信息，当有新的创建对象时，控制器负责获取Pod所需要的开发依赖库、系统配置等相关参数并将这些参数生成Pod调度任务发送至调度器，同时将Pod调度任务添加到挂起队列当中。控制器将Pod调度任务序列化为对象送入调度器，调度器将检测对象合法性。

进一步的，控制器将Pod调度任务序列化为对象送入调度器，包括：

根据etcd中待调度任务，获取任务W_i的提交时间A_i和截止期约束D_i，并计算出关键路径的长度CP_i，计算任务优先级指数：

α_i该值越小表示任务的CP_i越接近与D_i-A_i，即此调度任务就越紧急，需要优先处理，CP_i主要是通过节点提供的cpu以及内存资源预测Pod任务运行时间。

将etcd中待调度任务基于此值作降序排序，形成先入先出队列，按照队列顺序传入调度器。

步骤2)，调度器经过访问Api Server获取待调度事件，如查询到先入先出队列中出现了新的调度事件，则由调度器执行调度流程。若未收集到有最新的调度请求，则不执行任何操作，继续等待下一轮通知查询。

执行调度流程，首先调用一组过滤算法，根据调度器缓存区中拿到的调度事件信息对集群内所有节点进行过滤，得到任务可以运行的服务器节点，在此，按照Kubernetes默认的过滤算法进行过滤，主要包括以下五个步骤：

2-1)PodFitsPorts:检查Pod申请的端口是不是与已经被使用的端口有冲突，筛选Pod所需端口是否被占用，如果被占用即存在端口已经被使用的情况则过滤该节点。

2-2)PodFitsResources：筛选Pod所需资源是否满足，即检查Pod的主要特征需求字段，例如CPU、内存、IO资源以及网络资源等需求，如果不满足则过滤该节点。

2-3)NoDiskConflict：筛选节点上的磁盘卷标与Pod中的磁盘卷标是否存在冲突，如果存在冲突则过滤该节点。

2-4)PodSelectorMatches：如果Pod指定了NodeSelector属性，则筛选出与PodNodeSelector属性匹配的节点；Pod的节点选择器或者节点亲和性指定的节点，是否与待考察节点匹配。

2-5)PodCFitsHost：如果Pod指定了HostName，则筛选出与HostName匹配的节点。

然后为可以运行的服务器节点列表中的各个服务器节点进行打分，分数范围为0～10，最终的调度结果，就是得分最高的那个服务器节点，进而将该服务器节点与任务进行绑定，并在服务器节点名称字段写入最终的调度节点名称。

打分过程如下：

根据Pod类型与资源需求判定此次调度事件是计算密集型服务还是普通型服务。Pod类型是根据Pod的资源需求类型决定的，如果Pod调度任务所需要的资源需求信息中只包含cpu、内存等计算资源则是计算密集型服务，若Pod调度任务所需要的资源需求信息中包含资源类型比较多样复杂，例如cpu、内存、i/o读写速率、网络带宽、显卡、硬盘等多样化的资源的组合则为普通型服务。

若属于计算密集型服务，则根据资源空闲度(CPU和内存)给集群内各个服务器节点打分并记录分值：

其中，cpu表示CPU空闲度，memory表示内存空闲度，capacity表示服务器节点对应资源的资源总量，requested表示本服务器节点其他运行的任务占用的资源量，都是已知的。

此处采用了默认调度器中资源优先级的打分策略。资源优先级方法实际上就是在选择集群内部空闲资源(CPU和Memory)最多的节点。根据上述打分准则给集群内各个可用服务器节点打分后，得分最高的服务器节点就是最后被Pod绑定的最佳服务器节点。由于计算密集型服务往往需要大量CPU以及内存的支撑，所以在处理资源密集型任务时，采用资源优先级打分策略能够快速高效的处理调度的任务。

若属于普通型服务，则根据调度任务的资源需求，自动生成资源比重列表，根据资源比重列表以及系数动态的给集群内各个服务器节点进行打分。由于资源需求多样，在这里，忽略资源的类型，根据任务的标签，找出任务需求占重较大，影响任务性能的要素，生成多维的资源比重列表：

假设待调度的Pod任务序列为：

P＝[p₁,p₂,p₃,…p_n],

其中，p_i，i＝1,2,…n表示第i个待调度Pod任务；

集群内服务器节点为：

N＝[n₁,n₂,n₃,…n_k]，k表示服务器节点数；

Pod任务序列需要的资源类型列表为：

T＝[t₁,t₂…t_n]，

其中，t_i，i＝1,2,…n，表示第i个待调度Pod任务需要的资源类型；

集群内服务器节点的资源优先级为：

G＝[G₁,G₂,…G_k]，

其中，G_i，i＝1,2,…k，表示第i个服务器节点的资源优先级；

每个服务器节点的资源配额根据工作任务流中任务的资源需求而定，资源比重系数为：

其中，c_j，j＝1,2,…s为服务器节点中第j个资源的比重系数，s为服务器节点中资源类型总数，资源包括cpu、内存、i/o读写速率、网络带宽、显卡、硬盘等。c_i可以根据任务需求动态的设定，对哪项资源需求要求较高则资源比重系数较大，资源需求要求较低则资源比重系数较小。

通过动态的调节资源比重系数，来控制各项资源在优先级评判中的比重。

资源优先级：新的任务容器调度到一个节点上，这个节点的资源优先级为节点空闲的那部分与总容量的比值所得，即资源总容量减去节点上已用资源减去新任务调度资源与总资源量的比值决定，计算公式如下：

其中，T_ij代表集群内部第i个节点的第j类资源的资源总量，W_ij代表集群内部第i个节点的第j类资源的优先级，T_ijused集群内部第i个节点已部署的Pod和其他应用消耗的第j类资源总量，T_ijreq代表当前待调度Pod请求的第j类资源量，G_i表示第i个节点的资源优先级，该值统计了各项资源的优先级之和，比值越大，节点的优先级就越高，i＝1,2,…k，j＝1,2,…s。

资源均衡度：就是空闲节点的各类资源的相对比例。此设置主要是减少Pod部署在节点资源不均衡的节点上，也是比较节点出现资源耗尽，另一种资源剩余较多的手段。节点资源均衡度越好选择该节点的可能性就越大，根据二维资源均衡度的参考公式：

B＝1-abs(W_cpu-W_mem)

该公式主要是求节点的cpu以及内存这两种资源的相对比例，从而选择调度后，所有节点里各种资源分配最均衡的那个节点，从而避免一个节点上CPU被大量分配、而Memory大量剩余的情况。本发明设计出多维资源均衡度评判公式：

其中，B_i表示第i个节点的资源均衡度。

然后，综合资源优先级以及资源均衡度，给各个服务器节点进行打分：

s_corei＝K(G_i+B_i)

其中，K为+1或者-1表示经过过滤流程后的结果，通过过滤阶段K＝+1，未通过过滤阶段K＝-1。s_corei为负值时，表示此节点不可用；s_corei为正时表示此节点可用。

最终选取打分最高的服务器节点。

步骤3)，循环上述步骤直至待调度任务列表为空。

默认调度器在部署Pod所运行的物理节点时，通常把内存、CPU作为衡量各类节点性能的重要指标参数，基于这两类因素对各个节点进行打分排序，对于默认调度算法的各类优化也仅仅加上了类似网络负载量、IO读取速度等指标参数，忽略了在服务任务组中，各类服务资源需求的多样性，往往各类服务的指标参数各不相同，资源的多样化调度集群调度策略中，不局限于资源的种类，根据任务自带标签优选资源需求列表，不同资源需求进行节点打分。在调度部署Pod时，静态调度可以使集群保持负载的相对均衡，然而，在集群长时间的运行之后，集群系统会出现负载不均衡的问题，因此，在调度过程中，也结合动态负载均衡机制，采用动态比重系数保证集群在长时间运行的情况下，维持集群系统的稳定均衡性，从而更好地保持集群系统的稳定。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明技术原理的前提下，还可以做出若干改进和变形，这些改进和变形也应视为本发明的保护范围。

Claims (6)

1.Kubernetes集群架构系统下多维资源调度方法，其特征在于，包括：

发起Pod创建请求；

获取Pod所需要参数生成Pod调度任务；

将Pod调度任务序列化为对象送入调度器，包括：

计算Pod调度任务的优先级指数，将Pod调度任务按优先级指数作降序排序，形成先入先出队列，按照队列顺序传入调度器；

所述优先级指数计算如下：

其中，α_i表示第i个Pod调度任务的优先级指数，D_i表示第i个Pod调度任务的截止期约束，A_i表示第i个Pod调度任务的提交时间，CP_i表示第i个Pod调度任务的关键路径长度；

将调度器内Pod调度任务绑定到目标Node节点上执行，包括：

对服务器节点进行可行性检查，筛选出Pod调度任务能够运行的服务器节点；

为能够运行的服务器节点进行打分；

将Pod调度任务绑定到打分最高的服务器节点上；

所述为能够运行的服务器节点进行打分，包括：

判定此次Pod调度任务事件是计算密集型服务还是普通型服务，如果是计算密集型服务则根据资源空闲度给集群内各个服务器节点打分，如下：

其中，score表示服务器节点分值，cpu表示CPU空闲度，memory表示内存空闲度，capacity表示服务器节点对应资源的资源总量，requested表示服务器节点其他运行的任务占用的资源量；

如果是普通型服务，则根据Pod调度任务的资源需求，服务器节点的资源优先级以及服务器节点的资源均衡度给集群内各个服务器节点打分。

2.根据权利要求1所述的Kubernetes集群架构系统下多维资源调度方法，其特征在于，所述发起Pod创建请求包括：

通过kubectl客户端命令行发起的请求；

控制器为补足副本而创建的Pod请求；

通过Api Server发起的外部请求。

3.根据权利要求1所述的Kubernetes集群架构系统下多维资源调度方法，其特征在于，还包括：

Pod创建请求需要通过鉴权认证后传入集群主节点的Api Server中，由Api Server创建相应的Pod。

4.根据权利要求3所述的Kubernetes集群架构系统下多维资源调度方法，其特征在于，还包括：

所有的Pod创建信息都将被持久化存储在分布式存储数据库etcd中。

5.根据权利要求1所述的Kubernetes集群架构系统下多维资源调度方法，其特征在于，采用kubernetes默认的过滤算法筛选服务器节点，如下：

过滤掉Pod所需端口已经被占用服务器节点，

过滤掉Pod所需资源无法满足的服务器节点，

过滤掉与Pod中的磁盘卷标存在冲突的服务器节点，

筛选出与Pod NodeSelector属性匹配以及HostName匹配的服务器节点。

6.根据权利要求1所述的Kubernetes集群架构系统下多维资源调度方法，其特征在于，所述根据Pod调度任务的资源需求，服务器节点的资源优先级以及服务器节点的资源均衡度给集群内各个服务器节点打分，包括：

计算服务器节点的资源优先级：

其中，T_ij代表集群内部第i个服务器节点的第j类资源的资源总量，W_ij代表集群内部第i个服务器节点的第j类资源的优先级，T_ijused集群内部第i个服务器节点已部署的Pod和其他应用消耗的第j类资源总量，T_ijreq代表当前待调度Pod任务请求的第j类资源量，G_i表示第i个服务器节点的资源优先级，C_i表示第i个服务器节点的资源比重系数，i＝1,2,…k，j＝1,2,…s，k表示服务器节点数，s表示服务器节点中资源类型总数，所述资源类型包括cpu、内存、i/o读写速率、网络带宽、显卡和硬盘；

计算服务器节点的资源均衡度：

其中，B_i表示第i个服务器节点的资源均衡度；

计算服务器节点打分：

s_corei＝K(G_i+B_i)，

其中，s_corei表示第i个服务器节点分值，K为+1或者-1表示经过过滤流程后的结果，通过过滤阶段K＝+1，未通过过滤阶段K＝-1，s_corei为负值时，表示此服务器节点不可用，s_corei为正时表示此服务器节点可用。

Images