CN114398208A - 一种无状态应用的跨集群备份方法、系统、介质和设备 - Google Patents

Abstract

本申请提供了一种无状态应用的跨集群备份方法、系统、计算机可读存储介质和电子设备。该方法由部署在第一集群上的灾备系统执行，包括：对部署在第一集群上的待备份的无状态应用对应的资源文件进行监听；响应于无状态应用对应的资源文件产生变化，获取无状态应用对应的资源文件；基于预设的配置对无状态应用对应的资源文件中指定字段的内容进行修改；将修改后的待备份的无状态应用对应的资源文件同步至第二集群，以将无状态应用从第一集群同步至第二集群。籍此，通过灾备系统将第一集群上的无状态应用的资源文件实时同步至第二集群后，即可实现对部署在第一集群上的无状态应用的实时备份。

Description

一种无状态应用的跨集群备份方法、系统、介质和设备

技术领域

本申请涉及云原生技术领域，特别涉及一种无状态应用的跨集群备份方法、系统、计算机可读存储介质和电子设备。

背景技术

在生产实践中，企业通常采用主/备集群部署模式来部署应用实例，即将应用实例分别部署在主集群和备用集群上，并且将主集群上的应用实例的运行状态实时同步至备用集群上，当主集群出现故障无法正常对外部访问流量进行响应时，由备用集群代替主集群进行响应。

通过手动部署的方式将应用实例分别部署在主集群和备用集群上，在对主集群上的应用实例手动进行变更和升级后，还需要对备用集群上的应用实例手动进行相同的变更和升级，以确保分别部署在主集群和备用集群上的应用实例的运行状态保持一致。

随着服务网络和微服务技术的发展，将云原生应用以微服务架构进行部署已经成为了技术发展的趋势，微服务架构通过独立部署和运行一系列的低耦合微服务应用来构建分布式应用，由于微服务之间的相互影响小，单个微服务应用的变更和升级对同一分布式应用下其它微服务应用的影响也小，在生产实践中用于构建分布式应用的微服务应用的变更和升级变得十分频繁。

手动对微服务应用频繁地进行变更和升级，操作繁琐，且一旦操作出错，将导致微服务应用实例的运行状态同步失败，备用集群上部署的分布式应用实例无法在主集群出现故障时代替主集群上的分布式应用实例对外部访问流量进行响应。

因此，需要提供一种针对上述现有技术不足的改进技术方案。

发明内容

本申请的目的在于提供一种无状态应用的跨集群备份方法、系统、计算机可读存储介质和电子设备，以解决或缓解上述现有技术中存在的问题。

为了实现上述目的，本申请提供如下技术方案：

本申请提供了一种无状态应用的跨集群备份方法，所述方法由部署在第一集群上的灾备系统执行，包括：对部署在所述第一集群上的待备份的无状态应用对应的资源文件进行监听；所述资源文件包括应用描述文件、配置文件中的至少一种；响应于所述无状态应用对应的资源文件产生变化，获取所述无状态应用对应的资源文件；基于预设的配置对所述无状态应用对应的资源文件中指定字段的内容进行修改；将修改后的待备份的所述无状态应用对应的资源文件同步至第二集群，以将所述无状态应用从所述第一集群同步至所述第二集群。

优选的，所述第一集群为Kubernetes集群，对待备份的无状态应用对应的资源文件进行监听，包括：与所述第一集群上的API-Server组件之间建立长连接；通过所述长连接对所述待备份的无状态应用对应的资源文件的变化事件进行监听；或者，周期性地访问所述第一集群上的API-Server组件，以获取待备份的所述无状态应用对应的资源文件；对多次获取的待备份的所述无状态应用对应的资源文件进行比对，以确定待备份的所述无状态应用对应的资源文件产生变化。

优选的，所述基于预设的配置对所述无状态应用对应的资源文件中指定字段的内容进行修改，包括：对预先写入的应用管理资源对象进行解析；所述应用管理资源对象用于指定所述第二集群和所述无状态应用对应的资源文件中待修改的字段，以及设置对所述指定字段进行修改的顺序；根据所述应用管理资源对象，按顺序对所述无状态应用对应的资源文件中指定字段的内容进行修改，以符合所述第二集群的运行要求；所述指定字段包括IP地址、镜像仓库中的至少一个。

优选的，所述根据所述应用管理资源对象，按顺序对所述无状态应用对应的资源文件中指定字段的内容进行修改，包括：根据所述应用管理资源对象，实例化出至少一个资源修改单元；所述至少一个资源修改单元组成资源修改流水线，所述资源修改流水线用于按照指定顺序对所述指定字段的内容进行修改，每个所述资源修改单元用于修改对应的所述指定字段的内容；响应于所述无状态应用对应的资源文件输入所述资源修改流水线，按所述指定顺序对待备份的所述无状态应用对应的资源文件中的所述指定字段的内容进行修改。

优选的，在所述对待备份的无状态应用对应的资源文件进行监听之前，还包括：对所述应用管理资源对象进行解析，以确定所述待备份的无状态应用。

优选的，还包括：从多集群管理系统获取所述第二集群的访问认证信息；所述多集群管理系统用于管理所述第一集群和所述第二集群，所述访问认证信息包括证书、密钥、令牌中的至少一种。

优选的，所述第二集群为Kubernetes集群，所述将修改后的所述待备份的无状态应用对应的资源文件同步至第二集群，具体为：基于所述第二集群的访问认证信息，对所述第二集群进行访问；通过所述第二集群的API-Server组件，将所述待备份的无状态应用对应的资源文件写入所述第二集群的分布式状态存储数据库。

本申请实施例还提供一种无状态应用的跨集群备份系统，该系统部署在第一集群上，包括：监听单元，配置为对部署在所述第一集群上的待备份的无状态应用对应的资源文件进行监听；所述资源文件包括应用描述文件、配置文件中的至少一种；文件获取单元，配置为响应于所述无状态应用对应的资源文件产生变化，获取所述无状态应用对应的资源文件；文件修改单元，配置为基于预设的配置对所述无状态应用对应的资源文件中的指定字段的内容进行修改；同步单元，配置为将修改后的待备份的所述无状态应用对应的资源文件同步至第二集群，以将所述无状态应用从所述第一集群同步至所述第二集群。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序为如上任一所述的无状态应用的跨集群备份方法。

本申请实施例还提供一种电子设备，包括：存储器、处理器、以及存在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如上任一所述的无状态应用的跨集群备份方法。

有益效果：

本申请提供的无状态应用的跨集群备份技术由部署在第一集群上的灾备系统执行，通过对部署在第一集群上的待备份的无状态应用对应的资源文件(包括应用描述文件、配置文件中的至少一种)进行监听。当无状态应用对应的资源文件发生变化时，获取无状态应用对应的资源文件，基于预设的配置对无状态应用对应的资源文件中指定字段的内容进行修改。将修改后的待备份的无状态应用对应的资源文件同步至第二集群，以将无状态应用从第一集群同步至第二集群。籍此，通过灾备系统将第一集群上的无状态应用的资源文件实时同步至第二集群后，即可实现对部署在第一集群上的无状态应用的实时备份。

附图说明

构成本申请的一部分的说明书附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。其中：

图1为根据本申请的一些实施例提供的一种无状态应用的跨集群备份方法的流程示意图；

图2为根据本申请的一些实施例提供的获取无状态应用对应的资源文件的逻辑示意图；

图3为根据本申请的一些实施例提供的一种无状态应用的跨集群备份方法中步骤S103的流程示意图；

图4为根据本申请的一些实施例提供的应用管理员向灾备系统写入应用管理资源对象的逻辑示意图；

图5为根据本申请的一些实施例提供的对无状态应用对应的资源文件进行修改的逻辑示意图；

图6为根据本申请的一些实施例提供的多集群管理员为灾备系统提供集群访问认证信息的逻辑示意图；

图7为根据本申请的一些实施例提供的无状态应用对应的资源文件同步传输的逻辑示意图；

图8为根据本申请的一些实施例提供的一种无状态应用的跨集群备份系统的结构示意图；

图9为根据本申请的一些实施例提供的一种电子设备的结构示意图；

图10为根据本申请的一些实施例提供的一种电子设备的硬件结构。

具体实施方式

下面将参考附图并结合实施例来详细说明本申请。各个示例通过本申请的解释的方式提供而非限制本申请。实际上，本领域的技术人员将清楚，在不脱离本申请的范围或精神的情况下，可在本申请中进行修改和变型。例如，示为或描述为一个实施例的一部分的特征可用于另一个实施例，以产生又一个实施例。因此，所期望的是，本申请包含归入所附权利要求及其等同物的范围内的此类修改和变型。

基于前述对背景技术的说明，可以知道，现有技术中，企业采用主/备集群部署模式来部署分布式应用实例，每个分布式应用实例由至少一个微服务应用实例构建形成。

具体地，在将分布式应用实例分别部署在主集群和备用集群上以后，还需要将主集群上的分布式应用实例的运行状态实时同步至备用集群上，即需要将主集群上用于构建分布式应用实例的所有微服务应用实例的运行状态实时同步至备用集群。

根据是否需要持久化存储数据，可以将微服务应用分为无状态应用和有状态应用。在部署无状态应用时，只需要对无状态应用对应的应用描述文件(Deployment)、配置文件(ConfigMap)等资源文件的内容进行编辑，并将资源文件部署在集群上，即可将该无状态应用部署在集群上。相应地，只需要对该无状态应用对应的应用描述文件、配置文件等资源文件的内容进行修改，即可对该无状态应用的运行状态进行变更。

采用主/备集群部署模式来部署无状态应用时，需要应用管理员将部署在主集群上的该无状态应用对应的资源文件在备用集群上手动重新部署一次。此外，在无状态应用运行维护过程中，每当应用管理员对部署在主集群上的该无状态应用对应的资源文件的内容进行编辑修改后，都需要手动对部署在备用集群上的该无状态应用对应的资源文件内容进行相同的编辑修改，以确保分别部署在主集群和备用集群上的该无状态应用的应用实例的运行状态保持一致。

通过手动部署、编辑修改资源文件内容的方式来对不同集群上的无状态应用的应用实例进行部署和运行状态进行同步，在对无状态应用进行频繁地变更和升级时，需要应用管理员对无状态应用对应的资源文件进行繁琐的编辑操作，一旦该无状态应用对应的某个资源文件部署出错，或者其中某个字段编辑修改出错，都会导致该无状态应用的同步失败。

申请人对无状态应用的上述特点进行深入研究后发现，要实现在备用集群上对无状态应用进行部署和运行状态的同步，关键是将主集群上无状态应用对应的应用描述文件、配置文件等资源文件的内容实时同步至备用集群。基于此，申请人提出了一种无状态应用的跨集群备份方法。

为了便于说明，本申请实施例中将主集群称作第一集群，将备用集群称作第二集群。

需要说明的是，在本申请实施例中，第一集群为待备份的无状态应用所在的集群，第二集群为应用管理员指定的备用集群。在生产实践中，应用管理员可以为待备份的无状态应用指定一个或者多个备用集群，本申请实施例以指定一个备用集群的情况进行说明，不作为对本申请实施例的限定。

示例性方法

如图1所示，该无状态应用的跨集群备份方法由部署在第一集群上的灾备系统执行，包括：

步骤S110、对部署在第一集群上的待备份的无状态应用对应的资源文件进行监听。

其中，资源文件包括应用描述文件、配置文件中的至少一种。

基于前述说明，可以知道，无状态应用的运行状态取决于无状态应用对应的应用描述文件、配置文件等资源文件的内容，将前述资源文件部署在集群上，即可让无状态应用以对应的运行状态在该集群上运行。

因此，为了实现对部署在第一集群上的无状态应用的实时备份，需要由部署在第一集群上的灾备系统在首次备份时获取待备份的无状态应用对应的最新资源文件，并持续对待备份的无状态应用对应的资源文件进行监听，将首次备份时获取的最新资源文件和持续监听过程中获取的资源文件变化情况同步至第二集群。

需要说明的是，在本申请实施例中，应用管理员可以指定对任意集群上的任意无状态应用进行备份，因此可以在每个集群上部署灾备系统，以对灾备系统所在集群上的待备份的无状态应用进行备份。换句话说，由于本申请实施例只涉及对部署在第一集群上的无状态应用进行实时备份，因此具体由部署在第一集群上的灾备系统执行本申请实施例所提出的方法。但如果是对部署在第二集群上的无状态应用进行实时备份，则具体由部署在第二集群上的灾备系统执行本申请实施例所提出的方法，本申请实施例在此不作赘述。

如图2所示，为了执行上述步骤S110中的对部署在第一集群上的待备份的无状态应用对应的资源文件进行监听，本申请实施例在灾备系统中设置了容器化部署的资源管理器，由资源管理器具体实现对部署在第一集群上的待备份的无状态应用对应的资源文件进行实时或周期性的监听。

在一种特殊的情况下，当第一集群为Kubernetes集群时，鉴于Kubernetes系统的API-Server组件提供了Kubernetes集群中全部资源文件的访问入口，相应地，步骤S110中的对部署在第一集群上的待备份的无状态应用对应的资源文件进行监听包括：与第一集群上的API-Server组件之间建立长连接，并通过长连接对待备份的无状态应用对应的资源文件的变化事件进行监听。

具体地，可以在资源管理器和第一集群上的API-Server组件之间建立长连接，由资源管理器通过该长连接对所在第一集群中无状态应用对应的应用描述文件、配置文件等资源文件的变化事件进行监听，当第一集群中无状态应用对应的资源文件发生变化时，资源管理器可立即获取全部的资源文件或者发生变化的资源文件。

此外，为了防止资源管理器与第一集群上的API-Server组件之间建立的长连接因网络问题而中断，在另一具体的例子中，步骤S110中的对部署在第一集群上的待备份的无状态应用对应的资源文件进行监听还包括：周期性地访问第一集群上的API-Server组件，以获取待备份的无状态应用对应的资源文件，并对多次获取的待备份的无状态应用对应的资源文件进行比对，以确定待备份的无状态应用对应的资源文件产生变化。

具体地，可以让资源管理器周期性地主动访问第一集群上的API-Server组件，以获取第一集群中无状态应用对应的资源文件。可以理解，经过持续性、周期性地对第一集群上的API-Server组件进行访问，可以多次获取第一集群中无状态应用对应的资源文件，将相邻两次获取的资源文件进行比对，一旦发现不同，即可确定待备份的无状态应用对应的资源文件产生了变化。

籍此，资源管理器通过周期性地主动访问第一集群上的API-Server组件，主动获取第一集群中待备份的无状态应用对应的全部的或者发生变化的应用描述文件、配置文件等资源文件，有效避免了资源管理器与第一集群上的API-Server组件之间建立的长连接因网络问题而中断。

需要说明的是，还可以将上述建立长连接和周期性地主动访问API-Server组件的方案相结合，本申请实施例对此不做限定。

步骤S120、响应于无状态应用对应的资源文件产生变化，获取无状态应用对应的资源文件。

基于前述说明，可以知道，资源管理器对待备份的无状态应用对应的资源文件进行监听的目的在于，当无状态应用对应的资源文件产生变化时，资源管理器可以立即确定发生变化的资源文件，并获取全部的资源文件或者发生变化的资源文件，再将全部的资源文件或者发生变化的资源文件进行处理后，同步至第二集群，以实现对无状态应用对应的运行状态的实时同步。

当第一集群为Kubernetes集群时，Kubernetes系统的Kubelet组件能够对部署在第一集群上的无状态应用对应的资源文件进行实时监测。当第一集群中的Kubelet组件监测到部署在第一集群上的待备份的无状态应用的资源文件发生变化，即通过第一集群上的API-Server组件将资源文件的变化写入第一集群上的分布式状态存储数据库(ETCD)。通过第一集群上的API-Server组件访问第一集群上的分布式状态存储数据库，即可实时或周期性地获取部署在第一集群上的待备份的无状态应用对应的全部的资源文件或者发生变化的资源文件。

在本申请实施例中，资源管理器从配置管理器中获取自身配置信息，实现对待备份的无状态应用对应的资源文件进行实时或周期性的监听，并通过第一集群上的API-Server组件访问第一集群上的分布式状态存储数据库，获取待备份的无状态应用对应的全部的资源文件或者发生变化的资源文件。

步骤S130、基于预设的配置对无状态应用对应的资源文件中指定字段的内容进行修改。

其中，预设的配置可以由应用管理员在指定待备份的无状态应用和第二集群时进行预先配置。需要说明的是，由于第一集群和第二集群的运行环境存在差异，比如说两个集群的内网环境不同，或者两个集群使用的镜像仓库不同，因此在将待备份的无状态应用对应的资源文件从第一集群同步至第二集群之前，需要对资源文件中用于适配运行环境的相关字段的内容进行修改。

由于待备份的无状态应用和用于备份的第二集群都是由应用管理员人工指定的，存在很大的主观性，而且对于不同的待备份的无状态应用和不同的用于备份的第二集群，需要进行修改的相关字段和修改后的内容都不一样，因此可以由应用管理员在指定待备份的无状态应用和第二集群时一并配置。

在一具体的例子中，如图3所示，步骤S130中的基于预设的配置对无状态应用对应的资源文件中指定字段的内容进行修改具体包括：

步骤S131、对预先写入的应用管理资源对象进行解析。

其中，应用管理资源对象(CR)用于指定第二集群和无状态应用对应的资源文件中待修改的字段，以及设置对指定字段进行修改的顺序。

需要说明的是，如图4所示，本申请实施例中，应用管理员可以通过向灾备系统手动写入应用管理资源对象的方式来指定待备份的无状态应用、用于备份的第二集群、无状态应用对应的资源文件中待修改的字段，如果需要修改的指定字段为两处以上，还可以设置对指定字段进行修改的顺序。

为了执行上述步骤S131中的对预先写入的应用管理资源对象进行解析，本申请实施例在灾备系统中设置了容器化部署的配置管理器，配置管理器中包含自定义应用管理资源(CRD)，应用管理员具体可以预先向灾备系统中的配置管理器中的自定义应用管理资源写入应用管理资源对象，来指定待备份的无状态应用、用于备份的第二集群、无状态应用对应的资源文件中待修改的字段，以及设置对指定字段进行修改的顺序。

当配置管理器中的自定义应用管理资源接收到应用管理员写入的应用管理资源对象后，由配置管理器具体执行对预先写入的应用管理资源对象进行解析。

具体地，在步骤S110、对部署在第一集群上的待备份的无状态应用对应的资源文件进行监听之前，还包括：对应用管理资源对象进行解析，以确定待备份的无状态应用。

此外，步骤S131中的对预先写入的应用管理资源对象进行解析具体为：对应用管理资源对象进行解析，以确定用于备份的第二集群、无状态应用对应的资源文件中待修改的字段、对指定字段进行修改的顺序。

步骤S132、根据应用管理资源对象，按顺序对无状态应用对应的资源文件中指定字段的内容进行修改，以符合第二集群的运行要求。

其中，指定字段包括IP地址、镜像仓库中的至少一个。

基于前述说明，可以知道，应用管理资源对象指定了用于备份的第二集群、无状态应用对应的资源文件中待修改的字段、对指定字段进行修改的顺序，因此在对应用管理资源对象进行解析后，可以根据应用管理资源对象的内容，确定无状态应用对应的资源文件中待修改的字段，对指定字段进行修改的顺序，用于备份的第二集群，并根据用于备份的第二集群，确定待修改的字段经修改后的内容。

如果待修改的字段为IP地址，则先获取第二集群中内网网段下的空闲IP地址，再将资源文件中的IP地址修改为第二集群中内网网段下的IP地址。

如果待修改的字段为镜像仓库，则先获取第二集群使用的镜像仓库，再将资源文件中的镜像仓库修改为第二集群所使用的镜像仓库。

在一具体的例子中，步骤S132中的根据应用管理资源对象的内容，按顺序对无状态应用对应的资源文件中指定的字段的内容进行修改，包括：根据应用管理资源对象，实例化出至少一个资源修改单元；至少一个资源修改单元组成资源修改流水线，资源修改流水线用于按照指定顺序对指定字段的内容进行修改，每个资源修改单元用于修改对应的指定字段的内容。响应于无状态应用对应的资源文件输入资源修改流水线，按指定顺序对待备份的无状态应用对应的资源文件中的指定字段的内容进行修改。

需要说明的是，本申请实施例中通过资源修改流水线具体执行按顺序对无状态应用对应的资源文件中指定的字段的内容进行修改，资源修改流水线中包括至少一个资源修改单元，每个资源修改单元用于修改对应的指定字段的内容。也就是说，每个资源修改单元与一个待修改的指定字段对应，所有资源修改单元在资源修改单元中所处的位置决定了全部待修改的指定字段的修改顺序，最先修改的指定字段对应的资源修改单元位于资源修改流水线的头部，之后依次顺序排列，最后修改的指定字段对应的资源修改单元位于资源修改流水线的尾部。

在一种特殊的情况下，如果待修改的指定字段只有一个，则资源修改流水线只包括一个资源修改单元。

在另一种特殊的情况下，如果没有待修改的指定字段，则资源修改流水线无需对无状态应用对应的资源文件进行修改。

如图5所示，为了执行上述根据应用管理资源对象，实例化出至少一个资源修改单元，本申请实施例在灾备系统中设置了容器化部署的资源修改管理器，配置管理器在完成对预先写入的应用管理资源对象进行解析后，将无状态应用对应的资源文件中待修改的字段、待修改的字段经修改后的内容、对指定字段进行修改的顺序传输给资源修改管理器，资源修改管理器根据从配置管理器获取的信息，在资源修改流水线中按顺序实例化出至少一个资源修改单元，并为每个资源修改单元设置对应的待修改的字段、待修改的字段经修改后的内容。

需要说明的是，本申请实施例中的资源修改流水线也是以容器化形式部署在第一集群上的，用于根据资源修改管理器的指示实例化出至少一个资源修改单元，并从资源管理器接收无状态应用对应的资源文件，由资源修改流水线上按顺序设置的资源修改单位对资源文件中指定字段的内容进行修改，使其能够在第二集群上正常运行。

步骤S140、将修改后的待备份的无状态应用对应的资源文件同步至第二集群，以将无状态应用从第一集群同步至第二集群。

基于前述说明，可以知道，为了实现对部署在第一集群上的无状态应用的实时备份，关键需要将第一集群上的无状态应用对应的资源文件实时同步至第二集群。

由于第一集群和第二集群分属两个集群，部署在第一集群上的灾备系统无权对第二集群进行访问。

为了解决跨集群访问的权限问题，具体地，本申请实施例中的无状态应用的跨集群备份方法还包括：从多集群管理系统获取第二集群的访问认证信息，多集群管理系统用于管理第一集群和第二集群。

其中，访问认证信息包括证书、密钥、令牌中的至少一种。

在本申请实施例中，如图6所示，可以由多集群管理员将集群管理资源对象(CR)写入部署在多集群管理系统上的自定义集群管理资源(CRD)，并通过多集群管理系统将集群之间建立连接的访问认证信息发送至各个集群，各个集群之间通过访问认证信息即可相互连接。也就是说，部署在第一集群上的灾备系统通过访问认证信息对第二集群进行访问，将待备份的无状态应用对应的资源文件同步至第二集群。

在一具体的例子中，第二集群为Kubernetes集群，鉴于Kubernetes系统的API-Server组件提供了资源文件的存储入口，相应地，步骤S140中的将修改后的待备份的无状态应用对应的资源文件同步至第二集群，具体为：基于第二集群的访问认证信息，对第二集群进行访问。通过第二集群的API-Server组件，将修改后的待备份的无状态应用对应的资源文件写入第二集群的分布式状态存储数据库。

在本申请实施例中，如图7所示，在灾备系统中设置了容器化部署的传输管理器，在应用管理员将应用管理资源对象写入部署在配置管理器中的自定义应用管理资源后，传输管理器从配置管理器中获取用于备份的第二集群，以及从多集群管理系统获取第二集群的访问认证信息。当资源修改流水线完成对待备份的无状态应用对应的资源文件的修改后，通过第二集群的API-Server组件，将修改后的待备份的无状态应用对应的资源文件写入第二集群的分布式状态存储数据库。

进一步地，第二集群上的Controller Manager组件可以通过API-Server组件从第二集群的分布式状态存储数据库中读取同步过来的无状态应用对应的资源文件的内容，实现在第二集群上容器化部署该无状态应用或者变更该无状态应用在第二集群上的应用实例的运行状态。籍此，当第一集群上待备份的无状态应用的运行状态发生变化时，即待备份的无状态应用对应的资源文件发生变化时，灾备系统能够实时或周期性地对资源文件的变化进行监测和同步，使得第一集群和第二集群上的无状态应用的应用实例的运行状态时刻保持一致。

需要说明的是，在灾备系统中设置的容器化部署的配置管理器、资源管理器、资源修改管理器、传输管理器，均可以由Kubernetes系统的Kubelet组件进行管理。

灾备系统根据应用管理员指定的待备份的无状态应用和用于备份的第二集群的运行环境，对无状态应用对应的资源文件的指定字段按顺序进行修改，并将修改后的无状态应用对应的资源文件实时同步至指定的第二集群，从而实现将部署在第一集群上的无状态应用的运行状态实时同步至应用管理员指定的第二集群。

为了更加清楚地说明，本申请实施例提出的无状态应用的跨集群备份方法，下面进行举例说明。

将多个集群纳入多集群管理系统进行统一管理，由多集群管理员通过多集群管理系统来对多集群进行管理，集群管理员访问各自的集群来对单个集群进行管理。

在各个集群上容器化部署配置管理器、资源管理器、资源修改管理器、传输管理器、资源修改流水线等组件。其中，配置管理器、资源管理器、资源修改管理器、传输管理器组成了灾备系统，应用管理员通过配置管理器指定待备份的无状态应用和用于备份的第二集群。

首先，多集群管理员将集群管理资源对象写入部署在多集群管理系统上的自定义集群管理资源，并通过多集群管理系统将集群之间建立连接的访问认证信息发送至各个集群，各个集群之间通过访问认证信息即可相互连接，使得部署在第一集群上的灾备系统能够通过访问认证信息对任意集群进行访问。

接着，应用管理员手动向第一集群的灾备系统中的配置管理器中的自定义应用管理资源写入应用管理资源对象，来指定待备份的无状态应用、用于备份的第二集群、无状态应用对应的资源文件中待修改的字段，如果需要修改的指定字段为两处以上，还可以设置对指定字段进行修改的顺序。

资源管理器从配置管理器获取自身配置信息，包括但不限于待备份的无状态应用的信息，对部署在第一集群上的待备份的无状态应用对应的资源文件进行实时或周期性的监听，当待备份的无状态应用对应的资源文件产生变化时，通过第一集群上的API-Server组件访问第一集群上的分布式状态存储数据库，获取待备份的无状态应用对应的全部的资源文件或者发生变化的资源文件。

资源修改管理器从配置管理器获取自身配置信息，包括但不限于无状态应用对应的资源文件中待修改的字段、待修改的字段经修改后的内容、对指定字段进行修改的顺序，并在资源修改流水线中按顺序实例化出至少一个资源修改单元。

资源修改流水线从资源管理器接收无状态应用对应的资源文件，由资源修改流水线上按顺序设置的资源修改单位对资源文件中指定字段的内容进行修改，使其能够在第二集群上正常运行。

传输管理器从配置管理器中获取自身配置信息，包括但不限于用于备份的第二集群，以及从多集群管理系统获取第二集群的访问认证信息。当资源修改流水线完成对待备份的无状态应用对应的资源文件的修改后，传输管理器通过第二集群的API-Server组件，将修改后的待备份的无状态应用对应的资源文件写入第二集群的分布式状态存储数据库。

第二集群上的Controller Manager组件通过API-Server组件从第二集群的分布式状态存储数据库中读取同步过来的无状态应用对应的资源文件的内容，实现在第二集群上容器化部署该无状态应用或者变更该无状态应用在第二集群上的应用实例的运行状态。

在本申请实施例中，通过灾备系统对无状态应用对应的资源文件中的指定字段进行修改，使得资源文件在同步至第二集群后能够正常运行，实现第一集群和第二集群上的无状态应用的应用实例的运行状态的实时同步。

此外，以应用为粒度对无状态应用对应的资源文件进行备份，由应用管理员根据需求自由的将待备份的无状态应用对应的资源文件在指定的一个或多个第二集群上进行备份。

通过零延迟的资源变化时间驱动触发或周期性对待备份的无状态应用对应的资源文件进行同步，并通过第一集群上的资源修改流水线对无状态应用对应的资源文件中的指定字段进行修改，使得修改后的待备份的无状态应用对应的资源文件在同步至第二集群后能够正常运行。

需要说明的是，本申请中设置了三种不同权限的管理员：多集群管理员——具有最高权限，可以管理多个集群；集群管理员——具有中级权限，可以管理单个集群；应用管理员——具有最低权限，管理单个应用或其名下的多个应用。多集群管理员和集群管理员通过写入集群管理资源对象，对多集群和集群进行管理，应用管理员通过写入应用管理资源对象指定无状态应用的备用集群和配置资源的同步设置及执行过程。籍此，每个管理员的权限层级分明，有效提高对整个灾备系统的高效管理和风险控制。

示例性系统

图8为根据本申请的一些实施例提供的一种无状态应用的跨集群备份系统的结构示意图；如图8所示，该无状态应用的跨集群备份系统由部署在第一集群上的灾备系统执行，包括：

监听单元801，配置为对部署在第一集群上的待备份的无状态应用对应的资源文件进行监听；资源文件包括应用描述文件、配置文件中的至少一种。

文件获取单元802，配置为响应于无状态应用对应的资源文件产生变化，获取无状态应用对应的资源文件。

文件修改单元803，配置为基于预设的配置对无状态应用对应的资源文件中的指定字段的内容进行修改。

同步单元804，配置为将修改后的待备份的无状态应用对应的资源文件同步至第二集群，以将无状态应用从第一集群同步至第二集群。

本申请实施例提供的无状态应用的跨集群备份系统能够实现上述任一实施例的无状态应用的跨集群备份方法的步骤、流程，并达到相同的技术效果，在此不再一一赘述。

示例性设备

图9为根据本申请的一些实施例提供的电子设备的结构示意图；如图9所示，该电子设备包括：

一个或多个处理器901；

计算机可读介质，可以配置为存储一个或多个程序902，一个或多个处理器901执行一个或多个程序902时，实现如下步骤：对部署在第一集群上的待备份的无状态应用对应的资源文件进行监听；资源文件包括应用描述文件、配置文件中的至少一种。响应于无状态应用对应的资源文件产生变化，获取无状态应用对应的资源文件。基于预设的配置对无状态应用对应的资源文件中指定字段的内容进行修改。将修改后的待备份的无状态应用对应的资源文件同步至第二集群，以将无状态应用从第一集群同步至第二集群。

图10为根据本申请的一些实施例提供的电子设备的硬件结构；如图10所示，该电子设备的硬件结构可以包括：处理器1001、通信接口1002、计算机可读介质1003和通信总线1004。

其中，处理器1001、通信接口1002、计算机可读存储介质1003通过通信总线1004完成相互间的通信。

可选地，通信接口1002可以为通信模块的接口，如GSM模块的接口。

其中，处理器1001具体可以配置为：对部署在第一集群上的待备份的无状态应用对应的资源文件进行监听；资源文件包括应用描述文件、配置文件中的至少一种。响应于无状态应用对应的资源文件产生变化，获取无状态应用对应的资源文件。基于预设的配置对无状态应用对应的资源文件中指定字段的内容进行修改。将修改后的待备份的无状态应用对应的资源文件同步至第二集群，以将无状态应用从第一集群同步至第二集群。

处理器1001可以是通用处理器，包括中央处理器(central processing unit，简称CPU)、网络处理器(Network Processor，简称NP)等，还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本申请实施例的电子设备以多种形式存在，包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如：iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括：音频、视频播放器(例如：iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其他具有数据交互功能的电子装置。

需要指出，根据实施的需要，可将本申请实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可以将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本申请实施例的目的。

上述根据本申请实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器存储介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，RAM、ROM、闪存等)，当软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的无状态应用的跨集群备份方法。此外，当通用计算机访问用于实现在此示出的方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的方法的专用计算机。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和涉及约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其它实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述得设备及系统实施例仅仅是示意性的，其中作为分离不见说明的单元可以使或者也可以不是物理上分开的，作为单元提示的不见可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上仅为本申请的优选实施例，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种无状态应用的跨集群备份方法，其特征在于，所述方法由部署在第一集群上的灾备系统执行，包括：

对部署在所述第一集群上的待备份的无状态应用对应的资源文件进行监听；所述资源文件包括应用描述文件、配置文件中的至少一种；

响应于所述无状态应用对应的资源文件产生变化，获取所述无状态应用对应的资源文件；

基于预设的配置对所述无状态应用对应的资源文件中指定字段的内容进行修改；

将修改后的待备份的所述无状态应用对应的资源文件同步至第二集群，以将所述无状态应用从所述第一集群同步至所述第二集群。

2.根据权利要求1所述的无状态应用的跨集群备份方法，其特征在于，所述第一集群为Kubernetes集群，对待备份的无状态应用对应的资源文件进行监听，包括：

与所述第一集群上的API-Server组件之间建立长连接；

通过所述长连接对所述待备份的无状态应用对应的资源文件的变化事件进行监听；

或者，

周期性地访问所述第一集群上的API-Server组件，以获取待备份的所述无状态应用对应的资源文件；

对多次获取的待备份的所述无状态应用对应的资源文件进行比对，以确定待备份的所述无状态应用对应的资源文件产生变化。

3.根据权利要求1所述的无状态应用的跨集群备份方法，其特征在于，所述基于预设的配置对所述无状态应用对应的资源文件中指定字段的内容进行修改，包括：

对预先写入的应用管理资源对象进行解析；所述应用管理资源对象用于指定所述第二集群和所述无状态应用对应的资源文件中待修改的字段，以及设置对所述指定字段进行修改的顺序；

根据所述应用管理资源对象，按顺序对所述无状态应用对应的资源文件中指定字段的内容进行修改，以符合所述第二集群的运行要求；所述指定字段包括IP地址、镜像仓库中的至少一个。

4.根据权利要求3所述的无状态应用的跨集群备份方法，其特征在于，所述根据所述应用管理资源对象，按顺序对所述无状态应用对应的资源文件中指定字段的内容进行修改，包括：

根据所述应用管理资源对象，实例化出至少一个资源修改单元；所述至少一个资源修改单元组成资源修改流水线，所述资源修改流水线用于按照指定顺序对所述指定字段的内容进行修改，每个所述资源修改单元用于修改对应的所述指定字段的内容；

响应于所述无状态应用对应的资源文件输入所述资源修改流水线，按所述指定顺序对待备份的所述无状态应用对应的资源文件中的所述指定字段的内容进行修改。

5.根据权利要求4所述的无状态应用的跨集群备份方法，其特征在于，在所述对待备份的无状态应用对应的资源文件进行监听之前，还包括：

对所述应用管理资源对象进行解析，以确定所述待备份的无状态应用。

6.根据权利要求1-5中任一项所述的无状态应用的跨集群备份方法，其特征在于，还包括：

从多集群管理系统获取所述第二集群的访问认证信息；所述多集群管理系统用于管理所述第一集群和所述第二集群，所述访问认证信息包括证书、密钥、令牌中的至少一种。

7.根据权利要求6所述的无状态应用的跨集群备份方法，其特征在于，所述第二集群为Kubernetes集群，所述将修改后的所述待备份的无状态应用对应的资源文件同步至第二集群，具体为：

基于所述第二集群的访问认证信息，对所述第二集群进行访问；

通过所述第二集群的API-Server组件，将修改后的所述待备份的无状态应用对应的资源文件写入所述第二集群的分布式状态存储数据库。

8.一种无状态应用的跨集群备份系统，其特征在于，该系统部署在第一集群上，包括：

监听单元，配置为对部署在所述第一集群上的待备份的无状态应用对应的资源文件进行监听；所述资源文件包括应用描述文件、配置文件中的至少一种；

文件获取单元，配置为响应于所述无状态应用对应的资源文件产生变化，获取所述无状态应用对应的资源文件；

文件修改单元，配置为基于预设的配置对所述无状态应用对应的资源文件中的指定字段的内容进行修改；

同步单元，配置为将修改后的待备份的所述无状态应用对应的资源文件同步至第二集群，以将所述无状态应用从所述第一集群同步至所述第二集群。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序为如权利要求1-7任一所述的无状态应用的跨集群备份方法。

10.一种电子设备，其特征在于，包括：存储器、处理器、以及存在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如权利要求1-7任一所述的无状态应用的跨集群备份方法。

Images