CN111737003A - Pod均衡调度方法、装置、主节点及存储介质 - Google Patents

Abstract

本发明涉及Kubernetes技术领域，提供了一种Pod均衡调度方法、装置、主节点及存储介质，所述方法包括：获取待调度Pod的资源需求量；获取每一预选子节点的实时资源使用量，其中，预选子节点是依据预选策略从多个子节点中确定的；依据优选策略及每一预选子节点的实时资源使用量从预选子节点中确定满足资源需求量的目标子节点，以对待调度Pod进行调度，通过将Kubernetes集群中子节点的实时资源使用量和调度策略相结合进行资源调度，从而实现了Kubernetes集群中各子节点上的资源的均衡利用。

Description

Pod均衡调度方法、装置、主节点及存储介质

技术领域

本发明涉及Kubernetes技术领域，具体而言，涉及一种Pod均衡调度方法、装置、主节点及存储介质。

背景技术

Kubernetes是一个编排容器的工具，其实也是管理应用的全生命周期的一个工具，从创建应用，应用的部署，应用提供服务，扩容缩容应用，应用更新，都非常的方便，而且可以做到故障自愈，例如一个服务器挂了，可以自动将这个服务器上的服务调度到另外一个主机上进行运行，无需进行人工干涉。

应用通常以Pod形式部署在Kubernetes管理的集群中，Kubernetes集群包括主节点和子节点，Pod创建并运行于子节点上，当Kubernetes集群部署的应用增多后，各子节点的资源使用率不均衡会造成部分子节点的负载过高、而另一些子节点并未充分使用的问题，进而导致应用的运行性能。

如何使各子节点上的资源得以均衡利用是本领域技术人员当前亟待解决的技术问题。

发明内容

本发明实施例的目的在于提供了一种Pod均衡调度方法、装置、主节点及存储介质，通过将Kubernetes集群中子节点的实时资源使用量和调度策略相结合进行Pod调度，使Pod得以均衡调度，最终运行在较合适的子节点上，从而实现了Kubernetes集群中各子节点上的资源的均衡利用。

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

第一方面，本发明实施例提供一种Pod均衡调度方法，应用于Kubernetes集群中的主节点，主节点预先存储有预选策略和优选策略，主节点与多个子节点通信连接，所述方法包括：获取待调度Pod的资源需求量；获取每一预选子节点的实时资源使用量，其中，预选子节点是依据预选策略从多个子节点中确定的；依据优选策略及每一预选子节点的实时资源使用量从预选子节点中确定满足资源需求量的目标子节点，以对待调度Pod进行调度。

第二方面，本发明实施例提供一种Pod均衡调度装置，应用于Kubernetes集群中的主节点，主节点预先存储有预选策略和优选策略，主节点与多个子节点通信连接，所述装置包括获取模块和调度模块，获取模块用于获取待调度Pod的资源需求量及获取每一预选子节点的实时资源使用量，其中，预选子节点是依据预选策略从多个子节点中确定的；调度模块，用于依据优选策略及每一预选子节点的实时资源使用量从预选子节点中确定满足资源需求量的目标子节点，以对待调度Pod进行调度。

第三方面，本发明实施例提供一种主节点，主节点包括：一个或多个处理器；存储器，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现上述的Pod均衡调度方法。

第四方面，本发明实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述的Pod均衡调度方法。

相对于现有技术，本发明实施例提供了一种Pod均衡调度方法、装置、主节点及存储介质，当需要调度Pod时，首先获取待调度Pod的资源需求量，依据预选策略从多个子节点中确定预选子节点，并获取每一预选子节点的实时资源使用量，依据优选策略及每一预选子节点的实时资源使用量从预选字节中确定满足待调度Pod的资源需求量的目标子节点，以对所述待调度Pod进行调度，与现有技术相比，调度Pod时，将Kubernetes集群中子节点的实时资源使用量和调度策略相结合进行Pod调度，保证了Pod调度的均衡性，最终实现了Kubernetes集群中各子节点上的资源的均衡利用。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本发明实施例提供的应用场景图。

图2示出了本发明实施例提供的主节点的方框示意图。

图3示出了本发明实施例提供的一种Pod均衡调度方法的流程图。

图4示出了本发明实施例提供的另一种Pod均衡调度方法的流程图。

图5示出了本发明实施例提供的另一种Pod均衡调度方法的流程图。

图6示出了本发明实施例提供的另一种Pod均衡调度方法的流程图。

图7示出了本发明实施例提供的另一种Pod均衡调度方法的流程图。

图8示出了本发明实施例提供的另一种Pod均衡调度方法的流程图。

图9示出了本发明实施例提供的Pod均衡调度装置的方框示意图。

图标：10-主节点；11-处理器；12-存储器；13-总线；14-通信接口；20-子节点；100-Pod均衡调度装置；110-获取模块；120-调度模块；130-更新模块。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

在本发明的描述中，需要说明的是，若出现术语“上”、“下”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，或者是该发明产品使用时惯常摆放的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。

此外，若出现术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

需要说明的是，在不冲突的情况下，本发明的实施例中的特征可以相互结合。

Kubernetes提供了应用部署、规划、更新、维护的全方位机制，其目标是更加简单且高效地部署容器化应用，而由一个主节点和多个子节点构成的Kubernetes集群则使得部署于其中的应用运行得更高效、更可靠。

请参考图1，图1示出了本发明实施例提供的应用场景图，Kubernetes集群包括一个主节点10和多个子节点20，主节点10与每一子节点20均通信连接，当一个应用需要部署至Kubernetes集群时，首先，该应用会以Pod的形式实现，在子节点创建后运行该Pod，由此实现该应用的部署，其中，一个应用可以是一个完整的程序软件，也可以是一个程序软件中的一个独立功能模块等。主节点根据Pod的资源需求量从多个子节点20中确定一个目标子节点，在该目标子节点上创建该Pod后运行该Pod，由此实现该Pod对应的应用的部署。

需要说明的是，图1只是示例，每个子节点20上只运行了一个Pod，事实上，实际应用场景中，一个子节点20上可以同时运行多个Pod，同一个Pod只能运行在一个子节点20上。

主节点10可以是由一个服务器实现，也可以是多个服务器组成的服务器组实现，或者是云端服务器等，此处的服务器可以是实体服务器，或者可以实现与实体服务器具有相同功能的虚拟机等。

子节点20可以是物理主机，也可以是实现与物理主机具有相同功能的虚拟机等。

在Kubernetes集群运行过程中常常会出现各子节点存在大量的不均衡情况，主要表现为各子节点的资源，例如CPU、内存、存储、网络等资源的使用率不均衡，这一情况会造成一部分子节点的负载过高、而另一部分的子节点的资源空闲率高，未充分得以利用的问题，进而导致应用的性能瓶颈。

针对这一问题，当前并没有很好的解决方案，只能通过监控系统对Kubernetes集群运行状态进行监测，并采取人工干预措施，而这一方法对于大规模的Kubernetes集群是极其低效、无法容忍的。

虽然Kubernetes集群也提供了默认调度器对Pod进行调度，尽量使Pod得以均衡调度，但是实际的均衡效果并不理想，仍然存在各子节点上的资源的利用不均衡的问题。

发明人通过仔细、深入的研究发现，造成上述问题的原因主要在于调度过程中，Kubernetes集群的默认调度器的调度策略仅仅考虑了Pod申请时所需资源的下限，实际上，Pod也有一个所需资源的上限，而Pod在实际运行过程占用的资源处于上限和下限之间，例如，一个Pod所需的资源为[1，100]，即下限为1，上限为100，默认调度器根据该Pod所需资源的下限即1确定子节点，而该Pod运行后，其实际占用的资源可能是99，由此可能会导致子节点的实际资源使用率与Pod申请时所需资源的下限相差较大，即Pod申请时所需资源量较低而实际资源使用率较高的情况，采用默认调度器调度后，Pod仍旧可能会调度至实际资源使用率较高的子节点，进而造成子节点负载过大、Kubernetes集群中各子节点的资源利用不均衡。由以上分析可知，是否能够对Pod所需资源的上限和下限进行合理配置也是导致Kubernetes集群中各子节点的资源利用不均衡的原因之一。

而针对如何对Pod所需资源的上限和下限进行合理配置，也是当前难以克服的技术障碍，目前尚未有对Pod所需资源的上限和下限进行合理配置的较好的解决方案，其原因在于：一方面，多数开发人员并不知道该如何对此上限和下限进行合理配置，通常根据自己的经验进行配置，导致配置不合理，另一方面，Kubernetes集群中部署的应用繁多复杂，也使得对于Pod所需资源的上限和下限进行合理配置的实际操作性极低。

针对上述问题及存在的上述技术障碍，发明人极具创造性地提出，在对Pod进行调度时，将Kubernetes集群中子节点的实时资源使用量和默认调度器的调度策略相结合，既绕过了上述技术障碍，又使Pod得以均衡调度，最终实现了Kubernetes集群中各子节点上的资源的均衡利用。

基于图1，本发明实施例还给出了图1中的主节点的方框示意图，请参照图2，图2示出了本发明实施例提供的主节点的方框示意图，主节点10包括处理器11、存储器12、总线13、通信接口14，处理器11、存储器12及通信接口14通过总线13连接。

处理器11可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，Pod均衡调度方法的各步骤可以通过处理器11中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器11可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

存储器12用于存储程序，例如上述Pod均衡调度装置。Pod均衡调度装置包括至少一个可以软件或固件(firmware)的形式存储于存储器12中或固化在主节点10的操作系统(operating system，OS)中的软件功能模块。处理器11在接收到执行指令后，执行所述程序以实现下述实施例揭示的Pod均衡调度方法。

主节点10通过通信接口14与子节点20、或者与其他外设设备进行通信。

在图1和图2的基础上，本发明实施例提供了一种Pod均衡调度方法的流程图，该方法应用于图1和图2中的主节点10，请参照图3，图3示出了本发明实施例提供的一种Pod均衡调度方法的流程图，该方法包括以下步骤：

步骤S110，获取待调度Pod的资源需求量。

在本实施例中，资源需求量包括、但不限于CPU资源需求量、内存资源需求量等。

步骤S120，获取每一预选子节点的实时资源使用量，其中，预选子节点是依据预选策略从多个子节点中确定的。

在本实施例中，预选策略用于过滤掉不满足Pod运行的最低要求的子节点，例如，待调度Pod的CPU资源需求量为2，内存资源需求量为2GB，则将多个子节点中不能同时满足这两个资源需求量的子节点直接过滤掉。

在本实施例中，预选策略也称为预选策略，通常包括多个预选策略项，例如：

GeneralPred策略项：包括一些基本的、通用的策略项；

CheckNodeConditionPred策略项：检查子节点是否正常；

NoDiskConflict策略项：判断Pod定义的存储是否在子节点上使用的策略；

PodToleratesNodeTaints策略项：检查Pod上Tolerates的能否容忍污点；

CheckNodeLabelPresence策略项：检查子节点上的标志是否存在。

需要说明的是，预选策略中的所有预选策略项可以单独使用，也可以组合使用以执行复杂的过滤策略。

在本实施例中，每一预选子节点的实时资源使用量可以包括该预选子节点的当前CPU资源的利用率，当前已使用内存资源大小等。

步骤S130，依据优选策略及每一预选子节点的实时资源使用量从预选子节点中确定满足资源需求量的目标子节点，以对待调度Pod进行调度。

在本实施例中，优选策略用于对预选子节点进行排名，以找到最适合待调度Pod的节点。优选策略通常包括多个优选策略项，例如：

LeastRequested策略项：选择消耗最小的预选子节点；

BalancedResourceAllocation策略项：选出资源使用率最均衡的预选子节点；

NodePreferAvoidPods策略项：预选子节点的倾向性；

TaintToleration策略项：将Pod对象的spec.toleration与预选子节点的taints列表项进行匹配度检查；

SelectorSpreading策略项：与services上其他Pod尽量不在同一个预选子节点，预选子节点上同一个service的Pod越少得分越高；

InterPodAffinity策略项：遍历预选子节点上的亲和性条目，匹配项越多的得分越高；

NodeAffinity策略项：衡量预选子节点亲和性；

MostRequested策略项：选择消耗最大的预选子节点；

ImageLocality策略项：预选子节点有所需要的镜像既得分，所需镜像越多得分越高。

在本实施例中，一种具体实施方式可以是：针对每一个预选子节点，使用每一项优选策略进行打分，再使用每一预选子节点的实时资源使用量进行打分，最终计算每一个预选子节点所有优选策略项及实时资源使用量的加权总分作为每一个预选子节点的最终得分。

在本实施例中，另一种具体实施方式也可以是：先对优选策略进行筛选，再使用筛选后的优选策略进行打分，再使用每一预选子节点的实时资源使用量进行打分，最终计算每一个预选子节点筛选后的优选策略项及实时资源使用量的加权总分作为每一个预选子节点的最终得分。

在本实施例中，目标子节点选定后，在目标子节点中创建待调度Pod后运行该Pod，由此实现待调度Pod对应的应用在Kubernetes集群上的部署。

本发明实施例提供的上述方法，通过将Kubernetes集群中子节点的实时资源使用量和调度策略相结合进行Pod调度，从而使Pod得以均衡调度，最终实现了Kubernetes集群中各子节点上的资源的均衡利用。

在图3的基础上，本发明实施例还提供了另一种Pod均衡调度方法，请参照图4，图4示出了本发明实施例提供的另一种Pod均衡调度方法的流程图，步骤S130包括以下子步骤：

子步骤S1301，依据优选策略、优选权重计算每一预选子节点的第一得分。

在本实施例中，优选策略对应优选权重，优选策略可以包括多个优选策略项，优选权重包括每一优选策略项对应的优选权重值。对于任意一个预选子节点的第一得分的计算方式可以为：根据每一优选策略项对该预选子节点进行打分，将每一优选策略项的打分分值与对应的优选权重的乘积作为该优选策略项权重分值，将该预选子节点的所有优选策略项的权重分值之和作为第一得分，具体过程可以参看表1。

表1中，对任意一个预选子节点来说，按照优选策略项1、优选策略项2、…、优选策略项n进行打分得到的打分分值分别为：S1、S2、…、Sn，优选策略项1、优选策略项2、…、优选策略项n对应的优选权重分别为W1、W2、…、Wn，最终第一得分为：

其中，C₁为第一得分，k为优选策略项的序号，n为优选策略项的数量，W_k为第k个优选策略项的优选权重，S_k为第k个优选策略项的打分分值。

子步骤S1302，依据每一预选子节点的实时资源使用量及资源需求量，计算每一预选子节点的第二得分。

在本实施例中，一种具体的计算第二得分的实施方式可以是：

依据每一预选子节点的实时资源使用量及资源需求量，得到每一预选子节点的空闲率，并依据每一预选子节点的空闲率确定该预选子节点的第二得分。

具体地，对于任意一个预选子节点，其第二得分可以采用如下公式计算得到：

其中，C₂为预选子节点的第二得分，R_alloc为预选子节点的可分配资源量，R_util为预选子节点的实时资源使用量，R_req为资源需求量，

为预选子节点的空闲率。

需要说明的是，本领域技术人员还可以无需付出创造性的劳动对上述公式进行调整，例如，将上述公式中的R_req去掉，则调整后的计算第二得分的公式为：

或者也可以采用预设值替换上述公式中的R_req计算第二得分，这种无需付出创造性的劳动对上述公式做出的调整和变形也在本申请保护的范围内。

当然，也可以依据每一预选子节点的实时资源使用量及资源需求量计算每一预选子节点的空闲资源量，以空闲资源量作为该预选子节点的第二得分，也可以在空闲率或者空闲资源量的基础上进行预设比例的上下浮动，将浮动后的值作为第二得分。

在本实施例中，对于任意一个预选子节点而言，实时资源使用量可以包括CPU资源使用量、GPU资源使用量、内存资源使用量及网络带宽资源使用量中的至少一种或者多种，以实时资源使用量包括这四种资源使用量为例，第二得分可以是这四种资源的空闲率的平均值，也可以为每一资源使用量预设对应的资源权重值，第二得分取这四种资源的空闲率的加权平均值。

子步骤S1303，将每一预选子节点的第一得分和第二得分之和作为每一预选子节点的综合得分。

子步骤S1304，将综合得分最高的预选子节点确定为目标子节点。

本发明实施例提供的上述方法，通过利用优选策略和预选子节点的空闲率确定目标子节点，使得最终得到的目标子节点在创建并运行待调度Pod后实际运行负载不会太大，进一步保证了Pod调度的均衡性。

本发明实施例给出一个具体Pod调度的实施例，将未采用实时资源使用量及资源需求量相结合的Pod调度方法和采用实时资源使用量及资源需求量相结合的Pod调度方法进行对比以说明本发明实施例取得的Pod调度更均衡的技术效果。

例如：Kubernetes集群运行过程中可能会出现根据Pod request计算较为均衡，但某个节点实时资源使用率过高的情况：

#./kube-capacity

#kubectl top nodes

上述node1～node3为子节点，kube-capacity命令用于显示各节点资源申请的最小值和最大值，CPU REQUESTS为CPU资源申请的最小值，CPU LIMITS为CPU资源申请的最大值，MEMORY REQUESTS为内存资源申请的最小值，MEMORY LIMITS为内存资源申请的最大值，kubectl top nodes命令用于显示各节点当前实际的CPU资源和内存资源的使用情况。由以上命令的执行结果可以看到：虽然node3资源申请的最小值较小，但其实时资源使用率过高，如果按照未采用实时资源使用量及资源需求量相结合的Pod调度方法，则待调度的Pod最终会运行在node3上，调度后，kube-capacity命令和kubectl top nodes命令执行结果如下：

#./kube-capacity

#kubectl top nodes

由上述命令执行结果可以看到，本来负载就很高的node3，因为运行了新的Pod，负载变得更高了，如果持续下去，最终node3可能会因为负载过高而宕机。

而按照采用实时资源使用量及资源需求量相结合的Pod调度方法，则待调度的Pod最终会运行在node1上，调度后的kube-capacity命令和kubectl top nodes命令执行结果如下：

#./kube-capacity

#kubectl top nodes

由上述命令执行结果可以看到，由于新的Pod被均衡地调度到node1上，此时，node1～node3上的资源利用更加均衡。

为了使Kubernetes集群更具有通用性，预选策略和优选策略通常大而全，例如，优选策略中各优选策略项的优选权重都是一样的，而与实际场景中，有些预选或者优选策略可以忽略、有些优选策略的优选权重可以适当增加或者降低，例如，在作为私有云平台的微云中，LeastRequested策略负责选出资源使用率最低的节点，权重可以相应提高；BalancedResourceAllocation策略负责选出各项资源使用率最均衡的节点，权重可以相应降低；SelectorSpreading策略负责将同一个控制器的Pod的分散至不同的节点上，权重可以相应提高；MostRequested策略负责选出资源使用率最高的节点，不符合私有云策略，可以直接去掉；ImageLocality策略负责根据各节点上是否存在Pod需求的Image，而私有云平台中的镜像下载不耗费时间，不应影响Pod调度结果，可以直接去掉。

在本实施例中，为了使得预选策略和优选策略与当前实际业务更匹配，本发明实施例还提供了另一种Pod均衡调度方法，请参照图5，图5示出了本发明实施例提供的另一种Pod均衡调度方法的流程图，该方法包括以下步骤：

步骤S210，获取策略配置文件。

在本实施例中，策略配置文件可以根据实际应用场景进行配置，策略配置文件中包括当前应用场景需要的策略配置项及对应的优选权重。

步骤S220，依据策略配置文件对预选策略和/或优选策略进行更新。

在本实施例中，策略配置文件可以只包括对预选策略进行更新的策略配置项，也可以只包括对优选策略进行更新的策略配置项，还可以同时包括对预选策略进行更新的策略配置项和对优选策略进行更新的策略配置项，当包括对优选策略进行更新的策略配置项时，策略配置文件还包括对优选策略进行更新的策略配置项对应的优选权重。

本发明实施例提供的上述方法，通过对预选策略和/或优选策略进行更新，可以使更新后的预选策略和/或优选策略更适配当前实际应用场景，进而使得待调度Pod得以均衡调度，最终实现Kubernetes集群在当前实际应用场景下各子节点的资源利用更均衡。

基于图5，本发明实施例还提供了一种具体的更新预选策略的实现方式，请参照图6，图6示出了本发明实施例提供的另一种Pod均衡调度方法的流程图，步骤S220包括以下子步骤：

子步骤S220-10，将未同时存在于预选策略中及第一策略中的预选策略项从预选策略中删除。

在本实施例中，第一策略包括针对预选策略进行更新的待更新策略项，通常情况下，预选策略包括多个预选策略项，作为一种具体实施方式，将未同时存在于预选策略中及第一策略中的预选策略项从预选策略中删除，即第一策略中的待更新策略项才是当前场景真正需要的预选策略项，因此，需要将预选策略中不需要的预选策略项删除。

本发明实施例提供的上述方法，通过将预选策略中实际场景不需要的预选策略项删除，可以减少资源调度时预选策略的处理量，提高了确定预选子节点的处理效率，进而提高Pod调度的效率，同时也去除了与当前场景不匹配的预选策略项，使得Pod调度更加均衡。

基于图5，本发明实施例还提供了一种具体的更新优选策略的实现方式，请参照图7，图7示出了本发明实施例提供的另一种Pod均衡调度方法的流程图，步骤S220还包括以下子步骤：

子步骤S220-20，将未同时存在于优选策略中及第二策略中的优选策略项从优选策略中删除。

在本实施例中，第二策略包括针对优选策略进行更新的待更新策略项及对应的优选权重，优选策略包括多个优选策略项及与每一个所述优选策略项对应的优选权重，作为一种具体实施方式，将未同时存在于优选策略中及第二策略中的优选策略项从优选策略中删除，即第二策略中的待更新策略项才是当前场景真正需要的优选策略项，因此，需要将优选策略中不需要的优选策略项删除。

子步骤S220-21，用每一待更新策略项对应的优选权重更新优选策略中与该待更新策略项一致的优选策略项的优选权重。

在本实施例中，除了将优选策略中不需要的优选策略项删除，还需要用第二策略中待更新策略项的优选权重替换第二策略中与待更新策略项一致的优选策略项的优选权重，以使优选策略中优选策略项的优选权重与当前场景最符合。

本发明实施例提供的上述方法，一方面，通过将优选策略中实际场景不需要的优选策略项删除，可以减少资源调度时预选策略的处理量，提高了确定预选子节点的处理效率，进而提高Pod调度的效率，同时也去除了与当前场景不匹配的优选策略项，使得Pod调度更加均衡。另一方面，将优选策略中优选策略项的优选权重更新为与当前场景最适合的值，进一步提高了Pod调度的均衡性，最终提高了子节点的资源利用均衡性。

本发明实施例给出一个具体Pod调度的实施例，将采用未更新优选策略(即未更新优选权重，也未更新优选策略项)的Pod调度方法和采用更新优选策略(更新优选权重及更新优选策略项)的Pod调度方法进行对比，以说明本发明实施例取得的Pod调度更均衡的技术效果。

例如：Kubernetes集群运行过程中可能会出现一个子节点各项资源间使用率较为均衡但利用率较高，另一个子节点各项资源间使用率较低但均衡性不够的情况：

#./kube-capacity

其中，node01～node03为子节点，node03的CPU和内存使用率均为75％，两者更为均衡，但资源使用率较高；而node01、node02使用率较低但资源间不太均衡。

如果按照未修改优选权重的Pod调度方法进行调度，则待调度的Pod最终会运行在node03上，调度后，kube-capacity命令和kubectl top nodes命令执行结果如下：

#./kube-capacity

这样的调度方式可能会使得node03的资源使用率持续走高，导致Kubernetes集群中各子节点间的资源利用愈发不均衡。

而按照更新优选策略的Pod调度方法进行调度，能够很好地将Pod调度至node01，调度后，kube-capacity命令和kubectl top nodes命令执行结果如下：

#./kube-capacity

由上述执行结果可以看出，node01～node03的资源利用更加均衡了。

在本实施例中，为了丰富资源调度策略，提高资源调度的灵活性，本发明实施例还提供了一种向预选策略和/或优选策略新增自定义策略项的具体实施方式，请参照图8，图8示出了本发明实施例提供的另一种Pod均衡调度方法的流程图，该方法包括以下步骤：

步骤S310，获取自定义预选策略项和/或自定义优选策略项。

在本实施例中，自定义预选策略项是用户根据实际场景需要添加至预选策略中的策略项，自定义优选策略项是用户根据实际场景需要添加至优选策略中的策略项，用户可以为自定义优选策略项设置对应的优选权重。

步骤S320，通过预先建立的插件框架将所述自定义预选策略项添加至所述预选策略中和/或通过预先建立的插件框架将所述自定义优选策略项添加至所述优选策略中。

在本实施例中，为了避免每加入一个自定义预选策略项和/或自定义优选策略项就对需要Kubernetes集群的源代码进行较大的修改，本申请实施例将加入自定义预选策略项和/或自定义优选策略项时需要修改的代码从功能进行了提炼，将相同的操作提取出来形成插件框架，利用该插件框架只需要新增和修改与当前待加入的自定义预选策略项和/或自定义优选策略项相关功能即可，由此可以提高Pod调度策略的可扩展性。

在本实施例中，每一个自定义预选策略项或每一个自定义优选策略项对应一个插件，该插件需要按照插件预设的要求注册至插件框架中，Kubernetes集群的默认调度器启动时，当新注册的插件是自定义预选策略项时，其与预选策略共同实现Pod调度，当新注册的插件是自定义预选策略项时，其与预选策略共同实现Pod调度。

在本实施例中，作为一种具体的实施方式，新注册的插件注册至插件框架后，处理步骤为：

第一，插件框架获取新注册的插件的源码及相关配置信息，其中，相关配置信息包括、但不限于该插件的名称、函数签名、对应的优选权重等信息。

第二，插件框架对该插件的源码进行编译，生成对应对链接对象文件。

在本实施例中，链接对象文件可以是动态链接对象，也可以是静态链接对象。

第三，加载该链接对象文件，生成对应的文件句柄。

在本实施例中，该加载支持的操作系统可以是、但不限于Linux和MacOS等操作系统。

在本实施例中，加载支持安全的并发操作，若多个线程同时进行加载，则直接返回已生成的句柄。

在本实施例中，该文件句柄中包含链接对象文件路径、符号散列表、加载通道等。

第四，根据该插件的名称，在对应的文件句柄中搜索对应的符号。

在本实施例中，该符号指的是指向某一对象的指针，即内存中加载的地址，具体来说，指向的可以是链接库源码中任何导出的变量或函数。

在本实施例中，搜索符号的过程支持安全的并发操作，若多个线程同时进行寻找，则会返回同一符号。

在本实施例中，若搜索的符号不存在，则返回一个错误。

第五，根据插件的函数签名，将对应的符号转换为函数类型。

在本实施例中，插件的函数签名为与默认调度器约定的签名。

第六，运行该函数类型对应的函数，启动新注册的插件及其中的各个组件。

在本实施例中，新注册的插件可以包含多个组件，如缓存组件、资源监控组件及所有依赖的外部组件。

本发明实施例提供的上述方法，一方面，可以根据实际场景的需求添加新的自定义预选策略项和/或自定义优选策略项，使得Pod调度更加均衡，最终使得子节点的资源利用更均衡，另一方面，采用插件框架的方式提高了该方法的可扩展性。

为了执行上述实施例及各个可能的实施方式中的相应步骤，下面给出一种Pod均衡调度装置100的实现方式。请参照图9，图9示出了本发明实施例提供的Pod均衡调度装置100的方框示意图。需要说明的是，本实施例所提供的Pod均衡调度装置100，其基本原理及产生的技术效果和上述实施例相同，为简要描述，本实施例部分未提及指出。

Pod均衡调度装置100包括至少一个可以软件或固件(firmware)的形式存储于图2中存储器12中的软件功能模块，处理器11在接收到执行指令后，从存储器12读出该软件功能模块并执行，以实现上述实施例揭示的Pod均衡调度方法。Pod均衡调度装置100包括获取模块110、调度模块120及更新模块130。

获取模块110，用于获取待调度Pod的资源需求量及获取每一预选子节点的实时资源使用量，其中，预选子节点是依据预选策略从多个子节点中确定的。

调度模块120，用于依据优选策略及每一预选子节点的实时资源使用量从预选子节点中确定满足资源需求量的目标子节点，以对待调度Pod进行调度。

作为一种具体实施方式，优选策略对应优选权重，调度模块120具体用于：依据优选策略、优选权重计算每一预选子节点的第一得分；依据每一预选子节点的实时资源使用量及资源需求量，计算每一预选子节点的第二得分；将每一预选子节点的第一得分和第二得分之和作为每一预选子节点的综合得分；将综合得分最高的预选子节点确定为目标子节点。

作为一种具体实施方式，调度模块120在依据每一所述预选子节点的实时资源使用量及所述资源需求量，计算每一所述预选子节点的第二得分时具体用于：依据每一预选子节点的实时资源使用量及资源需求量，得到每一预选子节点的空闲率，并依据每一预选子节点的空闲率确定该预选子节点的第二得分。

更新模块130，用于：获取策略配置文件及依据策略配置文件对预选策略和/或优选策略进行更新。

作为一种具体实施方式，预选策略包括多个预选策略项，策略配置文件包括第一策略，更新模块130具体用于：将未同时存在于预选策略中及第一策略中的预选策略项从预选策略中删除。

作为一种具体实施方式，优选策略包括多个优选策略项及与每一个优选策略项对应的优选权重，策略配置文件包括第二策略，第二策略包括至少一个待更新策略项及与每一待更新策略项对应的优选权重，更新模块130具体还用于：将未同时存在于优选策略中及第二策略中的优选策略项从优选策略中删除；用每一待更新策略项对应的优选权重更新优选策略中与该待更新策略项一致的优选策略项的优选权重。

作为一种具体实施方式，更新模块130具体还用于：获取自定义预选策略项和/或自定义优选策略项；通过预先建立的插件框架将自定义预选策略项添加至预选策略中和/或通过预先建立的插件框架将自定义优选策略项添加至优选策略中。

综上所述，本发明实施例提供了一种Pod均衡调度方法、装置、主节点及存储介质，应用于Kubernetes集群中的主节点，主节点预先存储有预选策略和优选策略，主节点与多个子节点通信连接，所述方法包括：获取待调度Pod的资源需求量；获取每一预选子节点的实时资源使用量，其中，预选子节点是依据预选策略从多个子节点中确定的；依据优选策略及每一预选子节点的实时资源使用量从预选子节点中确定满足资源需求量的目标子节点，以对待调度Pod进行调度。与现有技术相比，本发明实施例通过将Kubernetes集群中子节点的实时资源使用量和调度策略相结合进行资源调度，从而实现了Kubernetes集群中各子节点上的资源的均衡利用。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种Pod均衡调度方法，其特征在于，应用于Kubernetes集群中的主节点，所述主节点预先存储有预选策略和优选策略，所述主节点与多个子节点通信连接，所述方法包括：

获取待调度Pod的资源需求量；

获取每一预选子节点的实时资源使用量，其中，所述预选子节点是依据所述预选策略从所述多个子节点中确定的；

依据所述优选策略及所述每一预选子节点的实时资源使用量从所述预选子节点中确定满足所述资源需求量的目标子节点，以对所述待调度Pod进行调度。

2.如权利要求1所述的Pod均衡调度方法，其特征在于，所述优选策略对应优选权重，所述依据所述优选策略及所述每一预选子节点的实时资源使用量从所述预选子节点中确定满足所述资源需求量的目标子节点的步骤包括：

依据所述优选策略、优选权重计算每一所述预选子节点的第一得分；

依据每一所述预选子节点的实时资源使用量及所述资源需求量，计算每一所述预选子节点的第二得分；

将每一所述预选子节点的第一得分和第二得分之和作为每一所述预选子节点的综合得分；

将所述综合得分最高的预选子节点确定为所述目标子节点。

3.如权利要求2所述的Pod均衡调度方法，其特征在于，所述依据每一所述预选子节点的实时资源使用量及所述资源需求量，计算每一所述预选子节点的第二得分的步骤包括：

依据每一所述预选子节点的实时资源使用量及所述资源需求量，得到每一所述预选子节点的空闲率，并依据每一所述预选子节点的空闲率确定该预选子节点的第二得分。

4.如权利要求1所述的Pod均衡调度方法，其特征在于，所述获取每一预选子节点的实时资源使用量的步骤之前还包括：

获取策略配置文件；

依据所述策略配置文件对所述预选策略和/或所述优选策略进行更新。

5.如权利要求4所述的Pod均衡调度方法，其特征在于，所述预选策略包括多个预选策略项，所述策略配置文件包括第一策略，所述依据所述策略配置文件对所述预选策略进行更新的步骤包括：

将未同时存在于所述预选策略中及所述第一策略中的预选策略项从所述预选策略中删除。

6.如权利要求4所述的Pod均衡调度方法，其特征在于，所述优选策略包括多个优选策略项及与每一个所述优选策略项对应的优选权重，所述策略配置文件包括第二策略，所述第二策略包括至少一个待更新策略项及与每一所述待更新策略项对应的优选权重，所述依据所述策略配置文件对所述优选策略进行更新的步骤包括：

将未同时存在于所述优选策略中及所述第二策略中的优选策略项从所述优选策略中删除；

用每一所述待更新策略项对应的优选权重更新所述优选策略中与该待更新策略项一致的优选策略项的优选权重。

7.如权利要求1所述的Pod均衡调度方法，其特征在于，所述获取每一预选子节点的实时资源使用量的步骤之前还包括：

获取自定义预选策略项和/或自定义优选策略项；

通过预先建立的插件框架将所述自定义预选策略项添加至所述预选策略中和/或通过预先建立的插件框架将所述自定义优选策略项添加至所述优选策略中。

8.一种Pod均衡调度装置，其特征在于，应用于Kubernetes集群中的主节点，所述主节点预先存储有预选策略和优选策略，所述主节点与多个子节点通信连接，所述装置包括：

获取模块，用于获取待调度Pod的资源需求量及获取每一预选子节点的实时资源使用量，其中，所述预选子节点是依据所述预选策略从所述多个子节点中确定的；

调度模块，用于依据所述优选策略及所述每一预选子节点的实时资源使用量从所述预选子节点中确定满足所述资源需求量的目标子节点，以对所述待调度Pod进行调度。

9.一种主节点，其特征在于，所述主节点包括：

一个或多个处理器；

存储器，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1～7中任一项所述的Pod均衡调度方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现如权利要求1～7中任一项所述的Pod均衡调度方法。

Images