CN116048825A - 容器集群构建方法及系统 - Google Patents

Abstract

本发明公开了一种容器集群构建方法及系统。该系统包括：订单系统，适于接收用户通过调用集群业务逻辑接口而发送的容器集群构建请求，调用订单生成进程根据容器集群构建请求生成容器集群构建消息，将容器集群构建消息发布至容器消息队列；集群业务监听进程，适于若监听到容器消息队列中存在未消费的容器集群构建消息，则从容器消息队列获取容器集群构建消息，根据容器集群构建消息启动工作实例，将工作实例分发至对应的工作节点；工作节点，适于根据工作实例构建容器集群。本发明方案分离业务和订单系统，能够有效缓解大规模请求的压力，并且保障了请求的稳定执行，保障了大规模场景下容器集群部署的成功率。

Description

容器集群构建方法及系统

技术领域

本发明涉及容器集群技术领域，具体涉及一种容器集群构建方法及系统。

背景技术

云原生技术离不开容器集群，但是面对大规模用户压力的场景下，容器集群的部署会显得很慢，分析其原因，主要是面向用户的容器业务处理能力不足及订单系统的处理业务频繁出错，会出现大量的滞缓及重试。

发明内容

鉴于上述问题，提出了本发明实施例以便提供一种克服上述问题或者至少部分地解决上述问题的容器集群构建系统和相应的容器集群构建方法。

根据本发明实施例的一个方面，提供了一种容器集群构建系统，包括：订单系统、容器消息队列、多个集群业务监听进程、多个工作节点；

订单系统，适于接收用户通过调用集群业务逻辑接口而发送的容器集群构建请求，调用订单生成进程根据容器集群构建请求生成容器集群构建消息，将容器集群构建消息发布至容器消息队列；

集群业务监听进程，适于若监听到容器消息队列中存在未消费的容器集群构建消息，则从容器消息队列获取容器集群构建消息，根据容器集群构建消息启动工作实例，将工作实例分发至对应的工作节点；

工作节点，适于根据工作实例构建容器集群。

根据本发明实施例的另一方面，提供了一种容器集群构建方法，包括：

订单系统接收用户通过调用集群业务逻辑接口而发送的容器集群构建请求，调用订单生成进程根据容器集群构建请求生成容器集群构建消息，将容器集群构建消息发布至容器消息队列；

集群业务监听进程若监听到容器消息队列中存在未消费的容器集群构建消息，则从容器消息队列获取容器集群构建消息，根据容器集群构建消息启动工作实例，将工作实例分发至对应的工作节点；

工作节点根据工作实例构建容器集群。

根据本发明实施例的又一方面，提供了一种计算设备，包括：处理器、存储器、通信接口和通信总线，处理器、存储器和通信接口通过通信总线完成相互间的通信；

存储器用于存放至少一可执行指令，可执行指令使处理器执行上述容器集群构建方法对应的操作。

根据本发明实施例的再一方面，提供了一种计算机存储介质，存储介质中存储有至少一可执行指令，可执行指令使处理器执行如上述容器集群构建方法对应的操作。

根据本发明上述实施例提供的方案，分离业务和订单系统，能够有效缓解大规模请求的压力，并且保障了请求的稳定执行，保障了大规模场景下容器集群部署的成功率；引入消息缓存方式，能够缓解大规模请求到达时的压力，并且通过调度集群内多实例的消费逻辑，来保障请求的快速处理。

上述说明仅是本发明实施例技术方案的概述，为了能够更清楚了解本发明实施例的技术手段，而可依照说明书的内容予以实施，并且为了让本发明实施例的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明实施例的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明实施例的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例提供的容器集群构建系统的示意图；

图2示出了本发明实施例提供的容器集群构建方法的流程图；

图3示出了本发明实施例提供的计算设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本发明的示例性实施例。虽然附图中显示了本发明的示例性实施例，然而应当理解，可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本发明，并且能够将本发明的范围完整的传达给本领域的技术人员。

本发明的发明人发现，现有技术在构建容器集群时，需要部署在云主机上，依赖云硬盘等资源。当大规模用户业务到达时，为了提升用户的满意度，主流厂商都会按照先建立订单，后开始容器业务的部署过程，一步一步完成集群构建。而为了减少订单的调用次数或者压力，通常需要通过定制化的方式，完成它依赖的资源创建，而这些资源受到容器集群的单独管理，即没有为这些资源创建订单。因此，这时用户无法操作这些主机的订单，部分厂商的业务会因为订单的压力影响，出现错误，重试耗费时间，或者受到串行的处理逻辑的时间影响。

此外，当大规模业务到达时，除了集群内部的管理业务，比如查看等其他操作，现有的集群部署流程，从构建订单到业务构建完成，都是一气呵成。因此处理业务的进程比较久，会占用较多的文件句柄，甚至耗费较多的内存、CPU资源，从而多个进程间相互影响，最终导致的效果是其中一步出错，会导致先创建出来的资源，再回滚，这将大大浪费了资源开销，同时降低了集群部署的成功率。

另外，现有容器集群的部署方案中，订单和容器集群的操作过程基本同步，即创建好了资源，即确认订单开始生效。对于能够保障资源开通成功率的厂家来说，效率是非常高的，但是通常很难做到在高压情况下，各资源的接口成功率还能那么高。面对多用户压力的情况下，接口的合理性调用，尤为重要，高频度的订单生效调用，会影响集群整体的部署过程，尤其是出现了错误的情况下。

再者，现有的容器集群构建方案，遵循一定的部署过程，通常采用订单、业务控制顺序执行的过程，因此当大规用户请求到达时，受到后端的业务服务器的CPU、内存资源抢占影响，上层的集群构建会显得很慢。

在公有云场景下，用户构建的容器集群资源，原则上都是用户所有，不应该因为构建容器集群，而将订单定制化，即容器集群一套订单，管理所有资源的资费，从而影响用户对于部分资源的订单操作。另外，设置只允许用户在容器的界面上，通过集群的增删改查，来操作资源，缺乏资源自由控制的粒度。

在当前的容器集群构建方案中，通常订单系统不是针对一个系统服务，因此它存在理论上的阈值，即超过这个范围，请求无法响应，会触发大量的错误。因此，大规模用户构建集群的场景下，订单系统的压力，会影响集群部署的成功率。

此外，容器后端的业务接口，对于系统是“平等”的，它们抢占资源的方式，受到所在服务器的CPU等资源的影响。因此，在大规模用户请求到达时，不能够保证集群构建过程的成功执行。即进程可能会因服务器处理能力的上限，从而引发大规模容器构建失败，进而影响了产品或者系统的口碑。

因此，提出了本发明实施例的容器集群构建方案，该方案满足大规模业务到达的处理需求，并能够实现以下目的：1、设计合理的订单、业务分离方案，保障大规模场景下，容器集群部署的成功率。2、设计后端业务弹性调度功能实例至不同的工作节点，提升容器集群构建成功率。3、引入消息缓存方式，来缓解大规模请求到达时的压力，并且通过调度集群内多实例的消费逻辑，来保障请求的快速处理。4、设计合理的订单操作流程，能够灵活地为用户的每一个资源都构建订单，并且订单的生效逻辑，在容器构建完成后，统一生效，减少与订单系统的交互次数。

图1示出了本发明实施例提供的容器集群构建系统的示意图。如图1所示，该系统包括：订单系统101、容器消息队列102、多个集群业务监听进程103、多个工作节点104(图1仅是示意性说明)。

订单系统101，适于接收用户通过调用集群业务逻辑接口而发送的容器集群构建请求，调用订单生成进程根据容器集群构建请求生成容器集群构建消息，将容器集群构建消息发布至容器消息队列。

具体地，本实施例向用户提供有集群业务逻辑接口(Cluster Bll)，当用户希望构建容器集群时，可以调用集群业务逻辑接口向订单系统发送容器订单构建请求，一旦请求成功，则上层业务的流程结束，向用户返回容器集群构建中的状态。优选地，订单系统还适于：通过调用集群业务逻辑接口向用户返回状态消息，其中，状态消息用于标识容器集群处于构建中的状态。由于这个请求，只涉及订单构建，并没有后端业务的资源抢占，通常不会出现问题。如果因为订单系统的压力，导致出现偶发错误，则在Cluster Bll这一层按照现有节点优选的策略分发重试，直到所有批次的订单构建成功。

订单系统可以调用订单生成进程，订单生成进程是集群内多实例的，它能够快速处理用户创建的订单，并将它们以消息的载体，发布至容器消息队列，即，由订单生成进程负责容器集群构建消息的生成，消息产生的过程，依赖订单生成进程的处理能力，此处订单生成进程设置为多实例，提升订单的处理能力。

具体地，订单系统调用订单生成进程根据容器集群构建请求生成容器集群构建消息，将容器集群构建消息发布至容器消息队列，大规模场景下的容器构建，产生了大量的容器集群构建消息。

集群业务监听进程103，适于接收用户通过调用集群业务逻辑接口而发送的容器集群构建请求，调用订单生成进程根据容器集群构建请求生成容器集群构建消息，将容器集群构建消息发布至容器消息队列。

具体地，集群业务监听进程作为后端的业务逻辑的消费者，监听订单系统发送过来的容器集群构建消息，此时才开始后端容器集群的构建过程。

具体地，集群业务监听进程实时监听容器消息队列中是否存在未消费的容器集群构建消息，若监听到容器消息队列中存在未消费的容器集群构建消息，则立马从容器消息队列上取走容器集群构建消息，开始容器集群的构建流程。具体地，集群业务监听进程可以根据容器集群构建消息启动工作实例，将工作实例分发至对应的工作节点。

其中，集群业务监听进程可以启动新的工作实例(Pod实例)来处理容器集群的构建请求。而Pod实例，可以根据节点优选调度策略，优先将实例分发至不同的工作节点，工作节点具体作为不同的服务器，彼此之间没有资源竞争的影响，即使调度至同一工作节点，可设置预留处理资源，提升处理Pod实例处理性能。另外Pod实例在Kubernetes的过程是轻量级的，它的启动特别快，因此集群业务监听进程可以通过启动不同的Pod实例达到批处理最快的速度，处理完队列上的所有消息。这种实现了订单和业务处理的分离，达到高效的集群构建效果。

需要说明的是，容器集群的构建流程中，可能会依赖其它资源，这里可以通过其它资源的调度接口完成。而其它资源的构建，也是通过订单、业务构建分离的原则，保证了其它资源构建的稳定性和效率，因此当所依赖的资源构建完成后，再由容器构造的集群业务监听进程，将该过程中的所有资源的所有依赖订单，一批次向订单系统完成订单的生效时间。这将大大减少了其它资源订单与订单系统的交互次数，同时也将各资源以订单的条目，为用户生成。用户可以灵活操作容器集群中涉及的所有资源，不受容器集群订单业务本身的影响。而当在偶发情况下，容器集群依赖的资源构建失败，在pod的业务流程中增加了重试的机制，保证了资源开通的成功率，从而保障集群构建的成功率。

将工作实例弹性调度实例至不同的服务器节点，提升容器集群构建成功率，指的是在管理集群中，除了组件所在的节点之外，为了应对大规模用户请求，还配置了多台工作节点，可供不同的pod实例调度，充分使用工作节点资源，并且在工作实例完成之后，自动销毁，达到资源的回收。也就是说，集群业务监听进程还适于：在容器集群构建完成后，销毁工作实例。

工作节点104，适于根据工作实例构建容器集群。

工作节点根据工作实例构建容器集群，并且回调订单系统，以使所有相关的订单生效，减少了与订单业务频繁的交互过程，大大提升了容器集群构建的成功率及性能。

如图1所示，本实施例的容器集群构建系统包括三层架构，其中，最上层是ClusterBll(集群业务逻辑接口)，用于向用户开放业务逻辑接口；中间层包括容器消息队列、订单系统、订单生成进程)、集群业务监听进程等，用于分离业务和订单系统，能够有效缓解大规模容器构建请求的压力，并且保障了容器构建请求的稳定执行；最下层是服务器实例所在的工作节点，用于按照功能来分发处理业务的工作实例(pod)，这一层是内部服务器，它不对外开放，可以设定调度策略，将业务处理进程，按照pod的粒度进行调度，这样当大规模容器构建请求过来时，不再受到单服务器处理进程的影响。

容器集群构建请求的内容数据结构为(requestId，orderType，userId，poolId，orderId，productType，openParams)。

其中，requestId，表征请求的id，用于表征请求；

orderType，表述请求的操作类型，如创建；

userId，表示请求资源的用户；

poolId，表示请求的资源所在的资源池；

orderId，表示请求的订单信息，用于和资源绑定，在容器集群构建完成后，统一回调状态；

productType，表示请求的资源类型，如容器集群；

openParams，表示请求的参数信息。

这样，在收到请求后，可以明确它的相关信息，包括来源、请求类型、订单信息、操作参数等重要信息，容器集群构建消息携带有容器集群构建请求中的全部数据，通过对容器集群构建消息的解析，调度至不同的服务节点。

也就是说，容器集群构建消息包括以下至少一项：请求标识、请求操作类型、用户标识、所请求资源所在的资源池标识、所请求的订单信息、资源类型、容器集群参数信息。其中，容器集群参数信息包括：第一容器集群规模值、集群类型。

在本发明一种可选实施方式中，集群业务监听进程进一步适于：根据第一容器集群规模值确定实例功能，启动具有对应实例功能的工作实例，将具有对应实例功能的工作实例分发至对应的工作节点；

工作节点进一步适于：根据具有对应实例功能工作实例构建容器集群，其中，容器集群提供的集群功能与实例功能相对应。

其中，实例功能包括以下功能中的一个或多个：创建功能、扩容功能、缩容功能、查看功能、冻结功能、恢复功能、退订功能。

具体地，基于用户的容器构建请求I＝(requestId，orderType，userId，poolId，orderId，productType，openParams)来计算用户对应的请求信息Q。

Q＝(b*baseM*c*q*a，b*baseC*c*q*a)，其中，b为基础操作系数因子，base为基础操作系数，baseM为内存对应的基础操作系数，baseC为CPU对应的基础操作系数、c为容器类型因子、q为容器规模因子、a为容器操作方法因子。

之后确定工作实例的实例功能，并基于Q的值进行工作实例的调度。包括以下几种情况：

(1)当q<10的集群规模；

按照正常的操作系数(1，1)(这里是经验值，为(内存计算值，CPU计算值))来设计，同时，基于原始的clusterType请求集群类型，再结合容器规模q，即A＝a*clusterType+b*q，当A大于或等于X(X为预先设置的阈值)时，工作实例提供创建功能、扩容功能、缩容功能，若A小于X时，则提供具有创建功能的工作实例，在容器集群构建完成后，用户存在其他需求时，是直接在进程中提供服务，不需要额外创建实例去执行。这样的好处是，对于小规模的集群能够提供的包括扩容功能、缩容功能，由于规模小，不需要再创建实例去执行，反而执行速度快。

当orderType为创建时，它创建的依赖的处理资源逻辑比较复杂，包括容器集群内部的多个资源、容器集群部署的业务逻辑。根据集群类型的不同，将他们调度到不同型号的服务器上，并且根据不同类型的集群因子来配置，从而获取不同的资源分配规格，这类的调度过程采用现有技术的调度方法，只是这类需要根据算法Q公式，及各因子算出这个资源的值，然后执行调度，调度到不同型号的服务器上。如果是普通的小规模的集群，只需要调度到普通服务器上，如果是gpu集群，则需要调度到gpu主机上，从而提供更快的响应性能；如果是弹性裸金属集群，则调度到弹性裸金属机器上。(这里简单说明了一下调度的方案，本发明的重点是区分不同类型的集群、及规模，在大规模场景下，通过调度策略，从而提供更优的性能)。

(2)q＝10-50增大后的集群，在可控范围内需求的cpu、内存资源，按照比例增加，操作系数设定为(2.5，2.5)；同时根据集群类型、集群规模q，即B＝clusterType*q，当B小于X时，工作实例提供创建功能、扩容功能、缩容功能，若B大于或等于X时，工作实例提供创建功能、扩容功能、缩容功能、查看功能，当集群达到设定的阈值标准，通过pod工作实力的方式提高查看功能的效率及稳定性。

当orderType为创建时，它创建的依赖的处理资源逻辑比较复杂，包括容器集群内部的多个资源、容器集群部署的业务逻辑。根据集群类型的不同，将他们调度到不同型号的服务器上，并且根据不同类型的集群因子来配置，从而获取不同的资源分配规格。

(3)q＝50-100的中大型集群规模，设置的CPU资源需求增大，内存开销几乎同10-50的开销，操作系数设置为(2.5，5)，此时，工作实例提供创建功能、扩容功能、缩容功能、冻结功能、恢复功能。

当orderType为创建时，它创建的依赖的处理资源逻辑比较复杂，包括容器集群内部的多个资源、容器集群部署的业务逻辑。根据集群类型的不同，将他们调度到不同型号的服务器上，并且根据不同类型的集群因子来配置，从而获取不同的资源分配规格。

(4)q＝100-1000之间的大规模集群，集群内部交互的频次呈指数上涨，因此对于资源的需求因此，根据经验调整为(10，20)，集群类型仅仅为通用云主机，其它类型的容器集群，在这个规模下，资源开销过大，此时工作实例提供创建功能、查看功能、冻结功能、恢复功能。

当orderType为创建时，它创建的依赖的处理资源逻辑比较复杂，包括容器集群内部的多个资源、容器集群部署的业务逻辑。将他们调度到高性能服务器上，并且根据不同类型的集群因子来配置，从而获取不同的资源分配规格。

(5)q＝>1000以上的超大集群规模，针对大规模集群的构建，实际在业务上并不多见，因此，集群的影响不仅受到当前部署的进程影响，同时集群内部的流量受到带宽、时延、存储性能的影响，导致控制流程上加大了，因此这个参数设定为容器规模因子的上线值，根据经验可调整为100/100，并且设定了集群类型，仅仅为通用云主机，工作实例提供的仅仅是创建功能、查看功能、退订功能、缩容功能。由于集群规模太大，小实例的处理，通常会影响集群构建的稳定性，并且集群规模已经达到，不支持冻结、恢复这种集群不稳定的操作。

基于用户请求信息数据创建匹配的容器及对应的容器功能，能够提升容器的适配性以及实用性，减少因容器功能过多带来的容器创建较慢，成功率较低的问题。

本实施例的容器集群构建系统能够应用于大规模场景，根据用户不同的请求，将处理逻辑下发到多台不同的服务器，以pod实例的方式来处理逻辑，对于处理完的进程，自动销毁pod实例，由容器集群完成资源的回收。能够充分使用系统服务器的资源，在大规模场景之下，容器集群的构建流程更加顺畅，大大降低了资源抢占，而导致的时间损耗。因此，通过这样的流程设计，在大规模用户场景下，容器集群的构建，可通过多pod实例调度到不同的节点，大大提升了业务处理性能，从而提升了集群构建的成功率。

本实施例引入消息缓存方式，来缓解大规模请求到达时的压力，并且通过调度集群内多实例的消费逻辑，来保障请求的快速处理，主要是指在容器管理层的后端启动多个Cluster Consumer进程(集群业务监听进程)，来监听容器消息队列。而容器消息队列上面的消息，则由订单生成进程产生，即当大规模请求到达时，订单生成进程按照一定的批处理策略，分批次处理完订单逻辑，并将订单信息，通过消息的形式放到容器消息队列上，由Cluster Consumer来处理消息。而Cluster Consumer的消息处理流程，并不由ClusterConsumer进程本身来完成，它是通过调度实例，将压力分发到不同的pod实例，而在本实施例中pod实例被调度到充沛资源的服务器上，性能稳定，有足够的保障，因此本实施例中引入的容器消息队列，能够充分提升系统的稳定性、处理性能。本实施例能够灵活地为用户的每一个资源都构建订单，并且订单的生效逻辑，在容器构建完成后，统一生效，减少与订单系统的交互次数。本实施例基于用户请求创建匹配的容器及对应的容器功能，能够提升容器的适配性以及实用性，减少因容器功能过多带来的容器创建较慢，成功率较低的问题。

在本发明一种可选实施方式中，订单系统还适于：接收用户通过调用集群业务逻辑接口而发送的容器集群处理请求，调用订单生成进程根据容器集群构建请求生成容器集群处理消息，将容器集群处理消息发布至容器消息队列；

集群业务监听进程还适于：若监听到容器消息队列中存在未消费的容器集群处理消息，则从容器消息队列获取容器集群处理消息，根据容器集群处理消息启动具有对应实例功能的工作实例，将具有对应实例功能的工作实例分发至对应的工作节点；或者，根据容器集群处理消息对容器集群进行处理；

工作节点还适于：根据具有对应实例功能的工作实例对容器集群进行处理。

具体地，在容器集群构建完成后，用户还可以对容器集群进行相应的处理，例如，扩容、缩容、查看、冻结、恢复等处理，具体地，用户可以通过调用集群业务逻辑接口来发送容器集群处理请求，例如，可以是扩容请求、缩容请求、查看请求、冻结请求、恢复请求等任意请求，订单系统还适于：接收用户通过调用集群业务逻辑接口而发送的容器集群处理请求，调用订单生成进程根据容器集群构建请求生成容器集群处理消息，将容器集群处理消息发布至容器消息队列；

集群业务监听进程还适于：若监听到容器消息队列中存在未消费的容器集群处理消息，则从容器消息队列获取容器集群处理消息，根据容器集群处理消息启动具有对应实例功能的工作实例，将具有对应实例功能的工作实例分发至对应的工作节点；或者，根据容器集群处理消息对容器集群进行处理；

针对不同的集群规模的请求，对容器集群进行处理时所采用的方式是不同的：

(1)当q<10的集群规模；

按照正常的操作系数(1，1)(这里是经验值，为(内存计算值，CPU计算值))来设计，同时，基于原始的clusterType请求集群类型，再结合容器规模q，即A＝a*clusterType+b*q，当A大于或等于X(X为预先设置的阈值)时，当请求为扩容请求或缩容请求时，需要启动具有对应实例功能的工作实例，通过将工作实例调度至对应的工作节点，使得工作节点根据具有对应实例功能的工作实例对容器集群进行处理，例如，扩容处理、缩容处理；若A小于X时，由于集群规模较小，当存在扩容需求或缩容需求时，集群业务监听进程可以直接提供服务，不需要额外创建实例去执行。这样的好处是，由于规模小，不需要再创建实例去执行，反而执行速度快。

当orderType为扩容、缩容时，这种请求，操作的资源不像创建集群那么多。但是由于集群规模较小，将工作实例调度到普通型主机服务器上(调度的过程是通过(内存计算值，cpu计算值)这两个值来对比找到适合的值，服务器已经被打上标签，这类的集群请求会根据算法调度到普通的主机服务器上)，并且分配工作pod资源的实例，受到集群类型因子影响，采用base*c的模式配置，base表明cpu或者内存基本的运行开销，c表明集群的不同类型因子，当集群为GPU等这类资源的因子c，需要配置更大，这样才能快速完成容器集群的扩、缩容。

(2)q＝10-50增大后的集群，在可控范围内需求的cpu、内存资源，按照比例增加，操作系数设定为(2.5，2.5)；同时根据集群类型、集群规模q，即B＝clusterType*q，当B小于X时，当请求为扩容请求或者缩容请求时，需要启动具有对应实例功能的工作实例，而当请求为查看请求时，则无需启动工作实例，集群业务监听进程可以直接提供服务；当B大于或等于X时，请求为扩容请求或者缩容请求或查看请求时，需要启动具有对应实例功能的工作实例，当集群达到设定的阈值标准，通过pod实例的方式提高查看功能的效率及稳定性，具体的实现内容如下：

当orderType为扩容、缩容时，这种请求，操作的资源不像创建集群那么多。但是由于集群规模中等，将工作pod实例调度到空闲的普通型主机服务器上，并且分配工作pod资源的实例，受到集群类型因子影响，采用base*c的模式配置，base表明cpu或者内存基本的运行开销，c表明集群的不同类型因子，当集群为GPU等这类资源的因子c，需要配置更大，这样才能快速完成容器集群的扩、缩容。

当orderType为查看时，这里请求仅需要查看数据库相关的资源信息，因此，不管哪种类型的集群，都将它们调度到最廉价的服务器上，即通用型的主机，并且分配基本的内存、cpu开销，请求完成后，工作实例快速释放出来，这样的请求，能够被快速处理，并且资源被及时回收，提升了服务器的处理效率。

(3)q＝50-100的中大型集群规模，设置的cpu资源需求增大，内存开销几乎同10-50的开销，操作系数为(2.5，5)，这种规模下的集群支持通过工作pod实例形式进行扩容、缩容，冻结、恢复等处理，即，请求为扩容、缩容，冻结、恢复等请求时，需要启动具有相应实例功能的工作实例来对容器集群进行处理，具体方式如下：

当orderType为扩容、缩容时，这种请求，操作的资源不像创建集群那么多。但是由于集群规模较大，将工作pod实例调度到对应主机型号的服务器上，并且分配工作pod资源的实例，受到集群类型因子影响，采用base*c的模式配置，base表明cpu或者内存基本的运行开销，c表明集群的不同类型因子，当集群为GPU等这类资源的因子c，需要配置更大，这样才能快速完成容器集群的扩、缩容。

当orderType为查看时，这里请求仅需要查看数据库相关的资源信息，因此，由于集群规模较大，将它们调度到对应集群型号的服务器上，并且分配基本的内存、cpu开销，请求完成后，工作实例快速释放出来，这样的请求，能够被快速处理，并且资源被及时回收，提升了服务器的处理效率。

当orderType为冻结、恢复时，这种请求不操作资源，仅需要调整状态，因此需要非常少的资源开销，但是规模较大，将它们调度到的对应集群类型的服务器上，处理完成后，资源自动被系统回收。

(4)q＝100-1000之间的大规模集群，集群内部交互的频次呈指数上涨，因此对于资源的需求因此，根据经验调整为(10，20)，集群类型仅仅为通用云主机，其它类型的容器集群，在这个规模下，资源开销过大，容器集群仅提供查看、冻结、恢复等功能，而进行查看、冻结、恢复等操作时，需要启动相应实例功能的实例，具体方式如下：

当orderType为查看时，这里请求仅需要查看数据库相关的资源信息，因此，由于集群规模较大，将它们调度到高性能的服务器上，并且根据操作因子，设定一定的内存、cpu开销，请求完成后，工作实例快速释放出来，这样的请求，能够被快速处理，并且资源被及时回收，提升了服务器的处理效率。

当orderType为冻结、恢复时，这种请求不操作资源，仅需要调整状态，因此需要非常少的资源开销，但是规模较大，将它们调度到的高性能的服务器上，处理完成后，资源自动被系统回收。

(5)q＝>1000以上的超大集群规模，针对大规模集群的构建，实际在业务上并不多见，因此，集群的影响不仅受到当前部署的进程影响，同时集群内部的流量受到带宽、时延、存储性能的影响，导致控制流程上加大了，因此这个参数设定为容器规模因子的上线值，根据经验可调整为100/100，并且设定了集群类型，仅仅为通用云主机。容器集群仅提供查看、退订、缩容功能。由于集群规模太大，小实例的处理，通常会影响集群构建的稳定性，并且集群规模已经达到，不支持冻结、恢复这种集群不稳定的操作。而进行查看、退订、缩容等操作时，需要启动相应实例功能的实例，

本发明实施例提供的系统，通过引入容器消息队列缓存消息，能够缓解大规模场景下，用户请求的分发。同时，设计了订单系统，处理订单的业务，集群业务监听进程，能够通过启动pod实例并调度到其它服务器，实现队列上的消息快速处理的目的，而pod的构建流程，依赖的其它资源接口，也进行了订单与后端业务分离的原则，实现其它资源处理的快速、稳定处理，从而保障了容器集群的快速、稳定构建，在集群所有资源构建成功后，批量回调订单系统，使所有相关的订单生效，减少了与订单业务频繁的交互过程，大大提升了容器集群构建的成功率及性能。

图2示出了本发明实施例提供的容器集群构建方法的流程图。如图2所示，该方法包括以下步骤：

步骤S201，订单系统接收用户通过调用集群业务逻辑接口而发送的容器集群构建请求，调用订单生成进程根据容器集群构建请求生成容器集群构建消息，将容器集群构建消息发布至容器消息队列。

步骤S202，集群业务监听进程若监听到容器消息队列中存在未消费的容器集群构建消息，则从容器消息队列获取容器集群构建消息，根据容器集群构建消息启动工作实例，将工作实例分发至对应的工作节点。

步骤S203，工作节点根据工作实例构建容器集群。

可选地，该方法还包括：集群业务监听进程在容器集群构建完成后，销毁工作实例。

可选地，容器集群构建请求包括：请求标识、请求操作类型、用户标识、所请求资源所在的资源池标识、所请求的订单信息、资源类型、容器集群参数信息，其中，容器集群参数信息包括：第一容器集群规模值。

可选地，集群业务监听进程根据容器集群构建消息启动工作实例，将工作实例分发至对应的工作节点进一步包括：

根据第一容器集群规模值确定实例功能，启动具有对应实例功能的工作实例，将具有对应实例功能的工作实例分发至对应的工作节点；

工作节点根据工作实例构建容器集群进一步包括：根据具有对应实例功能工作实例构建容器集群，其中，容器集群提供的集群功能与实例功能相对应。

可选地，实例功能包括以下功能中的一个或多个：创建功能、扩容功能、缩容功能、查看功能、冻结功能、恢复功能、退订功能。

可选地，该方法还包括：订单系统接收用户通过调用集群业务逻辑接口而发送的容器集群处理请求，调用订单生成进程根据容器集群构建请求生成容器集群处理消息，将容器集群处理消息发布至容器消息队列；

集群业务监听进程若监听到容器消息队列中存在未消费的容器集群处理消息，则从容器消息队列获取容器集群处理消息，根据容器集群处理消息启动具有对应实例功能的工作实例，将具有对应实例功能的工作实例分发至对应的工作节点；或者，根据容器集群处理消息对容器集群进行处理；

工作节点根据具有对应实例功能的工作实例对容器集群进行处理。

可选地，该方法还包括：订单系统通过调用集群业务逻辑接口向用户返回状态消息，其中，状态消息用于标识容器集群处于构建中的状态。

本发明实施例提供的方法，通过引入容器消息队列缓存消息，能够缓解大规模场景下，用户请求的分发。同时，设计了订单系统，处理订单的业务，集群业务监听进程，能够通过启动pod实例并调度到其它服务器，实现队列上的消息快速处理的目的，而pod的构建流程，依赖的其它资源接口，也进行了订单与后端业务分离的原则，实现其它资源处理的快速、稳定处理，从而保障了容器集群的快速、稳定构建，在集群所有资源构建成功后，批量回调订单系统，使所有相关的订单生效，减少了与订单业务频繁的交互过程，大大提升了容器集群构建的成功率及性能。

本发明实施例提供了一种非易失性计算机存储介质，计算机存储介质存储有至少一可执行指令，该计算机可执行指令可执行上述任意方法实施例中的容器集群构建方法。

图3示出了本发明实施例提供的计算设备的结构示意图，本发明具体实施例并不对计算设备的具体实现做限定。

如图3所示，该计算设备可以包括：处理器(processor)、通信接口(Communications Interface)、存储器(memory)、以及通信总线。

其中：处理器、通信接口、以及存储器通过通信总线完成相互间的通信。通信接口，用于与其它设备比如客户端或其它服务器等的网元通信。处理器，用于执行程序，具体可以执行上述用于计算设备的容器集群构建方法实施例中的相关步骤。

具体地，程序可以包括程序代码，该程序代码包括计算机操作指令。

处理器可能是中央处理器CPU，或者是特定集成电路ASIC(Application SpecificIntegrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路。计算设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器，用于存放程序。存储器可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

程序具体可以用于使得处理器执行上述任意方法实施例中的容器集群构建方法。程序中各步骤的具体实现可以参见上述容器集群构建实施例中的相应步骤和单元中对应的描述，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。

在此提供的算法或显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明实施例也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明实施例的内容，并且上面对特定语言所做的描述是为了披露本发明实施例的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本发明实施例并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明实施例要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的一些或者全部部件的一些或者全部功能。本发明实施例还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明实施例的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明实施例进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明实施例可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。上述实施例中的步骤，除有特殊说明外，不应理解为对执行顺序的限定。

Claims (10)

1.一种容器集群构建系统，包括：订单系统、容器消息队列、多个集群业务监听进程、多个工作节点；

订单系统，适于接收用户通过调用集群业务逻辑接口而发送的容器集群构建请求，调用订单生成进程根据所述容器集群构建请求生成容器集群构建消息，将所述容器集群构建消息发布至容器消息队列；

集群业务监听进程，适于若监听到所述容器消息队列中存在未消费的容器集群构建消息，则从所述容器消息队列获取容器集群构建消息，根据所述容器集群构建消息启动工作实例，将所述工作实例分发至对应的工作节点；

工作节点，适于根据所述工作实例构建容器集群。

2.根据权利要求1所述的系统，其中，所述集群业务监听进程还适于：在容器集群构建完成后，销毁所述工作实例。

3.根据权利要求1或2所述的系统，其中，所述容器集群构建请求包括：请求标识、请求操作类型、用户标识、所请求资源所在的资源池标识、所请求的订单信息、资源类型、容器集群参数信息，其中，所述容器集群参数信息包括：第一容器集群规模值。

4.根据权利要求3所述的系统，其中，所述集群业务监听进程进一步适于：根据所述第一容器集群规模值确定实例功能，启动具有对应实例功能的工作实例，将具有对应实例功能的工作实例分发至对应的工作节点；

所述工作节点进一步适于：根据具有对应实例功能工作实例构建容器集群，其中，所述容器集群提供的集群功能与实例功能相对应。

5.根据权利要求4所述的系统，其中，所述实例功能包括以下功能中的一个或多个：创建功能、扩容功能、缩容功能、查看功能、冻结功能、恢复功能、退订功能。

6.根据权利要求1或2所述的系统，其中，所述订单系统还适于：接收用户通过调用集群业务逻辑接口而发送的容器集群处理请求，调用订单生成进程根据所述容器集群构建请求生成容器集群处理消息，将所述容器集群处理消息发布至容器消息队列；

所述集群业务监听进程还适于：若监听到所述容器消息队列中存在未消费的容器集群处理消息，则从所述容器消息队列获取容器集群处理消息，根据所述容器集群处理消息启动具有对应实例功能的工作实例，将具有对应实例功能的工作实例分发至对应的工作节点；或者，根据容器集群处理消息对容器集群进行处理；

所述工作节点还适于：根据具有对应实例功能的工作实例对容器集群进行处理。

7.根据权利要求1或2所述的系统，其中，所述订单系统还适于：通过调用集群业务逻辑接口向所述用户返回状态消息，其中，所述状态消息用于标识容器集群处于构建中的状态。

8.一种容器集群构建方法，包括：

订单系统接收用户通过调用集群业务逻辑接口而发送的容器集群构建请求，调用订单生成进程根据所述容器集群构建请求生成容器集群构建消息，将所述容器集群构建消息发布至容器消息队列；

集群业务监听进程若监听到所述容器消息队列中存在未消费的容器集群构建消息，则从所述容器消息队列获取容器集群构建消息，根据所述容器集群构建消息启动工作实例，将所述工作实例分发至对应的工作节点；

工作节点根据所述工作实例构建容器集群。

9.一种计算设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求8所述的容器集群构建方法对应的操作。

10.一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如权利要求8所述的容器集群构建方法对应的操作。

Images