CN113672347A - 一种容器组调度方法及装置 - Google Patents

Abstract

本申请提供一种Pod调度方法及装置。该方法中，按照用户业务对Pod进行划分，属于同一业务的Pod划入同一业务组，针对不同业务组确定业务优先级，然后，基于不同业务优先级确定各业务组调度顺序，且在集群可用资源满足业务组资源需求的情况下进行调度，因此，可保证被调度业务组对应业务正常运行，即，保证业务可用性。

Description

一种容器组调度方法及装置

技术领域

本申请涉及云计算技术领域，尤其涉及一种Pod调度方法及装置。

背景技术

Kurbernetes(也称为k8s)是Google开源的容器集群管理系统，它是一个完备的分布式支撑平台，具有完备的集群管理能力。同时，Kurbernetes系统也是一个全新的基于容器技术的分布式架构领先方案，为容器化的应用提供部署运行、资源调度、服务发现、动态伸缩等一系列完整功能。

Kurbernetes通常以集群的形式部署。Kurbernetes集群包括多个节点，该多个节点被划分为管理节点(Master)和工作节点(Node)。其中，工作节点用于承载被分配(调度)的容器组(Pod)的运行。

Pod为Kurbernetes集群的最小调度单位，一个Pod可包含一个或多个相关容器，属于同一Pod的多个容器共享网络、存储等资源。目前，Pod调度主要按照Pod列表中待调度Pod的先后顺序依次调度，即，逐一为每一个待调度Pod分配用于承载该Pod的工作节点。但在实际使用中发现，该调度方式可能导致部分业务不可用。

发明内容

有鉴于此，本申请提出一种Pod调度方法及装置，用以保证用户业务可用性。

为实现上述申请目的，本申请提供了如下技术方案：

第一方面，本申请提供一种Pod调度方法，应用于Kurbernetes集群，所述方法包括：

确定所述集群中待调度的N个业务组的业务优先级排序，所述业务组包括用于实现该业务组对应业务的至少一个Pod；

按照业务优先级从高到低的顺序，从所述N个业务组中，选择M个目标业务组，所述M个目标业务组的资源需求总量不大于所述集群的可用资源量；

针对每一个目标业务组，将该目标业务组中各Pod调度至所述集群包括的工作节点。

可选的，所述确定所述集群中待调度的N个业务组的业务优先级排序，包括：

针对所述N个业务组中的每一个业务组，统计该业务组在预设统计时间段内的访问量；

根据各业务组的访问量，确定所述N个业务组的业务优先级排序，其中，访问量越高对应业务优先级越高。

可选的，所述根据各业务组的访问量，确定所述N个业务组的业务优先级排序之后，所述方法还包括：

如果所述N个业务组中存在业务组间访问量差值小于预设差值阈值的至少两个第一业务组，分别统计各第一业务组的资源占用率；

根据所述各第一业务组的资源占用率，更新所述N个业务组对应业务优先级排序中所述至少两个第一业务组之间的业务优先级顺序，其中，资源占用率越小对应业务优先级越高。

可选的，所述将该目标业务组中各Pod调度至所述集群包括的工作节点，包括：

确定该目标业务组中各Pod之间的调用关系；

针对该目标业务组中每一个Pod，确定该Pod在所述调用关系中所处调用层级；

按照调用层级从深到浅的顺序，依次将各Pod调度至所述集群包括的工作节点。

可选的，所述针对每一个目标业务组，将该目标业务组中各Pod调度至所述集群包括的工作节点之后，所述方法还包括：

如果所述N个业务组中存在未调度的第二业务组，且所述M个目标业务组中存在预设时间段内访问量小于预设访问量阈值的空闲目标业务组，且所述第二业务组的资源需求量不大于所述空闲目标业务组的资源需求量与所述集群剩余资源量的和，删除所述集群中所述空闲目标业务组对应各Pod；

将所述第二业务组包括的各Pod调度至所述集群包括的工作节点。

可选的，所述针对每一个目标业务组，将该目标业务组中各Pod调度至所述集群包括的工作节点之后，所述方法还包括：

如果检测到新增工作节点，且所述M个目标业务组中存在预设时间段内访问量小于预设访问量阈值的空闲Pod，将所述空闲Pod迁移至所述新增工作节点。

第二方面，本申请提供一种Pod调度装置，应用于Kurbernetes集群，所述装置包括：

确定单元，用于确定所述集群中待调度的N个业务组的业务优先级排序，所述业务组包括用于实现该业务组对应业务的至少一个Pod；

选择单元，用于按照业务优先级从高到低的顺序，从所述N个业务组中，选择M个目标业务组，所述M个目标业务组的资源需求总量不大于所述集群的可用资源量；

调度单元，用于针对每一个目标业务组，将该目标业务组中各Pod调度至所述集群包括的工作节点。

可选的，所述确定单元确定所述集群中待调度的N个业务组的业务优先级排序，包括：

针对所述N个业务组中的每一个业务组，统计该业务组在预设统计时间段内的访问量；

根据各业务组的访问量，确定所述N个业务组的业务优先级排序，其中，访问量越高对应业务优先级越高。

可选的，所述装置还包括：

统计单元，用于在所述确定单元根据各业务组的访问量，确定所述N个业务组的业务优先级排序之后，如果所述N个业务组中存在业务组间访问量差值小于预设差值阈值的至少两个第一业务组，分别统计各第一业务组的资源占用率；

更新单元，用于根据所述各第一业务组的资源占用率，更新所述N个业务组对应业务优先级排序中所述至少两个第一业务组之间的业务优先级顺序，其中，资源占用率越小对应业务优先级越高。

可选的，所述调度单元将该目标业务组中各Pod调度至所述集群包括的工作节点，包括：

确定该目标业务组中各Pod之间的调用关系；

针对该目标业务组中每一个Pod，确定该Pod在所述调用关系中所处调用层级；

按照调用层级从深到浅的顺序，依次将各Pod调度至所述集群包括的工作节点。

可选的，所述装置还包括：

删除单元，用于在所述调度单元针对每一个目标业务组，将该目标业务组中各Pod调度至所述集群包括的工作节点之后，如果所述N个业务组中存在未调度的第二业务组，且所述M个目标业务组中存在预设时间段内访问量小于预设访问量阈值的空闲目标业务组，且所述第二业务组的资源需求量不大于所述空闲目标业务组的资源需求量与所述集群剩余资源量的和，删除所述集群中所述空闲目标业务组对应各Pod；

所述调度单元，还用于将所述第二业务组包括的各Pod调度至所述集群包括的工作节点。

可选的，所述装置还包括：

迁移单元，用于在所述调度单元针对每一个目标业务组，将该目标业务组中各Pod调度至所述集群包括的工作节点之后，如果检测到新增工作节点，且所述M个目标业务组中存在预设时间段内访问量小于预设访问量阈值的空闲Pod，将所述空闲Pod迁移至所述新增工作节点。

由以上描述可以看出，本申请实施例中，按照用户业务对Pod进行划分，属于同一业务的Pod划入同一业务组，针对不同业务组确定业务优先级，然后，基于不同业务优先级确定各业务组调度顺序，且在集群可用资源满足业务组资源需求的情况下进行调度，因此，可保证被调度业务组对应业务正常运行，即，保证业务可用性。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例示出的一种Pod调度方法流程图；

图2是本申请实施例示出的一种步骤101的实现流程；

图3是本申请实施例示出的一种业务优先级排序更新流程；

图4是本申请实施例示出的一种步骤103的实现流程；

图5是本申请实施例示出的一种业务组内各Pod调用关系示例；

图6是本申请实施例示出的一种Pod调度流程；

图7是本申请实施例示出的一种Pod调度装置的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。

在本申请实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请实施例。在本申请实施例中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请实施例范围的情况下，协商信息也可以被称为第二信息，类似地，第二信息也可以被称为协商信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本申请提供一种Pod调度方法，该方法基于业务组对Pod进行调度，可有效保证被调度业务组对应业务的可用性。

为了使本申请的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本申请执行详细描述：

参见图1，为本申请实施例示出的一种Pod调度方法流程图，该流程应用于Kurbernetes集群。该Kurbernetes集群包括至少一个工作节点(Node)，每一个工作节点用于承载被调度至本节点的Pod的运行。

如图1所示，该流程可包括以下步骤：

步骤101，确定集群中待调度的N个业务组的业务优先级排序。

本申请实施例中，按照用户业务划分业务组，每一个业务组包括用于实现该业务组对应业务的至少一个Pod。

本步骤针对当前待调度的N个业务组确定各业务组的业务优先级排序，具体确定业务优先级排序的过程在下文中描述，这里暂不赘述。

步骤102，按照业务优先级从高到低的顺序，从N个业务组中，选择M个目标业务组。

即，选择业务优先级较高的前M个业务组。这里，将选择出的前M个业务组均称为目标业务组。可以理解的是，之所以称为目标业务组，只是为便于区分而进行的命名，并非用于限定。

该选择出的M个目标业务组的资源需求总量不大于集群的可用资源量，以保证该M个目标业务组被调度后均可正常运行。

步骤103，针对每一个目标业务组，将该目标业务组中各Pod调度至集群包括的工作节点。

集群以Pod为基本调度单位，将目标业务组包括的各Pod逐一调度至集群的各工作节点，最终完成对每一个目标业务组的调度。

在具体调度时，可根据各工作节点的负载情况，将各Pod均衡调度至各工作节点。

至此，完成图1所示流程。

通过图1所示流程可以看出，本申请实施例中，按照用户业务对Pod进行划分，将属于同一业务的Pod划入同一业务组，然后，按照不同业务组的业务优先级确定各业务组调度顺序，且在集群可用资源满足业务组资源需求的情况下进行调度，从而保证被调度业务组对应业务的正常运行，即，保证业务可用性。

下面对步骤101中确定N个业务组的业务优先级排序的过程进行描述。参见图2，本申请实施例示出的一种步骤101的实现流程。

如图2所示，该流程可包括以下步骤：

步骤201，针对N个业务组中的每一个业务组，统计该业务组在预设统计时间段内的访问量。

这里，预设统计时间段通常为业务访问较集中的时间段。比如，针对业务1的访问主要集中在8:00到18:00，则可设置业务1对应业务组的统计时间段为8:00到18:00；针对业务2的访问主要集中在20:00到24:00，则可设置业务2对应业务组的统计时间段为20:00到24:00。

本步骤通过对各业务组在对应访问较集中时间段进行统计，来确定各业务组的访问情况。

步骤202，根据各业务组的访问量，确定N个业务组的业务优先级排序，其中，访问量越高对应业务优先级越高。

这里，以4个业务组为例，该4个业务组分别为Group1～Group4。如果通过步骤201确定Group1的访问量为50万次、Group2的访问量为10万次、Group3的访问量为30.05万次、Group4的访问量为30万次，则该4个业务组的业务优先级排序(从高到低)为Group1→Group3→Group4→Group2。

至此，完成图2所示流程。

通过图2所示流程可以看出，本申请实施例基于业务访问量确定各业务组的业务优先级排序，从而保证业务访问量大的业务组优先调度(尤其在集群资源不足时)，因此，可使集群资源利用更加合理。

作为一个实施例，在执行步骤202之后，还可执行图3所示业务优先级排序更新流程。如图3所示，该流程可包括以下步骤：

步骤301，如果N个业务组中存在业务组间访问量差值小于预设差值阈值的至少两个第一业务组，分别统计各第一业务组的资源占用率。

这里，将N个业务组中访问量差值小于预设差值阈值的至少两个业务组均称为第一业务组。可以理解的是，之所以称为第一业务组，只是为了便于区分而进行的命名，并非用于限定。

该至少两个第一业务组间的访问量差值小于预设差值阈值，说明该至少两个第一业务组的访问量非常接近，此时，可分别统计每一个第一业务组的资源占用率。

比如，预设差值阈值为1千次，则根据前述Group1～Group4的访问量可知，Group3与Group4之间的访问量差值(30.05-30＝0.05万次)小于预设差值阈值(1千次)，此时，可分别统计Group3、Group4的资源占用率。

这里，资源占用率主要包括CPU占用率和内存占用率。其中，CPU占用率可为业务组中各Pod的CPU资源需求总量占集群可用CPU资源的比率；内存占用率可为业务组中各Pod的内存资源需求总量占集群可用内存资源的比率。

仍以Group3、Group4为例，参见表1，为本申请实施例示出的Group3包括的各Pod的资源需求示例。

表1参见表2，为本申请实施例示出的Group4包括的各Pod的资源需求示例。

表2

当前集群可用CPU资源为20m、内存资源为40Gi，则Group3的CPU占用率为(0.5+1+1+2+0.5+0.5)/20＝27.5％，内存占用率为(512Mi+1Gi+512Mi+2Gi+512Mi+512Mi)/40Gi＝12.5％；Group4的CPU占用率为(1+1+0.5+2+0.5+1)/20＝30％，内存占用率为(1Gi+1Gi+512Mi+1Gi+512Mi+512Mi)/40Gi＝11.25％。

步骤302，根据各第一业务组的资源占用率，更新通过步骤202已确定的业务优先级排序中至少两个第一业务组之间的业务优先级顺序，其中，资源占用率越小对应业务优先级越高。

作为一个示例，可综合考虑各第一业务组的CPU占用率和内存占用率，确定该至少两个第一业务组之间的业务优先级顺序。

仍以Group3、Group4为例，Group3的CPU占用率为27.5％、内存占用率为12.5％；Group4的CPU占用率为30％、内存占用率为11.25％，以上所有占用率中最小占用率为11.25％，该最小占用率对应Group为Group4，因此，可确定Group4的业务优先级高于Group3的业务优先级。基于此，更新前述步骤202已确定的业务优先级排序Group1→Group3→Group4→Group2为Group1→Group4→Group3→Group2。

至此，完成图3所示流程。

通过图3所示流程可以看出，本申请实施例中，结合各业务组的业务访问量以及资源占用率，来确定各业务组的业务优先级排序，基于该业务优先级排序进行资源调度，可使集群资源利用更加合理。

下面对步骤103中将目标业务组中各Pod调度至工作节点的过程进行描述。参见图4，为本申请实施例示出的一种步骤103的实现流程。

如图4所示，该流程可包括以下步骤：

步骤401，确定目标业务组中各Pod之间的调用关系。

这里，需要说明的是，如果在本次调度之前，目标业务组曾正常运行过，则集群会记录该目标业务组中各Pod的调用关系。参见图5，为本申请实施例示出的一种业务组内各Pod的调用关系示例。

如图5所示，该图以Group4为例，示出Group4内Pod41～Pod46的调用关系。其中，上层Pod的运行依赖于下层Pod的运行。比如，图5中，Pod44的运行依赖于Pod45和Pod46的运行；再比如，Pod42的运行依赖于Pod44的运行，以此类推。

步骤402，针对目标业务组中每一个Pod，确定该Pod在调用关系中所处调用层级。

仍以图5所示Group4的调用关系为例，从业务访问入口开始遍历该调用关系，可得到表3所示Pod与调用层级的对应关系示例。

表3

步骤403，按照调用层级从深到浅的顺序，依次将各Pod调度至工作节点。

仍以图5所示Group4为例，该Group4包括4个调用层级，如表3所示。其中，最深调用层级为第四层，最浅调用层级为第一层，则按照调用层级从深到浅依次调度：位于第四层的Pod45、Pod46→位于第三层的Pod44→位于第二层的Pod42、Pod43→位于第一层的Pod41，从而保证被依赖的Pod优先调度(优先启动)。

至此，完成图4所示流程。

通过图4所示流程可以看出，本申请实施例中，按照业务组中各Pod的调用关系(依赖关系)，优先调度被依赖Pod，可有效避免因随机调度导致上层Pod多次重启影响业务启动效率，换言之，本申请实施例按照依赖关系从下到上(从深到浅)调度业务组的各Pod，可有效提升业务启动效率。

作为一个实施例，在执行步骤103之后，还可执行图6所示Pod调度流程。

如图6所示，该流程可包括以下步骤：

步骤601，如果N个业务组中存在未调度的第二业务组，且M个目标业务组中存在预设时间段内访问量小于预设访问量阈值的空闲目标业务组，且第二业务组的资源需求量不大于空闲目标业务组的资源需求量与集群剩余资源量的和，则删除集群中空闲目标业务组对应各Pod。

这里，需要说明的是，第二业务组可为N个业务组中任一未调度的业务组。较优地，该第二业务组可为未调度业务组中业务优先级最高的业务组。可以理解的是，之所以称为第二业务组，只是为便于区分而进行的命名，并非用于限定。

此外，本申请实施例将预设时间段内访问量小于预设访问量阈值的目标业务组称为空闲目标业务组。可以理解的是，之所以称为空闲目标业务组，只是为便于区分而进行的命名，并非用于限定。

该空闲目标业务组为M个目标业务组中访问量极小(小于预设访问量阈值)的目标业务组。如果该空闲目标业务组持续占用集群资源，会导致集群资源浪费。

为此，本申请实施例考虑释放空闲目标业务组所占用资源，提供给新的业务组使用。具体地，集群判断未调度的第二业务组的资源需求量是否大于空闲目标业务组的资源需求量与当前集群剩余资源量的和，如果不大于，说明空闲目标业务组对应资源释放后集群的资源量可以满足第二业务组的资源需求，因此，本步骤删除集群中空闲目标业务组对应各Pod，即，释放空闲目标业务组所占用资源，然后转步骤602。

步骤602，将第二业务组包括的各Pod调度至集群包括的工作节点。

至此，完成图6所示流程。

通过图6所示流程可以看出，本申请实施例通过将较空闲业务组所占用资源分配给未调度的新的业务组，使得集群资源利用率更高。

作为一个实施例，在执行步骤103之后，集群可监测是否存在新增工作节点，比如，集群扩容导致工作节点增加。当监测到新增工作节点时，确定已调度的M个目标业务组中是否存在空闲Pod，其中，该空闲Pod为预设时间段内访问量小于预设访问量阈值的Pod。

如果存在空闲Pod，则将空闲Pod迁移至新增工作节点，以尽量均衡集群中各工作节点的负担，同时，由于仅针对空闲Pod进行迁移，因此，可有效降低对已运行业务的影响。

以上对本申请实施例提供的方法进行了描述，下面对本申请实施例提供的Pod调度装置进行描述：

参见图7，为本申请实施例提供的Pod调度装置的结构示意图，该装置应用于Kurbernetes集群，该装置包括：确定单元701、选择单元702以及调度单元703，其中：

确定单元701，用于确定所述集群中待调度的N个业务组的业务优先级排序，所述业务组包括用于实现该业务组对应业务的至少一个Pod；

选择单元702，用于按照业务优先级从高到低的顺序，从所述N个业务组中，选择M个目标业务组，所述M个目标业务组的资源需求总量不大于所述集群的可用资源量；

调度单元703，用于针对每一个目标业务组，将该目标业务组中各Pod调度至所述集群包括的工作节点。

作为一个实施例，所述确定单元701确定所述集群中待调度的N个业务组的业务优先级排序，包括：

针对所述N个业务组中的每一个业务组，统计该业务组在预设统计时间段内的访问量；

根据各业务组的访问量，确定所述N个业务组的业务优先级排序，其中，访问量越高对应业务优先级越高。

作为一个实施例，所述装置还包括：

统计单元，用于在所述确定单元701根据各业务组的访问量，确定所述N个业务组的业务优先级排序之后，如果所述N个业务组中存在业务组间访问量差值小于预设差值阈值的至少两个第一业务组，分别统计各第一业务组的资源占用率；

更新单元，用于根据所述各第一业务组的资源占用率，更新所述N个业务组对应业务优先级排序中所述至少两个第一业务组之间的业务优先级顺序，其中，资源占用率越小对应业务优先级越高。

作为一个实施例，所述调度单元703将该目标业务组中各Pod调度至所述集群包括的工作节点，包括：

确定该目标业务组中各Pod之间的调用关系；

针对该目标业务组中每一个Pod，确定该Pod在所述调用关系中所处调用层级；

按照调用层级从深到浅的顺序，依次将各Pod调度至所述集群包括的工作节点。

作为一个实施例，所述装置还包括：

删除单元，用于在所述调度单元703针对每一个目标业务组，将该目标业务组中各Pod调度至所述集群包括的工作节点之后，如果所述N个业务组中存在未调度的第二业务组，且所述M个目标业务组中存在预设时间段内访问量小于预设访问量阈值的空闲目标业务组，且所述第二业务组的资源需求量不大于所述空闲目标业务组的资源需求量与所述集群剩余资源量的和，删除所述集群中所述空闲目标业务组对应各Pod；

所述调度单元703，还用于将所述第二业务组包括的各Pod调度至所述集群包括的工作节点。

作为一个实施例，所述装置还包括：

迁移单元，用于在所述调度单元703针对每一个目标业务组，将该目标业务组中各Pod调度至所述集群包括的工作节点之后，如果检测到新增工作节点，且所述M个目标业务组中存在预设时间段内访问量小于预设访问量阈值的空闲Pod，将所述空闲Pod迁移至所述新增工作节点。

至此，完成图7所示装置的描述。本申请实施例中，按照用户业务对Pod进行划分，将属于同一业务的Pod划入同一业务组，然后，按照不同业务组的业务优先级确定各业务组调度顺序，且在集群可用资源满足业务组资源需求的情况下进行调度，从而保证被调度业务组对应业务的正常运行，即，保证业务可用性。

以上所述仅为本申请实施例的较佳实施例而已，并不用以限制本申请，凡在本申请实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种容器组Pod调度方法，其特征在于，应用于Kurbernetes集群，所述方法包括：

确定所述集群中待调度的N个业务组的业务优先级排序，所述业务组包括用于实现该业务组对应业务的至少一个Pod；

按照业务优先级从高到低的顺序，从所述N个业务组中，选择M个目标业务组，所述M个目标业务组的资源需求总量不大于所述集群的可用资源量；

针对每一个目标业务组，将该目标业务组中各Pod调度至所述集群包括的工作节点。

2.如权利要求1所述的方法，其特征在于，所述确定所述集群中待调度的N个业务组的业务优先级排序，包括：

针对所述N个业务组中的每一个业务组，统计该业务组在预设统计时间段内的访问量；

根据各业务组的访问量，确定所述N个业务组的业务优先级排序，其中，访问量越高对应业务优先级越高。

3.如权利要求2所述的方法，其特征在于，所述根据各业务组的访问量，确定所述N个业务组的业务优先级排序之后，所述方法还包括：

如果所述N个业务组中存在业务组间访问量差值小于预设差值阈值的至少两个第一业务组，分别统计各第一业务组的资源占用率；

根据所述各第一业务组的资源占用率，更新所述N个业务组对应业务优先级排序中所述至少两个第一业务组之间的业务优先级顺序，其中，资源占用率越小对应业务优先级越高。

4.如权利要求1所述的方法，其特征在于，所述将该目标业务组中各Pod调度至所述集群包括的工作节点，包括：

确定该目标业务组中各Pod之间的调用关系；

针对该目标业务组中每一个Pod，确定该Pod在所述调用关系中所处调用层级；

按照调用层级从深到浅的顺序，依次将各Pod调度至所述集群包括的工作节点。

5.如权利要求1所述的方法，其特征在于，所述针对每一个目标业务组，将该目标业务组中各Pod调度至所述集群包括的工作节点之后，所述方法还包括：

如果所述N个业务组中存在未调度的第二业务组，且所述M个目标业务组中存在预设时间段内访问量小于预设访问量阈值的空闲目标业务组，且所述第二业务组的资源需求量不大于所述空闲目标业务组的资源需求量与所述集群剩余资源量的和，删除所述集群中所述空闲目标业务组对应各Pod；

将所述第二业务组包括的各Pod调度至所述集群包括的工作节点。

6.如权利要求1所述的方法，其特征在于，所述针对每一个目标业务组，将该目标业务组中各Pod调度至所述集群包括的工作节点之后，所述方法还包括：

如果检测到新增工作节点，且所述M个目标业务组中存在预设时间段内访问量小于预设访问量阈值的空闲Pod，将所述空闲Pod迁移至所述新增工作节点。

7.一种容器组Pod调度装置，其特征在于，应用于Kurbernetes集群，所述装置包括：

确定单元，用于确定所述集群中待调度的N个业务组的业务优先级排序，所述业务组包括用于实现该业务组对应业务的至少一个Pod；

选择单元，用于按照业务优先级从高到低的顺序，从所述N个业务组中，选择M个目标业务组，所述M个目标业务组的资源需求总量不大于所述集群的可用资源量；

调度单元，用于针对每一个目标业务组，将该目标业务组中各Pod调度至所述集群包括的工作节点。

8.如权利要求7所述的装置，其特征在于，所述确定单元确定所述集群中待调度的N个业务组的业务优先级排序，包括：

针对所述N个业务组中的每一个业务组，统计该业务组在预设统计时间段内的访问量；

根据各业务组的访问量，确定所述N个业务组的业务优先级排序，其中，访问量越高对应业务优先级越高。

9.如权利要求8所述的装置，其特征在于，所述装置还包括：

统计单元，用于在所述确定单元根据各业务组的访问量，确定所述N个业务组的业务优先级排序之后，如果所述N个业务组中存在业务组间访问量差值小于预设差值阈值的至少两个第一业务组，分别统计各第一业务组的资源占用率；

更新单元，用于根据所述各第一业务组的资源占用率，更新所述N个业务组对应业务优先级排序中所述至少两个第一业务组之间的业务优先级顺序，其中，资源占用率越小对应业务优先级越高。

10.如权利要求7所述的装置，其特征在于，所述调度单元将该目标业务组中各Pod调度至所述集群包括的工作节点，包括：

确定该目标业务组中各Pod之间的调用关系；

针对该目标业务组中每一个Pod，确定该Pod在所述调用关系中所处调用层级；

按照调用层级从深到浅的顺序，依次将各Pod调度至所述集群包括的工作节点。

Images