CN115061811A - 一种资源调度方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种资源调度方法、装置、设备及存储介质，其中，所述方法包括：确定所述Kubernetes集群中变化的调度策略；基于所述变化的调度策略，更新所述Kubernetes集群中每一节点缓存中的调度策略集合；获取所述Kubernetes集群中新建Pod的部署策略；基于所述部署策略，在更新的调度策略集合中确定目标调度策略；基于所述目标调度策略，在所述Kubernetes集群的节点集合中确定目标节点；将所述新建Pod部署至所述目标节点。

Description

一种资源调度方法、装置、设备及存储介质

技术领域

本申请实施例涉及云计算技术领域，涉及但不限于一种资源调度方法、装置、设备及存储介质。

背景技术

在Kubernetes集群中，一个服务或应用通常会与同一系统内，乃至外部的服务进行交互和通信。企业系统中的一个应用往往需要几十个、甚至数百个单独服务的协同工作，导致微服务架构的应用拓扑结构变得更加复杂，服务之间的交互稳定性降低，一个服务的故障可能会影响调用链上其它服务，形成雪崩效应。对于某些相互依赖的服务，假如这些服务分布在集群中的不同节点，当集群中某个节点故障或节点间网络通信出现故障时，依赖该节点上某些服务的其他服务、应用会收到不同程度的影响，甚至无法正常工作。此时，运维人员只能等待Kubernetes进行服务迁移或手动将该服务迁移至其他可用节点，服务的可用性将会受到影响。

原生的Kubernetes调度器的调度策略虽然可以用来应对节点资源分配不均的问题，比如BalancedResourceAllocation。但是Kubernetes的原生调度器对实际的资源使用情况无法进行感知，都是基于静态的配置进行分配。由于资源分配是静态的，不能代表资源真实使用情况，节点的中央处理器和内存利用率则会经常处于不均衡的状态。

发明内容

有鉴于此，本申请实施例提供一种资源调度方法、装置、设备及存储介质。

本申请实施例的技术方案是这样实现的：

第一方面，本申请实施例提供一种资源调度方法，应用于Kubernetes集群，所述方法包括：

确定所述Kubernetes集群中变化的调度策略；基于所述变化的调度策略，更新所述Kubernetes集群中每一节点缓存中的调度策略集合；获取所述Kubernetes集群中新建Pod的部署策略；基于所述部署策略，在更新的调度策略集合中确定目标调度策略；基于所述目标调度策略，在所述Kubernetes集群的节点集合中确定目标节点；将所述新建Pod部署至所述目标节点。

第二方面，本申请实施例提供一种资源调度装置，所述装置包括：

第一确定模块，用于确定所述Kubernetes集群中变化的调度策略；更新模块，用于基于所述变化的调度策略，更新所述Kubernetes集群中每一节点缓存中的调度策略集合；获取模块，用于获取所述Kubernetes集群中新建Pod的部署策略；第二确定模块，用于基于所述部署策略，在更新的调度策略集合中确定目标调度策略；第三确定模块，用于基于所述目标调度策略，在所述Kubernetes集群的节点集合中确定目标节点；部署模块，用于将所述新建Pod部署至所述目标节点。

第三方面，本申请实施例提供一种电子设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法。

第四方面，本申请实施例提供一种存储介质，存储有可执行指令，用于引起处理器执行时，实现上述方法。

本申请实施例中，首先确定所述Kubernetes集群中变化的调度策略；基于所述变化的调度策略，更新所述Kubernetes集群中每一节点缓存中的调度策略集合；然后获取所述Kubernetes集群中新建Pod的部署策略；基于所述部署策略，在更新的调度策略集合中确定目标调度策略；最后基于所述目标调度策略，在所述Kubernetes集群的节点集合中确定目标节点；将所述新建Pod部署至所述目标节点。这样，可以实现更好的调度弹性，根据不同服务(Pod)的调用、资源使用特性动态地配置调度策略，以针对不同的服务类型采用更合适的调度策略；实现对调度策略进行热修改，在集群运行中根据实际需求调整调度策略。

附图说明

图1为本申请实施例提供的一种资源调度方法的实现流程示意图；

图2A为本申请实施例提供的一种调度策略的结构示意图；

图2B为本申请实施例提供的一种策略缓存的流程示意图；

图2C为本申请实施例提供的一种节点注释的示意图；

图3为本申请实施例提供的部署Pod之后的节点资源对比图；

图4A为本申请实施例提供的一种Pod部署示意图；

图4B为本申请实施例提供的一种Pod部署示意图；

图5为本申请实施例提供的一种Pod调度工作流程示意图；

图6A为本申请实施例提供的一种部署Pod的流程示意图；

图6B为本申请实施例提供的一种部署Pod的流程示意图；

图7为本申请实施例提供的一种节点优选的流程示意图；

图8为本申请实施例提供的一种资源调度装置的组成结构示意图；

图9为本申请实施例提供的电子设备的一种硬件实体示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对申请实施例的具体技术方案做进一步详细描述。以下实施例用于说明本申请，但不用来限制本申请的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

kubernetes，简称K8s，是用8代替名字中间的8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，提供了应用部署，规划，更新，维护的一种机制。

Pod是K8s中的基本构建模块，代表着Kubernetes的部署单元及原子运行单元，即一个应用程序的单一运行实例，通常由共享资源且关系紧密的一个或多个应用容器组成。

ETCD，是Kubernetes提供默认的存储系统，保存所有集群数据，使用时需要为ETCD数据提供备份计划。

节点(Node)，是Kubernetes中最小的计算硬件单元，是集群中单个机器的表示。

本申请实施例提供一种资源调度方法，应用于Kubernetes集群，如图1所示，该方法包括：

步骤S110、确定所述Kubernetes集群中变化的调度策略；

这里，调度策略即资源分配策略，可以是Kubernetes的资源调度器在进行资源调度时通过调度策略将待调度的Pod部署至合适的节点上。在实施过程中，可以根据实际情况设置多个预选方案，在需要部署Pod的情况下，根据实际情况选择合适的预选方案。调度策略的结构可以定义为如图2A所示的策略结构。变化的调度策略，即用户根据实际需求对存储的调度策略进行新增、修改或删除后的调度策略。

在实施过程中，可以在Kubernetes集群中新增统一调度策略模块，即策略配置图(ConfigMap)，对所有Pod调度策略进行统一记录。用户可针对不同类型的服务灵活新增或修改相应的调度策略配置；确定该ConfigMap发生改动，即可以确定Kubernetes集群中变化的调度策略。

这里，变化的调度策略可以是新增的调度策略，也可以是基于原调度策略修改的调度策略，还可以是减少的调度策略。在实施过程中，可以通过设置监控程序监控调度策略ConfigMap，以确定变化的调度策略；还可以设置在调度策略ConfigMap中设置自动上报程序，在确定调度策略变化的情况下，上报变化的调度策略。

图2B为本申请实施例提供的一种策略缓存的流程示意图，如图2B所示，该流程示意图包括以下步骤：

步骤S21、监控策略是否更新；

这里，在Kubernetes集群中新增统一策略配置图，用户可针对不同类型的服务灵活新增、修改相应的调度策略配置。在实施过程中，可以在集群中的每个节点新增守护程序监控策略配置图中的监控策略是否变化。

步骤S22、刷新内存缓存；

当确定该策略配置图发生变化时，将变化更新至每个节点内存中的调度策略缓存中。在实施过程中，可以通过新增节点内存中的调度策略缓存，实现存储最新的汇总调度策略。

执行以上步骤S21和S22，可以实现调度策略的热修改，即在集群运行中根据实际需求调整调度策略。

步骤S120、基于所述变化的调度策略，更新所述Kubernetes集群中每一节点缓存中的调度策略集合；

在实施过程中，每一节点的缓存中可以存储最新的调度策略集合。这里，调度策略集合可以包括至少一种调度策略。如图2B所示，执行步骤S22，可以实现更新Kubernetes集群中每一节点缓存中的调度策略集合。

在一些实施例中，每一节点的缓存中还可以存储节点的打分规则，用户可以根据实际需求新增、修改或删除该打分规则。这里，每一节点的分数可以是基于对硬件可用情况、节点服务性能以及节点调度性能实时监控确定的，还可以是根据历史及实时服务调用统计，针对每个部署服务确定的。

步骤S130、获取所述Kubernetes集群中新建Pod的部署策略；

在实施过程中，该部署策略可以是基于Pod支撑的应用确定的，也可以是基于Pod实现的功能确定的。举例来说，可以基于该应用的调用情况确定部署策略，也可以基于该Pod对节点资源的需求确定部署策略。

步骤S140、基于所述部署策略，在更新的调度策略集合中确定目标调度策略；

在创建新的服务或Pod的情况下，应用程序编程接口服务器(API Server)可以根据Pod的部署策略，在节点缓存中的调度策略集合中选择目标调度策略。举例来说，在部署策略为基于应用的调用情况的部署策略的情况下，可以选择基于调用关系的部署策略；在部署策略为基于Pod对节点资源的需求的部署策略的情况下，可以选择基于节点效能的部署策略。

步骤S150、基于所述目标调度策略，在所述Kubernetes集群的节点集合中确定目标节点；

在实施过程中，目标调度策略中至少包括对节点的打分规则，对完成打分的节点进行排序，可以在Kubernetes集群的节点集合中确定目标节点。

步骤S160、将所述新建Pod部署至所述目标节点。

本申请实施例中，首先确定所述Kubernetes集群中变化的调度策略；基于所述变化的调度策略，更新所述Kubernetes集群中每一节点缓存中的调度策略集合；然后获取所述Kubernetes集群中新建Pod的部署策略；基于所述部署策略，在更新的调度策略集合中确定目标调度策略；最后基于所述目标调度策略，在所述Kubernetes集群的节点集合中确定目标节点；将所述新建Pod部署至所述目标节点。这样，可以实现更好的调度弹性，根据不同服务的调用、资源使用特性动态地配置调度策略，以针对不同的服务类型采用更合适的调度策略；实现对调度策略进行热修改，在集群运行中根据实际需求调整调度策略。

在一些实施例中，更新的调度策略包括以下至少之一：基于节点效能的第一调度策略、基于调用关系的第二调度策略、基于所述节点效能和所述调用关系的第三调度策略；

上述步骤S140“基于所述部署策略，在更新的调度策略集合中确定目标调度策略”可以通过以下步骤实现：

步骤141、确定所述部署策略为基于所述节点效能的部署策略；

这里，节点效能可以综合考量节点的硬件可用情况(CPU、内存、磁盘等)、节点服务性能(服务吞吐量、服务响应时延等)以及节点调度性能(从Pod创建到其被bind到host的耗时)。为了获得节点效能指标，在Pod调度流程及运行周期中，可以引入服务调用及监控统计组件。

步骤142、将所述第一调度策略确定为所述目标调度策略；

这里，用户可以基于实际调度需求将存储于节点缓存中的第一调度策略设置为基于节点效能的调度策略，在确定待部署Pod的部署策略为基于节点效能的部署策略的情况下，将第一调度策略确定为目标调度策略，以满足Pod的部署策略对节点效能的需求。

步骤143、确定所述部署策略为基于所述调用关系的部署策略；

这里，调用关系包括在Pod支撑的服务运行的情况下，各节点之间的调用流量和调用频率等。在实施过程中，可以利用服务调用统计组件获取服务历史及实时的调用关系。

步骤144、将所述第二调度策略确定为所述目标调度策略；

这里，用户可以基于实际调度需求将存储于节点缓存中的第二调度策略设置为基于调用关系的调度策略，在确定待部署Pod的部署策略为基于调用关系的部署策略的情况下，将第二调度策略确定为目标调度策略，以满足Pod的部署策略对调用关系的需求。

步骤145、确定所述部署策略为基于所述节点效能和所述调用关系的部署策略；

步骤146、将所述第三调度策略确定为所述目标调度策略。

这里，用户可以基于实际调度需求将存储于节点缓存中的第三调度策略设置为基于节点效能和调用关系的调度策略，在确定待部署Pod的部署策略为综合考虑节点效能和调用关系的部署策略的情况下，将第三调度策略确定为目标调度策略，以同时满足Pod的部署策略对节点效能和调用关系的需求。

本申请实施例中，更新的调度策略包括以下至少之一：基于节点效能的第一调度策略、基于调用关系的第二调度策略、基于所述节点效能和所述调用关系的第三调度策略；确定所述部署策略为基于所述节点效能的部署策略；将所述第一调度策略确定为所述目标调度策略；确定所述部署策略为基于所述调用关系的部署策略；将所述第二调度策略确定为所述目标调度策略；确定所述部署策略为基于所述节点效能和所述调用关系的部署策略；将所述第三调度策略确定为所述目标调度策略。这样，可以基于Pod的部署策略选择合适的调度策略，以满足Pod的部署需求。

在一些实施例中，上述步骤S150“基于所述目标调度策略，在所述Kubernetes集群的节点集合中确定目标节点”可以通过以下步骤实现：

步骤151、基于所述Kubernetes集群中每一节点的资源信息确定候选节点集合；

在实施过程中，可以首先为待部署的pod过滤集群中不适合运行的节点，即，可以基于Kubernetes集群中每一节点的资源信息，确定存在运行问题，或者已经没有可以利用资源的节点，将以上节点滤除，以确定候选节点集合。

步骤152、基于所述第一调度策略，获取所述候选节点集合中每一节点的硬件可用信息、服务性能信息和调度性能信息；

这里，第一调度策略即基于节点效能的调度策略。需要获取候选节点集合中每一节点的硬件可用信息、服务性能信息和调度性能信息，以对每一节点进行打分。其中，硬件可用信息至少包括CPU、内存和磁盘等硬件的利用率；服务性能信息至少包括服务吞吐量和服务响应时延等信息；调度性能信息至少包括每一节点绑定的Pod数量和每一Pod从创建到其被绑定到节点的耗时。

在实施过程中，在Pod调度流程及运行周期中，可以通过新增服务调用及监控统计组件，实现对接服务流量采集数据及资源监控组件，其中，监控统计组件用于实时监控每一节点的硬件可用信息、服务性能信息和调度性能信息，监控统计组件还可以将系统中采集的监控数据，包括硬件使用情况、节点上Pod的调度性能，定期同步到节点注释(annotation)中。在调度时可以更好地感知集群的实际运行情况，从而最终达到Pod调度后集群资源得到有效利用的效果。

图2C为本申请实施例提供的一种节点注释的示意图，如图2C所示，该示意图包括：节点注释23，用于存储可用CPU信息(avaiable_cpu)、可用内存信息(avaiable_memory)、服务吞吐量(service.throught)、服务响应时延(service.latency)和绑定时间(scheduler.bindtime)。

步骤153、基于所述候选节点集合中每一节点的硬件可用信息、服务性能信息和调度性能信息，对所述每一节点打分，得到节点打分排序；

步骤154、基于所述节点打分排序，在所述候选节点集合中确定目标节点。

在实施过程中，对候选节点集合中每一节点进行打分排序，选择分数最高的节点为目标节点。

图3为本申请实施例提供的部署Pod之后的节点资源对比图，如图3所示，左边部分为现有技术完成Pod部署后的节点资源，右边部分基于第一调度策略，获取候选节点集合中每一节点的硬件可用信息、服务性能信息和调度性能信息，并、基于候选节点集合中每一节点的硬件可用信息、服务性能信息和调度性能信息，对所述每一节点打分，完成Pod部署后的节点资源。

图3左边部分：新pod被调度至node2，但该节点的资源实际利用率缺较低，空闲资源没有得到有效利用。

图3右边部分：node1在同样的资源分配情况下，可分配资源得到重新计算，从而新的业务Pod可以被调度至该节点，提升了节点的资源利用率。

本申请实施例中，首先基于Kubernetes集群中每一节点的资源信息确定候选节点集合；然后，在确定调度策略为第一调度策略的情况下，获取所述候选节点集合中每一节点的硬件可用信息、服务性能信息和调度性能信息；基于所述候选节点集合中每一节点的硬件可用信息、服务性能信息和调度性能信息，对所述每一节点打分，得到节点打分排序；最后基于所述节点打分排序，在所述候选节点集合中确定目标节点。这样，通过对系统资源和服务的实时监控，实现动态的集群运行状态感知，可以有效将效能最高的节点确定为目标节点。

在一些实施例中，上述步骤S150“基于所述目标调度策略，在所述Kubernetes集群的节点集合中确定目标节点”还包括以下步骤：

步骤155、基于所述第二调度策略，获取所述候选节点集合中每一节点关联所述新建Pod的调用分数；

在实施过程中，确定目标调度策略为第二调度策略的情况下，即确定基于调用关系的调度策略为目标调度策略。

步骤156、基于所述候选节点集合中每一节点关联所述新建Pod的调用分数，对所述每一节点打分，得到所述节点打分排序。

在实施过程中，在Pod调度流程及运行周期中，可以通过新增服务调用及监控统计组件，实现对接服务流量采集数据及资源监控组件，其中，服务调用统计组件获取服务历史及实时的调用关系，统计服务调用信息、每个节点的历史资源使用情况以及每个节点的Pod调度详情，并对所有节点进行打分。

关联所述新建Pod的调用分数可以是基于预测每一节点部署新建Pod后，运行该Pod支撑应用需要消耗的调度流量确定的。可以基于历史及实时服务调用信息统计，针对每个部署服务，计算每个节点对应的调用关系分数；并将计算所得分数定期维护至ETCD表中。

图4A为本申请实施例提供的一种Pod部署示意图，如图4A所示，调用关系频繁的服务被调度至不同节点，当Node2发生故障时，Pod1与Pod2提供的服务都会受到影响。

图4B为本申请实施例提供的一种Pod部署示意图，如图4B所示，在新建Pod时，基于节点的调用分数，将调用关系频繁的服务被调度至同一节点，当Node2发生故障时，Node1上的3个服务均无影响。

比对图4A和图4B，可以看出图4B基于调用分数部署的Pod，在节点发生故障的情况下，对服务的影响小于图4A部署的Pod。

本申请实施例中，确定目标调度策略为第二调度策略的情况下，获取所述候选节点集合中每一节点关联所述新建Pod的调用分数；基于所述候选节点集合中每一节点关联所述新建Pod的调用分数，对所述每一节点打分，得到所述节点打分排序。这样，通过对服务调用情况的实时监控，实现动态的集群运行状态感知，可以有效将关联新建Pod的调用分数最高的节点确定为目标节点。使得相关性较高的服务在集群Kubernetes中的分布较为紧密，当系统中某节点发生故障/掉线时，对其他节点上的应用服务影响得到降低；同理，当系统正常运行时，节点间的网络流量/负载得到降低。

在一些实施例中，上述步骤S150“基于所述目标调度策略，在所述Kubernetes集群的节点集合中确定目标节点”还包括以下步骤：

步骤157、基于所述第三调度策略，获取所述候选节点集合中每一节点的硬件可用信息、服务性能信息、调度性能信息、关联所述新建Pod的调用分数；

在实施过程中，通过读取节点annotation中的资源使用情况，获取候选节点集合中每一节点的硬件可用信息、服务性能信息、调度性能信息；读取ETCD中“服务-节点调用分数”，获取关联所述新建Pod的调用分数。

步骤158、基于所述候选节点集合中每一节点的硬件可用信息、服务性能信息、调度性能信息、关联所述新建Pod的调用分数，对所述每一节点打分，得到所述节点打分排序。

在实施过程中，可以基于节点上现存服务与待部署服务间的调用分数，在节点资源使用率低于阈值时，优先将服务调度至“服务-节点调用关系分数”较高的节点上。其中，“服务-节点调用关系分数”，由服务调用及监控统计组件计算写入，用于打分模块计算各节点调度排序分数。

举例来说，在节点打分排序阶段，可以使用以下公式(1)，计算每一节点的总分数：

总分数＝a*Norm(资源分数)+b*Norm(调用分数)(1)；

其中，调度策略中配置的a和b代表了用户在资源与调用关系间的倾向，Norm()表示的对分数归一化操作，可以使用以下公式(2)进行归一化计算：

其中，max为所有节点分数的最大值，min为最小值，x为当前节点的资源分数或调用分数。

本申请实施例中，确定目标调度策略为第三调度策略的情况下，获取所述候选节点集合中每一节点的硬件可用信息、服务性能信息、调度性能信息、关联所述新建Pod的调用分数；基于所述候选节点集合中每一节点的硬件可用信息、服务性能信息、调度性能信息、关联所述新建Pod的调用分数，对所述每一节点打分，得到所述节点打分排序。这样，可以综合节点效能和调用关系计算出得分最高的节点。

在一些实施例中，上述步骤152中“获取所述候选节点集合中每一节点的硬件可用信息、服务性能信息和调度性能信息”可以通过以下步骤实现：

步骤1521、基于所述节点的内存使用率、CPU使用率和磁盘使用率确定所述硬件可用信息；

在实施过程中，可以基于以下公式(3)，得到节点的硬件可用信息分数：

其中，S_hardware表示该节点的硬件可用信息分数，Usage_cpu表示该节点的CPU利用率，Usage_memory表示该节点的内存利用率。

步骤1522、基于所述节点的服务吞吐量和服务响应时延确定所述服务性能信息；

在实施过程中，可以基于以下公式(4)，得到节点的服务性能信息分数：

其中，S_service表示该节点的服务性能信息分数，Elasped_n表示该节点上部署的第n个Pod的服务响应时延，Throughput_n表示该节点上部署的第n个Pod的服务吞吐量。

步骤1523、基于所述节点的Pod部署时长和被绑定的Pod数量确定所述调度性能信息。

在实施过程中，可以基于以下公式(5)，得到节点的调度性能信息分数：

其中，S_schedule表示该节点的调度性能信息分数，BindTime_n表示该节点上部署的第n个Pod的绑定时间，n_pod表示该节点绑定的Pod的数量。

可以基于以下公式(6)，得到节点的资源分数：

其中，Score表示该节点的资源分数，α表示硬件可用信息分数的系数，β表示服务性能信息分数的系数，θ表示调度性能信息分数的系数。

在实施过程中，该资源分数越高说明节点的效能越高，越适合部署Pod。

本申请实施例中，可以基于所述节点的内存使用率、CPU使用率和磁盘使用率，有效确定所述硬件可用信息；基于所述节点的服务吞吐量和服务响应时延，有效确定所述服务性能信息；基于所述节点的Pod部署时长和被绑定的Pod数量，有效确定所述调度性能信息。

在一些实施例中，上述步骤155中“获取所述候选节点集合中每一节点关联所述新建Pod的调用分数”，可以通过以下步骤实现：

步骤1551、确定与所述新建Pod存在关联关系的至少一个服务和每一服务对应的调用流量；

在实施过程中，举例来说可以根据服务调用历史数据，确定待部署的Pod分别与3个服务有着调用关系，分别为service_0，service_1和service_2；获取这三个服务与已部署Pod的调用流量分别为traffic_0，traffic_1和traffic_2。

步骤1552、确定所述每一服务部署的节点；

确定当前集群中有3个节点node_0，node_1和node_2。其中，service_0与service_2部署于node_0，service_1部署于node_2。

步骤1553、基于所述每一服务部署的节点和所述每一服务对应的调用流量，确定所述候选节点集合中每一节点关联所述新建Pod的调用分数。

基于根据节点服务与调用流量，可以确定：

node_0的调用分数为：

node_1的调用分数为0，因为没有与当前Pod相关的服务被部署于该节点；

node_2的调用分数为：

本申请实施例中，首先确定与所述新建Pod存在关联关系的至少一个服务和每一服务对应的调用流量；然后确定所述每一服务部署的节点；最后基于所述每一服务部署的节点和所述每一服务对应的调用流量，确定所述候选节点集合中每一节点关联所述新建Pod的调用分数。这样，计算得到的节点分数可以有效计算出可以反映该节点关联待部署Pod的调用情况。在调度过程中，调度策略可以更倾向于将用于支撑调用关系紧密的服务的Pod调度至相同节点上。

在一些实施例中，上述步骤S110“确定所述Kubernetes集群中变化的调度策略”可以通过以下过程实现：

监控所述Kubernetes集群的调度策略，以确定所述Kubernetes集群中变化的调度策略。

在实施过程中，可以在集群中的每个节点新增节点内调度策略守护进程，监控该调度策略ConfigMap，当该ConfigMap发生变化的情况下，将变化的调度策略更新至每个节点内存中的调度策略缓存中。

本申请实施例中，可以通过监控Kubernetes集群的调度策略，有效确定Kubernetes集群中变化的调度策略。

图5为本申请实施例提供的一种Pod调度工作流程示意图，如图5所示，该工作流程示意图包括：调度过程(Scheduling Cycle)51和绑定过程(Binding Cycle)52，其中，

将调度过程51和绑定过程52合在一起，称之为调度上下文(SchedulingContext)。

调度过程51包括预过滤(Pre-filter)、过滤(Filter)、打分前(PreScore)、打分(Score)、标准打分(Normalize score)、预定(Reserve)和批准(Permit)。调度过程51是调度的核心流程，执行以上步骤进行调度决策，挑选出唯一的节点。

绑定过程52包括等待许可(WaitOnPermit)、预绑定(Pre-bind)、绑定(Bind)和后置绑定(Post-bind)。执行以上步骤，可以将Pod绑定至挑选出的唯一的节点。

图5所示的Pod调度策略为Kubernetes自身的调度策略，即完全静态的调度策略，无法根据服务实际需求进行定制；在服务迁移过程中，服务将暂时不可用；迁移过程中存在服务无法拉起的风险。

在现有技术中还存在以下两种Pod调度方案：

方案一、设置耦合度较高的服务Pod的nodeName，指定这些服务Pod只能被调度到某个指定节点。例如：若服务Pod1和Pod2依赖程度较高，则设置调度方案为：nodeName：nodeX，即规定Pod1和Pod2只能被调度到nodeX节点。

方案二、设置亲和性调度，通过给服务指定一组节点或Pod筛选条件，使得相关联服务被调度至同一节点。

以上两种Pod调度方案存在以下问题：

方案一存在问题：不能有效利用Kubernetes的调度策略，每个Pod只能调度至指定节点。如果Pod因为资源不足被驱逐，则不能调度到其他节点，导致服务不可用。

方案二存在问题：只能由运维或开发人员手动更新部署服务的亲和配置，且该配置是静态的，无法根据集群实际的运行情况自动调整。

图6A为本申请实施例提供的一种部署Pod的流程示意图，如图6A所示，该流程示意图包括以下步骤：

步骤S601、在需要创建Pod的情况下，API服务获取预设策略；

步骤S602、基于Pod注释和预设策略调度Pod，实现创建Pod。

这里，Pod注释中至少包括Pod的标识和部署策略，可以基于Pod的部署策略和预设策略调度，实现创建Pod。

图6B为本申请实施例提供的一种部署Pod的流程示意图，如图6B所示，该流程示意图包括以下步骤：

步骤S610、分析控制器读取服务调用数据和监测数据；

步骤S611、分析控制器分析监测数据得到资源分数，将监测数据和资源分数写入节点注释；分析控制器同时分析服务调用数据得到调用分数，将调用分数写入ETCD；

在实施过程中，分析控制器分析监测数据，并通过节点annotator组件将监测数据和资源分数写入至节点的annotation中；分析控制器同时分析服务调用数据，通过服务调用统计组件计算得出“服务-节点调用分数”，并写入ETCD。

步骤S612、获取Pod注释；

步骤S613、在需要创建Pod的情况下，API服务从节点的策略缓存中获取最新策略；

这里，Kubernetes中的调度策略守护进程，会将调度策略ConfigMap中的变更，实时更新至节点的调度策略缓存中。

在实施过程中，当有创建Pod的请求的情况下，API Server会从调度策略缓存中读取最新的调度策略，结合Pod注释选取合适的调度策略。

步骤S614、基于节点注释、ETCD中的调用分数、Pod注释和最新策略调度Pod，实现创建Pod。

图6B所示的部署Pod流程相较于图6A所示的部署Pod流程，增加了节点注释和缓存最新策略。这样，使用图6B所示的部署Pod流程具有以下有益技术效果：

1、更好的调度弹性，可针对不同的服务类型采用更合适的调度策略；可对调度策略进行热修改，在集群运行中根据实际需求调整调度策略；

2、通过对系统资源和服务的实时监控，实现动态的集群运行状态感知。

图7为本申请实施例提供的一种节点优选的流程示意图，如图7所示，该流程示意图包括以下步骤：

步骤S701、读取节点注释和调用分数；

这里节点注释至少包括：节点实际可用资源详情，节点服务性能统计和节点调度性能统计。调用分数为分析控制器分析服务调用数据得到每一节点的调用分数。

步骤S702、根据当前策略设定，计算节点分数并排序；

策略至少包括：各节点指标的倾向权重。若选中的调度策略是基于服务的调用关系，则在调度的节点打分(优选)阶段，将结合节点的资源使用率情况与ETCD中调用关系计算出的分数，得到最终打分。

步骤S703、基于节点最终优选排序完成Pod部署。

在实施过程中，Pod将在分数最高的节点上完成部署。

执行以上步骤，可以完成节点的排序，选择目标节点，完成Pod部署。

基于前述的实施例，本申请实施例提供一种资源调度装置，该装置包括所包括的各模块，各模块包括各子模块，各子模块包括各单元，可以通过电子设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU)、微处理器(MPU)、数字信号处理器(DSP)或现场可编程门阵列(FPGA)等。

图8为本申请实施例提供的资源调度装置的组成结构示意图，如图8所示，所述装置800包括：

第一确定模块810，用于确定所述Kubernetes集群中变化的调度策略；

更新模块820，用于基于所述变化的调度策略，更新所述Kubernetes集群中每一节点缓存中的调度策略集合；

获取模块830，用于获取所述Kubernetes集群中新建Pod的部署策略；

第二确定模块840，用于基于所述部署策略，在更新的调度策略集合中确定目标调度策略；

第三确定模块850，用于基于所述目标调度策略，在所述Kubernetes集群的节点集合中确定目标节点；

部署模块860，用于将所述新建Pod部署至所述目标节点。

在一些实施例中，所述更新的调度策略包括以下至少之一：基于节点效能的第一调度策略、基于调用关系的第二调度策略、基于所述节点效能和所述调用关系的第三调度策略；所述第二确定模块840包括第一确定子模块、第二确定子模块、第三确定子模块、第四确定子模块、第五确定子模块和第六确定子模块，其中，所述第一确定子模块，用于确定所述部署策略为基于所述节点效能的部署策略；所述第二确定子模块，用于将所述第一调度策略确定为所述目标调度策略；所述第三确定子模块，用于确定所述部署策略为基于所述调用关系的部署策略；所述第四确定子模块，用于将所述第二调度策略确定为所述目标调度策略；所述第五确定子模块，用于确定所述部署策略为基于所述节点效能和所述调用关系的部署策略；所述第六确定子模块，用于将所述第三调度策略确定为所述目标调度策略。

在一些实施例中，所述第三确定模块830包括第七确定子模块、第一获取子模块、第一打分子模块和第八确定子模块，其中，所述第七确定子模块，用于于所述Kubernetes集群中每一节点的资源信息确定候选节点集合；所述第一获取子模块，用于基于所述第一调度策略，获取所述候选节点集合中每一节点的硬件可用信息、服务性能信息和调度性能信息；所述第一打分子模块，用于基于所述候选节点集合中每一节点的硬件可用信息、服务性能信息和调度性能信息，对所述每一节点打分，得到节点打分排序；所述第八确定子模块，用于基于所述节点打分排序，在所述候选节点集合中确定目标节点。

在一些实施例中，所述第三确定模块830还包括第二获取子模块和第二打分子模块，其中，所述第二获取子模块，用于基于所述第二调度策略，获取所述候选节点集合中每一节点关联所述新建Pod的调用分数；所述第二打分子模块，用于基于所述候选节点集合中每一节点关联所述新建Pod的调用分数，对所述每一节点打分，得到所述节点打分排序。

在一些实施例中，所述第三确定模块830还包括第三获取子模块和第三打分子模块，其中，所述第三获取子模块，用于基于所述第三调度策略，获取所述候选节点集合中每一节点的硬件可用信息、服务性能信息、调度性能信息、关联所述新建Pod的调用分数；所述第三打分子模块，用于基于所述候选节点集合中每一节点的硬件可用信息、服务性能信息、调度性能信息、关联所述新建Pod的调用分数，对所述每一节点打分，得到所述节点打分排序。

在一些实施例中，所述第一获取子模块包括第一确定单元、第二确定单元和第三确定单元，其中，所述第一确定单元，用于基于所述节点的内存使用率、CPU使用率和磁盘使用率确定所述硬件可用信息；所述第二确定单元，用于基于所述节点的服务吞吐量和服务响应时延确定所述服务性能信息；所述第三确定单元，用于基于所述节点的Pod部署时长和被绑定的Pod数量确定所述调度性能信息。

在一些实施例中，所述第二获取子模块包括第四确定单元、第五确定单元和第六确定单元，其中，所述第四确定单元，用于确定与所述新建Pod存在关联关系的至少一个服务和每一服务对应的调用流量；所述第五确定单元，用于确定所述每一服务部署的节点；所述第六确定单元，用于基于所述每一服务部署的节点和所述每一服务对应的调用流量，确定所述候选节点集合中每一节点关联所述新建Pod的调用分数。

在一些实施例中，所述第一确定模块810，还用于监控所述Kubernetes集群的调度策略，以确定所述Kubernetes集群中变化的调度策略。

以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得电子设备(可以是手机、平板电脑、笔记本电脑、台式计算机等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

对应地，本申请实施例提供一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中提供的资源调度方法中的步骤。

对应地，本申请实施例提供一种电子设备，图9为本申请实施例提供的电子设备的一种硬件实体示意图，如图9所示，该设备900的硬件实体包括：包括存储器901和处理器902，所述存储器901存储有可在处理器902上运行的计算机程序，所述处理器902执行所述程序时实现上述实施例中提供的资源调度方法中的步骤。

存储器901配置为存储由处理器902可执行的指令和应用，还可以缓存待处理器902以及电子设备900中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(FLASH)或随机访问存储器(Random AccessMemory，RAM)实现。

这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得电子设备(可以是手机、平板电脑、笔记本电脑、台式计算机等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

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

Claims (11)

1.一种资源调度方法，应用于Kubernetes集群，所述方法包括：

确定所述Kubernetes集群中变化的调度策略；

基于所述变化的调度策略，更新所述Kubernetes集群中每一节点缓存中的调度策略集合；

获取所述Kubernetes集群中新建Pod的部署策略；

基于所述部署策略，在更新的调度策略集合中确定目标调度策略；

基于所述目标调度策略，在所述Kubernetes集群的节点集合中确定目标节点；

将所述新建Pod部署至所述目标节点。

2.如权利要求1所述的方法，所述更新的调度策略包括以下至少之一：基于节点效能的第一调度策略、基于调用关系的第二调度策略、基于所述节点效能和所述调用关系的第三调度策略；

所述基于所述部署策略，在更新的调度策略集合中确定目标调度策略，包括：

确定所述部署策略为基于所述节点效能的部署策略；

将所述第一调度策略确定为所述目标调度策略；

确定所述部署策略为基于所述调用关系的部署策略；

将所述第二调度策略确定为所述目标调度策略；

确定所述部署策略为基于所述节点效能和所述调用关系的部署策略；

将所述第三调度策略确定为所述目标调度策略。

3.如权利要求2所述的方法，所述基于所述目标调度策略，在所述Kubernetes集群的节点集合中确定目标节点，包括：

基于所述Kubernetes集群中每一节点的资源信息确定候选节点集合；

基于所述第一调度策略，获取所述候选节点集合中每一节点的硬件可用信息、服务性能信息和调度性能信息；

基于所述候选节点集合中每一节点的硬件可用信息、服务性能信息和调度性能信息，对所述每一节点打分，得到节点打分排序；

基于所述节点打分排序，在所述候选节点集合中确定目标节点。

4.如权利要求3所述的方法，所述方法还包括：

基于所述第二调度策略，获取所述候选节点集合中每一节点关联所述新建Pod的调用分数；

基于所述候选节点集合中每一节点关联所述新建Pod的调用分数，对所述每一节点打分，得到所述节点打分排序。

5.如权利要求3所述的方法，所述方法还包括：

基于所述第三调度策略，获取所述候选节点集合中每一节点的硬件可用信息、服务性能信息、调度性能信息、关联所述新建Pod的调用分数；

基于所述候选节点集合中每一节点的硬件可用信息、服务性能信息、调度性能信息、关联所述新建Pod的调用分数，对所述每一节点打分，得到所述节点打分排序。

6.如权利要求3所述的方法，所述获取所述候选节点集合中每一节点的硬件可用信息、服务性能信息和调度性能信息，包括：

基于所述节点的内存使用率、CPU使用率和磁盘使用率确定所述硬件可用信息；

基于所述节点的服务吞吐量和服务响应时延确定所述服务性能信息；

基于所述节点的Pod部署时长和被绑定的Pod数量确定所述调度性能信息。

7.如权利要求4所述的方法，所述获取所述候选节点集合中每一节点关联所述新建Pod的调用分数，包括：

确定与所述新建Pod存在关联关系的至少一个服务和每一服务对应的调用流量；

确定所述每一服务部署的节点；

基于所述每一服务部署的节点和所述每一服务对应的调用流量，确定所述候选节点集合中每一节点关联所述新建Pod的调用分数。

8.如权利要求1所述的方法，所述确定所述Kubernetes集群中变化的调度策略，包括：

监控所述Kubernetes集群的调度策略，以确定所述Kubernetes集群中变化的调度策略。

9.一种资源调度装置，所述装置包括：

第一确定模块，用于确定所述Kubernetes集群中变化的调度策略；

更新模块，用于基于所述变化的调度策略，更新所述Kubernetes集群中每一节点缓存中的调度策略集合；

获取模块，用于获取所述Kubernetes集群中新建Pod的部署策略；

第二确定模块，用于基于所述部署策略，在更新的调度策略集合中确定目标调度策略；

第三确定模块，用于基于所述目标调度策略，在所述Kubernetes集群的节点集合中确定目标节点；

部署模块，用于将所述新建Pod部署至所述目标节点。

10.一种种电子设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现权利要求1至8任一项所述方法中的步骤。

11.一种存储介质，存储有可执行指令，用于引起处理器执行时，实现权利要求1至8任一项所述的方法中的步骤。

Images