一种基于多容器集群的工作负载组合统一部署方法及系统

摘要

本发明涉及一种基于多容器集群的工作负载组合统一部署方法及系统，其中方法包括：步骤1：响应外部用户应用后，根据外部用户应用中的微服务的相关信息，生成待填充的工作负载配置文件；步骤2：根据外部用户应用中的批次信息，将批次信息填充至工作负载配置文件中进行组合；步骤3：根据批次信息中的批次定制属性，将对应工作负载配置文件中的信息进行覆盖，得到完整的工作负载配置文件；步骤4：根据批次信息中的关联容器集群信息和每个容器集群本身的配置信息，将每一份工作负载配置文件生成真实的集群API访问接口配置并发送至对应的集群进行统一部署，同时本发明提供一种与方法对应的系统，与现有技术相比，本发明具有能够适用多地部署等优点。

说明书

技术领域

本发明涉及计算机技术领域，尤其是涉及一种基于多容器集群的工作负载组合统一部署方法及系统。

背景技术

随着Kubernetes容器集群的使用，我们发现单容器集群的容量和能力始终存在上限，并且企业内部往往有多个异地的机房，容器集群在部署上并不建议异地部署，这会降低其内部调度的效率。同时，对应用来说，其逻辑架构可能会横跨多个物理集群，传统基于单容器集群的部署会限制应用部署的效率，并且无法满足应用异地多活、单元化的要求。这就存在一个系统逻辑上统一管理但是物理上分别部署的场景。

现有技术中，采用Kubernetes社区提供的Federation集群联邦架构，集群联邦架构对Kubernetes的版本有一定要求，并且无法解决异构集群的问题；在顶层设计开发一个容器集群管理平台，对于每个容器集群进行管理调度，无法实现应用跨集群部署时的统一管理。

发明内容

本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种基于多容器集群的工作负载组合统一部署方法及系统。

本发明的目的可以通过以下技术方案来实现：

一种基于多容器集群的工作负载组合统一部署方法，该方法包括以下步骤：

步骤1：响应外部用户应用后，根据外部用户应用中的微服务的相关信息，生成待填充的工作负载配置文件；

步骤2：根据外部用户应用中的批次信息，将批次信息填充至工作负载配置文件中进行组合；

步骤3：根据批次信息中的批次定制属性，将对应工作负载配置文件中的信息进行覆盖，得到完整的工作负载配置文件；

步骤4：根据批次信息中的关联容器集群信息和每个容器集群本身的配置信息，将每一份工作负载配置文件生成真实的集群API访问接口配置并发送至对应的集群进行统一部署。

进一步地，所述的步骤1中的微服务的相关信息，包括名称、类型和工作负载模板。

进一步地，所述的步骤2中的批次信息，包括批次名、关联容器集群和批次定制属性。

进一步地，所述的步骤3中的完整的工作负载配置文件，其包括：工作负载基本信息和工作负载所属容器集群。

进一步地，所述的步骤4中的每个容器集群本身的配置信息，其包括：集群ID和接口清单映射。

本发明还提供一种用于所述的基于多容器集群的工作负载组合统一部署方法的集群管理系统，该系统包括：

部署接口模块，用于通过自身接口响应外部用户应用，并获取该应用相关信息；

模型生成模块，用于根据外部用户应用中的微服务的相关信息，生成待填充的工作负载配置文件，并根据外部用户应用中的批次信息，将批次信息填充至工作负载配置文件中进行组合，并根据批次信息中的批次定制属性，将对应工作负载配置文件中的信息进行覆盖，得到完整的工作负载配置文件；

模型翻译模块，用于根据批次信息中的关联容器集群信息和每个容器集群本身的配置信息，将每一份工作负载配置文件生成真实的集群API访问接口配置并发送至对应的集群；

集群调用模块，用于最终负责调用具体容器集群并进行统一部署。

进一步地，于该集群管理系统中，该应用相关信息包括：名称、类型、微服务列表和批次列表。

进一步地，于该集群管理系统中，所述每个容器集群本身的配置信息，其包括：集群ID和接口清单映射；所述完整的工作负载配置文件，其包括：工作负载基本信息和工作负载所属容器集群；所述微服务的相关信息，包括名称、类型和工作负载模板；所述批次信息，包括批次名、关联容器集群和批次定制属性。

本发明还提供一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现所述的基于多容器集群的工作负载组合统一部署方法的步骤。

本发明还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现所述的基于多容器集群的工作负载组合统一部署方法的步骤。

与现有技术相比，本发明具有以下优点：

(1)本发明可以有效整合存量的各类异构或不同版本的容器集群，并给用户层一个统一的模型视角，屏蔽了底层的变化，有利于未来下层容器平台的升级和切换，减少对某一个固定厂商或固定版本的依赖。

(2)本发明通过批次的概念，可以将日常开发运维过程中所常见的应用多环境部署、应用的蓝绿发布和灰度发布，以及应用的多地部署单元化架构这些场景都转化为对应用不同批次的配置和定制，从管理角度，真正实现了部署即代码，体现了PaaS平台的价值。

(3)本发明构建容器管理平台，封装容器集群本身的工作负载API，转换为平台标准API，在模型设计中增加批次的概念属性，用于进行各种场景下部署模式的灵活实现，如果仅做一层封装，不实现批次相关的逻辑，也能够满足统一管理异构集群的需要，但是针对多环境部署，灰度发布等场景，都要单独设计技术方案。所以本技术方案更具灵活性和扩展性。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本发明用于实现基于多容器集群的工作负载组合统一部署方法的配套集群管理系统所对应的逻辑架构图；

图2为本发明用于实现基于多容器集群的工作负载组合统一部署方法的配套集群管理系统的实际应用示意图；

图3为本发明用于实现基于多容器集群的工作负载组合统一部署方法的流程图。

具体实施方式

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

因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

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

在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，或者是该发明产品使用时惯常摆放的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

此外，术语“水平”、“竖直”等术语并不表示要求部件绝对水平或悬垂，而是可以稍微倾斜。如“水平”仅仅是指其方向相对“竖直”而言更加水平，并不是表示该结构一定要完全水平，而是可以稍微倾斜。

在本发明的描述中，还需要说明的是，除非另有明确的规定和限定，术语“设置”、“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

本发明主要为了解决如下问题：1、解决多容器集群(含异构商业版本)应用统一部署；2、提供一种顶层应用描述模型的设计思路；3、基于相关设计思路，提供多环境部署、蓝绿发布、单元化的解决方案。

平台逻辑处理架构如下，核心部分共分为四个模块，分别为响应外部用户的应用部署接口，负责生成和保存应用数据的模型生成模块，负责将管理平台模型转为不同容器集群的模型翻译模块和最终负责调用具体容器集群的集群调用模块，如图1所示。

本发明解决问题所采用的技术方案是：构建一个顶层的容器集群管理平台，并在平台中抽象出一个应用部署模型。每个容器集群仍旧通过其自有的API进行控制，管理单个工作负载的运行，而由顶层的集群管理平台来完成应用部署模型和工作负载API的翻译。用户通过对顶层管理平台应用模型的API操作，间接完成对底层容器平台工作负载的相关操作。

针对应用模型如下，可以看到，本方案在传统微服务和工作负载一一对应的基础上，扩展了应用管理和批次的概念，将原本的一维关联关系扩展到了二维，增加了应用部署上的灵活性，如图2所示。

具体的模型生成的逻辑如下：

首先根据微服务本身的信息(名称、类型和工作负载模板)，生成一份待填充的工作负载配置文件，这样一个应用会根据微服务的数量生成若干份工作负载配置。

其次根据批次信息，将批次名填充到工作负载配置文件中，这样一个应用的每个微服务的工作负载配置都会根据批次的数量再生成若干份信息完备的配置。

然后根据批次的定制属性，将对应工作负载配置文件中的信息进行覆盖，例如某个微服务需要在A批次里启动V1.0版本2个实例，在B批次里启动V1.1版本3个实例，就可以通过这个属性来实现。

最后，根据批次的关联容器集群信息和每个容器集群本身的配置信息，将每一份工作负载配置生成真实的集群API访问接口配置并发送到对应的集群，这里可以通过逻辑处理屏蔽异构集群或不同版本集群的差异，实现统一的调度，如图3所示。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。