CN118092982A - 一种云原生应用的多集群运维方法、设备及介质 - Google Patents

Abstract

本说明书实施例公开了一种云原生应用的多集群运维方法、设备及介质，涉及云原生技术领域，方法包括：获取指定云原生应用的集群运维需求信息，集群运维需求信息包括至少一个已部署集群、指定云原生应用的当前应用版本信息和运维类型，运维类型包括部署运维类型、资源分配运维类型和版本更新运维类型；通过预置的文件下载接口根据集群运维需求信息中的指定云原生应用的当前应用版本信息，确定当前应用版本信息对应的当前版本应用部署文件包，当前版本应用部署文件包包括当前云原生集群数据模型；根据当前版本应用部署文件包和运维类型，对指定云原生应用进行多集群运维，提高应用部署运维效率，实现一次构建多处运行和云原生应用的动态资源分配。

Description

一种云原生应用的多集群运维方法、设备及介质

技术领域

本说明书涉及云原生技术领域，尤其涉及一种云原生应用的多集群运维方法、设备及介质。

背景技术

随着云原生的推广以及应用云原生容器化运行需求的增加，越来越多的应用开始寻求在容器集群内运行。在业务应用中，要实现复杂的业务逻辑和多样的系统业务功能，往往需要各种中间件应用的功能支持。尤其是微服务架构的应用，其复杂程度及需要的中间件数量更是直线上升，云原生集群部署此类应用的复杂程度自然也相应地增加。

以数据库为例，在云原生集群内运行一个标准的可用数据库，需要部署主程序工作负载、应用服务、持久化数据存储、数据保密字典、运行数据配置项等多种资源。对于业务应用来说，除去其自身逻辑需要资源外，业务应用所依赖的中间件都需要配置这些资源才可正常使用。在这种情况下，一套完整的微服务架构业务应用部署下来需要较多数量的云原生集群资源定义才能正常运行。当需要在多集群同时运行时，例如生产集群、测试集群、开发集群、仿真集群等，现有技术通常通过手动部署、手动运维的方式，对每个集群中的应用分别进行手动部署、手动运维。在手动部署的过程中，需要对业务应用及各中间件、网络插件等应用进行复杂数据配置；在进行手动运维时，为了操持相同版本应用的部署与运行的一致性，通常需要重复构建模型，在多集群运维过程中，产生了较大的工作量，并且手动操作存在操作失误的风险，导致应用运行失败。

因此，当需要在多集群同时运行时，通过手动部署、手动运维的方式，对每个集群中的应用分别进行手动运维，产生了较大的工作量，并且手动操作存在操作失误的风险，导致应用运行失败。

发明内容

本说明书一个或多个实施例提供了一种云原生应用的多集群运维方法、设备及介质，用于解决如下技术问题：当需要在多集群同时运行时，通过手动部署、手动运维的方式，对每个集群中的应用分别进行手动运维，产生了较大的工作量，并且手动操作存在操作失误的风险，导致应用运行失败。

本说明书一个或多个实施例采用下述技术方案：

本说明书一个或多个实施例提供一种云原生应用的多集群运维方法，所述方法包括：获取指定云原生应用的集群运维需求信息，其中，所述集群运维需求信息包括至少一个已部署集群、所述指定云原生应用的当前应用版本信息和运维类型，所述运维类型包括部署运维类型、资源分配运维类型和版本更新运维类型；通过预置的文件下载接口，根据所述集群运维需求信息中的所述指定云原生应用的当前应用版本信息，确定所述当前应用版本信息对应的当前版本应用部署文件包，其中，所述当前版本应用部署文件包包括当前云原生集群数据模型；根据所述当前版本应用部署文件包和所述运维类型，对所述指定云原生应用进行多集群运维。

可选地，在本说明书的一个或多个实施例中，获取指定云原生应用的集群运维需求信息之前，所述方法还包括：确定所述指定云原生应用的集群部署需求，其中，所述集群部署需求包括至少一个待部署集群；在运维用户对客户端页面组件的拖拽操作触发下，基于所述集群部署需求，获取所述指定云原生应用的云原生集群资源，以生成云原生集群数据模型；通过所述云原生集群数据模型，在所述至少一个待部署集群中进行多集群部署，实现所述指定云原生应用的多集群部署。

可选地，在本说明书的一个或多个实施例中，在运维用户对客户端页面组件的拖拽操作触发下，基于所述集群部署需求，获取所述指定云原生应用的云原生集群资源，以生成云原生集群数据模型，具体包括：获取预先设置在客户端的页面组件，其中，所述页面组件对应集群内多种类型资源；在所述运维用户对所述页面组件的拖拽操作触发下，根据所述集群部署需求，进行资源节点添加，以确定所述集群部署需求中所述至少一个待部署集群对应的多个类型资源节点；通过页面表单的方式，对每个所述类型资源节点添加配置数据，以生成云原生集群数据模型，其中，所述云原生集群数据模型为页面表单数据。

可选地，在本说明书的一个或多个实施例中，通过所述云原生集群数据模型，在所述至少一个待部署集群中进行多集群部署，具体包括：通过预先设置的前后端约定数据结构，对所述云原生集群数据模型进行解析，以将所述云原生集群数据模型对应的页面表单数据映射为服务端实体，确定每个所述服务端实体的实体字段；获取所述至少一个待部署集群对应的各类型描述资源内置模板，其中，所述各类型描述资源内置模板的模板结构和字段值固定；根据所述服务端实体对应的实体字段对应的字段数据，对所述各类型描述资源内置模板中的字段内容进行覆盖，生成所述云原生集群数据模型对应的当前模板内容；对所述当前模板内容进行合法性校验，并将所述当前模板内容批量部署至所述至少一个待部署集群中。

可选地，在本说明书的一个或多个实施例中，通过所述云原生集群数据模型，在所述至少一个待部署集群中进行多集群部署之后，所述方法还包括：对所述云原生集群数据模型进行解析，生成所述指定云原生应用的当前版本的应用部署文件包，其中，所述应用部署文件包为当前版本应用部署文件包；通过预先获取的所述指定云原生应用的应用标识和预先获取的部署时间戳，对所述应用部署文件包进行应用版本定义，并进行持久化存储，以通过预置的文件下载接口，下载指定版本应用部署文件包。

可选地，在本说明书的一个或多个实施例中，当所述运维类型为部署运维类型时，根据所述当前版本应用部署文件包和所述运维类型，对所述指定云原生应用进行多集群运维，具体包括：获取所述指定云原生应用的部署运维需求信息，其中，所述部署运维需求信息包括至少一个待运维部署集群；根据所述部署运维需求信息，确定所述至少一个待运维部署集群的集群配置文件，以通过所述集群配置文件对每个所述待运维部署集群进行集群预置，确定至少一个预置集群；将所述当前版本应用部署文件包，在每个所述预置集群中进行一键部署，以在每个所述待运维部署集群中部署所述指定云原生应用。

可选地，在本说明书的一个或多个实施例中，当所述运维类型为版本更新运维类型时，根据所述当前版本应用部署文件包和所述运维类型，对所述指定云原生应用进行多集群运维，具体包括：获取所述集群运维需求信息中的版本更新运维信息，其中，所述版本更新运维信息包括至少一个待修改模板数据；根据所述当前版本应用部署文件包，获取所述指定云原生应用对应的当前云原生集群数据模型；基于所述版本更新运维信息，对所述当前云原生集群数据模型进行修改，生成更新云原生集群数据模型；根据所述更新云原生集群数据模型，在所述至少一个已部署集群中进行多集群部署，实现所述指定云原生应用的版本更新运维。

可选地，在本说明书的一个或多个实施例中，当所述运维类型为资源分配运维类型时，根据所述当前版本应用部署文件包和所述运维类型，对所述指定云原生应用进行多集群运维，具体包括：根据所述当前版本应用部署文件包，获取所述指定云原生应用对应的当前云原生集群数据模型；获取所述集群运维需求信息中的资源分配运维信息，其中，所述资源分配运维信息包括至少一个待修改应用工作负载；基于所述资源分配运维信息，对所述当前云原生集群数据模型进行修改，实现工作负载的资源分配运维。

本说明书一个或多个实施例提供一种云原生应用的多集群运维设备，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述方法。

本说明书一个或多个实施例提供的一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：

获取指定云原生应用的集群运维需求信息，其中，所述集群运维需求信息包括至少一个已部署集群、所述指定云原生应用的当前应用版本信息和运维类型，所述运维类型包括部署运维类型、资源分配运维类型和版本更新运维类型；通过预置的文件下载接口，根据所述集群运维需求信息中的所述指定云原生应用的当前应用版本信息，确定所述当前应用版本信息对应的当前版本应用部署文件包，其中，所述当前版本应用部署文件包包括当前云原生集群数据模型；根据所述当前版本应用部署文件包和所述运维类型，对所述指定云原生应用进行多集群运维。

本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：通过上述技术方案，通过当前版本应用部署文件包的优化，满足多种运维场景，在部署运维场景中，提高应用部署效率，数据模型的统一优化可以大量减少大型业务系统中的业务应用及各中间件、网络插件等应用手动部署的复杂数据配置，有效避免手动部署失误导致应用运行失败的问题；在版本更新运维场景中，由数据模型生成应用部署文件包，可实现一次构建多处运行，避免重复构建模型的工作并且保持相同版本应用的部署与运行的一致性；在资源分配运维场景中，实现云原生应用的动态资源分配以及应用的多集群批量在线运维支持，减少多集群手动运维成本。

附图说明

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

图1为本说明书实施例提供的一种云原生应用的多集群运维方法的流程示意图；

图2为本说明书实施例提供的一种云原生应用的多集群运维方法的应用示意图；

图3为本说明书实施例提供的一种云原生应用的多集群运维设备的结构示意图。

具体实施方式

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

随着云原生的推广以及应用云原生容器化运行需求的增加，越来越多的应用开始寻求在容器集群内运行。在业务应用中，要实现复杂的业务逻辑和多样的系统业务功能，往往需要各种中间件应用的功能支持。尤其是微服务架构的应用，其复杂程度及需要的中间件数量更是直线上升，云原生集群部署此类应用的复杂程度自然也相应地增加。

以数据库为例，在云原生集群内运行一个标准的可用数据库，需要部署主程序工作负载、应用服务、持久化数据存储、数据保密字典、运行数据配置项等多种资源。对于业务应用来说，除去其自身逻辑需要资源外，业务应用所依赖的中间件都需要配置这些资源才可正常使用。在这种情况下，一套完整的微服务架构业务应用部署下来需要较多数量的云原生集群资源定义才能正常运行。当需要在多集群同时运行时，例如生产集群、测试集群、开发集群、仿真集群等，现有技术通常通过手动部署、手动运维的方式，对每个集群中的应用分别进行手动部署、手动运维，在手动部署的过程中，需要对业务应用及各中间件、网络插件等应用进行复杂数据配置，在进行手动运维时，为了操持相同版本应用的部署与运行的一致性，通常需要重复构建模型，在多集群运维过程中，产生了较大的工作量，并且手动操作存在操作失误的风险，导致应用运行失败。

因此，当需要在多集群同时运行时，通过手动部署、手动运维的方式，对每个集群中的应用分别进行手动运维，产生了较大的工作量，并且手动操作存在操作失误的风险，导致应用运行失败。

本说明书实施例提供一种云原生应用的多集群运维方法，需要说明的是，本说明书实施例中的执行主体可以是服务器，也可以是任意一种具备数据处理能力的设备。图1为本说明书实施例提供的一种云原生应用的多集群运维方法的流程示意图，如图1所示，主要包括如下步骤：

步骤S101，获取指定云原生应用的集群运维需求信息。

其中，该集群运维需求信息包括至少一个已部署集群、该指定云原生应用的当前应用版本信息和运维类型，该运维类型包括部署运维类型、资源分配运维类型和版本更新运维类型。

在本说明书的一个实施例中，指定云原生应用的集群运维需求信息是指对已经在至少一个集群中部署了此指定云原生应用的运行维护，集群运维需求信息包括至少一个已部署集群、该指定云原生应用的当前应用版本信息和运维类型，至少一个已部署集群是指指定云原生应用当前已部署的集群，当前应用版本信息是指此指定云原生应用的部署版本，运维类型用于对运维进行标识，包括部署运维类型、资源分配运维类型和版本更新运维类型。需要说明的是，部署运维类型是指将指定云原生应用部署至其他的集群中，资源分配运维类型是指对指定云原生应用的进行资源分配，版本更新运维类型是指当指定云原生应用的版本更新时或应用修改时，在至少一个已部署集群中进行指定云原生应用的版本更新运维。

获取指定云原生应用的集群运维需求信息之前，该方法还包括：确定该指定云原生应用的集群部署需求，其中，该集群部署需求包括至少一个待部署集群；在运维用户对客户端页面组件的拖拽操作触发下，基于该集群部署需求，获取该指定云原生应用的云原生集群资源，以生成云原生集群数据模型；通过该云原生集群数据模型，在该至少一个待部署集群中进行多集群部署，实现该指定云原生应用的多集群部署。

在本说明书的一个实施例中，在进行多集群运维之前，需要预先将指定云原生应用在初次部署阶段，部署至至少应该待部署集群中。首先，可以通过在客户端页面输入的形式获取指定云原生应用的集群部署需求，此处的集群部署需求包括至少一个待部署集群。在客户端页面中设置有页面组件，页面组件对应云原生集群应用部署及配置等相关资源类型，例如工作负载、保密字典、配置项、持久化存储等。通过客户端页面组件的拖拽及必要数据的填写，在线生成模型化数据，即生成云原生集群数据模型，经过数据校验后传入服务端。服务端对云原生集群数据模型进行解析处理，转化为云原生集群所需资源，并连接该至少一个待部署集群，并在至少一个待部署集群中进行业务应用及各相关中间件应用的部署。

在运维用户对客户端页面组件的拖拽操作触发下，基于该集群部署需求，获取该指定云原生应用的云原生集群资源，以生成云原生集群数据模型，具体包括：获取预先设置在客户端的页面组件，其中，该页面组件对应集群内多种类型资源；在该运维用户对该页面组件的拖拽操作触发下，根据该集群部署需求，进行资源节点添加，以确定该集群部署需求中该至少一个待部署集群对应的多个类型资源节点；通过页面表单的方式，对每个该类型资源节点添加配置数据，以生成云原生集群数据模型，其中，该云原生集群数据模型为页面表单数据。

在本说明书的一个实施例中，以如下场景为例进行说明，一个简单的微服务场景应用系统，分为三个微服务业务应用，需要一个消息中间件、一个数据库、一个redis缓存库以及注册发现中心应用共计需要部署7个云原生集群应用资源，同时需要配套4个保密字典用于存储各中间件的用户名密码、2个配置项用于配置数据库及redis缓存库的配置内容，4个持久化存储挂载用于中间件的持久化容灾备份，合计共17个云原生集群资源。需要说明的是，可以将微服务场景应用系统拆分为三个微服务业务应用，可以提高应用的高可用性。

获取预先设置在客户端的页面组件，获取页面组件对应集群内各类型资源，例如工作负载、保密字典、配置项、持久化存储等，此处的页面组件对应集群内多种类型资源，用户通过组件拖拽方式进行资源节点添加，得到集群部署需求中该至少一个待部署集群对应的多个类型资源节点。通过页面表单对上述得到的不同类型的多个类型资源节点添加必要配置数据，例如用户名/密码、持久存储大小、应用镜像、数据库镜像、数据库配置等。对各个类型资源节点的节点数据通过页面表单进行校验，校验通过后，将各个类型资源节点的表单数据组合后传入服务端。

除通过客户端界面进行模型数据生成后再传入服务端外，服务端也可接收云原生集群原生数据结构并进行数据逻辑解析处理，生成对应模型与文件包并进行应用部署以及资源的持久化存储，即数据模型由云原生集群资源反向生成。

通过该云原生集群数据模型，在该至少一个待部署集群中进行多集群部署，具体包括：通过预先设置的前后端约定数据结构，对该云原生集群数据模型进行解析，以将该云原生集群数据模型对应的页面表单数据映射为服务端实体，确定每个该服务端实体的实体字段；获取该至少一个待部署集群对应的各类型描述资源内置模板，其中，该各类型描述资源内置模板的模板结构和字段值固定；根据该服务端实体对应的实体字段对应的字段数据，对该各类型描述资源内置模板中的字段内容进行覆盖，生成该云原生集群数据模型对应的当前模板内容；对该当前模板内容进行合法性校验，并将该当前模板内容批量部署至该至少一个待部署集群中。

在本说明书的一个实施例中，在服务端预先设置有前后端约定数据结构，也可以称为前后端约定模型，其作用在于将用户在客户端页面中的界面操作对应的数据转化为集群要求的集群复杂数据结构。通过前后端约定数据结构，对云原生集群数据模型进行解析，以将云原生集群数据模型对应的页面表单数据映射为服务端实体，确定每个服务端实体的实体字段。需要说明的是，云原生集群数据模型通过用户在客户端页面中的界面操作得到，即云原生集群数据模型对应的数据为必填的配置数据，除了必填的配置数据之外，还存在固定的数据，因此，获取该至少一个待部署集群对应的各类型描述资源内置模板，各类型描述资源内置模板的模板结构和字段值固定。读取服务端实体对应字段的数据，将服务端实体对应字段的数据对各类型描述资源内置模板中对应的字段内容进行覆盖，生成新的模板内容，即当前模板内容。对当前模板内容进行合法性校验，例如，可以通过非空检测的方式，若每个字段的字段值或字段内容为非空值，则通过合法性校验，将该当前模板内容批量部署至该至少一个待部署集群中。

通过上述技术方案，通过创建云原生集群数据模型的方式，配置云原生系统应用及其相关支持应用的部署模型数据，服务端通过对模型数据的解析与转换，生成云原生集群运行应用所需的资源并进行应用批量部署，由数据模型生成应用部署文件包，可实现应用一次构建多处运行，避免重复构建模型的工作并且保持相同版本应用的部署与运行的一致性。

通过该云原生集群数据模型，在该至少一个待部署集群中进行多集群部署之后，该方法还包括：对该云原生集群数据模型进行解析，生成该指定云原生应用的当前版本的应用部署文件包，其中，该应用部署文件包为当前版本应用部署文件包；通过预先获取的该指定云原生应用的应用标识和预先获取的部署时间戳，对该应用部署文件包进行应用版本定义，并进行持久化存储，以通过预置的文件下载接口，下载指定版本应用部署文件包。

在本说明书的一个实施例中，服务端通过对传入的模型化数据，即云原生集群数据模型进行解析，生成应用部署文件包。通过指定云原生应用的应用标识和部署时间戳，进行应用版本定义，例如应用系统名称+时间戳的形式。对应用部署文件包进行持久化存储，为文件包下载及版本回滚提供支持。通过下载指定版本的应用部署文件包，可将其解压后直接通过集群内置命令行工具进行部署或版本回滚，此功能同样可通过前端页面一键回滚实现。

下载服务端存储的应用部署文件包后，可以在任意集群内通过运行命令行的方式快速部署应用，即定义一次应用模型后，无需在新云原生集群内再次定义模型即可实现同一版本业务应用的全新部署。

步骤S102，通过预置的文件下载接口，根据集群运维需求信息中的指定云原生应用的当前应用版本信息，确定当前应用版本信息对应的当前版本应用部署文件包。

其中，该当前版本应用部署文件包包括当前云原生集群数据模型。

在本说明书的一个实施例中，通过文件下载接口，根据集群运维需求信息中的指定云原生应用的当前应用版本信息，在多个应用部署文件包中进行查找，确定当前应用版本信息对应的当前版本应用部署文件包，此处的当前应用版本信息包括当前应用版本的部署时间戳以及指定云原生应用的应用标识，通过部署时间戳和应用标识的形式匹配当前版本应用部署文件包。

步骤S103，根据当前版本应用部署文件包和该运维类型，对指定云原生应用进行多集群运维。

当该运维类型为部署运维类型时，根据该当前版本应用部署文件包和该运维类型，对该指定云原生应用进行多集群运维，具体包括：获取该指定云原生应用的部署运维需求信息，其中，该部署运维需求信息包括至少一个待运维部署集群；根据该部署运维需求信息，确定该至少一个待运维部署集群的集群配置文件，以通过该集群配置文件对每个该待运维部署集群进行集群预置，确定至少一个预置集群；将该当前版本应用部署文件包，在每个该预置集群中进行一键部署，以在每个该待运维部署集群中部署该指定云原生应用。

在本说明书的一个实施例中，当该运维类型为部署运维类型时，即指定云原生应用在当前已经部署至已部署集群的情况下，需要再部署至其他集群中。首先获取指定云原生应用的部署运维需求信息，此处的部署运维需求信息包括至少一个待运维部署集群，即需要额外部署的集群。例如某大型公司云原生集群微服务应用容器化部署运维场景，需要在云原生集群内部署三个功能不同的微服务应用、一个主注册中心、一个从注册中心、一个主数据库、一个从数据库、一个缓存、一个消息队列共计9个应用及其相关的集群资源，目前已经在开发环境、测试环境中进行了部署，需要在仿真演示环境以及生产环境中进行部署运维，此处的环境为集群。首先，根据部署运维需求信息，确定至少一个待运维部署集群的集群配置文件，运维人员通过客户端页面上传集群配置文件，对各个集群进行集群预置，此处可传入多个集群配置。需要说明的是，由于已经在开发环境、测试环境中进行了部署，说明运维人员在开发环境、测试环境部署时，通过在客户端页面将9个应用的部署配置及运行参数通过界面化操作完成定义，由客户端生成模型数据并传至服务端进行云原生集群应用部署与模型存储。因此，运维人员可以通过客户端的文件下载接口处，下载指定版本持久数据结构化文件包，即对应当前版本应用部署文件包，可在其他未预置的集群中进行一键部署，需要说明的是，当前版本应用部署文件包中的模板数据在不同集群中是通用的。通过上述技术方案，在部署运维类型的运维场景下，避免了重复构建数据模型，减少了工作量，实现了应用一次构建、多处运行，有效避免了手动运维部署的部署失误。

当该运维类型为版本更新运维类型时，根据该当前版本应用部署文件包和该运维类型，对该指定云原生应用进行多集群运维，具体包括：获取该集群运维需求信息中的版本更新运维信息，其中，该版本更新运维信息包括至少一个待修改模板数据；根据该当前版本应用部署文件包，获取该指定云原生应用对应的当前云原生集群数据模型；基于该版本更新运维信息，对该当前云原生集群数据模型进行修改，生成更新云原生集群数据模型；根据该更新云原生集群数据模型，在该至少一个已部署集群中进行多集群部署，实现该指定云原生应用的版本更新运维。

在本说明书的一个实施例中，该运维类型为版本更新运维类型，此处的更新除了新旧版本更新之外，还包括迭代更新，也就是说，除了更新前后存在区别的新旧版本更新之外，还包括未产生变化的迭代更新，即便内容完全一致也是新迭代，只要通过接口传入服务端即被视为更新迭代，用户将通过时间戳进行迭代版本的识别。通过对版本更新范围的扩展，可以适用于应用的多种维护场景，例如在某种场景下，本月需要使用上个月应用的数据，为了保证每个月都存在数据基础，需要每个月对应用进行迭代一次，即便内容完全一致也需要通过接口传入进行一次迭代更新。

当该运维类型为版本更新运维类型时，首先，获取集群运维需求信息中的版本更新运维信息，版本更新运维信息包括至少一个待修改模板数据。根据当前版本应用部署文件包，获取指定云原生应用对应的当前云原生集群数据模型。基于版本更新运维信息，在客户端页面中进行数据修改，通过在客户端页面的数据修改操作，对当前云原生集群数据模型进行修改，生成更新云原生集群数据模型。根据更新云原生集群数据模型，在该至少一个已部署集群中进行多集群部署，实现指定云原生应用的版本更新运维。此外，在完成部署之后生成新版本的应用部署文件包，并通过对时间戳的更新生成最新版本的应用部署文件包。由数据模型生成应用部署文件包，可实现应用一次构建多处运行，避免重复构建模型的工作并且保持相同版本应用的部署与运行一致性。

当该运维类型为资源分配运维类型时，根据该当前版本应用部署文件包和该运维类型，对该指定云原生应用进行多集群运维，具体包括：根据该当前版本应用部署文件包，获取该指定云原生应用对应的当前云原生集群数据模型；获取该集群运维需求信息中的资源分配运维信息，其中，该资源分配运维信息包括至少一个待修改应用工作负载；基于该资源分配运维信息，对该当前云原生集群数据模型进行修改，实现工作负载的资源分配运维。

在本说明书的一个实施例中，当该运维类型为资源分配运维类型时，通过客户端页面可进行集群内应用的资源动态分配。可通过如下两种方式实现动态资源分配，第一种方式通过云原生集群内置的水平自动扩展和缩减资源（Horizontal Pod Autoscaling，HPA）实现。在应用的初始部署阶段或新版本更新阶段，通过页面通过拖拽HPA组件节点并填写资源配置的方式增加HPA资源；填写资源配置（CPU\内存）后，通过绑定指定工作负载节点即可为指定应用工作负载设置水平自动扩缩。第二种方式是通过定义应用工作负载类型资源的资源配置实现。在应用的初始部署阶段或新版本更新阶段，定义或修改应用工作负载的资源配置内容（CPU\内存）可实现动态更新工作负载的资源分配与再次修改。

此外，通过客户端页面还可进行运维管理，例如应用日志查看、集群事件、容器副本数修改等。其中日志、集群事件查看主要用于对问题应用的日志分析处理，确定问题原因，此功能可通过调取云原生集群api接口实现或通过页面请求服务端进行日志及集群事件的下载查看。应用副本数的修改主要用于处理应用访问压力适配的场景，通过客户端页面进行现有模型数据的编辑修改，修改指定应用的副本数配置数据，可进行指定应用工作负载的副本数的修改。

通过上述技术方案，通过当前版本应用部署文件包的优化，实现多种运维场景，在部署运维场景中，提高应用部署效率，数据模型的统一优化可以大量减少大型业务系统中的业务应用及各中间件、网络插件等应用手动部署的复杂数据配置，有效避免手动部署失误导致应用运行失败的问题；在版本更新运维场景中，由数据模型生成应用部署文件包，可实现应用一次构建多处运行，避免重复构建模型的工作并且保持相同版本应用的部署与运行的一致性；在资源分配运维场景中，实现云原生应用的动态资源分配以及应用的多集群批量在线运维支持，减少多集群手动运维成本。

图2为本说明书实施例提供的一种云原生应用的多集群运维方法的应用示意图，如图2所示，第一步，用户在客户端页面中进行在线界面操作，生成当前云原生集群数据模型，将当前云原生集群数据模型传入服务端，服务端对当前云原生集群数据模型进行解析，生成云原生数据结构文件包，即当前版本应用部署文件包。第二步，根据当前版本应用部署文件包，使用云原生数据对指定云原生应用进行部署。第三步，将当前版本应用部署文件包和模型数据进行持久化存储。第四步，在需要进行运维时，通过文件下载接口进行持久化数据读取，通过服务端读取到的云原生数据结构文件包，获取当前云原生集群数据模型，将当前云原生集群数据模型发送至客户端，由用户在客户端修改模型数据产生新版本。

通过上述技术方案，通过创建云原生集群数据模型的方式，配置云原生系统应用及其相关支持应用的部署模型数据，服务端通过对模型数据的解析与转换，生成云原生集群运行应用所需的资源并进行应用批量部署（同时多集群部署），并生成应用部署文件包进行应用的版本构建存储与迭代发布。同时，通过对模型数据的修改，可快速实现应用资源（CPU、内存）的动态分配、日志查看及副本扩缩等运维需求。

本说明书实施例还提供一种云原生应用的多集群运维设备，如图3所示，设备包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够上述方法。

本说明书实施例还提供一种非易失性计算机存储介质，存储有计算机可执行指令，计算机可执行指令设置为：获取指定云原生应用的集群运维需求信息，其中，该集群运维需求信息包括至少一个已部署集群、该指定云原生应用的当前应用版本信息和运维类型，该运维类型包括部署运维类型、资源分配运维类型和版本更新运维类型；通过预置的文件下载接口，根据该集群运维需求信息中的该指定云原生应用的当前应用版本信息，确定该当前应用版本信息对应的当前版本应用部署文件包，其中，该当前版本应用部署文件包包括当前云原生集群数据模型；根据该当前版本应用部署文件包和该运维类型，对该指定云原生应用进行多集群运维。

Claims (10)

1.一种云原生应用的多集群运维方法，其特征在于，所述方法包括：

获取指定云原生应用的集群运维需求信息，其中，所述集群运维需求信息包括至少一个已部署集群、所述指定云原生应用的当前应用版本信息和运维类型，所述运维类型包括部署运维类型、资源分配运维类型和版本更新运维类型；

通过预置的文件下载接口，根据所述集群运维需求信息中的所述指定云原生应用的当前应用版本信息，确定所述当前应用版本信息对应的当前版本应用部署文件包，其中，所述当前版本应用部署文件包包括当前云原生集群数据模型；

根据所述当前版本应用部署文件包和所述运维类型，对所述指定云原生应用进行多集群运维。

2.根据权利要求1所述的一种云原生应用的多集群运维方法，其特征在于，获取指定云原生应用的集群运维需求信息之前，所述方法还包括：

确定所述指定云原生应用的集群部署需求，其中，所述集群部署需求包括至少一个待部署集群；

在运维用户对客户端页面组件的拖拽操作触发下，基于所述集群部署需求，获取所述指定云原生应用的云原生集群资源，以生成云原生集群数据模型；

通过所述云原生集群数据模型，在所述至少一个待部署集群中进行多集群部署，实现所述指定云原生应用的多集群部署。

3.根据权利要求2所述的一种云原生应用的多集群运维方法，其特征在于，在运维用户对客户端页面组件的拖拽操作触发下，基于所述集群部署需求，获取所述指定云原生应用的云原生集群资源，以生成云原生集群数据模型，具体包括：

获取预先设置在客户端的页面组件，其中，所述页面组件对应集群内多种类型资源；

在所述运维用户对所述页面组件的拖拽操作触发下，根据所述集群部署需求，进行资源节点添加，以确定所述集群部署需求中所述至少一个待部署集群对应的多个类型资源节点；

通过页面表单的方式，对每个所述类型资源节点添加配置数据，以生成云原生集群数据模型，其中，所述云原生集群数据模型为页面表单数据。

4.根据权利要求2所述的一种云原生应用的多集群运维方法，其特征在于，通过所述云原生集群数据模型，在所述至少一个待部署集群中进行多集群部署，具体包括：

通过预先设置的前后端约定数据结构，对所述云原生集群数据模型进行解析，以将所述云原生集群数据模型对应的页面表单数据映射为服务端实体，确定每个所述服务端实体的实体字段；

获取所述至少一个待部署集群对应的各类型描述资源内置模板，其中，所述各类型描述资源内置模板的模板结构和字段值固定；

根据所述服务端实体对应的实体字段对应的字段数据，对所述各类型描述资源内置模板中的字段内容进行覆盖，生成所述云原生集群数据模型对应的当前模板内容；

对所述当前模板内容进行合法性校验，并将所述当前模板内容批量部署至所述至少一个待部署集群中。

5.根据权利要求2所述的一种云原生应用的多集群运维方法，其特征在于，通过所述云原生集群数据模型，在所述至少一个待部署集群中进行多集群部署之后，所述方法还包括：

对所述云原生集群数据模型进行解析，生成所述指定云原生应用的当前版本的应用部署文件包，其中，所述应用部署文件包为当前版本应用部署文件包；

通过预先获取的所述指定云原生应用的应用标识和预先获取的部署时间戳，对所述应用部署文件包进行应用版本定义，并进行持久化存储，以通过预置的文件下载接口，下载指定版本应用部署文件包。

6.根据权利要求1所述的一种云原生应用的多集群运维方法，其特征在于，当所述运维类型为部署运维类型时，根据所述当前版本应用部署文件包和所述运维类型，对所述指定云原生应用进行多集群运维，具体包括：

获取所述指定云原生应用的部署运维需求信息，其中，所述部署运维需求信息包括至少一个待运维部署集群；

根据所述部署运维需求信息，确定所述至少一个待运维部署集群的集群配置文件，以通过所述集群配置文件对每个所述待运维部署集群进行集群预置，确定至少一个预置集群；

将所述当前版本应用部署文件包，在每个所述预置集群中进行一键部署，以在每个所述待运维部署集群中部署所述指定云原生应用。

7.根据权利要求1所述的一种云原生应用的多集群运维方法，其特征在于，当所述运维类型为版本更新运维类型时，根据所述当前版本应用部署文件包和所述运维类型，对所述指定云原生应用进行多集群运维，具体包括：

获取所述集群运维需求信息中的版本更新运维信息，其中，所述版本更新运维信息包括至少一个待修改模板数据；

根据所述当前版本应用部署文件包，获取所述指定云原生应用对应的当前云原生集群数据模型；

基于所述版本更新运维信息，对所述当前云原生集群数据模型进行修改，生成更新云原生集群数据模型；

根据所述更新云原生集群数据模型，在所述至少一个已部署集群中进行多集群部署，实现所述指定云原生应用的版本更新运维。

8.根据权利要求1所述的一种云原生应用的多集群运维方法，其特征在于，当所述运维类型为资源分配运维类型时，根据所述当前版本应用部署文件包和所述运维类型，对所述指定云原生应用进行多集群运维，具体包括：

根据所述当前版本应用部署文件包，获取所述指定云原生应用对应的当前云原生集群数据模型；

获取所述集群运维需求信息中的资源分配运维信息，其中，所述资源分配运维信息包括至少一个待修改应用工作负载；

基于所述资源分配运维信息，对所述当前云原生集群数据模型进行修改，实现工作负载的资源分配运维。

9.一种云原生应用的多集群运维设备，其特征在于，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1-8任一所述的方法。

10.一种非易失性计算机存储介质，存储有计算机可执行指令，其特征在于，所述计算机可执行指令设置为：

获取指定云原生应用的集群运维需求信息，其中，所述集群运维需求信息包括至少一个已部署集群、所述指定云原生应用的当前应用版本信息和运维类型，所述运维类型包括部署运维类型、资源分配运维类型和版本更新运维类型；

通过预置的文件下载接口，根据所述集群运维需求信息中的所述指定云原生应用的当前应用版本信息，确定所述当前应用版本信息对应的当前版本应用部署文件包，其中，所述当前版本应用部署文件包包括当前云原生集群数据模型；

根据所述当前版本应用部署文件包和所述运维类型，对所述指定云原生应用进行多集群运维。