CN112015536A

CN112015536A - Kubernetes集群容器组调度方法、装置及介质

Info

Publication number: CN112015536A
Application number: CN202010889293.9A
Authority: CN
Inventors: 李龙峰; 张东
Original assignee: Beijing Inspur Data Technology Co Ltd
Current assignee: Beijing Inspur Data Technology Co Ltd
Priority date: 2020-08-28
Filing date: 2020-08-28
Publication date: 2020-12-01
Anticipated expiration: 2040-08-28
Also published as: CN112015536B

Abstract

本申请公开了一种基于多架构服务器部署Kubernetes集群的容器组调度方法、装置及计算机可读存储介质。其中，方法包括若Kubernetes集群设置原有调度策略，则按照原有调度策略将待处理容器组调度至相应节点处理。若Kubernetes集群没有设置原有调度策略，则根据预先基于运行业务情况设置参与容器组调度的指标阈值信息和Kubernetes集群各节点参与容器组调度的指标实时值，将待处理容器组调度至相应节点处理，实现Kubernetes集群下容器组的可控调度，有效提升基于多架构服务器部署Kubernetes集群下节点的高可用性和高稳定性，使得资源利用更加合理化。

Description

Kubernetes集群容器组调度方法、装置及介质

技术领域

本申请涉及云计算领域，特别是涉及一种基于多架构服务器部署Kubernetes集群的容器组调度方法、装置及计算机可读存储介质。

背景技术

Kubernetes或称为K8s为用于容器集群的自动化部署、扩容以及运维的开源平台，可管理云平台中多个主机上的容器化的应用，让基于多架构服务器部署容器化的应用简单并且高效。在容器技术时代，大量的业务应用场景通过Kubernetes容器编排技术上云，其中业务场景中创建容器组，可以通过Kubernetes集群自身的调度策略调度到适合的节点上进行创建。

在基于多架构服务器部署Kubernetes集群中，创建的容器组会根据Kubernetes集群自身的调度策略调度到相应的节点上去创建。然而Kubernetes集群节点根据调度策略达到饱和时，并非业务场景想要达到的状态；此外，Kubernetes调度策略不能满足当节点达到业务设置的某一阈值时，如节点CPU使用率达50％，停止在该节点上创建容器组的场景。还有尽可能在不影响master主节点应用的前提下，让所有节点容器组的调度、运行达到最优的状态。

鉴于此，如何克服相关技术中Kubernetes集群自身调度策略无法满足业务场景需求的缺陷，提升基于多架构服务器部署Kubernetes集群下节点的高可用性和高稳定性，使得资源利用更加合理化，是所属领域技术人员需要解决的技术问题。

发明内容

本申请提供了一种基于多架构服务器部署Kubernetes集群的容器组调度方法、装置及计算机可读存储介质，实现Kubernetes集群下容器组的可控调度，有效提升基于多架构服务器部署Kubernetes集群下节点的高可用性和高稳定性，使得资源利用更加合理化。

为解决上述技术问题，本发明实施例提供以下技术方案：

本发明实施例一方面提供了一种基于多架构服务器部署Kubernetes集群的容器组调度方法，包括：

若Kubernetes集群设置原有调度策略，按照所述原有调度策略将待处理容器组调度至相应节点处理；

若没有设置原有调度策略，根据预先基于运行业务情况设置参与容器组调度的指标阈值信息和所述Kubernetes集群各节点参与容器组调度的指标实时值，将所述待处理容器组调度至相应节点处理。

可选的，所述根据预先基于运行业务情况设置参与容器组调度的指标阈值信息和所述Kubernetes集群各节点参与容器组调度的指标实时值，将所述待处理容器组调度至相应节点处理包括：

预先基于所述Kubernetes集群所有节点参与容器组调度的指标实时信息和所述运行业务情况确定每个节点的节点运行状态值；

对所述Kubernetes集群的每个节点，判断当前节点的指标实时值是否低于相应指标阈值；

若所述当前节点的指标实时值不低于相应指标阈值，所述当前节点不参与容器组调度；若所述当前节点的指标实时值低于相应指标阈值，根据所述当前节点的指标实时值和所述运行业务情况确定调度合适度值；根据所述调度合适度值和所述当前节点的节点运行状态值确定所述当前节点的节点调度值；

将所述Kubernetes集群中节点调度值最大的节点作为调度所述待处理容器组的目标节点。

可选的，所述根据所述调度合适度值和所述当前节点的节点运行状态值确定节点调度值包括：

根据所述运行业务情况确定所述调度合适度值和所述节点运行状态值的权重值；

对每个节点，将所述当前节点的调度合适度值和节点运行状态值进行加权求和，得到所述当前节点的节点调度值。

可选的，所述基于运行业务情况设置参与容器组调度的指标阈值信息包括：

基于运行业务情况确定参与容器组调度的目标指标，并发送开启各目标指标的参与容器组调度开关的指令；

根据接收的阈值设置指令，设置各目标指标的指标阈值最大值和指标阈值限制值；所述指标阈值最大值用于衡量作为调度所述待处理容器组的目标节点的可能性，所述指标阈值限制值用于作为节点不能创建容器组的限制条件。

可选的，所述若没有设置原有调度策略之后，还包括：

若没有设置指标阈值信息，按照所述Kubernetes集群默认调度策略将所述待处理容器组调度至相应节点处理。

本发明实施例另一方面提供了一种基于多架构服务器部署Kubernetes集群的容器组调度装置，包括：

原有调度优先处理模块，用于若Kubernetes集群设置原有调度策略，按照所述原有调度策略将待处理容器组调度至相应节点处理；

自建策略处理模块，用于若没有设置原有调度策略，根据预先基于运行业务情况设置参与容器组调度的指标阈值信息和所述Kubernetes集群各节点参与容器组调度的指标实时值，将所述待处理容器组调度至相应节点处理。

可选的，所述自建策略处理模块包括：

指标信息采集子模块，用于实时采集所述Kubernetes集群中所有节点参与容器组调度的指标实时信息；

节点状态评价子模块，用于基于所述指标实时信息和所述运行业务情况确定所述Kubernetes集群各节点的节点运行状态值；

自建策略适用判断子模块，用于对所述Kubernetes集群的每个节点，判断当前节点的指标实时值是否低于相应指标阈值；

节点调度值计算子模块，用于若所述当前节点的指标实时值不低于相应指标阈值，所述当前节点不参与容器组调度；若所述当前节点的指标实时值低于相应指标阈值，根据所述当前节点的指标实时值和所述运行业务情况确定调度合适度值；根据所述调度合适度值和所述当前节点的节点运行状态值确定所述当前节点的节点调度值；

调度节点确定子模块，用于将所述Kubernetes集群中节点调度值最大的节点作为调度所述待处理容器组的目标节点。

可选的，所述自建策略处理模块包括阈值设置子模块，所述阈值设置子模块包括：

开关开启单元，用于基于运行业务情况确定参与容器组调度的目标指标，并发送开启各目标指标的参与容器组调度开关的指令；

设置单元，用于根据接收的阈值设置指令，设置各目标指标的指标阈值最大值和指标阈值限制值；所述指标阈值最大值用于衡量作为调度所述待处理容器组的目标节点的可能性，所述指标阈值限制值用于作为节点不能创建容器组的限制条件。

本发明实施例还提供了一种基于多架构服务器部署Kubernetes集群的容器组调度装置，包括处理器，所述处理器用于执行存储器中存储的计算机程序时实现如前任一项所述基于多架构服务器部署Kubernetes集群的容器组调度方法的步骤。

本发明实施例最后还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有基于多架构服务器部署Kubernetes集群的容器组调度程序，所述基于多架构服务器部署Kubernetes集群的容器组调度程序被处理器执行时实现如前任一项所述基于多架构服务器部署Kubernetes集群的容器组调度方法的步骤。

本申请提供的技术方案的优点在于，可以直接对基于运行业务所关注的、需要参与到容器组的指标设置所需阈值，并结合Kubernetes集群运行过程中各节点的指标实时信息作为业务自建调度策略，作为对Kubernetes集群已有调度策略的合理的补充，从而将Kubernetes集群容器组的原有调度策略和业务自建调度策略有效的结合起来，Kubernetes集群的节点可以达到业务上的最优且可以控制，实现Kubernetes集群下容器组的可控调度，有利于将容器组调度到最优的节点上处理，保持Kubernetes集群处于最佳状态，有效提升基于多架构服务器部署Kubernetes集群下节点的高可用性、高稳定性，使得资源利用更加合理化。

此外，本发明实施例还针对基于多架构服务器部署Kubernetes集群的容器组调度方法提供了相应的实现装置及计算机可读存储介质，进一步使得所述方法更具有实用性，所述装置及计算机可读存储介质具有相应的优点。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

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

图1为本发明实施例提供的一种基于多架构服务器部署Kubernetes集群的容器组调度方法的流程示意图；

图2为本发明实施例提供的另一种基于多架构服务器部署Kubernetes集群的容器组调度方法的流程示意图；

图3为本发明实施例提供的再一种基于多架构服务器部署Kubernetes集群的容器组调度方法的流程示意图；

图4为本发明实施例提供的基于多架构服务器部署Kubernetes集群的容器组调度装置的一种具体实施方式结构图；

图5为本发明实施例提供的基于多架构服务器部署Kubernetes集群的容器组调度装置的另一种具体实施方式结构图；

图6为本发明实施例根据一示例性实施例示出的一种基于多架构服务器部署Kubernetes集群的容器组调度原理示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面结合附图和具体实施方式对本发明作进一步的详细说明。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等是用于区别不同的对象，而不是用于描述特定的顺序。此外术语“包括”和“具有”以及他们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可包括没有列出的步骤或单元。

首先参见图1，图1为本发明实施例提供的一种基于多架构服务器部署Kubernetes集群的容器组调度方法的流程示意图，本发明实施例可包括以下内容：

S101：判断Kubernetes集群是否设置原有调度策略，若是，则执行S102，若否，则执行S103。

在本步骤中，Kubernetes集群的原有调度策略包括诸如节点调度、亲和性反亲和性、节点容忍度等调度方法，如果设置原有调度策略，则原有调度策略优先级最高，按照原有调度策略执行。其中，节点调度是指节点本身是否允许容器组调度到节点上创建的调度方法，亲和性反亲和性是指处理在业务上有关联或者排斥的容器组调度方法，节点容忍度是指节点排斥某一业务场景容器组的调度方法。在原有调度策略的节点调度过程中，不考虑运行业务想要达到状态的情况，原有调度策略设置后，对Kubernetes集群中各节点的调度均按照此策略执行，Kubernetes集群中的节点是指Kubernetes集群中的虚拟机或服务器资源。

S102：按照原有调度策略将待处理容器组调度至相应节点处理。

本申请的容器组是指Kubernetes集群中每个节点上运行的POD资源，待处理容器组为Kubernetes集群当前需要按照调度策略在合适节点上创建的容器组。按照调度策略确定待处理容器组创建的节点可称为目标节点，也即通过调度策略在Kubernetes集群中确定目标节点，然后将待处理容器组创建在目标节点上，由目标节点运行该容器组的POD资源并处理相关业务。

S103：根据预先基于运行业务情况设置参与容器组调度的指标阈值信息和Kubernetes集群各节点参与容器组调度的指标实时值，将待处理容器组调度至相应节点处理。

考虑到不同业务所关注需要参与到容器组调度的指标的情况不同，而S101步骤中的原有调度策略不区分业务类型，其并不能有效的满足业务上的场景。针对这种业务场景，可不设置原有调度策略，而是根据业务需求自建调度策略。其中，基于运行业务情况设置参与容器组调度的指标例如但并不限制于CPU使用率、内存使用率、网络IO、容器组使用率等，CPU使用率为指节点已使用CPU与节点CPU的比值，内存使用率为指节点已使用内存与节点内存的比值，容器组使用率为节点已创建容器组与节点建议创建容器组数的比值。本申请可提供指标设置界面，指标设置界面中包括指标类型填写框或指标类型选择条目、指标阈值的填写框，用户可根据实际业务情况去选择或填写运行业务情况设置参与容器组调度的指标，然后在对相应指标进行阈值设置。在自建调度策略中，用户先设置业务所关注需要参与到容器组调度的指标阈值，然后计算、采集、存储Kubernetes集群中CPU使用率、内存使用率、容器组使用率等调度过程中需要使用的相应指标的实时值，可将实时指标信息进行存储，以便调度过程中使用时直接调用，最后将设置的指标阈值、采集的指标数据实时信息有效的结合起来构建业务自建调度策略，使用业务自建调度策略将待处理容器组调度到最优的节点上处理。从而提高基于多架构服务器部署Kubernetes集群的高可用、高稳定、资源利用合理化的特性。

在本发明实施例提供的技术方案中，可以直接对基于运行业务所关注的、需要参与到容器组的指标设置所需阈值，并结合Kubernetes集群运行过程中各节点的指标实时信息作为业务自建调度策略，作为对Kubernetes集群已有调度策略的合理的补充，从而将Kubernetes集群容器组的原有调度策略和业务自建调度策略有效的结合起来，Kubernetes集群的节点可以达到业务上的最优且可以控制，实现Kubernetes集群下容器组的可控调度，有利于将容器组调度到最优的节点上处理，保持Kubernetes集群处于最佳状态，有效提升基于多架构服务器部署Kubernetes集群下节点的高可用性、高稳定性，使得资源利用更加合理化。

在上述实施例中，对于如何执行步骤S103并不做限定，本实施例中给出一种业务自建调度策略的构建及调度实时方法，请参阅图2及图3所示，可如下步骤：

预先基于Kubernetes集群所有节点参与容器组调度的指标实时信息和运行业务情况确定每个节点的节点运行状态值。

对Kubernetes集群的每个节点，判断当前节点的指标实时值是否低于相应指标阈值。

若当前节点的指标实时值不低于相应指标阈值，当前节点不参与容器组调度；若当前节点的指标实时值低于相应指标阈值，根据当前节点的指标实时值和运行业务情况确定调度合适度值；根据调度合适度值和当前节点的节点运行状态值确定当前节点的节点调度值。

将Kubernetes集群中节点调度值最大的节点作为调度待处理容器组的目标节点。

在本实施例中，获取当前集群节点存储的指标实时信息，将指标实时信息和设置的指标阈值信息进行对比，如果节点指标信息超过指标阈值限制信息，该节点调度被关闭；如果节点指标信息低于指标阈值限制信息，会参考业务情况得到一个分值，该分值即为调度合适度值；根据获取的指标信息参照业务情况，得到每个节点的一个评分，该评分值为节点运行状态值；根据节点得到的两个分值确定最终分值即节点调度值，然后根据得到的评分按照分值大小正序或倒序对节点进行排序，对于分值逐渐减小的排序方式，排在首位就是目标调度节点，对于分值逐渐减大的排序方式，排在末位就是目标调度节点。

作为一种可选的实施方式，可预先基于运行业务设置分数和指标数值之间的对应关系，例如可以表格形式展示，节点的指标实时值与相应指标阈值的比例值越大，所得分数越低，而至于节点的指标实时值与相应指标阈值的比例范围与该范围的分数值可根据运行业务情况进行设置，也可设置固定的表格，这均不影响本申请的实现，举例来说，若节点的指标实时值与相应指标阈值的比例值在第一范围(0，20％)，且第一范围的分数值为100分，调度合适度值为100分；若节点的指标实时值与相应指标阈值的比例值在第二范围(21％，40％)，且第二范围的分数值为80分，调度合适度值为80分；若节点的指标实时值与相应指标阈值的比例值在第三范围(41％，60％)，且第三范围的分数值为65分，调度合适度值为65分；若节点的指标实时值与相应指标阈值的比例值在第四范围(61％，80％)，且第三范围的分数值为40分，调度合适度值为40分；若节点的指标实时值与相应指标阈值的比例值在第四范围(81％，100％)，且第三范围的分数值为10分，调度合适度值为10分。同样的，可预先基于运行业务对每个节点设置分数参照表，各级别分数即节点运行状态值可根据每个节点各指标实时值的综合评价情况确定，举例来说，可设置7个级别分数，分别为100、85、60、45、10和0，对于100分这个级别，节点各指标的实时值与指标阈值的比值不超过20％，对于85分这个级别，节点至少存在一半指标的实时值与指标阈值的比值不超过20％，对于60分这个级别，节点各指标的实时值与指标阈值的比值不超过40％，对于40分这个级别，节点各指标的实时值与指标阈值的比值不超过65％，对于10分这个级别，节点各指标的实时值与指标阈值的比值不超过85％，对于0分这个级别，节点各指标的实时值与指标阈值的比值超过85％。所属领域技术人员可根据实际情况进行确定，本申请对此不作任何限定。

在本实施例的另一些实施方式中，根据调度合适度值和当前节点的节点运行状态值确定节点调度值可包括：

根据运行业务情况确定调度合适度值和节点运行状态值的权重值；对每个节点，将当前节点的调度合适度值和节点运行状态值进行加权求和，得到当前节点的节点调度值。

通过设置权重值，使得得到的节点调度值更加符合业务运行情况，提高节点调度的灵活性。

为了进一步方便用户使用，提高调度策略的灵活性，提升用户使用体验，本申请在设置业务上关注的、需要参与到容器组调度的指标阈值时，可在操作界面设置所有指标，并在每个指标后设置开关设置，用户只需点击开关设置便可选择所需指标，来控制是否参与容器组调度无需填写，在该实施例中，可包括下述内容：

根据接收的阈值设置指令，设置各目标指标的指标阈值最大值和指标阈值限制值；指标阈值最大值用于衡量作为调度待处理容器组的目标节点的可能性，指标阈值限制值用于作为节点不能创建容器组的限制条件。

本发明实施例的指标阈值分最大值和限制值，最大值的设置参与节点打分，达到最大值系统还能高效运行，限制值时为保障系统正常运行，节点将不允许再创建容器组。

上述实施例中涉及到原有调度策略和业务自建调度策略，本申请还可设置默认调度策略，如图3所示，若没有设置原有调度策略和指标阈值信息，则可按照Kubernetes集群默认调度策略将待处理容器组调度至相应节点处理，进一步提升Kubernetes集群的调度灵活性。

需要说明的是，本申请中各步骤之间没有严格的先后执行顺序，只要符合逻辑上的顺序，则这些步骤可以同时执行，也可按照某种预设顺序执行，图1-图3只是一种示意方式，并不代表只能是这样的执行顺序。

本发明实施例还针对基于多架构服务器部署Kubernetes集群的容器组调度方法提供了相应的装置，进一步使得所述方法更具有实用性。其中，装置可从功能模块的角度和硬件的角度分别说明。下面对本发明实施例提供的基于多架构服务器部署Kubernetes集群的容器组调度装置进行介绍，下文描述的基于多架构服务器部署Kubernetes集群的容器组调度装置与上文描述的基于多架构服务器部署Kubernetes集群的容器组调度方法可相互对应参照。

基于功能模块的角度，参见图4，图4为本发明实施例提供的基于多架构服务器部署Kubernetes集群的容器组调度装置在一种具体实施方式下的结构图，该装置可包括：

原有调度优先处理模块401，用于若Kubernetes集群设置原有调度策略，按照原有调度策略将待处理容器组调度至相应节点处理。

自建策略处理模块402，用于若没有设置原有调度策略，根据预先基于运行业务情况设置参与容器组调度的指标阈值信息和Kubernetes集群各节点参与容器组调度的指标实时值，将待处理容器组调度至相应节点处理。

可选的，在本实施例的一些实施方式中，所述自建策略处理模块402可包括：

指标信息采集子模块，用于实时采集Kubernetes集群中所有节点参与容器组调度的指标实时信息；

节点状态评价子模块，用于基于指标实时信息和运行业务情况确定Kubernetes集群各节点的节点运行状态值；

自建策略适用判断子模块，用于对Kubernetes集群的每个节点，判断当前节点的指标实时值是否低于相应指标阈值；

节点调度值计算子模块，用于若当前节点的指标实时值不低于相应指标阈值，当前节点不参与容器组调度；若当前节点的指标实时值低于相应指标阈值，根据当前节点的指标实时值和运行业务情况确定调度合适度值；根据调度合适度值和当前节点的节点运行状态值确定当前节点的节点调度值；

调度节点确定子模块，用于将Kubernetes集群中节点调度值最大的节点作为调度待处理容器组的目标节点。

在本实施例的一种可选的实施方式中，所述节点调度值计算子模块例如可包括：

权重值确定单元，用于根据运行业务情况确定调度合适度值和节点运行状态值的权重值；

计算单元，用于对每个节点，将当前节点的调度合适度值和节点运行状态值进行加权求和，得到当前节点的节点调度值。

在本实施例的另一些实施方式中，所述自建策略处理模块402例如可包括阈值设置子模块，阈值设置子模块包括：

设置单元，用于根据接收的阈值设置指令，设置各目标指标的指标阈值最大值和指标阈值限制值；指标阈值最大值用于衡量作为调度待处理容器组的目标节点的可能性，指标阈值限制值用于作为节点不能创建容器组的限制条件。

可选的，在本实施例的其他一些实施方式中，所述装置还包括默认策略处理模块，用于若没有设置原有调度策略和指标阈值信息，按照Kubernetes集群默认调度策略将待处理容器组调度至相应节点处理。

本发明实施例所述基于多架构服务器部署Kubernetes集群的容器组调度装置的各功能模块的功能可根据上述方法实施例中的方法具体实现，其具体实现过程可以参照上述方法实施例的相关描述，此处不再赘述。

由上可知，本发明实施例实现Kubernetes集群下容器组的可控调度，有效提升基于多架构服务器部署Kubernetes集群下节点的高可用性和高稳定性，使得资源利用更加合理化。

上文中提到的基于多架构服务器部署Kubernetes集群的容器组调度装置是从功能模块的角度描述，进一步的，本申请还提供一种基于多架构服务器部署Kubernetes集群的容器组调度装置，是从硬件角度描述。图5为本申请实施例提供的另一种基于多架构服务器部署Kubernetes集群的容器组调度装置的结构图。如图5所示，该装置包括存储器50，用于存储计算机程序；

处理器51，用于执行计算机程序时实现如上述实施例提到的基于多架构服务器部署Kubernetes集群的容器组调度方法的步骤。

其中，处理器51可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器51可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器51也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器51可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器51还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器50可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器50还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。本实施例中，存储器50至少用于存储以下计算机程序501，其中，该计算机程序被处理器51加载并执行之后，能够实现前述任一实施例公开的基于多架构服务器部署Kubernetes集群的容器组调度方法的相关步骤。另外，存储器50所存储的资源还可以包括操作系统502和数据503等，存储方式可以是短暂存储或者永久存储。其中，操作系统502可以包括Windows、Unix、Linux等。数据503可以包括但不限于基于多架构服务器部署Kubernetes集群的容器组调度结果对应的数据等。

在一些实施例中，基于多架构服务器部署Kubernetes集群的容器组调度装置还可包括有显示屏52、输入输出接口53、通信接口54、电源55以及通信总线56。

本领域技术人员可以理解，图5中示出的结构并不构成对基于多架构服务器部署Kubernetes集群的容器组调度装置的限定，可以包括比图示更多或更少的组件，例如还可包括传感器57。

可以理解的是，如果上述实施例中的基于多架构服务器部署Kubernetes集群的容器组调度方法以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、磁碟或者光盘等各种可以存储程序代码的介质。

基于此，本发明实施例还提供了一种计算机可读存储介质，存储有基于多架构服务器部署Kubernetes集群的容器组调度程序，所述基于多架构服务器部署Kubernetes集群的容器组调度程序被处理器执行时如上任意一实施例所述基于多架构服务器部署Kubernetes集群的容器组调度方法的步骤。

本发明实施例所述计算机可读存储介质的各功能模块的功能可根据上述方法实施例中的方法具体实现，其具体实现过程可以参照上述方法实施例的相关描述，此处不再赘述。

为了使本领域技术人员更加清楚明白本申请技术方案，本申请还提供了在具体应用场景下的一个示意性例子，请参阅图6，可包括下述内容：

在业务端集成设置装置、调度装置和数据采集装置，设置装置用于设置参与容器组调度的指标阈值，数据采集装置用于实时采集集群内各节点的指标实时信息，调度装置用于根据指标阈值和指标实时值进行调度。在基于多架构服务器部署Kubernetes集群下需要进行调度容器组操作时，进入调度装置，通过调度装置执行容器组调度操作，如果需要设置参与容器组调度的指标阈值数据，则进入设置装置，设置参与容器组调度的指标阈值，并将设置的指标阈值信息进行存储；如果需要获取参与容器组调度的Kubernetes集群节点的指标信息，则进入数据采集装置，从Kubernetes集群获取参与容器组调度的指标信息，并将获取到的容器组调度的指标信息进行存储。调度装置最终输出容器组创建的指定节点，然后通过应用接口层向集群管理端发送在指定节点创建容器组的命令，集群管理端的应用程序接口服务器(apiserver)基于调度执行器(scheduler actuator)执行创建。调度器(scheduler)会将调度信息发送给应用程序接口服务器。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

以上对本申请所提供的一种基于多架构服务器部署Kubernetes集群的容器组调度方法、装置及计算机可读存储介质进行了详细介绍。本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

Claims

1.一种基于多架构服务器部署Kubernetes集群的容器组调度方法，其特征在于，包括：

2.根据权利要求1所述的基于多架构服务器部署Kubernetes集群的容器组调度方法，其特征在于，所述根据预先基于运行业务情况设置参与容器组调度的指标阈值信息和所述Kubernetes集群各节点参与容器组调度的指标实时值，将所述待处理容器组调度至相应节点处理包括：

3.根据权利要求2所述的基于多架构服务器部署Kubernetes集群的容器组调度方法，其特征在于，所述根据所述调度合适度值和所述当前节点的节点运行状态值确定节点调度值包括：

4.根据权利要求1至3任意一项所述的基于多架构服务器部署Kubernetes集群的容器组调度方法，其特征在于，所述基于运行业务情况设置参与容器组调度的指标阈值信息包括：

5.根据权利要求4所述的基于多架构服务器部署Kubernetes集群的容器组调度方法，其特征在于，所述若没有设置原有调度策略之后，还包括：

6.一种基于多架构服务器部署Kubernetes集群的容器组调度装置，其特征在于，包括：

7.根据权利要求6所述的基于多架构服务器部署Kubernetes集群的容器组调度装置，其特征在于，所述自建策略处理模块包括：

8.根据权利要求7所述的基于多架构服务器部署Kubernetes集群的容器组调度装置，其特征在于，所述自建策略处理模块包括阈值设置子模块，所述阈值设置子模块包括：

9.一种基于多架构服务器部署Kubernetes集群的容器组调度装置，其特征在于，包括处理器，所述处理器用于执行存储器中存储的计算机程序时实现如权利要求1至5任一项所述基于多架构服务器部署Kubernetes集群的容器组调度方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有基于多架构服务器部署Kubernetes集群的容器组调度程序，所述基于多架构服务器部署Kubernetes集群的容器组调度程序被处理器执行时实现如权利要求1至5任一项所述基于多架构服务器部署Kubernetes集群的容器组调度方法的步骤。