容器资源调度方法及装置

技术领域

本申请涉及云计算技术领域，尤其涉及云平台容器资源调度技术领域，具体而言，涉及一种容器资源调度方法及装置。

背景技术

随着云计算的推广和普及，各大厂商的基础设施的规模不断增加，总拥有成本也逐年上升，容器云平台，集群规模也在不断的扩大，集群资源的利用率问题逐步突显，在保持业务稳步增长的前提下，降本增效成为业界的一大趋势。

相关技术中的容器云平台(如容器编辑器Kubernetes，k8s)主要基于其原生的调度器进行调度，调度基于应用配置的请求request值进行分配(如某一服务器节点对应的CPU核数为8C，应用申请的request为4C，则该服务器节点部署两个此规格的容器后即无法再分配给其他应用)，应用习惯将Request设置较大，以锁定资源保证业务工作负载的稳定性，而实际资源使用率则大大低于申请的值，由此导致申请的资源远远超出实际使用的资源，造成大量的资源浪费。

针对相关技术中进行容器资源调度时按申请值调度，导致集群资源使用率不高，资源浪费严重的问题，目前尚未提出有效的解决方案。

发明内容

本申请的主要目的在于提供一种容器资源调度方法及装置，以解决相关技术中进行容器资源调度时按申请值调度，导致集群资源使用率不高，资源浪费严重的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种容器资源调度方法。该方法包括：获取目标应用对应的实际资源使用值，以及上述目标应用对应的目标资源类型；基于上述实际资源使用值，从服务器集群中确定出上述目标应用的目标应用容器对应的候选服务器，其中，上述服务器集群包括多个服务器；在上述候选服务器为多个的情况下，获取多个候选服务器分别对应的第一资源可分配值，上述多个候选服务器分别包括的第一应用，以及对应第一应用的第一资源类型；基于上述目标资源类型，上述第一资源可分配值和上述第一资源类型，从上述多个候选服务器中确定出上述目标应用容器对应的目标服务器。

为了实现上述目的，根据本申请的另一方面，提供了一种容器资源调度装置。该装置包括：第一获取模块，用于获取目标应用对应的实际资源使用值，以及上述目标应用对应的目标资源类型；第一确定模块，用于基于上述实际资源使用值，从服务器集群中确定出上述目标应用的目标应用容器对应的候选服务器，其中，上述服务器集群包括多个服务器；第二获取模块，用于在上述候选服务器为多个的情况下，获取多个候选服务器分别对应的第一资源可分配值，上述多个候选服务器分别包括的第一应用，以及对应第一应用的第一资源类型；第二确定模块，用于基于上述目标资源类型，上述第一资源可分配值和上述第一资源类型，从上述多个候选服务器中确定出上述目标应用容器对应的目标服务器。

通过本申请，通过获取目标应用对应的实际资源使用值，以及上述目标应用对应的目标资源类型；基于上述实际资源使用值，从服务器集群中确定出上述目标应用的目标应用容器对应的候选服务器，其中，上述服务器集群包括多个服务器；在上述候选服务器为多个的情况下，获取多个候选服务器分别对应的第一资源可分配值，上述多个候选服务器分别包括的第一应用，以及对应第一应用的第一资源类型；基于上述目标资源类型，上述第一资源可分配值和上述第一资源类型，从上述多个候选服务器中确定出上述目标应用容器对应的目标服务器，达到了综合目标应用的实际资源使用值和资源类型进行容器调度，提升集群资源使用率的同时，避免同类型资源争抢等问题的发生的目的，解决了相关技术中进行容器资源调度时按申请值调度，导致集群资源使用率不高，资源浪费严重的问题。进而达到了提升容器资源使用效率，减少资源浪费的效果。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例提供的容器资源调度方法的流程图；

图2是根据本申请实施例的一种可选的CPI阈值划分示意图；

图3是根据本申请实施例的一种可选的容器资源调度方法的处理流程图；

图4是根据本申请实施例提供的容器资源调度装置的示意图；

图5是根据本申请实施例提供的电子设备的示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，为方便理解本申请实施例，下面将对本申请中所涉及的部分术语或名词进行解释说明：

滑动平均(MA)模型，也叫做移动平均法，算法核心为：将该点附近的采样点做算数平均，作为这个点光滑后的值，用于剔除历史数据异常值。

3-sigma，又称为拉依达准则，该准则具体来说，就是先假设一组检测数据只含有随机误差，对原始数据进行计算处理得到标准差，然后按一定的概率确定一个区间，认为误差超过这个区间的就属于异常值。假设数据集满足正态分布，其区间占比满足以下规律，σ代表数据标准差,μ数据均值，具体数值分布与数据占比之间的对因关系如表1所示。

表1

Pod，容器编辑器Kubernetes最重要的基本概念，可由多个容器组成，是系统中资源分配和调度的最小单元。

kubelet，运行在每个节点node上主要的代理，每个节点会启动kubelet服务，用来处理主服务器master下发到本节点的任务。

etcd，一种开源的、高可用的分布式键值key-value存储系统。

需要说明的是，本申请所涉及的相关信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于展示的数据、分析的数据等)，均为经用户授权或者经过各方充分授权的信息和数据。例如，本系统和相关用户或机构间设置有接口，在获取相关信息之前，需要通过接口向前述的用户或机构发送获取请求，并在接收到前述的用户或机构反馈的同意信息后，获取相关信息。

下面结合优选的实施步骤对本申请进行说明，图1是根据本申请实施例提供的容器资源调度方法的流程图，如图1所示，该方法包括如下步骤：

步骤S102，获取目标应用对应的实际资源使用值，以及上述目标应用对应的目标资源类型。

可以理解，上述实际资源使用值为预测得到的预设预测时段对应的实际资源使用值，上述目标应用为服务器集群对应的任意一个应用。

在一种可选的实施例中，获取上述目标应用对应的上述实际资源使用值，包括：获取当前采样周期内上述目标应用对应的当前运行数据；获取预设的历史采样时段内上述目标应用对应的历史运行数据；基于上述历史运行数据，确定上述目标应用在预设的预测时段内的预测运行数据，其中，上述预测时段为上述当前采样周期之后的第二数量的连续历史采样周期；基于上述当前运行数据和上述预测运行数据，确定上述目标应用对应的资源使用曲线；根据上述资源使用曲线，确定上述实际资源使用值。

可选的，上述历史采样时段为上述当前采样周期之前的第一数量的连续历史采样周期，上述历史运行数据可以但不限于包括上述目标应用在上述历史采样时段内的历史资源使用数据，对应的上述预测运行数据可以但不限于为上述目标应用在上述预测时段内的预测资源使用数据。例如，基于上述历史采样时段采集到的历史资源使用数据，对上述目标应用进行资源画像，对上述目标应用在预测时段内的资源使用趋势进行预测，得到目标应用在预测时段对应的预测资源使用数据。基于上述实际资源使用值与上述预测资源使用数据，得到目标应用从历史某个时间点到未来一段时间的资源使用曲线，将上述资源使用曲线中资源使用的99线(99％的点)对应的值，作为上述实际资源使用值。

步骤S104，基于上述实际资源使用值，从服务器集群中确定出上述目标应用的目标应用容器对应的候选服务器，其中，上述服务器集群包括多个服务器。

在一种可选的实施例中，上述基于上述实际资源使用值，从服务器集群中确定出上述目标应用的目标应用容器的候选服务器，包括：确定上述服务器集群中包括的服务器，以及对应的第二资源可分配值；将上述服务器集群中上述第二资源可分配值大于或等于上述实际资源使用值的服务器，作为上述候选服务器。

需要说明的是，在确定目标应用的目标应用容器对应分配的服务器(即目标服务器)时，需要首先考虑对应的服务器能否满足目标应用的资源占用需求。因此，需要对上述服务器集群中包括的每一个服务器的资源可分配值(即上述第二资源可分配值)与上述目标应用对应的上述实际资源使用值进行对比，将上述服务器集群中上述第二资源可分配值大于或等于上述实际资源使用值的服务器，作为上述候选服务器。其中，上述第二资源可分配值计算方式为：服务器的实际规格减去该服务器上其他应用已占用的资源值。

步骤S106，在上述候选服务器为多个的情况下，获取多个候选服务器分别对应的第一资源可分配值，上述多个候选服务器分别包括的第一应用，以及对应第一应用的第一资源类型。

步骤S108，基于上述目标资源类型，上述第一资源可分配值和上述第一资源类型，从上述多个候选服务器中确定出上述目标应用容器对应的目标服务器。

可选的，在上述候选服务器为多个的情况下，综合目标应用的实际资源使用值和资源类型进行容器调度，确定对应的目标服务器。在上述候选服务器为一个的情况下，直接将该候选服务器作为上述目标服务器。

在一种可选的实施例中，上述基于上述目标资源类型，上述第一资源可分配值和上述第一资源类型，从上述多个候选服务器中确定出上述目标应用容器对应的目标服务器，包括：获取上述多个候选服务器中的任意一个候选服务器，判断上述任意一个候选服务器包括的上述第一应用分别对应的上述第一资源类型与上述目标资源类型是否相同；若上述任意一个候选服务器包括的上述第一应用分别对应的上述第一资源类型均与上述目标资源类型不相同，则将上述任意一个候选服务器作为第一候选服务器；在上述第一候选服务器为多个的情况下，获取多个第一候选服务器分别对应的上述第一资源可分配值；基于上述目标应用对应的上述实际资源使用值，以及上述多个第一候选服务器分别对应的上述第一资源可分配值，从上述多个第一候选服务器中确定出上述目标服务器。

通过以上方式，优先考虑将上述目标应用容器部署至不存在与上述目标应用的资源类型相同的服务器上，以有效避免相同类型的应用调度到同一个服务器上，造成同类型资源占用的争抢。在上述多个候选服务器中有多个服务器不存在与上述目标应用的资源类型相同的服务器时，即存在多个第一候选服务器时，结合上述目标应用对应的上述实际资源使用值，以及上述多个第一候选服务器分别对应的上述第一资源可分配值，对上述多个第一候选服务器做出进一步的筛选，最终得到上述目标服务器。

在一种可选的实施例中，上述基于上述目标应用对应的上述实际资源使用值，以及上述多个第一候选服务器分别对应的上述第一资源可分配值，从上述多个第一候选服务器中确定出上述目标服务器，包括：分别确定上述多个第一候选服务器对应的上述第一资源可分配值与上述实际资源使用值之间的第一资源差值；将上述多个第一候选服务器中上述第一资源差值最小的第一候选服务器，作为上述目标服务器。

通过以上方式，可以将上述目标应用部署至与该目标应用的实际资源使用值最为接近的第一候选服务器，调度时考虑尽可能填满服务器资源，将所有应用容器调度到尽可能少的服务器上，从而达到服务器资源利用率提升的目的。

在一种可选的实施例中，在上述基于上述目标资源类型，上述第一资源可分配值和上述第一资源类型，从上述多个候选服务器中确定出上述目标应用容器对应的目标服务器之后，上述方法还包括：获取上述目标服务器对应的目标服务器资源实际使用值；判断上述目标服务器资源实际使用值是否大于上述目标服务器对应的目标服务器资源预设使用值；若上述目标服务器资源实际使用值大于上述标服务器资源预设使用值，则获取上述目标服务器包括的第三应用分别对应的应用等级；将上述目标服务器包括的第三应用中上述应用等级最低的迁移出上述目标服务器。

可选的，在从上述多个候选服务器中确定出上述目标应用容器对应的目标服务器之后，还需要实时考虑目标服务器资源实际使用值是否达到目标服务器资源预设使用值(即目标服务器的实际规格)，如果达到目标服务器资源预设使用值，则获取上述目标服务器包括的应用分别对应的应用等级，将上述目标服务器中应用等级最低的应用迁移出上述目标服务器，以保证上述目标服务器的正常稳定运行。

在一种可选的实施例中，上述方法还包括：分别获取上述目标服务器包括的第三应用在上述第一数量的连续历史采样周期分别对应的目标平均指令周期数；判断上述目标服务器包括的第三应用中，是否存在上述历史采样时段内第三数量的连续历史采样周期分别对应的上述目标平均指令周期数均大于平均指令周期数阈值的第四应用，其中，上述第三数量小于或等于上述第一数量；在上述目标服务器包括的第三应用中存在上述第四应用，并且上述第四应用的应用等级不为上述目标服务器包括的第三应用中的最低等级的情况下，将上述目标服务器包括的第三应用中上述应用等级最低的迁移出上述目标服务器。

需要说明的是，目标平均指令周期数(cycles per instruction，CPI)与应用的响应时间存在很强的关联性，可以用CPI来代替应用的响应时间来判断应用是否受干扰。当某一个服务器(如上述目标服务器)调度了更多的资源之后，有可能造成应用间的相互干扰，导致应用业务受影响，通过获取到的上述目标平均指令周期数可以判断，上述目标服务器中的某个第三应用在N个(即上述第三数量，可配置)连续历史采样周期内的目标平均指令周期数均大于平均指令周期数阈值(即预设的CPI健康值)的时，则可以判断该第三应用受到了影响，此时需要根据预先设定的应用优先级将上述目标服务器中应用等级最低的第三应用迁移出上述目标服务器，并将该应用等级最低的第三应用重新调度到其他资源压力较小的服务器。

在一种可选的实施例中，上述分别获取上述目标服务器包括的第三应用在上述第一数量的连续历史采样周期分别对应的目标平均指令周期数，包括：分别获取上述目标服务器包括的第三应用在上述第一数量的连续历史采样周期分别对应的初始平均指令周期数；采用移动平均法对上述初始平均指令周期数进行第一处理，得到上述目标服务器包括的第三应用在上述第一数量的连续历史采样周期分别对应的第一平均指令周期数；基于拉依达准则对上述第一平均指令周期数进行第二处理，得到上述目标服务器包括的第三应用在上述第一数量的连续历史采样周期分别对应的上述目标平均指令周期数。

通过以上方式，首先采用移动平均法对获取到的历史采样周期对应的初始平均指令周期数进行第一处理，剔除上述初始平均指令周期数异常值和毛刺点，得到第一平均指令周期数，再基于拉依达准则对获取到的上述第一平均指令周期数进行第二处理，即基于拉依达准则计算出阈值线，作为CPI健康阈值上下界，下界为μ-3σ，上界为μ+3σ(如图2所示)，最终筛选得到上述目标平均指令周期数。

在一种可选的实施例中，上述方法还包括：对上述历史运行数据进行量化处理，得到上述历史采样时段内上述目标应用对应的标准向量数据集；对上述标准向量数据集进行归一化处理，得到标准聚类数据集；确定上述多个资源类型分别对应的标准化向量；基于上述标准聚类数据集和上述标准化向量，得到目标数据集；采用K均值聚类算法对上述目标数据集进行聚类处理，得到上述服务器集群中包括的服务器分别包括的第二应用，以及上述第二应用对应的第二资源类型；基于上述服务器集群中包括的服务器分别包括的上述第二应用，以及上述第二应用对应的上述第二资源类型，确定上述目标应用对应的上述目标资源类型；以及基于上述服务器集群中包括的服务器分别包括的上述第二应用，上述第二应用对应的上述第二资源类型，确定上述多个候选服务器分别包括的上述第一应用，上述第一应用对应的上述第一资源类型。

可选的，上述标准向量数据集的特征维度与上述历史运行数据中包括的特征指标相对应，上述历史运行数据中包括的特征指标对应于多个资源类型。上述多个资源类型可以但不限于包括：中央处理器CPU密集型，内存密集型，磁盘密集型，网络密集型，其中，上述CPU密集型表示应用在实际运行的过程中CPU资源使用相对密集，上述内存密集型表示应用在实际运行的过程中内存资源使用相对密集，上述磁盘密集型表示应用在实际运行的过程中磁盘资源使用相对密集，上述网络密集型表示应用在实际运行的过程中网络通讯资源使用相对密集。上述多个资源类型分别对应于不同的特征指标，表2分别列出了多个资源类型与对应的特征指标。

表2

可选的，基于表2所示的多个(16个)特征指标，把历史采样时段内采集到的上述历史运行数据量化为16个维度的标准向量数据集，并对上述标准向量数据集进行最大最小值归一化处理，得到标准聚类数据集D1，根据资源类型将上述16个特征指标进行划分，定义为四类标准化向量，作为聚类结果标识向量，将上述四类标准化向量和上述标准聚类数据集D1作为完整的目标数据集D2，其中，上述四类标准化向量依次为：

CPU密集型：1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0

内存密集型：0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0

磁盘密集型：0 0 0 0 0 0 0 1 1 1 1 1 1 0 0 0

网络密集型：0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1

采用K均值聚类算法(即k-means++模型)对上述目标数据集D2进行聚类训练，得到聚类结果，聚类结果中四类标准化向量归属到不同的聚类簇，某一聚类簇下的数据分类结果为与其所属同一聚类簇的标准向量资源密集型类型一一对应。由此得到上述服务器集群内每一个应用对应的资源类型(即上述服务器集群中包括的服务器分别包括的第二应用对应的第二资源类型)。在得到上述服务器集群内每一个应用对应的资源类型之后，即可对应得到上述目标应用对应的上述目标资源类型，以及上述多个候选服务器分别包括的上述第一应用对应的上述第一资源类型。

本申请实施例中，通过步骤S102至步骤S108，可以达到综合目标应用的实际资源使用值和资源类型进行容器调度，提升集群资源使用率的同时，避免同类型资源争抢等问题的发生的目的，解决了相关技术中进行容器资源调度时按申请值调度，导致集群资源使用率不高，资源浪费严重的问题。进而达到了提升容器资源使用效率，减少资源浪费的效果。

基于上述实施例和可选实施例，本申请提出一种可选实施方式，图3是根据本申请实施例的一种可选的容器资源调度方法的处理流程图，如图3所示，该方法包括：

步骤S1，采集监控数据(即当前运行数据)。采集服务器集群内各应用以及其服务器运行一段时间的监控数据(如以五分钟作为一个采样周期，每五分钟采集一次数据)，通过采集表2所示的各指标特征数据，从CPU、内存、磁盘、网络等资源角度描述应用资源的使用情况，用以计算应用的资源使用趋势及资源类型。

步骤S2，应用资源画像。具体包括：服务器集群内各应用的资源使用趋势预测，资源类型确定，以及CPI健康值计算。

步骤S21，对于服务器集群内各应用的资源使用趋势预测，基于应用预设历史时间的资源使用数据，对应用的资源使用进行画像，对应用的资源使用趋势进行预测，得到目标应用在预测时段对应的预测资源使用数据。

步骤S22，对于服务器集群内各应用的资源类型确定，将服务器集群内各应用按资源消耗情况划分为CPU密集型，内存密集型，网络密集型、磁盘IO密集型(如磁盘密集型)等；选取每种类型各若干个特征指标(如表2所示的16个特征指标)，通过聚类算法计算每个应用的资源类型，自定义调度器进行调度时，根据不同类型进行均衡化筛选，避免将多个同种资源密集型的应用Pod调度到一个服务器节点node上，从而降低出现资源瓶颈的概率。

步骤S23，对于服务器集群内各应用的目标平均指令周期数计算，首先采用移动平均法对获取到的历史采样周期内各应用的初始平均指令周期数进行第一处理，剔除初始平均指令周期数异常值和毛刺点，得到第一平均指令周期数，再基于拉依达准则对获取到的第一平均指令周期数进行第二处理，即基于拉依达准则计算出阈值线，作为CPI健康阈值上下界，最终筛选得到各应用对应的目标平均指令周期数。

步骤S3，为服务器集群中各应用设置高低优先级(根据应用的重要程度)，在资源发生干扰时使用。

步骤S4，基于上述实际资源使用值与上述预测资源使用数据，得到目标应用从历史某个时间点到未来一段时间的资源使用曲线，将上述资源使用曲线中资源使用的99线(99％的点)对应的值，作为上述实际资源使用值。

步骤S5，在服务器集群中的任意一个应用(即目标应用)申请变更时，由目标应用发起的投产动作，此时会重启目标应用对应的目标应用容器，可以对目标应用容器进行重新调度，本调度器对目标应用容器进行重新调度，按优化后的资源量对目标应用容器进行迁移，具体为：

步骤S51，在对目标应用容器进行调度时，考虑服务器集群中各服务器节点上已部署的应用的资源类型，将目标应用容器调度至不存在与该目标应用容器调度相同资源类型的服务器节点上。即根据是否存在与目标应用容器资源类型相同的应用对服务器节点进行评分，相同类型的应用数量越多，对应的服务器节点评分则越低，由此达到尽量避免相同类型的应用调度到同一个服务器节点上，造成同类型资源争抢。

步骤S52，在对目标应用容器进行调度时，考虑尽可能填满服务器资源，即将目标应用容器调度至与该目标应用的实际资源使用值最为接近的第一候选服务器，调度时考虑尽可能填满服务器资源，将所有应用容器调度到尽可能少的服务器上，从而达到服务器资源利用率提升的目的。

步骤S6，应用调度完成后，在运行过程中，步骤S2中的应用资源画像模块会定期为应用进行计算，由agent从资源画像取预测运行数据，当预测运行数据发现未来一段时间，应用资源使用上升，服务器节点资源可能会不足，则会发起重调度，提前对优先级最低的应用进行迁移，减少节点的负载，从而避免了应用资源不足而影响业务的问题。

步骤S7，当一个节点调度了更多的资源之后，有可能造成应用间的相互干扰，导致应用业务受影响，由步骤S2应用资源画像的CPI健康值可以判断，当某个高优先级应用的CPI值连续N个周期(可配置)大于CPI健康值时，则可以判断该应用受到了影响，则需要对低优先级应用进行主动移出该服务器节点，重新调度到其他压力较小的服务器节点上。

需要说明的是，在本申请实施例中，相比原生调度策略，相同服务器节点下可调度更多的容器，从而提升集群节点的资源利用率；并且相同服务器节点上，尽可能的避免了相同资源类型部署，降低服务器节点资源争抢概率，减少了热点问题的发生。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请实施例还提供了一种容器资源调度装置，需要说明的是，本申请实施例的容器资源调度装置可以用于执行本申请实施例所提供的用于容器资源调度方法。以下对本申请实施例提供的容器资源调度装置进行介绍。

图4是根据本申请实施例的容器资源调度装置的示意图。如图4所示，该装置包括：第一获取模块400、第一确定模块402、第二获取模块404、第二确定模块406，其中：

上述第一获取模块400，用于获取目标应用对应的实际资源使用值，以及上述目标应用对应的目标资源类型；

上述第一确定模块402，连接于上述第一获取模块400，用于基于上述实际资源使用值，从服务器集群中确定出上述目标应用的目标应用容器对应的候选服务器，其中，上述服务器集群包括多个服务器；

上述第二获取模块404，连接于上述第一确定模块402，用于在上述候选服务器为多个的情况下，获取多个候选服务器分别对应的第一资源可分配值，上述多个候选服务器分别包括的第一应用，以及对应第一应用的第一资源类型；

上述第二确定模块406，连接于上述第二获取模块404，用于基于上述目标资源类型，上述第一资源可分配值和上述第一资源类型，从上述多个候选服务器中确定出上述目标应用容器对应的目标服务器。

通过本申请，通过设置上述第一获取模块400，用于获取目标应用对应的实际资源使用值，以及上述目标应用对应的目标资源类型；上述第一确定模块402，连接于上述第一获取模块400，用于基于上述实际资源使用值，从服务器集群中确定出上述目标应用的目标应用容器对应的候选服务器，其中，上述服务器集群包括多个服务器；上述第二获取模块404，连接于上述第一确定模块402，用于在上述候选服务器为多个的情况下，获取多个候选服务器分别对应的第一资源可分配值，上述多个候选服务器分别包括的第一应用，以及对应第一应用的第一资源类型；上述第二确定模块406，连接于上述第二获取模块404，用于基于上述目标资源类型，上述第一资源可分配值和上述第一资源类型，从上述多个候选服务器中确定出上述目标应用容器对应的目标服务器，达到了综合目标应用的实际资源使用值和资源类型进行容器调度，提升集群资源使用率的同时，避免同类型资源争抢等问题的发生的目的，解决了相关技术中进行容器资源调度时按申请值调度，导致集群资源使用率不高，资源浪费严重的问题。进而达到了提升容器资源使用效率，减少资源浪费的效果。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，例如，对于后者，可以通过以下方式实现：上述各个模块可以位于同一处理器中；或者，上述各个模块以任意组合的方式位于不同的处理器中。

此处需要说明的是，上述第一获取模块400、第一确定模块402、第二获取模块404、第二确定模块406对应于实施例中的步骤S102至步骤S108，上述模块与对应的步骤所实现的实例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在计算机终端中。

需要说明的是，本实施例的可选或优选实施方式可以参见实施例中的相关描述，此处不再赘述。

上述容器资源调度装置包括处理器和存储器，上述单元等均作为程序单元存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。

处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来(本申请的目的)。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。

本申请实施例提供了一种计算机可读存储介质，其上存储有程序，该程序被处理器执行时实现上述容器资源调度方法。

本申请实施例提供了一种处理器，上述处理器用于运行程序，其中，上述程序运行时执行上述容器资源调度方法。

如图5所示，本申请实施例提供了一种电子设备，该电子设备10包括处理器、存储器及存储在存储器上并可在处理器上运行的程序，处理器执行程序时实现以下步骤：获取目标应用对应的实际资源使用值，以及上述目标应用对应的目标资源类型；基于上述实际资源使用值，从服务器集群中确定出上述目标应用的目标应用容器对应的候选服务器，其中，上述服务器集群包括多个服务器；在上述候选服务器为多个的情况下，获取多个候选服务器分别对应的第一资源可分配值，上述多个候选服务器分别包括的第一应用，以及对应第一应用的第一资源类型；基于上述目标资源类型，上述第一资源可分配值和上述第一资源类型，从上述多个候选服务器中确定出上述目标应用容器对应的目标服务器。本文中的设备可以是服务器、PC、PAD、手机等。

本申请还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行初始化有如下方法步骤的程序：获取目标应用对应的实际资源使用值，以及上述目标应用对应的目标资源类型；基于上述实际资源使用值，从服务器集群中确定出上述目标应用的目标应用容器对应的候选服务器，其中，上述服务器集群包括多个服务器；在上述候选服务器为多个的情况下，获取多个候选服务器分别对应的第一资源可分配值，上述多个候选服务器分别包括的第一应用，以及对应第一应用的第一资源类型；基于上述目标资源类型，上述第一资源可分配值和上述第一资源类型，从上述多个候选服务器中确定出上述目标应用容器对应的目标服务器。

可选的，上述计算机程序产品还适于执行初始化有如下方法步骤的程序：。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。