A cross-cluster backup method, system, medium and device for stateless application

Abstract

The present application provides a cross-cluster backup method, system, computer-readable storage medium, and electronic device for stateless applications. The method is executed by a disaster recovery system deployed on a first cluster, and includes: monitoring resource files corresponding to stateless applications to be backed up that are deployed on the first cluster; obtaining resource files corresponding to the stateless applications in response to changes in resource files corresponding to the stateless applications; modifying the content of a specified field in the resource files corresponding to the stateless applications based on a preset configuration; synchronizing the modified resource files corresponding to the stateless applications to be backed up to the second cluster, so as to synchronize the stateless applications from the first cluster to the second cluster. Thus, after the resource files of the stateless applications on the first cluster are synchronized to the second cluster in real time through the disaster recovery system, real-time backup of the stateless applications deployed on the first cluster can be achieved.

Description

Technical Field

[0001] The present application relates to the field of cloud native technology, and in particular to a cross-cluster backup method, system, computer-readable storage medium, and electronic device for stateless applications. Background Art

[0002] In production practice, enterprises usually adopt the active / standby cluster deployment mode to deploy application instances, that is, deploy application instances on the active cluster and the standby cluster respectively, and synchronize the running status of the application instances on the active cluster to the standby cluster in real time. When the active cluster fails and cannot respond to external access traffic normally, the standby cluster responds instead of the active cluster.

[0003] The application instances are deployed on the primary cluster and the standby cluster respectively through manual deployment. After manually changing and upgrading the application instances on the primary cluster, the application instances on the standby cluster also need to be manually changed and upgraded in the same way to ensure that the running status of the application instances deployed on the primary cluster and the standby cluster remain consistent.

[0004] With the development of service networks and microservice technologies, deploying cloud-native applications with a microservice architecture has become a trend in technological development. The microservice architecture builds distributed applications by independently deploying and running a series of low-coupled microservice applications. Since microservices have little impact on each other, changes and upgrades of a single microservice application have little impact on other microservice applications under the same distributed application. In production practice, changes and upgrades of microservice applications used to build distributed applications have become very frequent.

[0005] Manually changing and upgrading microservice applications frequently is cumbersome, and once an error occurs, the synchronization of the running status of the microservice application instance will fail. The distributed application instance deployed on the standby cluster will not be able to respond to external access traffic on behalf of the distributed application instance on the primary cluster when the primary cluster fails.

[0006] Therefore, it is necessary to provide an improved technical solution to address the above-mentioned deficiencies in the prior art. Summary of the invention

[0007] The purpose of the present application is to provide a cross-cluster backup method, system, computer-readable storage medium and electronic device for stateless applications to solve or alleviate the problems existing in the above-mentioned prior art.

[0008] In order to achieve the above objectives, this application provides the following technical solutions:

[0009] The present application provides a cross-cluster backup method for a stateless application, which is executed by a disaster recovery system deployed on a first cluster, and includes: monitoring resource files corresponding to the stateless application to be backed up that is deployed on the first cluster; the resource files include at least one of an application description file and a configuration file; in response to a change in the resource file corresponding to the stateless application, obtaining the resource file corresponding to the stateless application; modifying the content of a specified field in the resource file corresponding to the stateless application based on a preset configuration; synchronizing the modified resource file corresponding to the stateless application to be backed up to a second cluster, so as to synchronize the stateless application from the first cluster to the second cluster.

[0010] Preferably, the first cluster is a Kubernetes cluster, and the resource files corresponding to the stateless application to be backed up are monitored, including: establishing a long connection with the API-Server component on the first cluster; monitoring the change events of the resource files corresponding to the stateless application to be backed up through the long connection; or, periodically accessing the API-Server component on the first cluster to obtain the resource files corresponding to the stateless application to be backed up; comparing the resource files corresponding to the stateless application to be backed up obtained multiple times to determine that the resource files corresponding to the stateless application to be backed up have changed.

[0011] Preferably, the modification of the content of the specified field in the resource file corresponding to the stateless application based on the preset configuration includes: parsing a pre-written application management resource object; the application management resource object is used to specify the fields to be modified in the resource files corresponding to the second cluster and the stateless application, and to set the order in which the specified fields are modified; according to the application management resource object, the content of the specified field in the resource file corresponding to the stateless application is modified in sequence to meet the operating requirements of the second cluster; the specified field includes at least one of an IP address and a mirror repository.

[0012] Preferably, the modifying the contents of the specified fields in the resource file corresponding to the stateless application in sequence according to the application management resource object includes: instantiating at least one resource modification unit according to the application management resource object; the at least one resource modification unit constitutes a resource modification pipeline, the resource modification pipeline is used to modify the contents of the specified fields in a specified sequence, and each resource modification unit is used to modify the contents of the corresponding specified field; in response to the resource file corresponding to the stateless application being input into the resource modification pipeline, the contents of the specified fields in the resource file corresponding to the stateless application to be backed up are modified in the specified sequence.

[0013] Preferably, before monitoring the resource file corresponding to the stateless application to be backed up, the method further includes: parsing the application management resource object to determine the stateless application to be backed up.

[0014] Preferably, the method further includes: acquiring access authentication information of the second cluster from a multi-cluster management system; the multi-cluster management system is used to manage the first cluster and the second cluster, and the access authentication information includes at least one of a certificate, a key, and a token.

[0015] Preferably, the second cluster is a Kubernetes cluster, and synchronizing the modified resource files corresponding to the stateless application to be backed up to the second cluster is specifically: accessing the second cluster based on the access authentication information of the second cluster; and writing the resource files corresponding to the stateless application to be backed up into the distributed state storage database of the second cluster through the API-Server component of the second cluster.

[0016] An embodiment of the present application also provides a cross-cluster backup system for stateless applications, which is deployed on a first cluster and includes: a monitoring unit, configured to monitor resource files corresponding to the stateless application to be backed up that is deployed on the first cluster; the resource files include at least one of an application description file and a configuration file; a file acquisition unit, configured to acquire the resource files corresponding to the stateless application in response to changes in the resource files corresponding to the stateless application; a file modification unit, configured to modify the content of a specified field in the resource files corresponding to the stateless application based on a preset configuration; and a synchronization unit, configured to synchronize the modified resource files corresponding to the stateless application to be backed up to the second cluster, so as to synchronize the stateless application from the first cluster to the second cluster.

[0017] An embodiment of the present application further provides a computer-readable storage medium on which a computer program is stored. The computer program is a cross-cluster backup method for a stateless application as described above.

[0018] An embodiment of the present application further provides an electronic device, comprising: a memory, a processor, and a program stored in the memory and executable on the processor, wherein when the processor executes the program, the cross-cluster backup method for stateless applications as described above is implemented.

[0019] Beneficial effects:

[0020] The cross-cluster backup technology for stateless applications provided in the present application is executed by a disaster recovery system deployed on the first cluster, by monitoring the resource files (including at least one of the application description files and configuration files) corresponding to the stateless applications to be backed up deployed on the first cluster. When the resource files corresponding to the stateless application change, the resource files corresponding to the stateless application are obtained, and the content of the specified fields in the resource files corresponding to the stateless application are modified based on the preset configuration. The modified resource files corresponding to the stateless application to be backed up are synchronized to the second cluster to synchronize the stateless application from the first cluster to the second cluster. Thereby, after the resource files of the stateless applications on the first cluster are synchronized to the second cluster in real time through the disaster recovery system, the real-time backup of the stateless applications deployed on the first cluster can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The drawings constituting part of the present application are used to provide a further understanding of the present application. The exemplary embodiments and descriptions of the present application are used to explain the present application and do not constitute an improper limitation on the present application. Among them:

[0022] Figure 1 A schematic diagram of a process flow of a cross-cluster backup method for a stateless application provided according to some embodiments of the present application;

[0023] Figure 2 A logical schematic diagram of obtaining resource files corresponding to a stateless application provided according to some embodiments of the present application;

[0024] Figure 3 A flowchart of step S103 in a cross-cluster backup method for a stateless application provided according to some embodiments of the present application;

[0025] Figure 4 A logical schematic diagram of an application administrator writing an application management resource object to a disaster recovery system according to some embodiments of the present application;

[0026] Figure 5 A logical schematic diagram of modifying a resource file corresponding to a stateless application according to some embodiments of the present application;

[0027] Figure 6 A logical schematic diagram of a multi-cluster administrator providing cluster access authentication information to a disaster recovery system according to some embodiments of the present application;

[0028] Figure 7 A logical schematic diagram of synchronous transmission of resource files corresponding to a stateless application provided according to some embodiments of the present application;

[0029] Figure 8A schematic diagram of the structure of a cross-cluster backup system for a stateless application provided according to some embodiments of the present application;

[0030] Fig. 9 A schematic diagram of the structure of an electronic device provided according to some embodiments of the present application;

[0031] Fig.10 A hardware structure of an electronic device is provided according to some embodiments of the present application. DETAILED DESCRIPTION

[0032] The present application will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments. Each example is provided by way of explanation of the present application and does not limit the present application. In fact, it will be clear to those skilled in the art that modifications and variations may be made in the present application without departing from the scope or spirit of the present application. For example, a feature shown or described as a part of an embodiment may be used in another embodiment to produce yet another embodiment. Therefore, it is desired that the present application includes such modifications and variations within the scope of the appended claims and their equivalents.

[0033] Based on the above description of the background technology, it can be known that in the prior art, enterprises use the master / slave cluster deployment mode to deploy distributed application instances, and each distributed application instance is constructed by at least one microservice application instance.

[0034] Specifically, after the distributed application instances are deployed on the primary cluster and the backup cluster respectively, the running status of the distributed application instances on the primary cluster needs to be synchronized to the backup cluster in real time, that is, the running status of all microservice application instances on the primary cluster used to build the distributed application instances needs to be synchronized to the backup cluster in real time.

[0035] Microservice applications can be divided into stateless applications and stateful applications according to whether persistent data storage is required. When deploying a stateless application, you only need to edit the content of the application description file (Deployment), configuration file (ConfigMap) and other resource files corresponding to the stateless application, and deploy the resource files on the cluster to deploy the stateless application on the cluster. Accordingly, you only need to modify the content of the application description file, configuration file and other resource files corresponding to the stateless application to change the running state of the stateless application.

[0036] When deploying stateless applications in the master / slave cluster deployment mode, the application administrator needs to manually redeploy the resource files corresponding to the stateless application deployed on the master cluster on the slave cluster. In addition, during the operation and maintenance of the stateless application, every time the application administrator edits and modifies the content of the resource files corresponding to the stateless application deployed on the master cluster, the application administrator needs to manually edit and modify the content of the resource files corresponding to the stateless application deployed on the slave cluster in the same way to ensure that the operation status of the application instances of the stateless application deployed on the master cluster and the slave cluster remain consistent.

[0037] The application instances of stateless applications on different clusters are deployed and their running statuses are synchronized by manually deploying and editing the contents of resource files. When stateless applications are frequently changed and upgraded, application administrators need to perform tedious editing operations on the resource files corresponding to the stateless applications. Once a resource file corresponding to the stateless application is deployed incorrectly, or a field is edited incorrectly, the synchronization of the stateless application will fail.

[0038] After conducting an in-depth study on the above characteristics of stateless applications, the applicant found that the key to achieving the synchronization of deployment and running status of stateless applications on the backup cluster is to synchronize the content of resource files such as application description files and configuration files corresponding to the stateless applications on the primary cluster to the backup cluster in real time. Based on this, the applicant proposed a cross-cluster backup method for stateless applications.

[0039] For ease of explanation, in the embodiment of the present application, the main cluster is referred to as the first cluster, and the backup cluster is referred to as the second cluster.

[0040] It should be noted that in the embodiment of the present application, the first cluster is the cluster where the stateless application to be backed up is located, and the second cluster is the backup cluster specified by the application administrator. In production practice, the application administrator can specify one or more backup clusters for the stateless application to be backed up. The embodiment of the present application is described in terms of specifying one backup cluster, which is not intended to limit the embodiment of the present application.

[0041] Exemplary Methods

[0042] like Figure 1 As shown, the cross-cluster backup method of the stateless application is executed by a disaster recovery system deployed on the first cluster, and includes:

[0043] Step S110: monitor resource files corresponding to the stateless application to be backed up that is deployed on the first cluster.

[0044] The resource file includes at least one of an application description file and a configuration file.

[0045] Based on the above description, it can be known that the running state of a stateless application depends on the content of resource files such as application description files and configuration files corresponding to the stateless application. By deploying the above resource files on a cluster, the stateless application can run on the cluster in the corresponding running state.

[0046] Therefore, in order to achieve real-time backup of stateless applications deployed on the first cluster, the disaster recovery system deployed on the first cluster needs to obtain the latest resource files corresponding to the stateless applications to be backed up during the first backup, and continuously monitor the resource files corresponding to the stateless applications to be backed up, and synchronize the latest resource files obtained during the first backup and the changes in the resource files obtained during the continuous monitoring process to the second cluster.

[0047] It should be noted that in the embodiment of the present application, the application administrator can specify the backup of any stateless application on any cluster, so a disaster recovery system can be deployed on each cluster to back up the stateless application to be backed up on the cluster where the disaster recovery system is located. In other words, since the embodiment of the present application only involves real-time backup of stateless applications deployed on the first cluster, the method proposed in the embodiment of the present application is specifically executed by the disaster recovery system deployed on the first cluster. However, if the stateless application deployed on the second cluster is to be backed up in real time, the method proposed in the embodiment of the present application is specifically executed by the disaster recovery system deployed on the second cluster, and the embodiment of the present application is not described in detail here.

[0048] like Figure 2 As shown, in order to execute the above-mentioned step S110 of monitoring the resource files corresponding to the stateless application to be backed up deployed on the first cluster, an embodiment of the present application sets up a containerized deployed resource manager in the disaster recovery system, and the resource manager specifically implements real-time or periodic monitoring of the resource files corresponding to the stateless application to be backed up deployed on the first cluster.

[0049] In a special case, when the first cluster is a Kubernetes cluster, given that the API-Server component of the Kubernetes system provides access to all resource files in the Kubernetes cluster, correspondingly, monitoring the resource files corresponding to the stateless application to be backed up deployed on the first cluster in step S110 includes: establishing a long connection with the API-Server component on the first cluster, and monitoring change events of the resource files corresponding to the stateless application to be backed up through the long connection.

[0050] Specifically, a long connection can be established between the resource manager and the API-Server component on the first cluster, and the resource manager can monitor change events of resource files such as application description files and configuration files corresponding to the stateless application in the first cluster through the long connection. When the resource files corresponding to the stateless application in the first cluster change, the resource manager can immediately obtain all resource files or the changed resource files.

[0051] In addition, in order to prevent the long connection established between the resource manager and the API-Server component on the first cluster from being interrupted due to network problems, in another specific example, monitoring the resource files corresponding to the stateless application to be backed up deployed on the first cluster in step S110 also includes: periodically accessing the API-Server component on the first cluster to obtain the resource files corresponding to the stateless application to be backed up, and comparing the resource files corresponding to the stateless application to be backed up obtained multiple times to determine whether the resource files corresponding to the stateless application to be backed up have changed.

[0052] Specifically, the resource manager can be allowed to periodically and actively access the API-Server component on the first cluster to obtain the resource files corresponding to the stateless application in the first cluster. It can be understood that by continuously and periodically accessing the API-Server component on the first cluster, the resource files corresponding to the stateless application in the first cluster can be obtained multiple times, and the resource files obtained twice are compared. Once a difference is found, it can be determined that the resource files corresponding to the stateless application to be backed up have changed.

[0053] Thereby, the resource manager actively accesses the API-Server component on the first cluster periodically to actively obtain all or changed application description files, configuration files and other resource files corresponding to the stateless applications to be backed up in the first cluster, thereby effectively avoiding the interruption of the long connection established between the resource manager and the API-Server component on the first cluster due to network problems.

[0054] It should be noted that the above-mentioned solution of establishing a long connection and periodically actively accessing the API-Server component can also be combined, and the embodiments of the present application do not limit this.

[0055] Step S120: In response to a change in a resource file corresponding to the stateless application, obtain the resource file corresponding to the stateless application.

[0056] Based on the above description, it can be known that the purpose of the resource manager monitoring the resource files corresponding to the stateless application to be backed up is that when the resource files corresponding to the stateless application change, the resource manager can immediately determine the changed resource files, and obtain all the resource files or the changed resource files, and then process all the resource files or the changed resource files, and synchronize them to the second cluster to achieve real-time synchronization of the running status corresponding to the stateless application.

[0057] When the first cluster is a Kubernetes cluster, the Kubelet component of the Kubernetes system can monitor the resource files corresponding to the stateless applications deployed on the first cluster in real time. When the Kubelet component in the first cluster detects that the resource files of the stateless applications to be backed up deployed on the first cluster have changed, the changes in the resource files are written to the distributed state storage database (ETCD) on the first cluster through the API-Server component on the first cluster. By accessing the distributed state storage database on the first cluster through the API-Server component on the first cluster, all resource files or changed resource files corresponding to the stateless applications to be backed up deployed on the first cluster can be obtained in real time or periodically.

[0058] In an embodiment of the present application, the resource manager obtains its own configuration information from the configuration manager, implements real-time or periodic monitoring of resource files corresponding to the stateless application to be backed up, and accesses the distributed state storage database on the first cluster through the API-Server component on the first cluster to obtain all resource files corresponding to the stateless application to be backed up or changed resource files.

[0059] Step S130: modify the content of a specified field in a resource file corresponding to the stateless application based on a preset configuration.

[0060] Among them, the preset configuration can be pre-configured by the application administrator when specifying the stateless application to be backed up and the second cluster. It should be noted that due to the differences in the operating environments of the first cluster and the second cluster, such as different intranet environments of the two clusters, or different image repositories used by the two clusters, before synchronizing the resource files corresponding to the stateless application to be backed up from the first cluster to the second cluster, it is necessary to modify the contents of the relevant fields in the resource files used to adapt to the operating environment.

[0061] Since the stateless application to be backed up and the second cluster for backup are manually specified by the application administrator, there is a lot of subjectivity, and for different stateless applications to be backed up and different second clusters for backup, the related fields that need to be modified and the modified contents are different. Therefore, the application administrator can configure them together when specifying the stateless application to be backed up and the second cluster.

[0062] In a specific example, Figure 3 As shown, the step S130 of modifying the content of the specified field in the resource file corresponding to the stateless application based on the preset configuration specifically includes:

[0063] Step S131: Parse the pre-written application management resource object.

[0064] The application management resource object (CR) is used to specify the fields to be modified in the resource files corresponding to the second cluster and the stateless application, and to set the order in which the specified fields are modified.

[0065] It should be noted that if Figure 4 As shown, in an embodiment of the present application, the application administrator can specify the stateless application to be backed up, the second cluster for backup, and the fields to be modified in the resource file corresponding to the stateless application by manually writing the application management resource object to the disaster recovery system. If there are more than two specified fields that need to be modified, the order in which the specified fields are modified can also be set.

[0066] In order to execute the parsing of the pre-written application management resource object in the above-mentioned step S131, an embodiment of the present application sets up a containerized deployment configuration manager in the disaster recovery system, and the configuration manager includes a custom application management resource (CRD). The application administrator can specifically write the application management resource object to the custom application management resource in the configuration manager in the disaster recovery system in advance to specify the stateless application to be backed up, the second cluster for backup, the fields to be modified in the resource file corresponding to the stateless application, and set the order in which the specified fields are to be modified.

[0067] When the custom application management resource in the configuration manager receives the application management resource object written by the application administrator, the configuration manager specifically performs parsing of the pre-written application management resource object.

[0068] Specifically, before monitoring the resource files corresponding to the stateless application to be backed up deployed on the first cluster in step S110, the method further includes: parsing the application management resource object to determine the stateless application to be backed up.

[0069] In addition, parsing the pre-written application management resource object in step S131 specifically includes: parsing the application management resource object to determine the second cluster for backup, the fields to be modified in the resource file corresponding to the stateless application, and the order of modifying the designated fields.

[0070] Step S132: According to the application management resource object, the contents of the specified fields in the resource file corresponding to the stateless application are modified in sequence to meet the operation requirements of the second cluster.

[0071] The specified field includes at least one of an IP address and an image repository.

[0072] Based on the foregoing description, it can be known that the application management resource object specifies the second cluster for backup, the fields to be modified in the resource file corresponding to the stateless application, and the order in which the specified fields are modified. Therefore, after parsing the application management resource object, the fields to be modified in the resource file corresponding to the stateless application, the order in which the specified fields are modified, and the second cluster for backup can be determined based on the content of the application management resource object. Based on the second cluster for backup, the modified content of the fields to be modified can be determined.

[0073] If the field to be modified is an IP address, first obtain an idle IP address in the intranet segment of the second cluster, and then modify the IP address in the resource file to the IP address in the intranet segment of the second cluster.

[0074] If the field to be modified is an image warehouse, the image warehouse used by the second cluster is first obtained, and then the image warehouse in the resource file is modified to the image warehouse used by the second cluster.

[0075] In a specific example, the content of the specified field in the resource file corresponding to the stateless application is modified in sequence according to the content of the application management resource object in step S132, including: instantiating at least one resource modification unit according to the application management resource object; at least one resource modification unit constitutes a resource modification pipeline, the resource modification pipeline is used to modify the content of the specified field in a specified order, and each resource modification unit is used to modify the content of the corresponding specified field. In response to the resource file corresponding to the stateless application inputting the resource modification pipeline, the content of the specified field in the resource file corresponding to the stateless application to be backed up is modified in the specified order.

[0076] It should be noted that in the embodiment of the present application, the resource modification pipeline is specifically executed to modify the contents of the fields specified in the resource file corresponding to the stateless application in sequence. The resource modification pipeline includes at least one resource modification unit, and each resource modification unit is used to modify the contents of the corresponding specified field. In other words, each resource modification unit corresponds to a specified field to be modified, and the positions of all resource modification units in the resource modification unit determine the modification order of all specified fields to be modified. The resource modification unit corresponding to the first specified field to be modified is located at the head of the resource modification pipeline, and then arranged in sequence. The resource modification unit corresponding to the last specified field to be modified is located at the tail of the resource modification pipeline.

[0077] In a special case, if there is only one designated field to be modified, the resource modification pipeline includes only one resource modification unit.

[0078] In another special case, if there is no specified field to be modified, the resource modification pipeline does not need to modify the resource file corresponding to the stateless application.

[0079] like Figure 5 As shown, in order to execute the above-mentioned instantiation of at least one resource modification unit according to the application management resource object, an embodiment of the present application sets up a containerized deployed resource modification manager in the disaster recovery system. After the configuration manager completes the parsing of the pre-written application management resource object, it transmits the fields to be modified in the resource file corresponding to the stateless application, the modified contents of the fields to be modified, and the order of modifying the specified fields to the resource modification manager. The resource modification manager instantiates at least one resource modification unit in sequence in the resource modification pipeline based on the information obtained from the configuration manager, and sets the corresponding fields to be modified and the modified contents of the fields to be modified for each resource modification unit.

[0080] It should be noted that the resource modification pipeline in the embodiment of the present application is also deployed in a containerized form on the first cluster, and is used to instantiate at least one resource modification unit according to the instructions of the resource modification manager, and receive the resource file corresponding to the stateless application from the resource manager. The resource modification units set in sequence on the resource modification pipeline modify the content of the specified field in the resource file so that it can run normally on the second cluster.

[0081] Step S140: Synchronize the modified resource files corresponding to the stateless application to be backed up to the second cluster, so as to synchronize the stateless application from the first cluster to the second cluster.

[0082] Based on the above description, it can be known that in order to achieve real-time backup of the stateless application deployed on the first cluster, it is crucial to synchronize the resource files corresponding to the stateless application on the first cluster to the second cluster in real time.

[0083] Since the first cluster and the second cluster belong to two different clusters, the disaster recovery system deployed on the first cluster has no right to access the second cluster.

[0084] In order to solve the cross-cluster access permission problem, specifically, the cross-cluster backup method of stateless applications in the embodiment of the present application further includes: obtaining access authentication information of the second cluster from a multi-cluster management system, where the multi-cluster management system is used to manage the first cluster and the second cluster.

[0085] The access authentication information includes at least one of a certificate, a key, and a token.

[0086] In the embodiments of the present application, Figure 6 As shown, the multi-cluster administrator can write the cluster management resource object (CR) into the custom cluster management resource (CRD) deployed on the multi-cluster management system, and send the access authentication information for establishing connections between clusters to each cluster through the multi-cluster management system. Each cluster can be connected to each other through the access authentication information. In other words, the disaster recovery system deployed on the first cluster accesses the second cluster through the access authentication information, and synchronizes the resource files corresponding to the stateless application to be backed up to the second cluster.

[0087] In a specific example, the second cluster is a Kubernetes cluster. Since the API-Server component of the Kubernetes system provides a storage entry for resource files, the step S140 of synchronizing the resource files corresponding to the modified stateless application to be backed up to the second cluster is specifically: based on the access authentication information of the second cluster, the second cluster is accessed. Through the API-Server component of the second cluster, the resource files corresponding to the modified stateless application to be backed up are written into the distributed state storage database of the second cluster.

[0088] In the embodiments of the present application, Figure 7 As shown, a containerized deployment transmission manager is set in the disaster recovery system. After the application administrator writes the application management resource object into the custom application management resource deployed in the configuration manager, the transmission manager obtains the second cluster for backup from the configuration manager, and obtains the access authentication information of the second cluster from the multi-cluster management system. When the resource modification pipeline completes the modification of the resource files corresponding to the stateless application to be backed up, the modified resource files corresponding to the stateless application to be backed up are written into the distributed state storage database of the second cluster through the API-Server component of the second cluster.

[0089] Furthermore, the Controller Manager component on the second cluster can read the contents of the resource files corresponding to the synchronized stateless application from the distributed state storage database of the second cluster through the API-Server component, so as to realize the containerized deployment of the stateless application on the second cluster or change the running state of the application instance of the stateless application on the second cluster. Thus, when the running state of the stateless application to be backed up on the first cluster changes, that is, when the resource files corresponding to the stateless application to be backed up change, the disaster recovery system can monitor and synchronize the changes of the resource files in real time or periodically, so that the running state of the application instance of the stateless application on the first cluster and the second cluster is always consistent.

[0090] It should be noted that the configuration manager, resource manager, resource modification manager, and transmission manager of the containerized deployment set up in the disaster recovery system can all be managed by the Kubelet component of the Kubernetes system.

[0091] The disaster recovery system modifies the specified fields of the resource files corresponding to the stateless applications to be backed up specified by the application administrator and the operating environment of the second cluster used for backup in sequence, and synchronizes the modified resource files corresponding to the stateless applications to the specified second cluster in real time, thereby realizing real-time synchronization of the operating status of the stateless applications deployed on the first cluster to the second cluster specified by the application administrator.

[0092] To explain more clearly, the cross-cluster backup method for stateless applications proposed in the embodiments of the present application is described below with examples.

[0093] Multiple clusters are incorporated into the multi-cluster management system for unified management. The multi-cluster administrator manages the multiple clusters through the multi-cluster management system, and the cluster administrators access their respective clusters to manage a single cluster.

[0094] Components such as the configuration manager, resource manager, resource modification manager, transmission manager, and resource modification pipeline are deployed in containers on each cluster. Among them, the configuration manager, resource manager, resource modification manager, and transmission manager form a disaster recovery system. The application administrator specifies the stateless application to be backed up and the second cluster for backup through the configuration manager.

[0095] First, the multi-cluster administrator writes the cluster management resource object into the custom cluster management resource deployed on the multi-cluster management system, and sends the access authentication information for establishing connections between clusters to each cluster through the multi-cluster management system. The clusters can be connected to each other through the access authentication information, so that the disaster recovery system deployed on the first cluster can access any cluster through the access authentication information.

[0096] Next, the application administrator manually writes an application management resource object to the custom application management resource in the configuration manager in the disaster recovery system of the first cluster to specify the stateless application to be backed up, the second cluster for backup, and the fields to be modified in the resource file corresponding to the stateless application. If there are more than two specified fields that need to be modified, the order in which the specified fields are modified can also be set.

[0097] The resource manager obtains its own configuration information from the configuration manager, including but not limited to information about the stateless application to be backed up, and monitors the resource files corresponding to the stateless application to be backed up deployed on the first cluster in real time or periodically. When the resource files corresponding to the stateless application to be backed up change, the resource manager accesses the distributed state storage database on the first cluster through the API-Server component on the first cluster to obtain all resource files corresponding to the stateless application to be backed up or the changed resource files.

[0098] The resource modification manager obtains its own configuration information from the configuration manager, including but not limited to the fields to be modified in the resource file corresponding to the stateless application, the modified content of the fields to be modified, and the order of modifying the specified fields, and instantiates at least one resource modification unit in the resource modification pipeline in sequence.

[0099] The resource modification pipeline receives the resource file corresponding to the stateless application from the resource manager, and the resource modification units set in sequence on the resource modification pipeline modify the content of the specified field in the resource file so that it can run normally on the second cluster.

[0100] The transmission manager obtains its own configuration information from the configuration manager, including but not limited to the second cluster used for backup, and obtains the access authentication information of the second cluster from the multi-cluster management system. When the resource modification pipeline completes the modification of the resource files corresponding to the stateless application to be backed up, the transmission manager writes the modified resource files corresponding to the stateless application to be backed up into the distributed state storage database of the second cluster through the API-Server component of the second cluster.

[0101] The Controller Manager component on the second cluster reads the contents of the resource files corresponding to the synchronized stateless application from the distributed state storage database of the second cluster through the API-Server component, thereby implementing containerized deployment of the stateless application on the second cluster or changing the running status of the application instance of the stateless application on the second cluster.

[0102] In an embodiment of the present application, the disaster recovery system modifies the specified fields in the resource file corresponding to the stateless application so that the resource file can operate normally after being synchronized to the second cluster, thereby realizing real-time synchronization of the operating status of the application instances of the stateless application on the first cluster and the second cluster.

[0103] In addition, resource files corresponding to the stateless application are backed up at the application granularity, and the application administrator can freely back up the resource files corresponding to the stateless application to be backed up on one or more designated second clusters according to needs.

[0104] The resource files corresponding to the stateless application to be backed up are triggered or periodically synchronized through zero-delay resource change time drive, and the specified fields in the resource files corresponding to the stateless application are modified through the resource modification pipeline on the first cluster, so that the modified resource files corresponding to the stateless application to be backed up can run normally after being synchronized to the second cluster.

[0105] It should be noted that three types of administrators with different permissions are set up in this application: multi-cluster administrators - have the highest permissions and can manage multiple clusters; cluster administrators - have intermediate permissions and can manage a single cluster; application administrators - have the lowest permissions and manage a single application or multiple applications under its name. Multi-cluster administrators and cluster administrators manage multiple clusters and clusters by writing cluster management resource objects, and application administrators specify the synchronization settings and execution processes of backup clusters and configuration resources of stateless applications by writing application management resource objects. In this way, each administrator has a clear hierarchy of permissions, which effectively improves the efficient management and risk control of the entire disaster recovery system.

[0106] Exemplary Systems

[0107] Figure 8 A schematic diagram of the structure of a cross-cluster backup system for a stateless application provided according to some embodiments of the present application; Figure 8 As shown, the cross-cluster backup system of the stateless application is executed by the disaster recovery system deployed on the first cluster, including:

[0108] The monitoring unit 801 is configured to monitor resource files corresponding to the stateless application to be backed up deployed on the first cluster; the resource files include at least one of an application description file and a configuration file.

[0109] The file acquisition unit 802 is configured to acquire the resource file corresponding to the stateless application in response to a change in the resource file corresponding to the stateless application.

[0110] The file modification unit 803 is configured to modify the content of a specified field in the resource file corresponding to the stateless application based on a preset configuration.

[0111] The synchronization unit 804 is configured to synchronize the modified resource files corresponding to the stateless application to be backed up to the second cluster, so as to synchronize the stateless application from the first cluster to the second cluster.

[0112] The cross-cluster backup system for stateless applications provided in the embodiments of the present application can implement the steps and processes of the cross-cluster backup method for stateless applications in any of the above embodiments and achieve the same technical effects, which will not be described in detail here.

[0113] Exemplary Devices

[0114] Fig. 9 Schematic diagram of the structure of an electronic device provided according to some embodiments of the present application; Fig. 9 As shown, the electronic device includes:

[0115] One or more processors 901;

[0116] The computer-readable medium can be configured to store one or more programs 902. When one or more processors 901 execute one or more programs 902, the following steps are implemented: monitor the resource files corresponding to the stateless application to be backed up deployed on the first cluster; the resource files include at least one of the application description file and the configuration file. In response to changes in the resource files corresponding to the stateless application, obtain the resource files corresponding to the stateless application. Modify the content of the specified field in the resource file corresponding to the stateless application based on the preset configuration. Synchronize the modified resource files corresponding to the stateless application to be backed up to the second cluster to synchronize the stateless application from the first cluster to the second cluster.

[0117] Fig.10 The hardware structure of the electronic device provided according to some embodiments of the present application; Fig.10 As shown, the hardware structure of the electronic device may include: a processor 1001 , a communication interface 1002 , a computer-readable medium 1003 and a communication bus 1004 .

[0118] The processor 1001 , the communication interface 1002 , and the computer-readable storage medium 1003 communicate with each other via a communication bus 1004 .

[0119] Optionally, the communication interface 1002 may be an interface of a communication module, such as an interface of a GSM module.

[0120] The processor 1001 can be specifically configured to: monitor the resource files corresponding to the stateless application to be backed up deployed on the first cluster; the resource files include at least one of the application description file and the configuration file. In response to changes in the resource files corresponding to the stateless application, obtain the resource files corresponding to the stateless application. Modify the content of the specified field in the resource file corresponding to the stateless application based on the preset configuration. Synchronize the modified resource files corresponding to the stateless application to be backed up to the second cluster, so as to synchronize the stateless application from the first cluster to the second cluster.

[0121] The processor 1001 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc. It may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. It may implement or execute the disclosed methods, steps and logic block diagrams in the embodiments of the present application. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0122] The electronic device of the embodiment of the present application exists in various forms, including but not limited to:

[0123] (1) Mobile communication devices: These devices are characterized by their mobile communication functions and their main purpose is to provide voice and data communications. These terminals include: smart phones (e.g., iPhone), multimedia phones, functional phones, and low-end phones.

[0124] (2) Ultra-mobile personal computer devices: These devices fall into the category of personal computers, have computing and processing capabilities, and generally also have mobile Internet access features. These terminals include: PDA, MID and UMPC devices, such as iPad.

[0125] (3) Portable entertainment devices: These devices can display and play multimedia content. They include audio and video players (such as iPods), handheld game consoles, e-books, smart toys, and portable car navigation devices.

[0126] (4) Server: A device that provides computing services. The server consists of a processor, hard disk, memory, system bus, etc. The server is similar to a general computer architecture, but because it needs to provide highly reliable services, it has higher requirements in terms of processing power, stability, reliability, security, scalability, and manageability.

[0127] (5) Other electronic devices with data interaction functions.

[0128] It should be pointed out that, according to the needs of implementation, the various components / steps described in the embodiments of the present application can be split into more components / steps, or two or more components / steps or partial operations of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of the present application.

[0129] The above-mentioned method according to the embodiment of the present application can be implemented in hardware, firmware, or implemented as software or computer code that can be stored in a recording medium (such as a CD ROM, RAM, floppy disk, hard disk or magneto-optical disk), or implemented as a computer code originally stored in a remote recording medium or a non-temporary machine storage medium downloaded through a network and to be stored in a local recording medium, so that the method described herein can be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor or programmable or dedicated hardware (such as an ASIC or FPGA). It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code, and when the software or computer code is accessed and executed by a computer, a processor or hardware, the cross-cluster backup method for stateless applications described herein is implemented. In addition, when a general-purpose computer accesses the code for implementing the method shown herein, the execution of the code converts the general-purpose computer into a dedicated computer for executing the method shown herein.

[0130] Those of ordinary skill in the art will appreciate that the units and method steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and constraints involved in the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the embodiments of the present application.

[0131] It should be noted that each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments. The device and system embodiments described above are merely schematic, wherein the units not described as separation may or may not be physically separated, and the units not described as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without creative work.

[0132] The above are only preferred embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A cross-cluster backup method for stateless applications, characterized in that: The method is executed by a disaster recovery system deployed on the first cluster, and includes: Parse the application management resource object to determine the stateless application to be backed up; Monitoring a resource file corresponding to the stateless application to be backed up deployed on the first cluster; the resource file includes at least one of an application description file and a configuration file; In response to a change in a resource file corresponding to the stateless application, acquiring the resource file corresponding to the stateless application; Modify the content of a specified field in the resource file corresponding to the stateless application based on a preset configuration; Synchronizing the modified resource file corresponding to the stateless application to be backed up to the second cluster, so as to synchronize the stateless application from the first cluster to the second cluster; The modifying the content of a specified field in the resource file corresponding to the stateless application based on a preset configuration includes: Parsing a pre-written application management resource object; the application management resource object is used to specify the fields to be modified in the resource files corresponding to the second cluster and the stateless application, and to set the order in which the specified fields are modified; Modify the contents of the specified fields in the resource file corresponding to the stateless application in order according to the application management resource object to meet the operation requirements of the second cluster; the specified fields include at least one of an IP address and an image repository; The modifying, in order, the contents of the specified fields in the resource file corresponding to the stateless application according to the application management resource object comprises: At least one resource modification unit is instantiated according to the application management resource object; the at least one resource modification unit constitutes a resource modification pipeline, the resource modification pipeline is used to modify the content of the specified field in a specified order, and each resource modification unit is used to modify the content of the corresponding specified field; In response to the resource file corresponding to the stateless application being input into the resource modification pipeline, the content of the specified field in the resource file corresponding to the stateless application to be backed up is modified in the specified order.

2. The cross-cluster backup method for stateless applications according to claim 1, characterized in that: The first cluster is a Kubernetes cluster, and monitoring resource files corresponding to the stateless application to be backed up deployed on the first cluster includes: Establishing a persistent connection with the API-Server component on the first cluster; Monitoring the change events of the resource files corresponding to the stateless application to be backed up through the persistent connection; or, Periodically accessing the API-Server component on the first cluster to obtain resource files corresponding to the stateless application to be backed up; The resource files corresponding to the stateless application to be backed up that are obtained multiple times are compared to determine whether the resource files corresponding to the stateless application to be backed up are changed.

3. The cross-cluster backup method for stateless applications according to any one of claims 1-2, characterized in that: Also includes: Acquire access authentication information of the second cluster from the multi-cluster management system; The multi-cluster management system is used to manage the first cluster and the second cluster, and the access authentication information includes at least one of a certificate, a key, and a token.

4. The cross-cluster backup method for stateless applications according to claim 3, characterized in that: The second cluster is a Kubernetes cluster, and synchronizing the modified resource files corresponding to the stateless application to be backed up to the second cluster is specifically: Accessing the second cluster based on the access authentication information of the second cluster; The modified resource file corresponding to the stateless application to be backed up is written into the distributed state storage database of the second cluster through the API-Server component of the second cluster.

5. A cross-cluster backup system for stateless applications, characterized in that: The system is deployed on the first cluster and is used to implement the cross-cluster backup method of the stateless application according to claim 1, comprising: A monitoring unit configured to monitor a resource file corresponding to the stateless application to be backed up deployed on the first cluster; the resource file includes at least one of an application description file and a configuration file; A file acquisition unit, configured to acquire a resource file corresponding to the stateless application in response to a change in the resource file corresponding to the stateless application; A file modification unit, configured to modify the content of a specified field in a resource file corresponding to the stateless application based on a preset configuration; The synchronization unit is configured to synchronize the modified resource file corresponding to the stateless application to be backed up to the second cluster, so as to synchronize the stateless application from the first cluster to the second cluster.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that: The computer program is a cross-cluster backup method for stateless applications as described in any one of claims 1 to 4.

7. An electronic device, characterized in that: include: A memory, a processor, and a program stored in the memory and running on the processor, wherein when the processor executes the program, the cross-cluster backup method for stateless applications as described in any one of claims 1 to 4 is implemented.

Images