资源重调度方法、装置、设备和介质

技术领域

本发明实施例涉及计算机技术领域，尤其涉及一种资源重调度方法、装置、设备和介质。

背景技术

Kubernetes是开源的容器集群管理系统，提供应用部署、维护、扩展机制等功能，利用kubernetes能方便管理跨集群运行容器化的应用。

在Kubernetes集群技术中，节点(Node)代表Kubernetes集群中运行的宿主物理计算机或虚拟机服务器，为容器提供必要的计算资源。Pod(容器集合)作为Kubernetes集群的最小调度单位，一个Pod中可以包含一个或多个运行的容器，这些容器运行在同一台节点上，共享节点的资源。

原生的Kube-scheduler(调度)组件只根据集群当前资源分布情况进行最优调度选择，对后续资源变化后的资源状况不会进行二次调度。社区的descheduler项目可以周期性根据当前集群资源分布，针对高分配率节点驱逐部分Pod达到平衡节点资源分配率的目的。但是，descheduler项目根据资源分配率均衡节点会出现节点实际负载不均衡问题，而且有可能导致被驱逐的Pod被重新调度回原节点甚至在调度队列中无法调度的问题。

发明内容

本发明实施例提供一种资源重调度方法、装置、设备和介质，以均衡集群内各节点的实际负载，同时尽量保证针对被驱逐的Pod的重调度成功率。

第一方面，本发明实施例提供了一种资源重调度方法，包括：

定时获取集群内各节点的实际负载数据；

如果根据所述各节点的实际负载数据确定存在高载节点和低载节点，则确定所述高载节点上的待重调度POD，并模拟计算所述待重调度POD的重调度结果；

如果所述重调度结果指示允许将所述待重调度POD迁移至所述低载节点上，则驱逐所述待重调度POD，以实现所述待重调度POD在所述集群中被重新部署。

第二方面，本发明实施例还提供了一种资源重调度装置，包括：

实际负载获取模块，用于定时获取集群内各节点的实际负载数据；

重调度结果模拟模块，用于如果根据所述各节点的实际负载数据确定存在高载节点和低载节点，则确定所述高载节点上的待重调度POD，并模拟计算所述待重调度POD的重调度结果；

POD驱逐模块，用于如果所述重调度结果指示允许将所述待重调度POD迁移至所述低载节点上，则驱逐所述待重调度POD，以实现所述待重调度POD在所述集群中被重新部署。

第三方面，本发明实施例还提供了一种计算机设备，所述计算机设备包括：

一个或多个处理器；

存储器，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现任意实施例所述的资源重调度方法。

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

在本发明实施例提供的技术方案中，定时获取集群内各节点的实际负载数据，并在根据实际负载数据确定集群中存在高载节点和低载节点时，确定所述高载节点上的待重调度POD进行驱逐，以此均衡了集群内各节点的实际负载，能够避免高载节点出现过载的问题；同时，在对所述高载节点上的待重调度POD进行驱逐之前，模拟计算了待重调度POD的重调度结果，只有在重调度结果指示在待重调度POD被驱逐后允许将其迁移至低载节点上时，才会对待重调度POD进行驱逐，由此尽量保证了针对被驱逐的Pod的重调度成功率，避免了待重调度POD在被驱逐后又被重新调度回原高载节点，甚至在调度队列中无法调度的问题。

附图说明

图1是本发明实施例一提供的一种资源重调度方法的流程图；

图2是本发明实施例二提供的一种资源重调度方法的流程图；

图3是本发明实施例三提供的一种资源重调度方法的流程图；

图4是本发明实施例三提供的资源重调度方法所适用的系统架构示意图；

图5是本发明实施例四提供的一种资源重调度装置的模块结构示意图；

图6是本发明实施例五提供的一种计算机设备的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于述，附图中仅示出了与本发明相关的部分而非全部结构。

在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

实施例一

图1是本发明实施例一提供的一种资源重调度方法的流程图，本实施例可适用于Kubernetes集群中对Pod进行重调度的情况，该方法可以由本发明任意实施例提供的资源重调度装置来执行，该装置可由硬件和/或软件组成，并一般可集成在计算机设备。

如图1所示，本实施例提供的资源重调度方法，包括以下步骤：

S110、定时获取集群内各节点的实际负载数据。

其中，集群可以是指Kubernetes集群；集群内各节点可以是指Kubernetes集群中除了主节点之外的各计算节点。

实际负载数据，可以是指在集群内各节点运行过程中通过监控系统monitor监控到的负载数据，可以包括CPU负载数据、内存负载数据、磁盘负载数据、网络负载数据等。可选的，实际负载数据指的是实际CPU负载数据和/或实际内存负载数据。下述以实际负载数据为实际CPU负载数据为例进行解释说明。

在获取到的各节点的实际CPU负载数据中，除了包括节点的实际CPU负载数据，还可以包括节点上每个POD的实际CPU负载数据。

按照预设周期定时获取集群内各节点的实际负载数据，进而可以根据各节点的实际负载数据判断集群内各节点的负载类型。

S120、如果根据所述各节点的实际负载数据确定存在高载节点和低载节点，则确定所述高载节点上的待重调度POD，并模拟计算所述待重调度POD的重调度结果。

在获取到各节点的实际负载数据之后，可以根据预设的节点类型划分规则确定各节点的节点负载类型，节点负载类型可以包括低载节点和高载节点，或者可以包括低载节点、高载节点和过载节点。

可选的，预设的节点类型划分规则可以是依据节点的实际负载率而确定的，由此可以精准的定位高载节点，克服了“实际生产环境中存在资源声明很高但实际使用率很低的容器而导致节点分配率很高，但实际上并没有高载”的问题。

其中，低载节点的实际负载率属于第一负载率区间，高载节点的实际负载率属于第二负载率区间，过载节点的实际负载率属于第三负载率区间，第一负载率区间中的实际负载率值小于第二负载率区间中的实际负载率值，第二负载率区间中的实际负载率值小于第三负载率区间中的实际负载率值。

例如，可以将实际CPU负载率在0～40％之间的节点确定为低载节点，将实际CPU负载率在70％～90％之间的节点确定为高载节点，将实际CPU负载率大于等于90％的节点确定为过载节点。其中，不同负载类型的节点的状态标识不同。

作为一种可选的实施方式，可以在Kubernetes集群中引入新组件“节点控制(node-controller)组件”用于实现对集群中各节点的负载类型进行确定。其中，node-controller组件周期性通过监控系统拉取集群内所有节点的CPU负载数据，针对不同负载率区间的节点设置不同的负载状态标识(包括低载状态标识、高载状态标识、过载状态标识)，以标识各节点的节点负载类型。同时，node-controller组件还可以对外提供节点上每个Pod的CPU负载数据的查询功能。

例如，node-controller组件为实际CPU负载率在0～40％之间的节点添加低载状态标识(如cpuUnderload标识)，为实际CPU负载率在70％～90％之间的节点添加高载状态标识(如cpuPressure标识)，为实际CPU负载率大于90％的节点添加过载状态标识(如cpuoverPressure标识)。

可选的，node-controller组件为实际CPU负载率在70％～90％之间的节点添加高载状态标识(如cpuPressure标识)，为实际CPU负载率大于90％的节点添加高载状态标识(如cpuPressure标识)以及高载状态(cpuPressure)的污点规则(Taint)。其中，存在Taint的节点(也即过载节点)可以避免新的POD调度。

在确定集群中存在高载节点和低载节点时，例如可以通过集群内各台节点的负载状态标识确定各台节点的负载类型，则可以对高载节点上POD进行重调度，以降低该节点负载类型的等级，如负载类型由高载节点调整为低载节点。

首先，在高载节点上所有POD中选择可剥离POD作为待重调度POD。其中，可剥离POD可以是指能够从节点上剥离且不会影响业务可用性的POD。若高载节点上存在多个可剥离POD，可以按照预设选择策略或者随机方式在其中确定待重调度POD。

然后，针对待重调度POD模拟计算重调度结果。也即，根据集群当前的资源分布情况进行模拟计算，判断所述待重调度POD被驱逐后的重调度结果，例如可以是能否被重调度，以及在能够被重调度的情况下被重部署的节点负载类型(是低载节点还是高载节点)等等。

S130、如果所述重调度结果指示允许将所述待重调度POD迁移至所述低载节点上，则驱逐所述待重调度POD，以实现所述待重调度POD在所述集群中被重新部署。

在模拟计算完成所述待重调度POD的重调度结果之后，如果重调度结果指示在对所述待重调度POD进行重部署至所述低载节点上，也即所述待重调度POD在被驱逐后，在重调度时可被迁移到所述低载节点上，在将所述待重调度POD进行驱逐，以使所述待重调度POD在所述集群中被重新部署。

在模拟计算完成所述待重调度POD的重调度结果之后，如果重调度结果指示无法对待重调度POD进行重部署，或者在重调度时会被迁移到原高载节点上时，则不会将所述待重调度POD进行驱逐。

在本实施例中，在将待重调度POD驱逐之后，是由Kubernetes集群的调度组件kube-scheduler决定如何对待重调度POD进行重调度的，也即决定将待重调度POD进行驱逐的组件是无法决定待重调度POD的重调度结果的。其中，kube-scheduler是kubernetes控制面的核心组件之一，负责容器资源和宿主的调度和绑定。

因此，在将待重调度POD进行驱逐之前，首先模拟计算了待重调度POD的重调度结果，只有在重调度结果指示允许将所述待重调度POD迁移至所述低载节点时，才会将待重调度POD进行驱逐，并非是只考虑节点负载等级下降而不考虑重调度结果，以此尽量保证了针对被驱逐的Pod的重调度成功率，避免了待重调度POD在被驱逐后又被重新调度回原高载节点，甚至在调度队列中无法调度的问题。

作为一种可选的实施方式，可以在Kubernetes集群中引入新组件“负载平衡控制(balance-controller)组件”用于实现对集群中高载节点上的待重调度POD进行驱逐的操作。其中，balance-controller组件周期性获取集群内所有节点的负载类型(即低载节点、高载节点、过载节点)，例如可以通过组件kube-apiserver获取集群内所有节点的负载类型，并过滤出集群中的高载节点和低载节点，针对高载节点上的待重调度POD，模拟计算其重调度结果，只有在重调度结果指示在将其驱逐后允许将其迁移到低载节点上时，对所述待重调度POD进行驱逐，以此达到平衡集群中节点间实际负载的目的。其中，kube-apiserver是kubernetes控制面的核心组件之一，提供了所有资源对象的增删改查接口，包括节点(node)、容器集合(POD)、副本控制器(Replicaset)等。Relicaset用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出了，会自动创建新的POD来替代，而如果异常多出来的容器也会自动回收，并提供声明式更新等功能。

可选的，本实施例提供的资源重调度方法，还包括：如果根据所述各节点的实际负载数据确定存在过载节点，则确定所述过载节点上的待重调度POD，并驱逐所述待重调度POD。

其中，过载节点可以指的是实际负载率超过负载率阈值(如90％)且添加污点规则的节点。污点规则(Taint)，是kubernetes提供的一种调度策略，节点上打上Taint可以避免新的Pod调度，只有容忍Taint条件的Pod才可以调度。

针对过载节点上的待重调度POD，可以直接对其进行驱逐处理，例如可以根据业务优先级在过载节点上确定待重调度POD，并将其直接进行驱逐处理，以实现对过载节点的保护。可选的，node-controller组件在确定集群中存在过载节点时，直接对过载节点上的待重调度POD进行驱逐。

进一步的，本实施例提供的资源重调度方法，在驱逐所述待重调度POD之后，还包括：通过kube-scheduler组件基于预设的低载节点优选策略实现对所述待重调度POD的重新部署。

低载节点优选策略，指的是在原生调度策略的基础上增加优选低载节点进行重调度的策略。

在本实施例中，可以通过scheduler-extender的方式对组件kube-scheduler的调度策略进行调整，在原生调度策略的基础上增加优选低载节点进行重调度的策略。其中，scheduler-extender是kube-scheduler提供的一种扩展调度策略的机制，允许用户自定义调度策略。

在驱逐所述待重调度POD之后，通过kube-scheduler组件基于预设的低载节点优选策略实现对所述待重调度POD的重新部署，所述待重调度POD会优先重新部署到低载节点上，实现均衡负载的目的。

作为本实施例一种可选的实施方式，确定所述高载节点上的待重调度POD，可以具体为：确定所述高载节点上的一个待重调度POD。

在本实施方式中，每次只确定所述高载节点上的一个待重调度POD，也即每次只会驱逐所述高载节点上的一个待重调度POD，而不是驱逐所述高载节点上的多个待重调度POD，原因在于：

在本实施方式中，驱逐待重调度POD的组件(如balance-controller)不负责待重调度POD的调度，所有待重调度POD被驱逐后都要经过kube-scheduler的重新调度。因此，驱逐待重调度POD的组件无法保证驱逐的Pod的重调度结果。如果驱逐多个待重调度POD，模拟计算的重调度结果有可能会出现冲突，由于针对每个待重调度POD的重调度结果的模拟计算过程都是独立的，不会感知针对前一个待重调度POD的模拟重调度结果，也无法决定针对前一个待重调度POD的模拟重调度结果一定能实现(也即一定能重调度到理想中的节点)。

同时，在针对待重调度POD的重调度结果进行模拟计算时，集群同一时间还可能有新创建的POD在等待调度，驱逐待重调度POD的组件(如balance-controller)和调度组件(kube-scheduler)的调度视角有可能会存在误差。因此，驱逐多个待重调度POD只会放大这种潜在的误差，导致出现过多的待重调度POD被驱逐的问题，例如，同一时间有其他POD的调度占满了低载节点，则待重调度POD被驱逐后有概率继续回到高载节点。

另外，当高载节点上的一个待重调度POD被驱逐后，高载节点可能因为负载减少而已经进入正常节点的状态，此时也没必要驱逐过多的POD加大影响业务的可能性。

在本发明实施例提供的技术方案中，定时获取集群内各节点的实际负载数据，并在根据实际负载数据确定集群中存在高载节点和低载节点时，确定所述高载节点上的待重调度POD进行驱逐，以此均衡了集群内各节点的实际负载，能够避免高载节点出现过载的问题；同时，在对所述高载节点上的待重调度POD进行驱逐之前，模拟计算了待重调度POD的重调度结果，只有在重调度结果指示在待重调度POD被驱逐后允许将其迁移至低载节点上时，才会对待重调度POD进行驱逐，由此尽量保证了针对被驱逐的Pod的重调度成功率，避免了待重调度POD在被驱逐后又被重新调度回原高载节点，甚至在调度队列中无法调度的问题。

实施例二

图2是本发明实施例二提供的一种资源重调度方法的流程图，本实施例在上述实施例的基础上进行具体化，其中，所述模拟计算所述待重调度POD的重调度结果，可以具体为：

在根据所述集群的当前资源分布确定不存在满足所述待重调度POD重调度条件的低载节点的情况下，基于抢占调度策略模拟计算所述集群在所述低载节点上与所述待重调度POD对应的待抢占POD被驱逐之后的资源分布结果；

根据所述资源分布结果，判断是否存在满足所述待重调度POD重调度条件的低载节点。

如图2所示，本实施例提供的资源重调度方法，包括以下步骤：

S210、定时获取集群内各节点的实际负载数据。

S220、如果根据所述各节点的实际负载数据确定存在高载节点和低载节点，则确定所述高载节点上的待重调度POD。

可选的，确定所述高载节点上的待重调度POD，可以具体为：获取所述高载节点上的可剥离POD；根据所述可剥离POD的优先级和/或容器实际负载确定高载节点上的待重调度POD。

可剥离POD，指的是能够在节点上剥离且不会影响业务可用性的POD。在判断高载节点上的各个POD是否为可剥离POD时，可以判断POD是否归属于无状态编排应用(如Replicaset)，且归属的无状态编排应用是否具备大于1的可用副本，若是，在判断出该POD为可剥离POD，若否，则判断出该POD不是可剥离POD。

针对在高载节点上获取到的多个可剥离POD，可以基于优先级和/或容器实际负载确定高载节点上的待重调度POD。例如，在优先级各不相同的情况下可以按照优先级由低到高的顺序依次确定高载节点上的待重调度POD，或者，在优先级相同的情况下按照容器实际负载对高载节点实际负载率的影响程度由高到低的顺序依次确定高载节点上的待重调度POD。

作为一种可选的实施方式，根据所述可剥离POD的优先级和/或容器实际负载确定高载节点上的待重调度POD，可以包括：将所述可剥离POD中优先级最低的POD作为所述待重调度POD。

针对高载节点上的多个可剥离POD，将其按照优先级高低排序，将优先级最低的POD作为所述待重调度POD。

作为另一种可选的实施方式，根据所述可剥离POD的优先级和/或容器实际负载确定高载节点上的待重调度POD，可以包括：将所述可剥离POD中容器实际负载满足节点负载降级条件的POD作为所述待重调度POD。

节点负载降级条件，指的是使节点负载等级下降的条件，例如可以是使节点由高载节点调整为正常节点或者低载节点的条件，或者是使节点由过载节点调整为高载节点或正常节点或低载节点的条件。

针对高载节点上的多个可剥离POD，获取各个可剥离POD的实际负载，并根据各个可剥离POD的实际负载判断是否满足节点负载降级条件使所在的高载节点的节点负载等级下降，若是，则可以将其确定为所述待重调度POD。

作为又一种可选的实施方式，根据所述可剥离POD的优先级和/或容器实际负载确定高载节点上的待重调度POD，还可以包括：将所述可剥离POD中优先级最低且容器实际负载满足节点负载降级条件的POD作为所述待重调度POD。

针对高载节点上的多个可剥离POD，将其按照优先级高低排序，同时获取各个可剥离POD的实际负载，并根据各个可剥离POD的实际负载判断是否满足节点负载降级条件使所在的高载节点的节点负载等级下降，进而可以将优先级最低且容器实际负载满足节点负载降级条件的POD作为所述待重调度POD。

S230、在根据所述集群的当前资源分布确定不存在满足所述待重调度POD重调度条件的低载节点的情况下，基于抢占调度策略模拟计算所述集群在所述低载节点上与所述待重调度POD对应的待抢占POD被驱逐之后的资源分布结果。

在确定所述待重调度POD之后，根据集群的当前资源分布模拟计算所述待重调度POD的重调度结果。

根据集群的当前资源分布判断是否存在满足所述待重调度POD重调度条件的低载节点，若是，则所述待重调度POD的重调度结果即可指示允许将所述待重调度POD迁移至所述低载节点上，若否，则需要基于抢占调度策略模拟计算所述集群在所述低载节点上与所述待重调度POD对应的待抢占POD被驱逐之后的资源分布结果。

其中，低载节点满足所述待重调度POD重调度条件，指的是低载节点的空闲资源满足部署所述待重调度POD所需的资源。

抢占调度策略，指的是kubernetes原生抢占调度的策略。

在根据集群的当前资源分布判断出不存在满足所述待重调度POD重调度条件的低载节点时，可以继续模拟计算待重调度POD对低载节点上优先级低于其的POD进行抢占，并将被抢占的POD在对应的低载节点上驱逐后的资源分布结果。

S240、根据所述资源分布结果，判断是否存在满足所述待重调度POD重调度条件的低载节点，若是，则执行S250，若否，则执行S220。

在基于抢占调度策略模拟计算得出资源分布结果之后，可以继续根据该资源分布结果继续是否判断是否存在满足所述待重调度POD重调度条件的低载节点，若是，则可以执行S250执行对所述待重调度POD的驱逐操作，若否，则无法对所述待重调度POD进行驱逐，需要重新确定待重调度POD，继续执行S230-S240的判断流程。

S250、驱逐所述待重调度POD，以实现所述待重调度POD在所述集群中被重新部署。

需要注意的是，本实施例提供的流程是针对同一个高载节点而言的，针对其他高载节点流程亦是如此。本实施例未尽详细解释之处请参见前述实施例，在此不再赘述。

上述技术方案中，在不影响业务的前提下，有效地降低了集群内高载节点和低载节点的比例，达到均衡节点间负载的效果；基于抢占调度策略模拟计算待重调度POD的重调度结果，尽可能地保证了被驱逐的POD可以通过抢占调度被重新部署，而不是单纯驱逐所有满足条件的POD，进一步细化了资源重调度以均衡节点间负载的策略。

实施例三

图3是本发明实施例三提供的一种资源重调度方法的流程图，本实施例在上述实施例的基础上提供了一种具体的实施方式，在本实施例中引入node-controller组件和balance-controller组件。

其中，node-controller组件周期性通过监控系统拉取集群内所有节点的CPU负载数据，针对不同负载率区间的节点设置不同的负载状态标识(包括低载状态标识、高载状态标识、过载状态标识)，以标识各节点的节点负载类型。同时，node-controller组件还可以对外提供节点上每个Pod的CPU负载数据的查询功能。另外，在集群中存在过载节点时，node-controller组件可以根据业务优先级驱逐过载节点上的部分POD达到保护宿主节点的目的。

可选的，根据预定义的负载区间，node-controller组件为实际CPU负载率在0～40％之间节点添加低载状态标识(cpuUnderload标识)，为实际CPU负载率在70％～90％之间的节点添加高载状态标识(如cpuPressure标识)，为实际CPU负载率大于90％的节点添加高载状态标识(如cpuPressure标识)以及高载状态(cpuPressure)的污点规则(Taint)。其中，存在Taint的节点(也即过载节点)可以避免新的POD调度。

balance-controller组件周期性获取集群内所有节点的负载类型(即低载节点、高载节点、过载节点)，例如可以通过组件kube-apiserver获取集群内所有节点的负载类型，并过滤出集群中的高载节点和低载节点，针对高载节点上的待重调度POD，模拟计算其重调度结果，只有在重调度结果指示在将其驱逐后允许将其迁移到低载节点上时，对所述待重调度POD进行驱逐，也即评估高载节点上的容器实例，当存在适合迁移的低载节点时，驱逐高载节点上相应的容器实例，以此达到平衡集群中节点间实际负载的目的。

如图3所示，本实施例提供的资源重调度方法，包括以下步骤：

S310、通过node-controller组件周期性地获取集群内各节点的实际负载数据，并根据所述实际负载数据添加状态标识，更新对应节点的负载类型。

参照图4，node-controller组件周期性地通过监控系统monitor拉取集群内每台节点的负载监控数据，根据预定义的负载区间将图4中的三台示例节点(cpu使用率分别为30％、75％和90％)分别标识为低载节点(cpuPressure标识)、高载节点(cpuPressure标识)、过载节点(cpuPressure标识+污点规则)，更新对应节点的负载类型，同时缓存住最新的节点监控数据。可选的，关于低载节点的标识可以通过balance-controller组件在node-controller组件中获取后为节点进行标识。

S320、如果存在过载节点，则通过node-controller组件根据业务优先级将过载节点上的部分POD驱逐。

S330、通过balance-controller组件周期性地根据节点负载类型确定存在高载节点和低载节点时，确定所述高载节点上的待重调度POD。

其中，balance-controller组件可以在主节点中获取节点列表和各节点上的POD列表。

S340、在根据所述集群的当前资源分布确定不存在满足所述待重调度POD重调度条件的低载节点的情况下，通过balance-controller组件基于抢占调度策略模拟计算所述集群在所述低载节点上与所述待重调度POD对应的待抢占POD被驱逐之后的资源分布结果。

S350、通过balance-controller组件根据所述资源分布结果，判断是否存在满足所述待重调度POD重调度条件的低载节点，若是，则执行S360，若否，则执行S330。

参照图4，balance-controller组件周期性地通过kube-apiserver组件拉取所有节点的状态数据，根据节点负载类型过滤出高载节点和低载节点。当同时存在低载节点和高载节点时，通过node-controller组件提供的接口拉取最新缓存的节点监控数据，并评估高载节点上的Pod是否具备迁移条件。

首先，判断高载节点上的Pod是否归属Replicaset这种无状态编排应用，且归属的Replicaset是否具备大于1的可用副本，若是，则可以将其确定为待重调度POD，以此保证均衡重调度的操作不影响业务可用性。

其次，每次只判断一个待重调度POD是否具备迁移条件。

具体的，针对一个待重调度POD，根据所述集群的当前资源分布判断是否存在满足所述待重调度POD重调度条件的低载节点，若是，则该待重调度POD具备迁移条件，执行S360将其在高载节点上驱逐，若否，则基于抢占调度策略模拟计算所述集群在所述低载节点上与所述待重调度POD对应的待抢占POD被驱逐之后的资源分布结果，并继续根据所述资源分布结果判断是否存在满足所述待重调度POD重调度条件的低载节点，若是，则该待重调度POD具备迁移条件，执行S360将其在高载节点上驱逐，若否，则继续针对下一个待重调度POD进行是否具备迁移条件的判断。如果所有待重调度POD均不具备迁移条件，则本次流程结束。

其中，在执行基于抢占调度策略模拟计算所述集群在所述低载节点上与所述待重调度POD对应的待抢占POD被驱逐之后的资源分布结果，并继续根据所述资源分布结果判断是否存在满足所述待重调度POD重调度条件的低载节点的操作时，可以按照kubernetes原生抢占调度的策略，遍历低载节点的列表，对低载节点上优先级(PriorityClass)低于待重调度POD的POD(可以标记为待抢占POD)进行抢占模拟，并确定待抢占POD被驱逐后的资源分布结果，进而根据该资源分布结果判断是否存在满足所述待重调度POD重调度条件的低载节点，在至少存在一个满足所述待重调度POD重调度条件的低载节点时，即可确定该待重调度POD具备迁移条件。

参照图4，POD后缀的P5、P6、P7、P8为POD的业务优先级(PriorityClass)，原生kubernetes也是根据PriorityClass进行抢占式调度，balance-controller组件的核心思路是提前选择高载节点上的无状态业务进行抢占式调度的模拟计算，进而根据模拟计算得到的重调度结果确定是否对相应的POD进行驱逐。

S360、通过balance-controller组件将所述待重调度POD驱逐。

需要注意的是，高载节点上的待重调度POD驱是通过balance-controller组件驱逐的，而过载节点上的POD是通过node-controller组件直接驱逐的。

S370、通过kube-scheduler组件基于预设的低载节点优选策略实现对所述待重调度POD的重新部署。

通过scheduler-extender的方式对kube-scheduler组件加入了低载节点的优选策略，即kube-scheduler组件会优先选择低载节点进行调度，被驱逐的POD会优先被调度到低载节点，以此达到均衡负载的目的。

在如图4所示的示例中，高载节点(原CPU实际使用率为75％)中的POD_P5，以及过载节点(原CPU实际使用率为90％且添加污点规则)中的POD_P5被驱逐后，极大概率可以被重新部署在低载节点(原CPU实际使用率为30％)上。

本实施例未尽详细解释之处请参见前述实施例，在此不再赘述。

本实施例提供的技术方案，node-controller组件和balance-controller组件都在周期性工作，node-controller组件不断的标记最新的节点负载类型，balance-controller组件则不断的对高载节点进行均衡迁移的模拟计算，对计算可行的待重调度POD进行驱逐，有效地降低了集群内高载节点和低载节点的比例，达到均衡高低载节点的效果；同时基于抢占调度策略模拟计算待重调度POD的重调度结果，尽可能地保证了被驱逐的POD可以通过抢占调度被重新部署，而不是单纯驱逐所有满足条件的POD，而且通过扩展的调度策略优先调度低载节点，进一步细化了资源重调度以均衡节点间负载的策略。

实施例四

图5是本发明实施例四提供的一种资源重调度装置的模块结构示意图，本实施例可适用于Kubernetes集群中对Pod进行重调度的情况，该装置可以采用软件和/或硬件的方式实现，并一般可集成在计算机设备中。

如图5所示，本实施例提供的资源重调度装置具体包括：实际负载获取模块410、重调度结果模拟模块420和POD驱逐模块430。其中，

实际负载获取模块410，用于定时获取集群内各节点的实际负载数据；

重调度结果模拟模块420，用于如果根据所述各节点的实际负载数据确定存在高载节点和低载节点，则确定所述高载节点上的待重调度POD，并模拟计算所述待重调度POD的重调度结果；

POD驱逐模块430，用于如果所述重调度结果指示允许将所述待重调度POD迁移至所述低载节点上，则驱逐所述待重调度POD，以实现所述待重调度POD在所述集群中被重新部署。

在本发明实施例提供的技术方案中，定时获取集群内各节点的实际负载数据，并在根据实际负载数据确定集群中存在高载节点和低载节点时，确定所述高载节点上的待重调度POD进行驱逐，以此均衡了集群内各节点的实际负载，能够避免高载节点出现过载的问题；同时，在对所述高载节点上的待重调度POD进行驱逐之前，模拟计算了待重调度POD的重调度结果，只有在重调度结果指示在待重调度POD被驱逐后允许将其迁移至低载节点上时，才会对待重调度POD进行驱逐，由此尽量保证了针对被驱逐的Pod的重调度成功率，避免了待重调度POD在被驱逐后又被重新调度回原高载节点，甚至在调度队列中无法调度的问题。

可选的，重调度结果模拟模块420，具体用于在根据所述集群的当前资源分布确定不存在满足所述待重调度POD重调度条件的低载节点的情况下，基于抢占调度策略模拟计算所述集群在所述低载节点上与所述待重调度POD对应的待抢占POD被驱逐之后的资源分布结果；根据所述资源分布结果，判断是否存在满足所述待重调度POD重调度条件的低载节点。

可选的，重调度结果模拟模块420，具体用于获取所述高载节点上的可剥离POD；根据所述可剥离POD的优先级和/或容器实际负载确定高载节点上的待重调度POD。

进一步的，重调度结果模拟模块420，具体用于将所述可剥离POD中优先级最低的POD作为所述待重调度POD；或者，

将所述可剥离POD中容器实际负载满足节点负载降级条件的POD作为所述待重调度POD；或者，

将所述可剥离POD中优先级最低且容器实际负载满足节点负载降级条件的POD作为所述待重调度POD。

在上述技术方案的基础上，上述资源重调度装置还包括：重调度模块，用于在驱逐所述待重调度POD之后，通过kube-scheduler组件基于预设的低载节点优选策略实现对所述待重调度POD的重新部署。

可选的，重调度结果模拟模块420，具体用于确定所述高载节点上的一个待重调度POD。

可选的，上述资源重调度装置还包括：过载节点POD驱逐模块，用于如果根据所述各节点的实际负载数据确定存在过载节点，则确定所述过载节点上的待重调度POD，并驱逐所述待重调度POD。

本发明实施例所提供的资源重调度装置可执行本发明任意实施例所提供的资源重调度方法，具备执行方法相应的功能模块和有益效果。

实施例五

图6是本发明实施例五提供的一种计算机设备的结构示意图，如图6所示，该计算机设备包括处理器50、存储器51、输入装置52和输出装置53；计算机设备中处理器50的数量可以是一个或多个，图6中以一个处理器50为例；计算机设备中的处理器50、存储器51、输入装置52和输出装置53可以通过总线或其他方式连接，图6中以通过总线连接为例。

存储器51作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的资源重调度方法对应的程序指令/模块(例如，图5中资源重调度装置中的实际负载获取模块410、重调度结果模拟模块420和POD驱逐模块430)。处理器50通过运行存储在存储器51中的软件程序、指令以及模块，从而执行计算机设备的各种功能应用以及数据处理，即实现上述的资源重调度方法。

存储器51可主要包括存储程序区和存储数据表区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据表区可存储根据计算机设备的使用所创建的数据等。此外，存储器51可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器51可进一步包括相对于处理器50远程设置的存储器，这些远程存储器可以通过网络连接至计算机设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置52可用于接收输入的数字或字符信息，以及产生与计算机设备的用户设置以及功能控制有关的键信号输入。输出装置53可包括显示屏等显示设备。

实施例六

本发明实施例六还提供一种存储有计算机程序的计算机可读存储介质，计算机程序在由计算机处理器执行时用于执行一种资源重调度方法，该方法包括：

定时获取集群内各节点的实际负载数据；

如果根据所述各节点的实际负载数据确定存在高载节点和低载节点，则确定所述高载节点上的待重调度POD，并模拟计算所述待重调度POD的重调度结果；

如果所述重调度结果指示允许将所述待重调度POD迁移至所述低载节点上，则驱逐所述待重调度POD，以实现所述待重调度POD在所述集群中被重新部署。

当然，本发明实施例所提供的存储有计算机程序的计算机可读存储介质，其计算机程序不限于如上的方法操作，还可以执行本发明任意实施例所提供的资源重调度方法中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(RandomAccess Memory，RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例的方法。

值得注意的是，上述资源重调度装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。