容器调度方法、容器调度装置、存储介质和电子设备与流程

1.本公开涉及云计算技术领域，尤其涉及一种容器调度方法、装置、存储介质和电子设备。


背景技术：

2.网元部署逐渐从虚拟机(virtual machine，vm)形态向容器形态演进，开始以pod(封装了应用程序的一个或多个容器)的形式部署于已有的节点资源上。相关技术中，在多资源多用户的情况下，难以对容器进行有效地调度，导致资源浪费。


技术实现要素：

3.本公开提供了一种容器调度方法、装置、存储介质和电子设备，以在一定程度上解决相关技术问题中资源浪费的问题。
4.第一方面，本公开一个实施例提供了一种容器调度方法，包括：
5.获取目标集群的待调度容器组列表，所述待调度容器组列表包括一个或多个待调度容器组，所述目标集群包括多个节点，所述节点用于运行所述目标集群的容器组；
6.确定所述待调度容器组对应各节点的主导资源占比和所述待调度容器组对各节点的资源浪费程度；
7.基于所述主导资源占比和所述资源浪费程度，从所述各节点中确定目标节点，并将所述待调度容器组调度至所述目标节点。
8.在本公开一个可选的实施例中，节点提供至少两种资源；所述确定待调度容器组对各节点的资源浪费程度，包括：
9.获取所述待调度容器组的历史负载数据；
10.基于所述待调度容器组的历史负载数据，确定所述待调度容器组对各节点上各种资源的使用率；
11.基于所述待调度容器组对各节点上各种资源的使用率，确定所述待调度容器组对各节点的资源浪费程度。
12.在本公开一个可选的实施例中，基于所述待调度容器组的历史负载数据，确定所述待调度容器组对各节点上各种资源的使用率，包括：
13.基于所述待调度容器组的历史负载数据，确定所述待调度容器组各种资源的需求量；
14.将所述待调度容器组各种资源的需求量和所述节点提供的各种资源的总量的比值，确定为所述待调度容器组对各节点上各种资源的使用率。
15.在本公开一个可选的实施例中，基于所述待调度容器组对各节点上各种资源的使用率，确定所述待调度容器组对各节点的资源浪费程度，包括：
16.对所述待调度容器组对所述节点上各种资源的使用率进行加和；
17.将加和结果和所述节点提供的资源种类数的比值，确定为所述待调度容器组对所
述节点总资源的平均使用率；
18.基于所述待调度容器组对所述节点提供的各种资源的使用率和所述待调度容器组对所述节点总资源的平均使用率，确定所述待调度容器组对各节点的资源浪费程度。
19.在本公开一个可选的实施例中，基于所述主导资源占比和所述资源浪费程度，确定目标节点，并将所述待调度容器组调度至所述目标节点，包括：
20.从所述待调度容器组列表中选取主导资源占比最小的待调度容器组，并将对应的节点确定为预选节点；
21.在所述预选节点的主导资源存在可分配资源的情况下，确定所述待调度容器组对所述预选节点的资源浪费程度是否满足预设调度条件；
22.在所述待调度容器组对所述预选节点的资源浪费程度满足所述预设调度条件的情况下，将所述预选节点作为目标节点，并将所述待调度容器组调度至所述目标节点。
23.在本公开一个可选的实施例中，上述容器调度方法，还包括：
24.在所述目标集群的应用程序满足预设调整条件的情况下，根据最优副本数对所述容器组的副本进行调整；其中，所述最优副本数是根据历史负载数据确定的。
25.在本公开一个可选的实施例中，上述最优副本数通过以下步骤确定：
26.获取目标集群内各容器组的历史负载数据；其中，所述历史负载数据至少包括两种资源的负载数据；
27.基于所述历史负载数据，确定运行所述应用程序的容器组的最优副本数，以作为所述应用程序对应的最优副本数
28.第二方面，本公开一个实施例提供了一种容器调度装置，包括：
29.列表获取模块，用于获取目标集群的待调度容器组列表；所述待调度容器组列表包括一个或多个待调度容器组，所述目标集群包括多个节点，所述节点用于运行所述目标集群的容器组。
30.资源浪费程度确定模块，用于确定所述待调度容器组对应各节点的主导资源占比和所述待调度容器组对各节点的资源浪费程度；
31.容器调度模块，用于基于所述主导资源占比和所述资源浪费程度，从所述各节点中确定目标节点，并将所述待调度容器组调度至所述目标节点。
32.第三方面，本公开一个实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述容器调度方法。
33.第四方面，本公开一个实施例提供了一种电子设备，包括：处理器；存储器，用于存储处理器的可执行指令；其中，处理器配置为经由执行可执行指令来执行上述容器调度方法。
34.本公开的技术方案具有以下有益效果：
35.上述容器调度方法，首先，获取目标集群的待调度容器组列表，所述待调度容器组列表包括一个或多个待调度容器组，所述目标集群包括多个节点，所述节点用于运行所述目标集群的容器组；其次，确定所述待调度容器组对应各节点的主导资源占比和所述待调度容器组对各节点的资源浪费程度；最后，基于所述主导资源占比和所述资源浪费程度，从所述各节点中确定目标节点，并将所述待调度容器组调度至所述目标节点；如此，1)本公开全面考虑了各种资源，根据资源占比确定主导资源，因此，不同待调度容器组对应不同节点
的主导资源可能不同，即使同一待调度容器组，对应不同节点的主导资源也可能不同，在一定程度上克服了相关技术中基于单一资源进行资源分配导致资源浪费的问题；2)本公开结合待调度容器组对应各节点的主导资源占比和待调度容器组对各节点的资源浪费程度，对待调度容器组进行调度；而不仅仅依赖于主导资源占比进行资源调度，使得目标集群的节点的资源分配更加均衡。
36.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
37.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施方式，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
38.图1示出本示例性实施方式中一种容器调度方法在一种应用场景下的网络架构示意图；
39.图2示出本示例性实施方式中一种容器调度方法的流程图；
40.图3示出本示例性实施方式中一种容器调度方法中确定资源浪费程度的流程图；
41.图4示出本示例性实施方式中一种容器调度方法中确定资源浪费程度的流程图；
42.图5示出本示例性实施方式中一种容器调度方法中确定资源浪费程度的流程图；
43.图6示出本示例性实施方式中一种容器调度方法中调度待调度容器组的流程图；
44.图7示出本示例性实施方式中一种容器调度方法中调整容器组副本的流程图；
45.图8示出本示例性实施方式中一种容器调度装置的结构示意图；
46.图9示出本示例性实施方式中一种电子设备的结构示意图。
具体实施方式
47.现在将参考附图更全面地描述示例性实施方式。然而，示例性实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例性实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。
48.此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
49.附图中所示的流程图仅是示例性说明，不是必须包括所有的步骤。例如，有的步骤
还可以分解，而有的步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
50.网元部署逐渐从虚拟机(virtual machine，vm)形态向容器形态演进，开始以pod(封装了应用程序的一个或多个容器)的形式部署于已有的节点资源上，而kubernetes集群内部对pod的调度是基于kube-scheduler的一系列默认调度策略进行的，该调度策略针对使用资源的权重，采用了最简单的1:1和均衡模式，容易造成资源浪费。
51.其次，在承载云网系统的数据中心以pod承载网元后，在实现pod的多副本承载网元时，为解决上述问题，用户在首次部署服务或者根据经验所设置的minreplicas(最小副本数)和maxreplicas(最大副本数)并不准确。当集群低负载时，即使运行中的应用副本数为minreplicas，云网资源利用率依然较低。
52.综上，相关技术中，在多资源多用户情况下，通常基于单一资源进行资源分配，而用户对资源存在需求差异，由单一资源拓展的资源分配方法没有考虑到用户对各种资源的需求差异，容易造成节点某种资源使用过多而其他种类的资源使用过少的不良状态，造成了节点资源的浪费。
53.鉴于上述问题，本公开实施例提供了一种容器调度方法，以下对本公开实施例提供的容器调度方法的应用环境作简单介绍：
54.请参见图1，本公开实施例提供的容器调度方法的一种应用场景下的系统架构100，该系统架构100至少包括：master101、node102、资源调度单元103和etcd104。
55.其中，master101为集群的控制平面，负责集群的决策(管理)；master101包括：api server1011：是资源操作的唯一入口，用于接收用户输入的命令，提供认证、授权、api注册和发现等机制；scheduler1012：负责集群资源调度，按照预定的调度策略将pod调度到响应的node节点上；controllermanager1013：负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等。
56.node102包括：kubelet1021：负责维护容器的生命周期，即，通过控制docker，来创建、更新、销毁容器；kubeproxy1022：负责提供集群内部的服务发现和负载均衡；pod1023：kubernetes的最小控制单元，容器都是运行在pod中，一个pod可以包括一个或者多个容器。
57.资源调度单元103包括：资源均衡调度模块1031：用于对调度方法进行扩展，根据算法计算出每个节点的均衡得分后，将pod绑定到均衡得分最高的节点上；资源调度模块1032：用于通过资源调度模型对资源历史负载数据进行处理，得到最优副本数，提供给伸缩模块作为配置参数；监控模块1033：用于对容器集群中的各种资源进行监控，定期采集pod的负载数据，并存储到数据库中。
58.etcd104：负责存储集群中各种资源对象的信息。node102为集群的数据平面，负责为容器提供运行环境。
59.下面以上述资源调度单元103为执行主体，将该容器调度方法应用于上述资源均衡调度模块1031为例进行举例说明。请参见图2，本公开实施例提供的容器调度方法包括如下步骤201至步骤203：
60.步骤201：获取目标集群的待调度容器组列表。
61.其中，待调度容器组列表包括一个或多个待调度容器组，目标集群包括多个节点，节点用于运行目标集群的容器组。
62.目标集群是容器集群，比如：kubernetes集群等；这里，目标集群主要包括两个部分：一个master节点(主节点)和一群node节点(计算节点)；其中，每个node节点可以运行一个或多个pod，而一个pod可以运行一个或多个封装了应用程序的容器，因此，一个pod可以运行一个应用程序，也可以运行多个应用程序；当然，一个应用程序也可以由多个pod运行。
63.待调度容器组列表包括一个或多个待调度容器组；其中，容器组是实现业务功能的基本单元，例如可以是kubernetes中的pod。容器组代表了独立的应用程序运行实例，由一个或多个容器组成；在一些实施例中，待调度容器组可以理解为待调度pod；这是因为，pod是目标集群(比如：kubernetes集群)的最小控制单元。在一些实施例中，kubernetes集群内部对pod的调度是基于kube-scheduler的一系列默认调度策略展开的，待调度容器组列表可以理解为基于kube-scheduler的一系列默认调度策略对pod进行调度时生成的列表。
64.步骤202：确定待调度容器组对应各节点的主导资源占比和待调度容器组对各节点的资源浪费程度。
65.待调度容器组对应各节点的主导资源占比是指，待调度容器组各种资源需求量在节点各种资源供给量中的占比，哪种资源的占比高，则将该资源确定为主导资源，其占比为主导资源占比。
66.主导资源占比因待调度容器组对各种资源的需求量和节点对各种资源的提供量的不同而不同，比如：待调度容器组列表包括待调度容器组a和待调度容器组b，目标集群包括节点a和节点b，资源包括cpu和内存两种资源，待调度容器组a对两种资源的需求量为(1cpu，4gb)，待调度容器组b对两种资源的需求量为(3cpu，8gb)，节点a对两种资源的提供量(可分配量)是(9cpu，18gb)，节点b对两种资源的提供量(可分配量)是(7cpu，10gb)；那么，待调度容器组a对节点a的两种资源占比为(1/9，4/18)，对节点b的两种资源占比为(1/7，4/10)；待调度容器组b对节点a的两种资源占比为(3/9，8/18)，对节点b的两种资源占比为(3/7，8/10)；因此，待调度容器组a对应节点a的主导资源是内存(因为4/18大于1/9)，且主导资源占比为4/18，对应节点b的主导资源也是内存(因为4/10大于1/7)，且主导资源占比为4/10；待调度容器组b对应节点a的主导资源是内存(因为8/18大于3/9)，且主导资源占比为8/18，对应节点b的主导资源也是内存(因为8/10大于3/7)，且主导资源占比为8/10。
67.资源浪费程度可以采用资源浪费指数表征，资源浪费指数越高，说明资源浪费程度越高；资源浪费指数越低，说明资源浪费程度越低。资源浪费指数可以根据节点上各类资源的使用率确定；因此，资源浪费指数(资源浪费程度)能够说明节点上各种资源分配的均衡程度；资源浪费指数越高，说明节点上各种资源分配的越均衡；资源浪费指数越低，说明节点上各种资源分配的越失衡，极端情况下，可能出现木桶效应。
68.由于待调度容器组列表包括一个或多个待调度容器组，因此，步骤202确定的是待调度容器组列表包括的所有待调度容器组对应各节点的主导资源占比和所有待调度容器组对各节点的资源浪费程度。
69.步骤203：基于主导资源占比和资源浪费程度，从各节点中确定目标节点，并将待调度容器组调度至目标节点。
70.其中，由于待调度容器组列表包括一个或多个待调度容器组，这里，当待调度容器组列表包括多个待调度容器组时，优先分配主导资源占比最小的待调度容器组；比如：上述
主导资源占比最小的是4/18，而4/18是待调度容器组a对应节点a的主导资源占比，因此，优先调度待调度容器组a，并将对应的节点a作为预选节点。
71.资源浪费程度用于评价目标节点的资源分配的均衡程度，资源浪费程度越高，说明资源分配的均衡程度越低；资源浪费程度越低，说明资源分配的均衡程度越高；在一些实施例中，可以根据历史经验设置阈值，在预选节点的资源浪费程度小于或等于该阈值时，将预选节点确定为目标节点，并将待调度容器组调度至目标节点。
72.本公开实施例提供的容器调度方法，首先，获取目标集群的待调度容器组列表，待调度容器组列表包括一个或多个待调度容器组，目标集群包括多个节点，节点用于运行目标集群的容器组；其次，确定待调度容器组对应各节点的主导资源占比和待调度容器组对各节点的资源浪费程度；最后，基于主导资源占比和资源浪费程度，从各节点中确定目标节点，并将待调度容器组调度至目标节点；如此，由于结合待调度容器组对应各节点的主导资源占比和待调度容器组对各节点的资源浪费程度，对待调度容器组进行调度；因此，使得目标集群的节点的资源分配更加均衡。
73.请参见图3，在本公开一个可选实施例中，节点提供至少两种资源，上述步骤202确定待调度容器组对各节点的资源浪费程度，包括如下步骤301至步骤303：
74.步骤301：获取待调度容器组的历史负载数据。
75.其中，历史负载数据可以是任意一段历史时间内的负载数据。本公开对于负载数据的具体类别不做限定，例如可以包括：cpu使用数据(如cpu占用率)、内存使用数据(如内存占用率)、磁盘使用数据(如磁盘占用率)、网络带宽使用数据(如带宽使用率)。
76.历史负载数据的获取可以通过定期获取监控点数据得到；比如：对于每个pod，每分钟获取一次监控点数据，从而得到每个pod的负载数据。
77.步骤302：基于待调度容器组的历史负载数据，确定待调度容器组对各节点上各种资源的使用率。
78.其中，根据待调度容器组的历史负载数据可以确定待调度容器组对各类资源的需求量；在一些实施例中，可以根据平均日负载峰值确定，也可以根据最大日负载峰值确定，此处不做限定。
79.节点上各种资源的使用率可以通过待调度容器组对各种资源的需求量和节点提供的各种资源的总量确定。
80.步骤303：基于待调度容器组对各节点上各种资源的使用率，确定待调度容器组对各节点的资源浪费程度。
81.资源使用率与资源浪费程度呈反比；资源使用率越高，资源浪费程度越低；资源使用率越低，资源浪费程度越高。
82.基于图3的方法，能够基于历史负载数据确定出待调度容器组对各节点的资源浪费程度；待调度容器组的历史负载数据反映了待调度容器组的实际工作状况，基于该历史负载数据计算待调度容器组对各节点的资源浪费程度，能够使资源浪费程度的计算结果适应于实际情况，因此更加准确。
83.请参见图4，在本公开一个可选实施例中，上述步骤302基于待调度容器组的历史负载数据，确定待调度容器组对各节点上各种资源的使用率，包括如下步骤401和步骤402：
84.步骤401：基于待调度容器组的历史负载数据，确定待调度容器组各种资源的需求
量。
85.其中，待调度容器组各种资源的需求量，比如：有a种资源，那么，就有a个需求量。在一些实施例中，待调度容器组各种资源的需求量可以通过历史负载数据的平均日负载峰值确定；这里，平均日负载峰值可以通过对日负载峰值求平均得到；其中，日负载峰值可以直接采用日负载数据中的最高数据，也可以去掉日负载数据中最高的x个数据后，将其余数据中的较高数据作为日负载峰值，此处不做限定。
86.步骤402：将待调度容器组各种资源的需求量和节点提供的各种资源的总量的比值，确定为待调度容器组对各节点上各种资源的使用率。
87.其中，节点提供的各种资源的总量，比如：节点提供a种资源，那么，一共有a个资源总量。
88.上述步骤401确定出待调度容器组各种资源的需求量后，按照资源和节点，将待调度容器组对该节点上该资源的需求量与该节点提供的该资源的总量的比值，确定为待调度容器组对该节点上该资源的使用率；比如：有a种资源，b个节点，待调度容器组对(第i个节点)的第j种资源的需求量为g
ij
，第i个节点提供的第j种资源的总量为h
ij
，那么，第i个节点上第j种资源的使用率为比如：待调度容器组对节点i上资源j(比如：cpu)的需求量为3，节点i提供的资源j的总量为9，那么，待调度容器组对节点i上资源j的使用率为3/9＝1/3；按照上述过程，即可得到待调度容器组对各节点上各种资源的使用率。
89.基于图4的方法，能够基于历史负载数据确定出待调度容器组对各节点上各种资源的使用率；由于是基于历史负载数据确定出的待调度容器组对各节点上各种资源的使用率，因此，结果更加准确；进而，能够得到准确的待调度容器组对各节点的资源浪费程度。
90.请参见图5，在本公开一个可选实施例中，上述步骤303基于待调度容器组对各节点上各种资源的使用率，确定待调度容器组对各节点的资源浪费程度，包括如下步骤501至步骤503：
91.步骤501：对待调度容器组对节点上各种资源的使用率进行加和。
92.对于节点i，上述步骤可以用公式表示；即，将节点i上每种资源的使用率相加；其中，a表示资源种类数。
93.步骤502：将加和结果和节点提供的资源种类数的比值，确定为待调度容器组对节点总资源的平均使用率。
94.对于节点i，节点总资源的平均使用率可以采用如下公式(1)计算：
[0095][0096]
其中，j表示第j种资源。
[0097]
步骤503：基于待调度容器组对节点提供的各种资源的使用率和待调度容器组对节点总资源的平均使用率，确定待调度容器组对各节点的资源浪费程度。
[0098]
资源浪费程度可以通过资源浪费指数确定；其中，资源浪费指数w可以通过如下公式(2)计算：
[0099][0100]
其中，b表示目标集群的节点数。
[0101]
即，首先，基于待调度容器组对节点提供的各种资源的使用率和待调度容器组对节点总资源的平均使用率，确定节点上各种资源的使用率与总资源的平均使用率之间的误差(即)；其次，基于误差和目标集群内的节点数，确定待调度容器组对节点的资源浪费指数(即w)；最后，基于资源浪费指数，确定节点的资源浪费程度，得到待调度容器组对各节点的资源浪费程度(即，根据上述过程确定每一节点的资源浪费程度，进而，得到待调度容器组对各节点的资源浪费程度)。
[0102]
资源浪费程度与资源浪费指数呈正比，表示资源分配的均衡程度；资源浪费指数越大，资源浪费程度越大，表示资源分配越不均衡；资源浪费指数越小，资源浪费程度越小，表示资源分配越均衡。
[0103]
基于图5的方法，能够确定出待调度容器组对各节点的资源浪费程度，以指导调度过程，使得调度后节点上的资源分配更加均衡。
[0104]
请参见图6，在本公开一个可选实施例中，上述步骤203基于主导资源占比和资源浪费程度，在各节点中确定目标节点，并将待调度容器组调度至目标节点，包括如下步骤601至步骤603：
[0105]
步骤601：从待调度容器组列表中选取主导资源占比最小的待调度容器组，并将对应的节点确定为预选节点。
[0106]
其中，在步骤601之前，可以根据主导资源占比对待调度容器组列表中的待调度容器组进行排序，进而，从中选取主导资源占比最小的待调度容器组；比如：第s个待调度pod对应第1个节点的主导资源占比d
s1
最小，那么，将第s个待调度pod作为待调度容器组，将第1个节点作为预选节点。在一些实施例中，当主导资源占比最小的待调度容器组存在两个或两个以上时，选取第二主导资源占比最小的待调度容器组。
[0107]
步骤602：在预选节点的主导资源存在可分配资源的情况下，确定待调度容器组对预选节点的资源浪费程度是否满足预设调度条件。
[0108]
主导资源是否可分配可以通过主导资源的资源总量和主导资源的已分配资源量确定，即，主导资源的资源总量与主导资源的已分配资源量之差(主导资源的剩余资源量)，如果该差值大于0，说明主导资源存在可分配资源；如果该差值小于或等于0，说明主导资源不存在可分配资源。
[0109]
预设调度条件，可以根据经验设置预设阈值，将资源浪费程度与预设阈值之间的大小关系，确定为预设调度条件。
[0110]
步骤603：在待调度容器组对预选节点的资源浪费程度满足预设调度条件的情况下，将预选节点作为目标节点，并将待调度容器组调度至目标节点。
[0111]
由于资源浪费程度与资源分配的均衡程度呈反比，因此，当预选节点的资源浪费程度小于预设阈值时，视为满足预设调度条件(表示资源分配较为均衡)；当预选节点的资源浪费程度大于预设阈值时，视为不满足预设调度条件。在一些实施例中，当预选节点的资
源浪费程度不满足调度条件时，可以返回步骤202，以第二主导资源进行调度。
[0112]
基于图6的方法，能够将待调度容器组列表中的每一待调度容器组调度至对应的目标节点，使得目标集群节点的资源分配更加均衡。
[0113]
此外，在上述方法之后，还可以包括如下步骤和：
[0114]
判断目标节点上的待调度容器组的副本数是否达到最优副本数。
[0115]
在待调度容器组的副本数达到最优副本数的情况下，从待调度容器组列表中删除待调度容器组。
[0116]
其中，最优副本数可以是基于历史负载数据确定的，也可以直接采用deployment(kubernetes中用来管理发布的控制器)默认设置的数值；一般地，deployment默认设置的数值是用户根据经验所设置的。
[0117]
在本公开一个可选实施例中，上述容器调度方法，还包括如下步骤：
[0118]
在目标集群的应用程序满足预设调整条件的情况下，根据最优副本数对容器组的副本进行调整。
[0119]
其中，最优副本数是根据历史负载数据确定的。
[0120]
封装应用程序的容器运行在pod中，一般地，一个pod可以运行一个应用程序，也可以运行多个应用程序；当然，一个应用程序也可以由多个pod运行。
[0121]
无论是pod还是容器，其本质都是服务于应用程序。在应用程序对各种资源的使用率较高时，可以动态扩容以减轻各pod的压力；当应用程序对各种资源的使用率较低时，可以动态缩容以减少资源浪费。
[0122]
本公开提供的调度方法的主要目的是减少资源浪费，因此，预设调整条件可以理解为触发缩容操作的条件；比如：应用程序处于低负载状态，且副本数大于预设值。
[0123]
该步骤可以在步骤201之前，也可以在步骤203之后，此处不做限定。
[0124]
请参见图7，在本公开一个可选实施例中，上述步骤在目标集群的应用程序满足预设调整条件的情况下，根据最优副本数对容器组的副本进行调整，包括如下步骤701和步骤702：
[0125]
步骤701：获取目标集群内各容器组的历史负载数据。
[0126]
其中，历史负载数据至少包括两种资源的负载数据。
[0127]
历史负载数据包括：cpu数据、内存数据、disk数据等。
[0128]
历史负载数据可以通过监控模块得到，比如：对于每一监控点，基于预设间隔(比如：一分钟)获取负载数据。
[0129]
步骤702：基于历史负载数据，确定运行应用程序的容器组的最优副本数，以作为应用程序对应的最优副本数。
[0130]
其中，最优副本数可以通过如下公式(3)计算：
[0131][0132]
其中，d/e/f为预设值且0＜d/e/f＜1，roundup表示向上取整；
m为pod总数；p
pod
通过从每天的单pod负载数据中去掉最高的x个数据点之后，将剩余数据点中的较高者作为p
pod
。
[0133]
在一些实施例中，上述步骤701和步骤702还可以训练资源调度模型来计算最优副本数，此处不做限定。
[0134]
基于图7的方法，能够基于历史数据确定出最优副本数，确定处的最优副本数更加准确，克服了相关技术中用户根据经验确定最优副本数不准确的问题。
[0135]
请参见图8，为了实现上述容器调度方法，本公开的一个实施例中提供一种容器调度装置800，应用于上述系统架构800。图8示出了容器调度装置800的示意性架构图，该容器调度装置800包括：列表获取模块801、资源浪费程度确定模块802、容器调度模块803，其中：
[0136]
列表获取模块801，用于获取目标集群的待调度容器组列表；
[0137]
其中，待调度容器组列表包括一个或多个待调度容器组，目标集群包括多个节点，节点用于运行目标集群的容器组。
[0138]
资源浪费程度确定模块802，用于确定待调度容器组对应各节点的主导资源占比和待调度容器组对各节点的资源浪费程度；
[0139]
容器调度模块803，用于基于主导资源占比和资源浪费程度，从各节点中确定目标节点，并将待调度容器组调度至目标节点。
[0140]
在一个可选的实施例中，节点提供至少两种资源，该资源浪费程度确定模块802用于，获取待调度容器组的历史负载数据；基于待调度容器组的历史负载数据，确定待调度容器组对各节点上各种资源的使用率；基于待调度容器组对各节点上各种资源的使用率，确定待调度容器组对各节点的资源浪费程度。
[0141]
在一个可选的实施例中，该资源浪费程度确定模块802用于，基于待调度容器组的历史负载数据，确定待调度容器组各种资源的需求量；将待调度容器组各种资源的需求量和节点提供的各种资源的总量的比值，确定为待调度容器组对各节点上各种资源的使用率。
[0142]
在一个可选的实施例中，该资源浪费程度确定模块802用于，对待调度容器组对节点上各种资源的使用率进行加和；将加和结果和节点提供的资源种类数的比值，确定为待调度容器组对节点总资源的平均使用率；基于待调度容器组对节点提供的各种资源的使用率和待调度容器组对节点总资源的平均使用率，确定待调度容器组对各节点的资源浪费程度。
[0143]
在一个可选的实施例中，该容器调度模块803用于，从待调度容器组列表中选取主导资源占比最小的待调度容器组，并将对应的节点确定为预选节点；在预选节点的主导资源存在可分配资源的情况下，确定待调度容器组对预选节点的资源浪费程度是否满足预设调度条件；在待调度容器组对预选节点的资源浪费程度满足预设调度条件的情况下，将预选节点作为目标节点，并将待调度容器组调度至目标节点。
[0144]
在一个可选的实施例中，该容器调度装置800还包括，副本确定模块，用于在目标集群的应用程序满足预设调整条件的情况下，根据最优副本数对容器组的副本进行调整；其中，最优副本数是根据历史负载数据确定的。
[0145]
在一个可选的实施例中，副本确定模块用于获取目标集群内各容器组的历史负载
数据；其中，历史负载数据至少包括两种资源的负载数据；
[0146]
基于历史负载数据，确定运行应用程序的容器组的最优副本数，以作为应用程序对应的最优副本数。
[0147]
本公开的示例性实施方式还提供了一种计算机可读存储介质，可以实现为一种程序产品的形式，其包括程序代码，当程序产品在终端设备上运行时，程序代码用于使终端设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。在一种实施方式中，该程序产品可以实现为便携式紧凑盘只读存储器(cd-rom)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
[0148]
程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
[0149]
计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
[0150]
可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、rf等等，或者上述的任意合适的组合。
[0151]
可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，程序设计语言包括面向对象的程序设计语言—诸如java、c 等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。在本公开实施例中，计算机可读存储介质中存储的程序代码被执行时可以实现如上容器调度方法中的任一步骤。
[0152]
本公开的示例性实施方式还提供一种电子设备。一般的，该电子设备可以包括处理器与存储器，存储器用于存储处理器的可执行指令，处理器配置为经由执行可执行指令来执行上述容器调度方法。
[0153]
下面以图9中的电子设备900为例，对该电子设备的构造进行示例性说明。
[0154]
如图9所示，电子设备900以通用计算设备的形式表现。电子设备900的组件可以包括但不限于：至少一个处理单元910、至少一个存储单元920、连接不同系统组件(包括存储单元920和处理单元910)的总线930。
[0155]
其中，存储单元存储有程序代码，程序代码可以被处理单元910执行，使得处理单元910执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。例如，处理单元910可以执行如图2所示的方法步骤等。
[0156]
存储单元920可以包括易失性存储单元，例如随机存取存储单元(ram)921和/或高速缓存存储单元922，还可以进一步包括只读存储单元(rom)923。
[0157]
存储单元920还可以包括具有一组(至少一个)程序模块925的程序/实用工具924，这样的程序模块925包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
[0158]
总线930可以包括数据总线、地址总线和控制总线。
[0159]
电子设备900也可以与一个或多个外部设备1000(例如键盘、指向设备、蓝牙设备等)通信，这种通信可以通过i/o接口940进行。电子设备900还可以通过网络适配器950与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器950通过总线930与电子设备900的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备900使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
[0160]
在本公开实施例中，终端设备中存储的程序代码被执行时可以实现如上容器调度方法中的任一步骤。
[0161]
应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的示例性实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
[0162]
所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施方式。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施方式仅被视为示例性的，本公开的真正范围和精神由权利要求指出。
[0163]
应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限定。