Backup method and device for guaranteeing data consistency based on Kubernetes container

Abstract

The invention discloses a backup method and device for guaranteeing data consistency based on a Kubernetes container, and the backup method comprises the following steps: obtaining a container backup resource list, and executing the check before backup; executing application layer data consistency guarantee; guaranteeing the data consistency of the execution file system layer; creating snapshots for the resources to be backed up; cleaning a data consistency guarantee environment; according to the method, data consistency safeguard measures are executed on the application layer and the file system layer respectively, the logic of the application program does not need to be modified, the invasiveness to the application program is greatly reduced, it is ensured that backup operation can be executed on a stable and consistent file system snapshot, and the backup efficiency is improved. The risk that the backup data is lost and unavailable or a file system is damaged during recovery is greatly reduced, an efficient and reliable backup solution is provided for various containerized applications, and the service continuity and the data security are further improved.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing and container technology, and in particular to a backup method and device based on Kubernetes containers to ensure data consistency. Background Art

[0002] Cloud computing is an emerging shared infrastructure approach that connects huge system pools to provide various IT services. With the booming development of cloud computing technology, more and more enterprises and organizations choose to use containerization technology to deploy and manage applications. As a leading platform for container orchestration, Kubernetes has greatly simplified the deployment, expansion and management processes of containers. Although Kubernetes provides powerful container management capabilities, it still faces many challenges in ensuring data consistency in containerized environments and effectively performing backup operations. Data consistency is crucial for container backup. It is the key to ensure that backup data can accurately reflect the real-time status of the container. Once data consistency is not guaranteed, backup data may encounter serious problems such as data loss, unavailability or file system damage during recovery, which directly affects business continuity and data security.

[0003] The data consistency guarantee of traditional backup methods is inadequate when dealing with dynamically changing container environments. These methods often rely on the logic within the application to refresh the cache or suspend write operations. However, this method has limitations: on the one hand, not all applications have built-in perfect cache refresh and data consistency guarantee mechanisms; on the other hand, even if such a mechanism exists, its execution efficiency and compatibility may vary from application to application, making it difficult to form a unified and universal solution. Summary of the invention

[0004] The present invention provides a backup method and device for ensuring data consistency based on Kubernetes containers, which can effectively solve the problem that the data consistency assurance of the traditional backup methods proposed in the above background technology is incapable of handling dynamically changing container environments. These methods often rely on the logic inside the application to refresh the cache or suspend write operations. However, this method has limitations: on the one hand, not all applications have built-in perfect cache refresh and data consistency assurance mechanisms; on the other hand, even if such a mechanism exists, its execution efficiency and compatibility may vary from application to application, making it difficult to form a unified and universal solution.

[0005] To achieve the above object, the present invention provides the following technical solutions: a backup method based on Kubernetes container to ensure data consistency, which realizes safe and reliable backup of data under Kubernetes container platform by combining data consistency guarantee measures of application layer and file system layer, as well as efficient snapshot technology and back-end storage synchronization mechanism;

[0006] The backup method includes the following steps:

[0007] S1. Obtain a list of container backup resources and perform a pre-backup check.

[0008] S2, perform application layer data consistency guarantee;

[0009] S3, perform file system layer data consistency guarantee;

[0010] S4. Create a snapshot of the backup resource.

[0011] S5. Clean up the data consistency assurance environment;

[0012] S6. Synchronize the snapshot backup data to the backend storage.

[0013] According to the above technical solution, S1 specifically includes the following:

[0014] S11. Obtain a list of container resources to be backed up;

[0015] S12, determine whether the resource is empty, if the resource is not empty, execute step S13, if the resource is empty, end the process without backup;

[0016] S13, perform a pre-backup check, analyze the resources obtained in step S11, sort out the dependent resource information, bound pre- or post-script information, Label mode backup filter conditions, and write the metadata information of the container backup;

[0017] S14, determine whether the resource has been backed up, if the resource has been backed up, return to step S11 to wait for the next backup task plan, if the resource has not been backed up, execute S15;

[0018] S15. Determine whether the resource has dependencies. If the resource has no related dependencies, there is no need to back up the dependent resources. If the resource has related dependent resources, the dependent resources need to be backed up.

[0019] According to the above technical solution, the list of container resources to be backed up mentioned in S11 refers to a list of a series of container resources that the user plans to perform backup operations on. These containers may contain important applications, services or data. The user hopes to ensure that these resources can be restored in the event of data loss or system failure through backup. The list of container resources to be backed up usually includes but is not limited to the basic information of the container ID, name, resource type, image name, creation time and status;

[0020] The container backup metadata information mentioned in S13 refers to various descriptive data related to the container backup operation, which helps to identify, manage and restore the backup data. The main content of the container backup metadata information includes but is not limited to basic container information, backup parameters and policies, backup status, data consistency information and storage location. The container backup metadata information is a key component to ensure the effectiveness and recoverability of the container backup;

[0021] The backup task plan mentioned in S14 refers to a pre-set regular or event-driven backup task schedule in a containerized environment. This plan usually includes the frequency, time, type, scope of the backup, and how to execute and store the backup data.

[0022] According to the above technical solution, S2 specifically includes the following:

[0023] S21. Check whether the Pod resource is configured with a pre-script. If so, execute step S22. If not, execute step S23.

[0024] S22, execute the pre-script, which is responsible for calling the application layer API to refresh the cache data related to the Pod;

[0025] S23. Determine whether all PVC resource backup snapshots in the Pod have been created. If not, continue waiting. If snapshot creation has been completed, execute step S24.

[0026] S24. Check whether the Pod resource is configured with a post-script. If there is a post-script, execute step S25. If there is no post-script, it is considered that the processing flow of application layer data consistency assurance has been completed, and the operation of the current stage can be ended.

[0027] S25. Execute the post-script to perform cleanup, verify operation results, send notifications, and other necessary follow-up processing.

[0028] According to the above technical solution, the pre-script and post-script are key components for ensuring the consistency of application layer data during the backup process. The pre-script is executed before the backup process starts, and is mainly used to prepare the data of the application to ensure the consistency of the data during the backup, including the following operations:

[0029] Pause or lock write operations in the application to prevent data from being modified during the backup process;

[0030] Refresh cache data to ensure that the backup is the latest or consistent data;

[0031] Perform data verification to ensure that the backed up data is accurate;

[0032] Notify the application of an impending backup operation, allowing the application to perform necessary state cleanup or preparation;

[0033] The post-script is executed after the backup process is completed. It is mainly used to restore the application status and perform post-backup cleanup work, including the following operations:

[0034] Resume write operations that were paused or locked in the pre-script, allowing the application to resume normal operation;

[0035] Clean up temporary files or data that may be generated during the backup process;

[0036] Update application status;

[0037] During the backup process, the pre-script and post-script not only check whether the pre-script or post-script exists, but also verify the integrity and executableness of the script, check the permission settings of the script file to ensure that it allows execution, and verify whether the script content conforms to the expected syntax specifications to avoid errors during execution. In addition, corresponding error handling mechanisms are set for various errors such as network problems and insufficient permissions that may be encountered during script execution, including retry logic, exception capture, error logging and alarms.

[0038] According to the above technical solution, S3 specifically includes the following:

[0039] S31. Retrieve detailed information of the Pod to be backed up from the backup resource list;

[0040] S32. Analyze the obtained Pod information to check whether the PVC volume is mounted. If the PVC volume exists, continue to execute step S33. Otherwise, it is considered that the Pod does not involve the file system layer data consistency guarantee, and the current processing flow ends.

[0041] S33. Dynamically deploy a temporary Container on the Pod node. This Container will be used to perform subsequent data consistency operations.

[0042] S34, after starting the temporary Container, continue to monitor its status to determine whether the Container is ready. If not, continue to wait until the Container is fully ready and ready to perform operations. If it is ready, execute step S35;

[0043] S35. Use the pre-configured toolset in the Container to perform a file system refresh operation on the PVC volume mounted in the Pod to ensure that all pending I / O operations are completed, and then perform a file system freeze operation to prevent data changes from occurring during the backup process, thereby ensuring data consistency.

[0044] According to the above technical solution, S5 specifically includes the following:

[0045] S51, check whether the snapshots of the resources to be backed up and their related dependent resources have been completed to ensure the integrity and availability of the backup data before canceling any data consistency guarantee measures. If the snapshot has not been created, continue to wait. If the snapshot has been created, execute step S52;

[0046] S52, releasing the freeze performed at the file system level. This step ensures that the file system is restored to a normal read-write state, avoiding unnecessary delays and impacts on business operations;

[0047] S53. Delete the Container temporarily created on the Pod node to ensure data consistency. After deleting the temporary Container, the related resources will be released and the status of the Pod will be restored to normal operation.

[0048] According to the above technical solution, S6 specifically includes the following:

[0049] S61: Create a temporary PersistenVolumeClaim from the backup snapshot;

[0050] S62: To provide a secure and isolated environment for performing data synchronization operations, create a temporary Pod in the Kubernetes cluster. This Pod will be used as the operating environment for data synchronization operations.

[0051] S63: Mount the temporary PVC volume created in step S61 to the temporary Pod to ensure that the Pod can access and operate the backup data;

[0052] S64: Read data from the PVC volume mounted in the temporary Pod and transfer the backup data from the temporary mount point to the configured backend storage system;

[0053] S65: Check whether data synchronization has been completed, if not, continue synchronization, if completed, execute step S66;

[0054] S66: Cancel the mounting relationship between the temporary PVC volume and the temporary Pod to release temporary storage resources;

[0055] S67: Clean up and delete the temporary Pods created during data synchronization to keep the environment clean;

[0056] In S61 and S62, by using temporary PVC and Pod, data backup and synchronization operations can be performed without affecting the existing system environment, thereby reducing interference with the production environment.

[0057] A backup device based on Kubernetes containers to ensure data consistency, including a backup controller, a PVC replication controller, a recovery controller, a PVC recovery controller, a mirror controller, a storage controller and a data consistency assurance controller;

[0058] The backup controller is the core scheduler of the backup process and is responsible for initiating and managing the entire backup process, including scheduling backup operations, monitoring backup status, triggering backups, and handling failures;

[0059] The PVC replication controller is responsible for creating snapshots of the PVC, managing the life cycle of the snapshots, and copying the snapshots to the backup storage location;

[0060] The recovery controller is responsible for managing and executing data recovery tasks. When data is lost or the system fails, the recovery controller will restore data from the backup to ensure that the system can quickly resume normal operation;

[0061] The PVC recovery controller is responsible for restoring the data in the backup storage system to the PVC of the Kubernetes cluster;

[0062] The image controller is responsible for managing and backing up container images;

[0063] The storage controller is responsible for managing and configuring storage resources;

[0064] The data consistency assurance controller is an important component in the entire backup and recovery system, and is responsible for ensuring the consistency and recoverability of the backup data.

[0065] According to the above technical solution, the backup controller and recovery controller are deployed in the form of Deployment, which is mainly responsible for cluster-level task scheduling and management. It is not necessary to run instances on each node, but to process backup and recovery requests as a centralized service. Through Deployment deployment, the number of copies, update strategies, health checks and rollback mechanisms of these controllers can be easily managed to ensure high availability and stability of the service.

[0066] The PVC replication controller, PVC recovery controller, mirror controller, storage controller and data consistency assurance controller are deployed on each Kubernetes node to directly monitor and process data read and write operations related to the node.

[0067] Compared with the prior art, the present invention has the following beneficial effects:

[0068] 1. By executing data consistency measures at the application layer and the file system layer respectively, there is no need to modify the logic of the application, which greatly reduces the intrusion into the application and ensures that the backup operation can be performed on a stable and consistent file system snapshot, which greatly reduces the risk of backup data being lost, unavailable, or file system being damaged during recovery. It provides an efficient and reliable backup solution for various containerized applications, further improving business continuity and data security.

[0069] The backup method and device are generally applicable and can refresh the cache and freeze the data without affecting the logic and operation of the original container to ensure the consistency of the backup data. The method and device are applicable to various types of applications and data. By executing data consistency protection measures at the application layer and the file system layer respectively, the integrity and consistency of the persistent volume data can be more effectively ensured during the backup process, and the errors and inconsistencies that may occur during data recovery are reduced, thereby improving the reliability and stability of the container backup system. Moreover, since the consistency of the backup data is guaranteed, the data can be restored to the expected state more quickly and reliably during the recovery operation, thereby reducing the risk of data recovery failure and increasing the success rate of data recovery.

[0070] 2. Taking advantage of the shared network and storage features between containers in the Pod, a dedicated temporary Container is deployed in the Pod to perform file system refresh and freeze operations, thereby achieving the goal of performing necessary operations on the shared file system using the preset tool set in the Container without interfering with the logic and running status of the original container to ensure the consistency of backup data. The core advantage of this method lies in its high flexibility and non-intrusiveness. Compared with performing data consistency guarantee operations directly on the original container, it avoids the need to modify the container image content, maintains the purity and integrity of the original image, simplifies the complexity of operations, and reduces the potential risks that may be introduced by modifying the image;

[0071] In addition, since the deployment and destruction of temporary containers are performed dynamically, they will not occupy Pod resources for a long time, nor will they have a significant impact on Pod performance. They have higher universality and adaptability, and can be easily applied to various scenarios that need to ensure the consistency of backup data. BRIEF DESCRIPTION OF THE DRAWINGS

[0072] The accompanying drawings are used to provide further understanding of the present invention and constitute a part of the specification. They are used to explain the present invention together with the embodiments of the present invention and do not constitute a limitation of the present invention.

[0073] In the attached picture:

[0074] Figure 1 It is a schematic diagram of the steps of the backup method of the present invention;

[0075] Figure 2 It is a specific flow chart of obtaining a container backup resource list of the present invention;

[0076] Figure 3 It is a specific flow chart of the present invention for executing application layer data consistency guarantee;

[0077] Figure 4 This is a specific flow chart of creating snapshots of backup resources according to the present invention;

[0078] Figure 5 It is a specific flow chart of the present invention for cleaning the data consistency assurance environment;

[0079] Figure 6 It is a specific flow chart of synchronizing snapshot backup data to backend storage in the present invention;

[0080] Figure 7 Schematic diagram of the backup device of the present invention

[0081] Figure 8 It is a deployment diagram of the backup device of the present invention. DETAILED DESCRIPTION

[0082] The preferred embodiments of the present invention are described below in conjunction with the accompanying drawings. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present invention, and are not used to limit the present invention.

[0083] Example: Figure 1 As shown, the present invention provides a technical solution, a backup method based on Kubernetes container to ensure data consistency, which realizes safe and reliable backup of data under Kubernetes container platform by combining data consistency guarantee measures of application layer and file system layer, as well as efficient snapshot technology and back-end storage synchronization mechanism;

[0084] The backup method includes the following steps:

[0085] S1. Obtain a list of container backup resources and perform a pre-backup check.

[0086] S2, perform application layer data consistency guarantee;

[0087] S3, perform file system layer data consistency guarantee;

[0088] S4. Create a snapshot of the backup resource.

[0089] S5. Clean up the data consistency assurance environment;

[0090] S6. Synchronize the snapshot backup data to the backend storage.

[0091] like Figure 2 As shown, based on the above technical solution, S1 specifically includes the following:

[0092] S11. Obtain a list of container resources to be backed up through the backup controller;

[0093] S12, determine whether the resource is empty, if the resource is not empty, execute step S13, if the resource is empty, end the process without backup;

[0094] S13, perform a pre-backup check, analyze the resources obtained in step S11, sort out the dependent resource information, bound pre- or post-script information, Label mode backup filter conditions, and write the metadata information of the container backup;

[0095] S14, determine whether the resource has been backed up, if the resource has been backed up, return to step S11 to wait for the next backup task plan, if the resource has not been backed up, execute S15;

[0096] S15. Determine whether the resource has dependencies. If the resource has no related dependencies, there is no need to back up the dependent resources. If the resource has related dependent resources, the dependent resources need to be backed up.

[0097] Based on the above technical solution, the list of container resources to be backed up mentioned in S11 refers to a list of a series of container resources that the user plans to back up. These containers may contain important applications, services or data. The user hopes to ensure that these resources can be restored in the event of data loss or system failure through backup. The list of container resources to be backed up usually includes but is not limited to the basic information of the container ID, name, resource type, image name, creation time and status;

[0098] The container backup metadata information mentioned in S13 refers to various descriptive data related to the container backup operation, which helps to identify, manage and restore the backup data. The main contents of the container backup metadata information include but are not limited to basic container information, backup parameters and policies, backup status, data consistency information and storage location. The container backup metadata information is a key component to ensure the effectiveness and recoverability of container backups.

[0099] The basic information of the container includes container ID, container name, Pod ID, Pod name, namespace, application label, image name and version, creation and start time. The backup parameters and strategies include backup time, backup frequency and backup type. The backup status includes the progress or result of the current backup operation. Data consistency information refers to whether data consistency is achieved during the recording process.

[0100] The backup task plan mentioned in S14 refers to a pre-set regular or event-driven backup task schedule in a containerized environment. This plan usually includes the frequency, time, type, scope of the backup, and how to execute and store the backup data.

[0101] like Figure 3 As shown, based on the above technical solution, S2 specifically includes the following:

[0102] S21. Check whether the Pod resource is configured with a pre-script. If so, execute step S22. If not, execute step S23.

[0103] S22, through the data consistency guarantee controller, executes the pre-script, which is responsible for calling the application layer API to refresh the cache data related to the Pod;

[0104] S23. Determine whether all PVC resource backup snapshots in the Pod have been created. If not, continue waiting. If snapshot creation has been completed, execute step S24.

[0105] S24. Check whether the Pod resource is configured with a post-script. If there is a post-script, execute step S25. If there is no post-script, it is considered that the processing flow of application layer data consistency assurance has been completed, and the operation of the current stage can be ended.

[0106] S25. Through the data consistency assurance controller, execute the post-script to perform cleanup work, verify operation results, send notifications and other necessary follow-up processing.

[0107] Based on the above technical solution, the pre-script and post-script are key components for ensuring the consistency of application layer data during the backup process. The pre-script is executed before the backup process starts and is mainly used to prepare the application data to ensure data consistency during backup, including the following operations:

[0108] Pause or lock write operations in the application to prevent data from being modified during the backup process;

[0109] Refresh cache data to ensure that the backup is the latest or consistent data;

[0110] Perform data verification to ensure that the backed up data is accurate;

[0111] Notify the application of an impending backup operation, allowing the application to perform necessary state cleanup or preparation;

[0112] The post-script is executed after the backup process is completed. It is mainly used to restore the application status and perform post-backup cleanup work, including the following operations:

[0113] Resume write operations that were paused or locked in the pre-script, allowing the application to resume normal operation;

[0114] Clean up temporary files or data that may be generated during the backup process;

[0115] Update application status;

[0116] During the backup process, the pre-script and post-script not only check whether the pre-script or post-script exists, but also verify the integrity and executableness of the script, check the permission settings of the script file to ensure that it allows execution, and verify whether the script content conforms to the expected syntax specifications to avoid errors during execution. In addition, corresponding error handling mechanisms are set for various errors such as network problems and insufficient permissions that may be encountered during script execution, including retry logic, exception capture, error logging and alarms.

[0117] like Figure 4 As shown, based on the above technical solution, S3 specifically includes the following:

[0118] S31. Retrieve detailed information of the Pod to be backed up from the backup resource list;

[0119] S32. Analyze the obtained Pod information to check whether the PVC volume and PersistentVolumeClaim are mounted. If the PVC volume exists, continue to step S33. Otherwise, it is considered that the Pod does not involve the data consistency guarantee at the file system layer, and the current processing flow ends.

[0120] S33. Dynamically deploy a temporary Container on the Pod node. This Container will be used to perform subsequent data consistency operations.

[0121] S34, after starting the temporary Container, continue to monitor its status to determine whether the Container is ready. If not, continue to wait until the Container is fully ready and ready to perform operations. If it is ready, execute step S35;

[0122] S35. Use the pre-installed tool set in the Container to perform a file system refresh operation on the PVC volume mounted in the Pod through the file system management tool to ensure that all pending I / O operations are completed, and then perform a file system freeze operation to prevent data changes during the backup process, thereby ensuring data consistency;

[0123] Taking advantage of the shared network and storage features between containers in the Pod, a dedicated temporary Container is deployed in the Pod to perform file system refresh and freeze operations. This allows the tool set pre-installed in the Container to perform necessary operations on the shared file system without interfering with the logic and running status of the original container, thereby ensuring the consistency of backup data.

[0124] The core advantage of this method is its high flexibility and non-intrusiveness. Compared with directly performing data consistency guarantee operations on the original container, it avoids the need to modify the container image content, maintains the purity and integrity of the original image, simplifies the operation complexity, and reduces the potential risks that may be introduced by modifying the image, such as compatibility issues and configuration errors.

[0125] In addition, since the deployment and destruction of temporary containers are performed dynamically, they will not occupy Pod resources for a long time, nor will they have a significant impact on Pod performance, making the solution more universal and adaptable, and can be easily applied to various scenarios that need to ensure the consistency of backup data.

[0126] like Figure 5 As shown, based on the above technical solution, S5 specifically includes the following:

[0127] S51, check whether the snapshots of the resources to be backed up and their related dependent resources have been completed to ensure the integrity and availability of the backup data before canceling any data consistency guarantee measures. If the snapshot has not been created, continue to wait. If the snapshot has been created, execute step S52;

[0128] S52, releasing the freeze performed at the file system level through the data consistency assurance controller, this step ensures that the file system is restored to a normal read-write state, avoiding unnecessary delays and impacts on business operations;

[0129] S53. Delete the Container temporarily created on the Pod node to ensure data consistency. After deleting the temporary Container, the related resources will be released and the status of the Pod will be restored to normal operation.

[0130] like Figure 6 As shown, based on the above technical solution, S6 specifically includes the following:

[0131] S61: Create a temporary PersistenVolumeClaim, or PVC volume, from the backup snapshot.

[0132] S62: To provide a secure and isolated environment for performing data synchronization operations, create a temporary Pod in the Kubernetes cluster. This Pod will be used as the operating environment for data synchronization operations.

[0133] S63: Mount the temporary PVC volume created in step S61 to the temporary Pod to ensure that the Pod can access and operate the backup data;

[0134] S64: Read data from the PVC volume mounted in the temporary Pod and transfer the backup data from the temporary mount point to the configured backend storage system through the PVC replication controller;

[0135] S65: Check whether data synchronization has been completed, if not, continue synchronization, if completed, execute step S66;

[0136] S66: Cancel the mounting relationship between the temporary PVC volume and the temporary Pod to release temporary storage resources;

[0137] S67: Clean up and delete the temporary Pods created during data synchronization to keep the environment clean;

[0138] In S61 and S62, by using temporary PVC and Pod, data backup and synchronization operations can be performed without affecting the existing system environment, reducing interference with the production environment.

[0139] like Figure 7 As shown, a backup device for ensuring data consistency based on Kubernetes containers includes a backup controller, a PVC replication controller, a recovery controller, a PVC recovery controller, a mirror controller, a storage controller, and a data consistency assurance controller;

[0140] The backup controller is the core scheduler of the backup process, responsible for initiating and managing the entire backup process, including scheduling backup operations, monitoring backup status, triggering backups, and handling failures;

[0141] The PVC replication controller is responsible for creating snapshots of PVC, managing the lifecycle of snapshots, and copying snapshots to backup storage locations;

[0142] The recovery controller is responsible for managing and executing data recovery tasks. In the event of data loss or system failure, the recovery controller will restore data from the backup to ensure that the system can quickly resume normal operation.

[0143] The PVC recovery controller is responsible for restoring the data in the backup storage system to the PVC of the Kubernetes cluster;

[0144] The image controller is responsible for managing and backing up container images;

[0145] The storage controller is responsible for managing and configuring storage resources;

[0146] The data consistency assurance controller is an important component in the entire backup and recovery system. It is responsible for ensuring the consistency and recoverability of backup data.

[0147] like Figure 8 As shown in the figure, based on the above technical solution, the backup controller and recovery controller are deployed in the form of Deployment, which is mainly responsible for cluster-level task scheduling and management. It is not necessary to run instances on each node, but to process backup and recovery requests as a centralized service. Through Deployment deployment, the number of replicas, update strategies, health checks, and rollback mechanisms of these controllers can be easily managed to ensure high availability and stability of the service.

[0148] The PVC replication controller, PVC recovery controller, mirror controller, storage controller, and data consistency assurance controller are deployed on each Kubernetes node to directly monitor and process node-related data read and write operations.

[0149] Finally, it should be noted that the above description is only a preferred example of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art can still modify the technical solutions described in the aforementioned embodiments or replace some of the technical features therein by equivalents. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A backup method based on Kubernetes container to ensure data consistency, characterized by: By combining data consistency measures at the application layer and the file system layer, as well as efficient snapshot technology and backend storage synchronization mechanism, secure and reliable data backup is achieved on the Kubernetes container platform. The backup method includes the following steps: S1. Obtain a list of container backup resources and perform a pre-backup check. S2, perform application layer data consistency guarantee; S3, perform file system layer data consistency guarantee; S4. Create a snapshot of the backup resource. S5. Clean up the data consistency guarantee environment; S6. Synchronize the snapshot backup data to the backend storage.

2. According to claim 1, a backup method based on Kubernetes container to ensure data consistency is characterized in that: The S1 specifically includes the following: S11. Obtain a list of container resources to be backed up; S12, determine whether the resource is empty, if the resource is not empty, execute step S13, if the resource is empty, end the process without backup; S13, perform a pre-backup check, analyze the resources obtained in step S11, sort out the dependent resource information, bound pre- or post-script information, Label mode backup filter conditions, and write the metadata information of the container backup; S14, determine whether the resource has been backed up, if the resource has been backed up, return to step S11 to wait for the next backup task plan, if the resource has not been backed up, execute S15; S15. Determine whether the resource has dependencies. If the resource has no related dependencies, there is no need to back up the dependent resources. If the resource has related dependent resources, the dependent resources need to be backed up.

3. According to claim 2, a backup method based on Kubernetes container to ensure data consistency is characterized in that: The list of container resources to be backed up mentioned in S11 refers to a list of a series of container resources that the user plans to back up. These containers may contain important applications, services or data. The user hopes to ensure that these resources can be restored in the event of data loss or system failure through backup. The list of container resources to be backed up usually includes but is not limited to basic information such as the container ID, name, resource type, image name, creation time and status; The container backup metadata information mentioned in S13 refers to various descriptive data related to the container backup operation; The backup task plan mentioned in S14 refers to a pre-set regular or event-driven backup task schedule in a containerized environment.

4. According to claim 1, a backup method for ensuring data consistency based on Kubernetes containers is characterized in that: The S2 specifically includes the following: S21. Check whether the Pod resource is configured with a pre-script. If so, execute step S22. If not, execute step S23. S22, execute the pre-script, which is responsible for calling the application layer API to refresh the cache data related to the Pod; S23. Determine whether all PVC resource backup snapshots in the Pod have been created. If not, continue waiting. If snapshot creation has been completed, execute step S24. S24. Check whether the Pod resource is configured with a post-script. If there is a post-script, execute step S25. If there is no post-script, it is considered that the processing flow of application layer data consistency assurance has been completed, and the operation of the current stage can be ended. S25. Execute the post-script to perform cleanup, verify operation results, send notifications, and other necessary follow-up processing.

5. According to a backup method for ensuring data consistency based on Kubernetes containers according to claim 4, it is characterized in that: The pre-script and post-script are key components for ensuring the consistency of application layer data during the backup process. The pre-script is executed before the backup process starts and is mainly used to prepare the application data to ensure data consistency during the backup, including the following operations: Pause or lock write operations in the application to prevent data from being modified during the backup process; Refresh cache data to ensure that the backup is the latest or consistent data; Perform data verification to ensure that the backed up data is accurate; Notify the application of an impending backup operation, allowing the application to perform necessary state cleanup or preparation; The post-script is executed after the backup process is completed. It is mainly used to restore the application status and perform post-backup cleanup work, including the following operations: Resume write operations that were paused or locked in the pre-script, allowing the application to resume normal operation; Clean up temporary files or data that may be generated during the backup process; Update application status; During the backup process, the pre-script and post-script not only check whether the pre-script or post-script exists, but also verify the integrity and executableness of the script, check the permission settings of the script file to ensure that it allows execution, and verify whether the script content conforms to the expected syntax specifications to avoid errors during execution. In addition, corresponding error handling mechanisms are set for various errors such as network problems and insufficient permissions that may be encountered during script execution, including retry logic, exception capture, error logging and alarms.

6. According to claim 1, a backup method for ensuring data consistency based on Kubernetes containers is characterized in that: The S3 specifically includes the following: S31. Retrieve detailed information of the Pod to be backed up from the backup resource list; S32, analyzing the obtained Pod information to check whether the PVC volume is mounted. If the PVC volume exists, continue to step S33; otherwise, it is considered that the Pod does not involve the file system layer data consistency guarantee, and the current processing flow ends; S33. Dynamically deploy a temporary Container on the Pod node. This Container will be used to perform subsequent data consistency operations. S34, after starting the temporary Container, continue to monitor its status to determine whether the Container is ready. If not, continue to wait until the Container is fully ready and ready to perform operations. If it is ready, execute step S35; S35. Use the pre-configured toolset in the Container to perform a file system refresh operation on the PVC volume mounted in the Pod to ensure that all pending I / O operations are completed, and then perform a file system freeze operation to prevent data changes during the backup process, thereby ensuring data consistency.

7. According to claim 1, a backup method for ensuring data consistency based on Kubernetes containers is characterized in that: The S5 specifically includes the following: S51, check whether the snapshots of the resources to be backed up and their related dependent resources have been completed to ensure the integrity and availability of the backup data before canceling any data consistency guarantee measures. If the snapshot has not been created, continue to wait. If the snapshot has been created, execute step S52; S52, releasing the freeze performed at the file system level. This step ensures that the file system is restored to a normal read-write state, avoiding unnecessary delays and impacts on business operations; S53. Delete the Container temporarily created on the Pod node to ensure data consistency. After deleting the temporary Container, the related resources will be released and the status of the Pod will be restored to normal operation.

8. According to claim 1, a backup method for ensuring data consistency based on Kubernetes containers is characterized in that: The S6 specifically includes the following: S61: Create a temporary PersistenVolumeClaim from the backup snapshot; S62: To provide a secure and isolated environment for performing data synchronization operations, create a temporary Pod in the Kubernetes cluster. This Pod will be used as the operating environment for data synchronization operations. S63: Mount the temporary PVC volume created in step S61 to the temporary Pod to ensure that the Pod can access and operate the backup data; S64: Read data from the PVC volume mounted in the temporary Pod and transfer the backup data from the temporary mount point to the configured backend storage system; S65: Check whether data synchronization has been completed, if not, continue synchronization, if completed, execute step S66; S66: Cancel the mounting relationship between the temporary PVC volume and the temporary Pod to release temporary storage resources; S67: Clean up and delete the temporary Pods created during data synchronization to keep the environment clean; In S61 and S62, temporary PVC and Pod are used to perform data backup and synchronization operations without affecting the existing system environment.

9. A backup device based on Kubernetes container to ensure data consistency, characterized by: Including backup controller, PVC replication controller, recovery controller, PVC recovery controller, mirror controller, storage controller and data consistency assurance controller; The backup controller is the core scheduler of the backup process and is responsible for initiating and managing the entire backup process, including scheduling backup operations, monitoring backup status, triggering backups, and handling failures; The PVC replication controller is responsible for creating snapshots of the PVC, managing the life cycle of the snapshots, and copying the snapshots to the backup storage location; The recovery controller is responsible for managing and executing data recovery tasks. When data is lost or the system fails, the recovery controller will restore data from the backup to ensure that the system can quickly resume normal operation; The PVC recovery controller is responsible for restoring the data in the backup storage system to the PVC of the Kubernetes cluster; The image controller is responsible for managing and backing up container images; The storage controller is responsible for managing and configuring storage resources; The data consistency assurance controller is an important component in the entire backup and recovery system, and is responsible for ensuring the consistency and recoverability of the backup data.

10. A backup device for ensuring data consistency based on Kubernetes containers according to claim 9, characterized in that: The backup controller and recovery controller are deployed in the form of Deployment, which is mainly responsible for cluster-level task scheduling and management. It does not need to run instances on each node, but serves as a centralized service to handle backup and recovery requests. Through Deployment deployment, the number of copies, update strategies, health checks, and rollback mechanisms of these controllers can be easily managed to ensure high availability and stability of the service. The PVC replication controller, PVC recovery controller, mirror controller, storage controller and data consistency assurance controller are deployed on each Kubernetes node to directly monitor and process data read and write operations related to the node.

Images