容器的调度方法、装置和计算机可读存储介质与流程

本公开涉及计算机技术领域，特别涉及一种容器的调度方法、装置和计算机可读存储介质。

背景技术：

容器云是当前云计算平台的一个重要类型，主要应用于私有云场景，用于满足客户的私有化和定制化的需求。客户在构建容器云时，会将容器云集群部署在自建的机房内，往往会部署数百台物理服务器来承载容器云上的业务。

例如，可以配置多个节点(node)作为容器运行的主机。节点可以是物理机，也可以是依托于物理机的虚拟机。因此，这就需要生成合适的调度策略，用于将容器调度到相应的节点上运行。

在相关技术中，主要根据资源如何在各节点上均衡的分布生成调度策略。

技术实现要素：

本公开的发明人发现上述相关技术中存在如下问题：没有从集群管理和维护的角度来生成调度策略，造成资源使用量和资源提供量不匹配，导致系统资源的浪费。

鉴于此，本公开提出了一种容器的调度技术方案，能够降低系统资源的浪费。

根据本公开的一些实施例，提供了一种容器的调度方法，包括：根据已运行容器集合副本的资源使用量，确定待调度容器集合副本的预计资源使用量，已运行容器集合副本与待调度容器集合副本的类型相同；根据预计资源使用量和各候选节点支持的资源提供量，确定与已运行容器集合副本匹配的候选节点；将已运行容器集合副本调度到匹配的候选节点上运行。

在一些实施例中，确定与已运行容器集合副本匹配的候选节点包括：根据预计资源使用量中各类型资源的预计使用量，与资源提供量中各类型资源的提供量是否匹配，确定与已运行容器集合副本匹配的候选节点。

在一些实施例中，确定与已运行容器集合副本匹配的候选节点包括：判断预计资源使用量中各类型资源的预计使用量是否大于相应的使用量阈值；将大于相应的使用量阈值的类型资源，确定为需求资源；判断资源提供量中各类型资源在各候选节点中的当前使用率是否小于相应的使用率阈值；将小于相应的使用率阈值的类型资源，确定为各候选节点的可提供资源；根据需求资源和可提供资源的匹配，确定与已运行容器集合副本匹配的候选节点。

在一些实施例中，将已运行容器集合副本调度到匹配的候选节点上运行包括：根据预计资源使用量和匹配的候选节点的资源提供量，确定匹配的候选节点需要唤醒的物理机的数量，物理机的数量是能够满足预计资源使用量的最少数量。

在一些实施例中，该方法还包括：获取已运行容器集合副本的资源使用量的历史变化情况；根据历史变化情况，判断待调度容器集合副本当前处于使用量高峰时段还是低谷时段；根据判断结果，确定是否增加待调度容器集合副本的数量。

在一些实施例中，获取已运行容器集合副本的资源使用量的历史变化情况包括：根据指定时间段内各时刻已运行容器集合副本的资源使用量，计算各类型资源在指定时间段内的平均使用量；根据平均使用量，判断在指定时间段内各类型资源的使用量高峰时段和低谷时段作为历史变化情况。

在一些实施例中，该方法还包括：根据历史变化情况，估计待调度容器集合副本在目标时刻的资源使用量；在当前唤醒的物理机不能满足目标时刻的资源使用量的情况下，在目标时刻到来前，唤醒相应数量的物理机提供资源。

在一些实施例中，根据判断结果，确定是否增加待调度容器集合副本的数量包括：在处于高峰时段且单个待调度容器集合副本的资源负载超过负载阈值的情况下，增加待调度容器集合副本的数量。

在一些实施例中，根据判断结果，确定是否增加待调度容器集合副本的数量包括：在处于低谷时段的情况下，减少待调度容器集合副本的数量，并控制清空的物理机进入休眠状态。

在一些实施例中，该方法还包括：根据匹配的候选节点的相应物理机上运行的容器集合副本数量，控制相应物理机处于高性能模式或非高性能模式。

在一些实施例中，控制相应物理机处于高性能模式或非高性能模式包括：在相应的物理机上没有运行容器集合副本的情况下，控制相应的物理机处于休眠模式；在相应的物理机上运行的容器集合副本数量小于副本阈值的情况下，控制相应的物理机处于低性能模式。

在一些实施例中，各候选节点根据待调度容器集合副本的个数、高可用需求、亲和性需求和排斥性需求中的至少一项确定。

根据本公开的另一些实施例，提供一种容器的调度装置，包括：使用量确定单元，用于根据已运行容器集合副本的资源使用量，确定待调度容器集合副本的预计资源使用量，已运行容器集合副本与待调度容器集合副本的类型相同；节点匹配单元，用于根据预计资源使用量和各候选节点支持的资源提供量，确定与已运行容器集合副本匹配的候选节点；调度单元，用于根将已运行容器集合副本调度到匹配的候选节点上运行。

在一些实施例中，节点匹配单元根据预计资源使用量中各类型资源的预计使用量，与资源提供量中各类型资源的提供量是否匹配，确定与已运行容器集合副本匹配的候选节点。

在一些实施例中，节点匹配单元判断预计资源使用量中各类型资源的预计使用量是否大于相应的使用量阈值；将大于相应的使用量阈值的类型资源，确定为需求资源；判断资源提供量中各类型资源在各候选节点中的当前使用率是否小于相应的使用率阈值；将小于相应的使用率阈值的类型资源，确定为各候选节点的可提供资源；根据需求资源和可提供资源的匹配，确定与已运行容器集合副本匹配的候选节点。

在一些实施例中，调度单元根据预计资源使用量和匹配的候选节点的资源提供量，确定匹配的候选节点需要唤醒的物理机的数量，物理机的数量是能够满足预计资源使用量的最少数量。

在一些实施例中，该装置还包括判断单元，用于根据获取的已运行容器集合副本的资源使用量的历史变化情况，判断待调度容器集合副本当前处于使用量高峰时段还是低谷时段，以便根据判断结果，确定是否增加待调度容器集合副本的数量。

在一些实施例中，判断单元根据指定时间段内各时刻已运行容器集合副本的资源使用量，计算各类型资源在指定时间段内的平均使用量；根据平均使用量，判断在指定时间段内各类型资源的使用量高峰时段和低谷时段作为历史变化情况。

在一些实施例中，该装置还包括控制单元根据历史变化情况，估计待调度容器集合副本在目标时刻的资源使用量；在当前唤醒的物理机不能满足目标时刻的资源使用量的情况下，在目标时刻到来前，唤醒相应数量的物理机提供资源。

在一些实施例中，控制单元在处于高峰时段且单个待调度容器集合副本的资源负载超过负载阈值的情况下，增加待调度容器集合副本的数量。

在一些实施例中，控制单元在处于低谷时段的情况下，减少待调度容器集合副本的数量，并控制清空的物理机进入休眠状态。

在一些实施例中，控制单元用于根据匹配的候选节点的相应物理机上运行的容器集合副本数量，控制相应物理机处于高性能模式或非高性能模式。

在一些实施例中，控制单元控制相应物理机处于高性能模式或非高性能模式包括：在相应的物理机上没有运行容器集合副本的情况下，控制相应的物理机处于休眠模式；在相应的物理机上运行的容器集合副本数量小于副本阈值的情况下，控制相应的物理机处于低性能模式。

在一些实施例中，各候选节点根据待调度容器集合副本的个数、高可用需求、亲和性需求和排斥性需求中的至少一项确定。

根据本公开的又一些实施例，提供一种容器的调度装置，包括：存储器；和耦接至存储器的处理器，处理器被配置为基于存储在存储器装置中的指令，执行上述任一个实施例中的容器的调度方法。

根据本公开的再一些实施例，提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述任一个实施例中的容器的调度方法。

在上述实施例中，根据与待调度容器集合副本同类型的容器集合副本的资源使用量先验数据，估计待调度容器集合副本的资源使用量；在此基础上，结合各节点能够提供的资源数量生成调度策略。这样，能够使得系统的资源使用量和资源提供量相匹配，降低系统资源的浪费。

附图说明

构成说明书的一部分的附图描述了本公开的实施例，并且连同说明书一起用于解释本公开的原理。

参照附图，根据下面的详细描述，可以更加清楚地理解本公开：

图1示出本公开的容器的调度方法的一些实施例的流程图；

图2示出本公开的容器的调度方法的另一些实施例的流程图；

图3示出本公开的容器的调度装置的一些实施例的示意图；

图4a示出本公开的节点资源分布情况的一些实施例的示意图；

图4b示出本公开的pod副本资源使用情况的一些实施例的示意图；

图4c示出本公开的两个pod副本资源使用情况的一些实施例的示意图；

图4d示出本公开的容器的调度方法的一些实施例的示意图；

图5示出本公开的容器的调度方法的另一些实施例的示意图；

图6示出本公开的容器的调度装置的一些实施例的框图；

图7示出本公开的容器的调度装置的另一些实施例的框图；

图8示出本公开的容器的调度装置的又一些实施例的框图。

具体实施方式

现在将参照附图来详细描述本公开的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本公开的范围。

同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。

以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本公开及其应用或使用的任何限制。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，技术、方法和设备应当被视为授权说明书的一部分。

在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。

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

如前所述，客户在构建容器云时，会将容器云集群部署在自建的机房内，往往会部署数百台物理服务器来承载容器云上的业务。长时间运行的大量物理服务器能耗巨大，物理服务器运行的个数越多，需要的配套降温、除尘设施的规模也越大，给客户带来非常巨大的电费、管理费等持续成本开销。

针对上述技术问题，本公开立足于容器云技术，利用容器云中kubernetes能够对pod(容器集合)进行有策略的调度的机制，重点关注通过pod调度实现让部分物理机清空负载，进入无能耗的休眠状态。这样，可以是使资源的使用量与资源的需求量尽可能的进行匹配，实现既能满足业务需求，又能实现节能降本的目标。例如，可以通过下面的实施例来实现。

图1示出本公开的容器的调度方法的一些实施例的流程图。

如图1所示，该方法包括：步骤110，确定预计资源使用量；步骤120，确定匹配的候选节点；和步骤130，调度已运行容器集合副本。

在步骤110中，根据已运行容器集合副本的资源使用量，确定待调度容器集合副本的预计资源使用量。已运行容器集合副本与待调度容器集合副本的类型相同。

例如，pod是一组紧密关联的容器集合，是kubernetes调度的基本单位。pod内的多个容器共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。pod副本是利用同一个pod模式创建的pod的集合。通过rc(replicationcontroller，复制控制器)或rs(replicaset，副本集)来进行控制。

在一些实施例中，容器集合副本的类型根据相应的pod模式确定，pod模式相同的容器集合副本的类型相同。例如，pod模式可以包含pod包括的容器的镜像、镜像相应的规格、相应的service(服务)名称、副本数中的至少一项。规格可以包括镜像需要的cpu(centralprocessingunit，中央处理器)核数、内存容量、网络贷款、存储容量等硬件资源配置信息。

在一些实施例中，可以利用一个pod模板文件确定一类pod模式，例如，一类pod模式的结构体为：

{

镜像1，规格1；

镜像2，规格2；

…

镜像n，规格n；

service名称；

副本数；

}

规格可以包含cpu核数、内存容量、网络带宽、存储容量等硬件配置信息。例如，依照上述方式创建标签为x的pod，则称以上的结构体为podx的pod模式。

在步骤120中，根据预计资源使用量和各候选节点支持的资源提供量，确定与已运行容器集合副本匹配的候选节点。

在一些实施例中，各候选节点根据待调度容器集合副本的个数、ha(highavailability，高可用)需求、亲和性需求和排斥性需求中的至少一项确定。

例如，亲和性是pod运行时的调度策略包括：nodeaffinity(主机亲和性)、podaffinity(pod亲和性)和podantiaffinity(pod反亲和性)。nodeaffinity用于规定pod可以部署在哪个node或者不能部署在哪个节点上。podaffinity用于规定pod可以和哪些pod部署在同一拓扑结构下。podantiaffinity用于规定pod不可以和哪些pod部署在同一拓扑结构下，与podaffinity一起解决pod之间的关系。

在一些实施例中，根据预计资源使用量中各类型资源的预计使用量，与资源提供量中各类型资源的提供量是否匹配，确定与已运行容器集合副本匹配的候选节点。

在一些实施例中，判断预计资源使用量中各类型资源的预计使用量是否大于相应的使用量阈值；将大于相应的使用量阈值的类型资源，确定为需求资源；判断资源提供量中各类型资源在所述各候选节点中的当前使用率是否小于相应的使用率阈值；将小于相应的使用率阈值的类型资源，确定为各候选节点的可提供资源；根据需求资源和可提供资源的匹配，确定与已运行容器集合副本匹配的候选节点。

在步骤130中，将已运行容器集合副本调度到匹配的候选节点上运行。

在一些实施例中，根据预计资源使用量和匹配的候选节点的资源提供量，确定匹配的候选节点需要唤醒的物理机的数量，物理机的数量是能够满足预计资源使用量的最少数量。

在一些实施例中，还可以根据资源使用量的历史变化情况，估计当前资源使用量。例如，可以通过图2中的实施例实现。

图2示出本公开的容器的调度方法的另一些实施例的流程图。

如图2所示，该方法还可以包括：步骤210，获取历史变化情况；步骤220，判断当前时段；和步骤230，确定是否增加副本。

在步骤210中，获取已运行容器集合副本的资源使用量的历史变化情况。

在一些实施例中，根据指定时间段内各时刻已运行容器集合副本的资源使用量，计算各类型资源在指定时间段内的平均使用量；根据平均使用量，判断在指定时间段内各类型资源的使用量高峰时段和低谷时段作为历史变化情况。

例如，在各类型资源的使用量与各类型资源的平均使用量的差值大于高峰阈值的情况下，将指定时间段确定为高峰时段；在各类型资源的平均使用量与各类型资源的使用量的差值大于低谷阈值的情况下，将指定时间段确定为低谷时段。

在步骤220中，根据历史变化情况，判断待调度容器集合副本当前处于使用量高峰时段还是低谷时段。

在步骤230中，根据判断结果，确定是否增加待调度容器集合副本的数量。

在一些实施例中，在处于高峰时段且单个待调度容器集合副本的资源负载超过负载阈值的情况下，增加待调度容器集合副本的数量。

在一些实施例中，在处于低谷时段的情况下，减少待调度容器集合副本的数量，并控制清空的物理机进入休眠状态。

在一些实施例中，根据历史变化情况，估计待调度容器集合副本在目标时刻的资源使用量；在当前唤醒的物理机不能满足目标时刻的资源使用量的情况下，在目标时刻到来前，唤醒相应数量的物理机提供资源。

在一些实施例中，根据匹配的候选节点的相应物理机上运行的容器集合副本数量，控制相应物理机处于高性能模式或非高性能模式。

例如，在相应的物理机上没有运行容器集合副本的情况下，控制相应的物理机处于休眠模式；在相应的物理机上运行的容器集合副本数量小于副本阈值的情况下，控制相应的物理机处于低性能模式。

图3示出本公开的容器的调度装置的一些实施例的示意图。

如图3所示，调度装置可以包括资源用量评估模块、历史变化情况分析模块、调度模块和物理机状态控制模块。

在一些实施例中，资源用量评估模块(可以包括使用量确定单元)用来评估pod中资源的用量统计数据。统计数据可以为历史变化情况分析模块和调度模块提供数据依据。

在一些实施例中，资源用量评估模块可以记录并评估具有相同pod模式的pod的资源使用量。资源使用量可以用6元组来表示。例如，6元组可以包括cpu工作指令周期数、内存用量、网络io(inputoutput，输入输出)次数、网络io流量、存储io次数、存储io总量。

在一些实施例中，资源使用量可以是在单位时间t内统计的数值。例如，t可以是1秒、1分钟或1小时等。

在一些实施例中，可以用cpu的实际工作指令周期数来准确度量pod对cpu的实际使用情况；内存用量可以是内存在这一时间段t内，每秒内存用量的累加值；网络io和存储io分成次数和总量，用来区分频繁io的情况和大数据量io的情况。

在一些实施例中，资源用量评估模块针对相同pod模式的pod，统计其资源使用量，并对计算平均值。还可以将平均值除以一台物理机能达到的最大值，对平均值进行归一化，从而将6元组对应的各项数值统一为6个0到1之间的数值。

例如，物理机能达到的cpu最大值是物理机所有核在t内的全部周期数；物理机能达到的内存最大值是物理机全部内存总量减去管理程序和系统程序的内存用量。

物理机能达到的网络io次数最大值是历史上系统在t内进行的最多次的网络io次数(当有新的最大值时进行更新)；物理机能达到的网络io流量最大值是根据网络带宽计算出的t内能达到的最大网络传输数据量；物理机能达到的存储io次数最大值是历史上系统内t内进行的最多次的存储io次数(当有新的最大值时进行更新)；物理机能达到的存储io总量最大值是根据存储带宽计算出的t内能达到的最大传输数据量。

相同pod模式的pod实际资源用量，除以最大值，可以获得归一化的数值。除io次数之外，多个pod的资源用量在同一台物理机上相加之和不能大于物理机的能力值。

在一些实施例中，当多个物理机的规格不相同或处理能力不一致时，则物理机的处理能力也进行归一化。例如，将物理机的对应指标都要除以处理能力最大物理机的对应指标的值，即，归一化物理机能力指标＝物理机指标值/最大的物理机指标值。

在一些实施例中，node的资源提供量是归一化的6元组，用于衡量node能够为pod提供多少资源。

在一些实施例中，历史变化情况分析模块(可以包括判断单元)用于分析pod对cpu、内存、网络、io等资源用量的历史变化情况(如周期性规律)，从而为调度模块和物理机状态控制模块提供决策依据。

在一些实施例中，pod对系统资源的使用量是波浪式曲线变化的，一般也体现出周期性的变化规律。系统资源使用的变化规律一般是人类社会活动的周期性造成的。例如，大多数人们白天工作，晚上休息，造成与人们交互的系统大多是白天繁忙，晚上空闲。因此，可以利用获得的变化规律，实现资源的更好配置。

在一些实施例中，可以按照人的作息和活动规律，将变化规律的周期分为天、周、月、年等时间段。

在一些实施例中，可以对一天的资源使用量的规律进行统计。例如，以一个时间间隔(如1分钟)为单位时间，统计每个单位时间内同一pod模式的pod(pod样本)的资源使用量。

例如，可以在一段时间范围内(如20天)，去除异常的数据点，得到一天内每一个时间段的资源用量的平均值；确定资源使用量平均值的高峰时段和低谷时段的时间范围。高峰时段的资源使用量明显高于一天各类资源的平均使用量；低谷时段资源使用量明显低于一天各类资源的平均使用量。

在一些实施例中，可以对一周的资源使用量规律统计。例如，以某一天时间段为单位时间，统计每个单位时间内同一pod模式的pod的资源使用量。在一段时间范围内(如60天)，去除异常的数据点，得到一周内每一天的资源使用量的平均值。确定资源用量平均值的高峰时段和低谷时段的时间范围。

在一些实施例中，可以对一月的资源用量规律统计。例如，以某一天时间段为单位时间，统计每个单位时间内同一pod模式的pod的资源使用量。在一段时间范围内(如90天)，去除异常的数据点，得到一月内每一天的资源使用量的平均值。确定资源用量平均值的高峰时段和低谷时段的时间范围。

在一些实施例中，可以对一年的资源用量规律统计。例如，以某一天时间段为单位时间，统计每个单位时间内同一pod模式的pod的资源使用量。在一年时间范围内，去除异常的数据点，得到一年内每一天的资源使用量的平均值。确定资源使用量平均值的高峰时段和低谷时段的时间范围。

在一些实施例中，可以通过天、周、月、年四个时间跨度，清楚分析出资源使用量的高峰时段和低谷时段情况，用于指导资源分配。

在一些实施例中，调度模块(可以包含节点匹配单元、调度单元)，负责pod增、改、删等变化时系统对pod副本的动态调度。例如，动态调度主要分为pod创建时的调度和pod更改和删除时的调度。调度模块可以包括调度策略创建模块、动态变化调度模块。

在一些实施例中，调度策略创建模块可以将调度策略分为三级：predicate策略、peculiarity策略、setoptimize策略(或flex-grow策略)。

在一些实施例中，predicate策略用于过滤不符合已设定条件的节点。已设定条件可以包括pod副本与节点的互斥设定等，如指定pod副本不能部署在指定node1。

在一些实施例中，peculiarity策略用于在predicate策略过滤之后，根据pod副本要求的技术特性，确定符合条件的候选节点集合。技术特性可以包括pod副本个数、高可用需求、亲和性需求、排斥性需求等。

这样，性能和资源用量不是确定匹配的候选节点的唯一考量，还引入了高可用、高并发等要素，从而提高调度效果。

在一些实施例中，setoptimize策略用于集合优化，是第三级调度的第一种方式。例如，可以将待调度的全部pod副本作为一个pod集合进行考虑，选择能够使pod集合调度到候选节点集合后能形成最佳效能的策略进行调度。

在一些实施例中，最佳效能为在满足设定条件和特性要求的前提下，在预留部分应急流量处理空间的情况下，负载能够满足业务要求并，并能够使整个集群的能耗最低。

例如，可以将工作负载尽量分配到少量的物理机上，让少量的物理机能够满足资源和流量需求，使更多的物理机能够进行休眠。当已分配工作负载的物理机的负载较小时，使物理机进入节能模式，在能够满足业务流量需求的同时，做到能耗最低

在一些实施例中，集合优化可以包括同时考虑两个pod操作的情况，如需要删除一个pod副本，再新建一个pod副本。若多个pod副本中需要删除一个，则调度程序能够选择最优的可删除的pod副本，使新建的pod副本能达到最佳效能。

在一些实施例中，在pod副本进行创建时，采用setoptimize集合优化方法的主要流程如下。

第1步，根据创建pod副本的模板文件，确定pod副本的模式、创建pod副本的设定条件、副本个数等。

第2步，排除不符合设定条件的node。例如，标签(label)是识别kubernetes对象的标签，以key-value的方式附加到对象上。label不提供唯一性，并且实际上经常是很多对象(如pods)都使用相同的label来标志具体的应用。可以通过标签排除某些node。

第3步，根据pod副本个数、高可用需求、亲和性需求、排斥性需求等技术特性，划分可分配的候选节点集合，以及pod多个副本之间的分布关系。

例如，至少将pod副本分配到两个物理主机节点上，以保障跨物理机高可用；或者，至少将pod副本分配到两个机架上，以保障跨机架高可用；或者，pod副本都分配到具有高带宽网络的物理主机上，以保证网络高并发访问。

第4步，若存在运行一段时间的与待调度pod副本具有相同pod模式的pod副本，则根据资源用量评估模块获取该pod模式的近期资源实际使用资源用量的6元组。

第5步，可以将pod副本集合的资源用量6元组与候选节点集合中候选节点的资源剩余用量6元组进行匹配，计算能够使节点能够达到6项指标都较均衡的匹配策略。

在一些实施例中，若全部非休眠状态的物理主机上的node中的资源剩余用量能够支持新的pod副本的创建，则按照均衡匹配的策略调度pod副本到相应的node上。全部待调度的pod副本作为一个集合进行整体调度。

在一些实施例中，可以确定pod副本的资源使用量中指标明显偏高的几项作为高需求资源；选择节点中可用量最大的资源作为低谷资源(提供资源)，与高需求资源进行匹配。也就是说，尽量填满资源空闲大的指标，使全部6项指标在node上实现基本均衡的分配。

在一些实施例中，若一些pod副本需调度到同一node中，则将需要分配到同一node的pod副本资源用量进行组合。例如，node资源能够满足需求则进行分配。

例如，图4a-4d是将两个pod副本调度到同一node的资源评估实施例。

图4a示出本公开的节点资源分布情况的一些实施例的示意图。

图4a所示是一个可调度的node的归一化资源实际使用率和剩余可分配的资源空间。为了保障流量抖动、突发等情况系统能够承载业务流量，故在系统中设定预留的应急资源空间。例如，cpu、内存等相关指标的预留应急资源空间的比例可以不同。

在一些实施例中，可以计算各类资源的归一化平均使用率，根据归一化平均使用率，可以确定使用率较低的低谷资源：内存、网络io流量、存储io总量。

图4b示出本公开的pod副本资源使用情况的一些实施例的示意图。

图4b为根据与待调度pod副本具有相同pod模式的已运行pod副本的历史资源使用量，估计的预计资源使使用量。可以计算各类资源的归一化平均使用量，根据归一化平均使用量确定使用量的高需求资源：内存、网络io流量、存储io总量。

图4c示出本公开的两个pod副本资源使用情况的一些实施例的示意图。

图4c为两个pod副本资源使用量的估计，每项指标是单个pod的两倍。高需求资源：内存、网络io流量、存储io总量。在这种情况下，高需求资源类型和低谷资源类型刚好匹配，且低谷资源的数量能够满足高需求资源，则可以将该两个pod副本调度到该node上。

图4d示出本公开的容器的调度方法的一些实施例的示意图。

图4d为将两个pod副本分配到可调度的node上的资源用量情况。多个node的情况与单个类似，都需保证pod的估计资源用量能够得到满足。

在一些实施例中，若全部非休眠状态的物理主机上的node中的资源剩余用量不足以支持新的pod副本的创建，则将若干个休眠中的物理主机进行唤醒。并且，使得唤醒后的物理主机上的node与原有node可分配的资源用量能够满足创建pod副本的模式的资源用量总和需求。

在一些实施例中，若不存在相同pod模式的已运行pod副本，则根据模板文档中的资源需求(各镜像对应的规格)估计资源用量6元组。例如，核数要求越多则cpu用量预估越大。而后根据资源预估的用量按照上述实施例进行处理。

在一些实施例中，所有pod副本都被调度到node上，或者全部物理机被唤醒后，不存在能满足资源需求的node，则调度结束。

在一些实施例中，setoptimize策略的集合优化的模型包括：目标为最小化非休眠状态的物理机；约束条件为所有pod副本创建符合模板设定的条件；所有pod副本创建符合技术特性要求；创建出的pod副本能够满足业务负载；各node上pod副本的资源用量不超出限值。

在一些实施例中，flex-grow策略用于pod副本的弹性分配，是第三级调度的第二种可选方式。例如，可以在满足前两级调度限定条件的前提下，先创建一部分pod副本，而后再参照pod副本的工作负载对pod副本个数进行调整。

在一些实施例中，在pod进行创建时，采用flex-grow弹性调度方法的主要流程如下：

第1步，根据创建pod副本的模板文件，确定pod副本的模式，确定创建pod设定条件、副本个数。

第2步，排除不符合创建设定条件的node。例如，通过标签排除某些node。

第3步，根据pod副本个数、高可用需求、亲和性需求、排斥性需求等技术特性，划分可分配的候选节点集合，以及pod多个副本之间的分布关系。

例如，pod副本至少分配到两个物理主机节点上来保障跨物理机高可用。或pod副本至少分配到两个机架上来保障跨机架高可用。或pod副本都分配到具有高带宽网络的物理主机上保证网络高并发访问。

第4步，选择两种情况副本数的最大值，作为要创建的pod副本个数。例如，两种情况包括创建要求的pod副本量的一半、满足技术特性的最少副本数。

第5步，按照第4步中确定的pod副本个数进行pod调度，并在满足设定条件的情况下，使非休眠状态下的物理机个数最少。

第6步，当pod副本资源用量大于上限阈值时，增加pod副本的个数。增加的步长有两种选择，一是按照设定的个数为单元增加，二是按设定的比例为单元增加。例如，总数量减去已有数量后的一半。增加时同样要满足使非休眠状态的物理机最少的目标。

第7步，当pod副本资源用量小于下限阈值时，减少pod副本的个数。减少的步长有两种选择，一是按照设定的个数为单元减少，二是按设定的比例为单元减少，例如，已有数量的一半。

第8步，重复第6、7步，直到pod副本的资源用量在上下限阈值之间。

第9步，若第6、7、8步中物理机资源被清空则回收物理机并使其进入休眠状态，且物理机资源不足，则唤醒休眠的物理机，增大资源供给。

在一些实施例中，动态变化调度模块采用依赖于当前各pod副本的负载状态的弹性副本集进行调度。例如，可以将用户设置的pod副本个数3个作为标准值；当pod副本整体负载较低时，在满足高可用等限定条件下减少pod副本数量；当pod副本整体负载较高时，动态增加pod副本数量以适应需求。

这样，弹性副本集操作使得集群中减少大量的运算资源需求成为可能。而且，还能够实现集群部分物理机进入休眠状态，少云计算集群能耗。由于电费是云计算平台主要持续开销之一，因此能够降低运营成本。

动态变化调度模块的调度流程包括：

第1步，分析一个pod副本集提供service的资源用量的周期规律。如前所述，可以根据天、周、月、年四个时间跨度，分析出资源使用量的高峰时段、低谷时段和平均值情况。

例如，一个service的资源用量是其包含的全部pod副本的资源用量的总和。系统需要确保无论总共有多少个pod副本，都能够支撑service资源需求总量。

第2步，通过单个pod副本的资源用量的最大值，计算各个时段最大资源需求(流量洪峰)时所需的pod副本个数；计算各个时段最小资源需求(流量低谷)时所需的pod副本个数。

第3步，系统在流量洪峰时，需预留足够的资源，为pod副本调度提供支持。

第4步，在系统正常运行时期，按照service平均的资源需求，分配能够满足任务负载处理量的数个pod副本。

第5步，当流量洪峰到来，资源需求量增大，单个pod副本的资源负载超过设定的阈值，则启动增加pod副本个数的流程。

第6步，增加pod副本个数。例如，若集群没有足够的资源进行分配，则将休眠的物理机唤醒，增加资源的供给。

在一些实施例中，记录物理机唤醒和进行初始化所用的时间t0；根据资源用量的周期变化，估计出t时刻集群可用物理主机的资源将无法满足需求；在t-t0时刻启动物理主机的唤醒动作。

第7步，在物理资源到位后，对pod副本进行调度，并将其关联到对应的service。

第8步，若资源需求持续增大，则重复第5到7步的流程，直到需求不再增大。

第9步，当流量需求减少，并且根据资源需求规律分析得到资源需求将恢复到正常状态，则逐步减少pod副本个数；控制剩余的pod副本高负荷运行，并能够满足流量需求。可以尽量将pod副本调度到少量的物理主机上，使清空的物理主机能够进入休眠状态。

第10步，重复第9步，直到pod副本数量恢复到系统正常运行期间需要的个数。

第11步，当流量低谷到来，与处理洪峰流程相反，先减少pod副本个数；尽量将pod副本调度到少量的物理主机上；使清空的物理主机能够进入休眠状态。当流量增大时，增加pod副本个数到正常值。

在一些实施例中，物理机状态控制模块(可以包括控制单元)依据资源的需求情况，对物理机的休眠模式、节能模式、高性能模式等不同状态进行控制。例如，可以通过pod样本的运行情况对物理机模式进行控制。例如，可以通过图5中的实施例来实现。

图5示出本公开的容器的调度方法的另一些实施例的示意图。

如图5所示，当物理机被清空，即其上不存在正在运行的pod样本的情况下，判断近期业务流量是否会反弹。在不会反弹的情况下，则使物理主机进入休眠模式，最大程度减少能耗。

当物理机上只运行少量pod样本(样本数小于数量阈值)，并且实际资源使用量低于物理机能提供的能力，则使物理机进入节能模式(低性能模式)。这样，可以在保证资源用量的同时减少能耗。

当物理机处于休眠模式，并且系统评估将需要更多物理机资源时，将休眠的物理机进行唤醒，进入节能模式；使唤醒的物理机准备好资源和系统运行环境。

当物理机处于节能模式，并且实际资源用量提升，节能模式下的物理机无法满足性能需求，则使其进入高性能模式。

当物理机处于高性能模式，并且实际资源使用量降低，实际用量远低于物理机能力，则使其进入节能模式。

在上述实施例中，通过pod样本的调度，实现了容器云中的部分物理机进入休眠状态，从而使容器云平台集群的能耗大幅下降，降低电费成本。

在上述实施例中，采用基于6元组和pod模式的资源用量评估方法，更准确地评估pod副本可能的资源使用情况，从而为pod副本的调度提供更准确的依据。

在上述实施例中，在容器云上提出资源用量的周期性规律分析方法，采用更高的视角，能够更好地判断pod副本和资源的分配和回收的时机。

在上述实施例中，提出三级pod创建调度机制，在满足各种限定条件的前提下，以使用最少物理机为目标进行pod调度。

在上述实施例中，提出pod动态变化调度机制。在满足系统负载需求的前提下，对pod进行动态的调度，实现业务流量低谷时回收资源并节约能源的目标。在业务流量增大时，也能通过分配资源满足业务需求。

在上述实施例中，根据与待调度容器集合副本同类型的容器集合副本的资源使用量先验数据，估计待调度容器集合副本的资源使用量；在此基础上，结合各节点能够提供的资源数量生成调度策略。这样，能够使得系统的资源使用量和资源提供量相匹配，降低系统资源的浪费。

图6示出本公开的容器的调度装置的一些实施例的框图。

如图6所示，容器的调度装置6包括使用量确定单元61、节点匹配单元62、调度单元63。

使用量确定单元61根据已运行容器集合副本的资源使用量，确定待调度容器集合副本的预计资源使用量，已运行容器集合副本与待调度容器集合副本的类型相同。

节点匹配单元62根据预计资源使用量和各候选节点支持的资源提供量，确定与已运行容器集合副本匹配的候选节点。

在一些实施例中，节点匹配单元62根据预计资源使用量中各类型资源的预计使用量，与资源提供量中各类型资源的提供量是否匹配，确定与已运行容器集合副本匹配的候选节点。

在一些实施例中，节点匹配单元62判断预计资源使用量中各类型资源的预计使用量是否大于相应的使用量阈值；将大于相应的使用量阈值的类型资源，确定为需求资源；判断资源提供量中各类型资源在各候选节点中的当前使用率是否小于相应的使用率阈值；将小于相应的使用率阈值的类型资源，确定为各候选节点的可提供资源；根据需求资源和可提供资源的匹配，确定与已运行容器集合副本匹配的候选节点。

调度单元63根将已运行容器集合副本调度到匹配的候选节点上运行。

在一些实施例中，调度单元63根据预计资源使用量和匹配的候选节点的资源提供量，确定匹配的候选节点需要唤醒的物理机的数量，物理机的数量是能够满足预计资源使用量的最少数量。

在一些实施例中，调度装置6还包括判断单元64，用于根据获取的已运行容器集合副本的资源使用量的历史变化情况，判断待调度容器集合副本当前处于使用量高峰时段还是低谷时段，以便根据判断结果，确定是否增加待调度容器集合副本的数量。

在一些实施例中，判断单元64根据指定时间段内各时刻已运行容器集合副本的资源使用量，计算各类型资源在指定时间段内的平均使用量；根据平均使用量，判断在指定时间段内各类型资源的使用量高峰时段和低谷时段作为历史变化情况。

在一些实施例中，调度装置6还包括控制单元65根据历史变化情况，估计待调度容器集合副本在目标时刻的资源使用量；在当前唤醒的物理机不能满足目标时刻的资源使用量的情况下，在目标时刻到来前，唤醒相应数量的物理机提供资源。

在一些实施例中，控制单元65在处于高峰时段且单个待调度容器集合副本的资源负载超过负载阈值的情况下，增加待调度容器集合副本的数量。

在一些实施例中，控制单元65在处于低谷时段的情况下，减少待调度容器集合副本的数量，并控制清空的物理机进入休眠状态。

在一些实施例中，控制单元65用于根据匹配的候选节点的相应物理机上运行的容器集合副本数量，控制相应物理机处于高性能模式或非高性能模式。

在一些实施例中，控制单元65控制相应物理机处于高性能模式或非高性能模式包括：在相应的物理机上没有运行容器集合副本的情况下，控制相应的物理机处于休眠模式；在相应的物理机上运行的容器集合副本数量小于副本阈值的情况下，控制相应的物理机处于低性能模式。

在一些实施例中，各候选节点根据待调度容器集合副本的个数、高可用需求、亲和性需求和排斥性需求中的至少一项确定。

在上述实施例中，根据与待调度容器集合副本同类型的容器集合副本的资源使用量先验数据，估计待调度容器集合副本的资源使用量；在此基础上，结合各节点能够提供的资源数量生成调度策略。这样，能够使得系统的资源使用量和资源提供量相匹配，降低系统资源的浪费。

图7示出本公开的容器的调度装置的另一些实施例的框图。

如图7所示，该实施例的容器的调度装置7包括：存储器71以及耦接至该存储器71的处理器72，处理器72被配置为基于存储在存储器71中的指令，执行本公开中任意一个实施例中的容器的调度方法。

其中，存储器71例如可以包括系统存储器、固定非易失性存储介质等。系统存储器例如存储有操作系统、应用程序、引导装载程序、数据库以及其他程序等。

图8示出本公开的容器的调度装置的又一些实施例的框图。

如图8所示，该实施例的容器的调度装置8包括：存储器810以及耦接至该存储器810的处理器820，处理器820被配置为基于存储在存储器810中的指令，执行前述任意一个实施例中的容器的调度方法。

存储器810例如可以包括系统存储器、固定非易失性存储介质等。系统存储器例如存储有操作系统、应用程序、引导装载程序以及其他程序等。

容器的调度装置8还可以包括输入输出接口830、网络接口840、存储接口850等。这些接口830、840、850以及存储器810和处理器820之间例如可以通过总线860连接。其中，输入输出接口830为显示器、鼠标、键盘、触摸屏等输入输出设备提供连接接口。网络接口840为各种联网设备提供连接接口。存储接口850为sd卡、u盘等外置存储设备提供连接接口。

本领域内的技术人员应当明白，本公开的实施例可提供为方法、系统、或计算机程序产品。因此，本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用非瞬时性存储介质上实施的计算机程序产品的形式。

至此，已经详细描述了根据本公开的容器的调度方法、装置和计算机可读存储介质。为了避免遮蔽本公开的构思，没有描述本领域所公知的一些细节。本领域技术人员根据上面的描述，完全可以明白如何实施这里公开的技术方案。

可能以许多方式来实现本公开的方法和系统。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本公开的方法和系统。用于方法的步骤的上述顺序仅是为了进行说明，本公开的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本公开实施为记录在记录介质中的程序，这些程序包括用于实现根据本公开的方法的机器可读指令。因而，本公开还覆盖存储用于执行根据本公开的方法的程序的记录介质。

虽然已经通过示例对本公开的一些特定实施例进行了详细说明，但是本领域的技术人员应该理解，以上示例仅是为了进行说明，而不是为了限制本公开的范围。本领域的技术人员应该理解，可在不脱离本公开的范围和精神的情况下，对以上实施例进行修改。本公开的范围由所附权利要求来限定。