State snapshot method and state recovery method of cloud native container and related equipment

Abstract

The embodiment of the invention provides a state snapshot method of a cloud native container, a state recovery method and related equipment, and relates to the technical field of computers. The state snapshot method comprises the following steps: receiving a snapshot triggering instruction which is issued by a snapshot controller and carries a target container identifier; obtaining a writable layer path of the target container based on the target container identifier, wherein a writable layer is an Upperde layer of a basic mirror layer in the joint file system; based on a writable layer path of the target container, calling a snapshot execution component to perform persistent operation on a writable layer, generating snapshot data and associated snapshot metadata, and storing the snapshot data and the associated snapshot metadata to a persistent storage system; the snapshot metadata at least comprises a writable layer path, a basic mirror image layer identifier and a snapshot identifier, the basic mirror image layer identifier is used for uniquely identifying a basic mirror image layer on which a writable layer depends, and the snapshot identifier is used for uniquely identifying a snapshot version of the snapshot data. Therefore, the flexibility and reliability of container state management can be improved.

Description

TECHNICAL FIELD

[0001] The embodiments in the specification relate to the field of computer technology, and in particular, to a state snapshot method and a state recovery method of a cloud-native container and related equipment. BACKGROUND

[0002] In the current field of cloud-native computing, container technology has become the core carrier for application deployment and running due to its advantages such as lightweight, fast startup, and high resource utilization, and is widely used in microservices, continuous integration / continuous deployment (CI / CD), and edge computing scenarios. Generally, container runtimes (such as Docker and Containerd) are based on Linux namespaces, control groups (cgroups), and joint file systems (such as OverlayFS), and implement the startup and termination of containers by managing the life cycle of the container's main process.

[0003] Since containers themselves lack native suspend and resume mechanisms, once a container stops running, its runtime state, especially the writable layer state of the file system, will be completely lost. This limitation makes it difficult for containers to meet application requirements such as interactive application breakpoint resumption, temporary interruption and restart of long-time computing tasks, and dynamic migration of cluster nodes. However, related technologies lack efficient recovery mechanisms, making it difficult to support state management and flexible scheduling of containers in cloud-native scenarios.

[0004] Therefore, there is an urgent need to provide a container state snapshot and recovery method that can be deeply integrated with cloud-native container runtimes, save storage, and support automated management, to improve the efficiency of container recovery. SUMMARY

[0005] Therefore, there is an urgent need to provide a container state snapshot and recovery method that can be deeply integrated with cloud-native container runtimes, save storage, and support automated management, to improve the efficiency of container recovery.

[0006] The embodiments of the present specification provide a state snapshot method of a cloud-native container, applied to a container runtime of a cloud-native container platform, the cloud-native container platform comprising a snapshot controller and a snapshot execution component in communication connection with the container runtime; the method comprises: receiving a snapshot trigger instruction issued by the snapshot controller; wherein the snapshot trigger instruction carries a target container identifier, and the target container identifier is used to uniquely identify a target container; in response to the snapshot trigger instruction, obtaining a writable layer path of the target container based on the target container identifier, wherein the writable layer is an upperdir layer of a base image layer in a union file system; based on the writable layer path of the target container, calling the snapshot execution component to perform a persistent operation on the writable layer, generating snapshot data and associated snapshot metadata, and storing to a persistent storage system, so as to realize state snapshot of the target container; wherein the snapshot metadata at least comprises the writable layer path, a base image layer identifier and a snapshot identifier, the base image layer identifier is used to uniquely identify a base image layer relied on by the writable layer, and the snapshot identifier is used to uniquely identify a snapshot version of the snapshot data.

[0007] In some embodiments, the persistent operation is an incremental persistent operation; and the persistent operation on the writable layer comprises: performing a difference comparison between current data of the writable layer and snapshot data of a previous snapshot version of the writable layer, to obtain difference data; taking the difference data as incremental snapshot data, and performing persistent storage together with the associated snapshot metadata.

[0008] In some embodiments, the snapshot trigger instruction is determined based on any one of the following: a timing trigger; wherein the timing trigger is used to monitor whether the target container reaches a preset timing period; an event trigger; wherein the event trigger is used to monitor whether a size change of the writable layer path of the target container exceeds a preset threshold; a CRD component; the CRD component is used to respond to a snapshot request of a user.

[0009] The embodiments of the present specification provide a state recovery method of a cloud-native container, applied to a container runtime of a cloud-native container platform, the cloud-native container platform further comprising a snapshot controller and a snapshot execution component in communication connection with the container runtime; the method comprises: receiving a container recovery instruction issued by the snapshot controller; wherein the container recovery instruction carries a target snapshot identifier; in response to the container recovery instruction, calling the snapshot execution component to obtain target snapshot metadata corresponding to the target snapshot identifier and its associated target snapshot data from a persistent storage system based on the target snapshot identifier; wherein the persistent storage system comprises at least one snapshot data, and each snapshot data is associated with corresponding snapshot metadata, the snapshot metadata comprising a snapshot identifier, a writable layer path, and a base image layer identifier, the snapshot identifier being used to uniquely identify the snapshot version of the snapshot data, and the base image layer identifier being used to uniquely identify the base image layer on which the writable layer to which the snapshot data belongs depends; creating a target container based on the target snapshot metadata and its associated target snapshot data to realize state recovery of the target container.

[0010] In some embodiments, the creating a target container based on the target snapshot metadata and its associated target snapshot data comprises: loading a corresponding base image layer as a base image layer of a joint file system mounted by the target container according to the base image layer identifier in the target snapshot metadata, denoted as a target base image layer; and restoring the target snapshot data in the target base image layer according to a storage location indicated by the writable layer path in the target snapshot metadata to realize state recovery of the target container.

[0011] In some embodiments, before the creating a target container based on the target snapshot data and its associated target snapshot metadata, the method further comprises: performing a permission repair operation on the target snapshot data to be recovered to make the file permissions consistent with the environment requirements of the container runtime.

[0012] The embodiment of the present specification provides a state snapshot device of a cloud-native container, which is applied to a container runtime of a cloud-native container platform, the cloud-native container platform further comprising a snapshot controller and a snapshot execution component in communication connection with the container runtime; the device comprises: a snapshot instruction receiving module, configured to receive a snapshot trigger instruction issued by the snapshot controller; wherein the snapshot trigger instruction carries a target container identifier, and the target container identifier is used to uniquely identify a target container; a path acquisition module, configured to acquire a writable layer path of the target container based on the target container identifier in response to the snapshot trigger instruction, wherein the writable layer is an upperdir layer of a base image layer in a union file system; and a snapshot execution module, configured to perform a persistent operation on the writable layer by calling the snapshot execution component based on the writable layer path of the target container, to generate snapshot data and associated snapshot metadata, and store the snapshot data and the associated snapshot metadata to a persistent storage system, so as to realize state snapshot of the target container; wherein the snapshot metadata at least comprises the writable layer path, a base image layer identifier and a snapshot identifier, the base image layer identifier is used to uniquely identify a base image layer relied on by the writable layer, and the snapshot identifier is used to uniquely identify a snapshot version of the snapshot data.

[0013] The embodiment of the present specification provides a state recovery device of a cloud-native container, which is applied to a container runtime of a cloud-native container platform, the cloud-native container platform further comprising a snapshot controller and a snapshot execution component in communication connection with the container runtime; the device comprises: a recovery instruction receiving module, configured to receive a container recovery instruction issued by the snapshot controller; wherein the container recovery instruction carries a target snapshot identifier; a data acquisition module, configured to acquire target snapshot metadata corresponding to the target snapshot identifier and associated target snapshot data from a persistent storage system by calling the snapshot execution component based on the target snapshot identifier in response to the container recovery instruction; wherein the persistent storage system comprises at least one snapshot data, each snapshot data is associated with corresponding snapshot metadata, and the snapshot metadata comprises a snapshot identifier, a writable layer path and a base image layer identifier, the snapshot identifier is used to uniquely identify a snapshot version of the snapshot data, and the base image layer identifier is used to uniquely identify a base image layer relied on by a writable layer to which the snapshot data belongs; and a container creation module, configured to create a target container based on the target snapshot metadata and the associated target snapshot data, so as to realize state recovery of the target container.

[0014] The embodiment of the present specification provides a computer device, comprising a memory and a processor, the memory stores a computer program, and the processor implements the state snapshot method or the state recovery method of the cloud-native container according to any one of the above-mentioned embodiments when executing the computer program.

[0015] The embodiments of the present specification provide a computer readable storage medium, which stores a computer program. The computer program is executed by a processor to implement the state snapshot method or the state recovery method of the cloud-native container.

[0016] In the plurality of embodiments provided by the present specification, the cloud-native container platform includes a container runtime and a snapshot controller and a snapshot execution component in communication connection with the container runtime. In the container snapshot method, first, the container runtime receives a snapshot trigger instruction carrying a target container identifier issued by the snapshot controller. The target container identifier is used to uniquely identify the target container. Then, the container runtime acquires a writable layer path of the target container based on the target container identifier in response to the snapshot trigger instruction. The writable layer is an upperdir layer of a base image layer in a union file system. Next, based on the writable layer path of the target container, the snapshot execution component is called to perform a persistent operation on the writable layer to generate snapshot data and associated snapshot metadata. The snapshot metadata at least includes the writable layer path, a base image layer identifier and a snapshot identifier. The base image layer identifier is used to uniquely identify the base image layer relied on by the writable layer. The snapshot identifier is used to uniquely identify the snapshot version of the snapshot data. Finally, the snapshot data and the associated snapshot metadata are stored to a persistent storage system to realize the state snapshot of the target container, so as to facilitate the subsequent state recovery of the target container. In this way, the container state management can be deeply integrated with the cloud-native container runtime, storage is saved, and automatic management is supported, thereby improving the flexibility and reliability of the container state management. BRIEF DESCRIPTION OF DRAWINGS

[0017] Figure 1 A schematic diagram of the state management system of the cloud-native container provided by the embodiments of the present specification; Figure 2 A flowchart of the state snapshot method of the cloud-native container provided by the embodiments of the present specification; Figure 3 A flowchart of the state recovery method of the cloud-native container provided by the embodiments of the present specification; Figure 4 A schematic diagram of the computer device provided by the embodiments of the present specification. DETAILED DESCRIPTION

[0018] In order for those skilled in the art to better understand the present specification, the technical solutions in the embodiments of the present specification will be described clearly and completely in conjunction with the drawings in the embodiments of the present specification. Obviously, the described embodiments are only part of the embodiments of the present specification, not all the embodiments. Based on the embodiments in the present specification, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present specification.

[0019] In related technologies, in order to realize the saving and recovery of the container state, a containerd native snapshot scheme or a Docker Commit scheme can be used. In the containerd native snapshot scheme, the container runtime Containerd manages the image layer and the container file system through its built-in Snapshotter, such as overlayfs snapshotter. The snapshot structure thereof contains the base image layer: the read-only layer lowerdir, the writable layer upperdir, and the merged view layer mergedir. However, this native scheme mainly serves the image building and container creation process, and the upperdir layer is only used as temporary storage for the container runtime, and does not provide a mechanism for directly and efficiently persisting it as an independent entity. When recovering the container, the existing process must recreate the container based on the original base image, and then synchronize the persisted upperdir layer content back to the new container through file copying or the like, resulting in a tedious and time-consuming recovery process with low efficiency. In the Docker Commit-based scheme, the current state of the running container is committed as a new image. However, each commit operation needs to package the entire writable layer to generate a complete image layer, and the time consumption is positively correlated with the increase of the container data volume, which cannot realize the fast snapshot and recovery within seconds, and the flexibility and efficiency cannot meet the needs of high-frequency state management in production environment. Other related schemes such as the Kubernetes native VolumeSnapshot mainly target the data of the persistent volume, and cannot capture the complete state of the container root file system.

[0020] Therefore, it is necessary to perform targeted persistence on the container writable layer upperdir, reduce repeated processing of the base image layer, perform fine management on the container state, and improve the efficiency of container recovery.

[0021] The present specification embodiment provides a scenario example of a container state management system for state snapshot and state recovery of cloud-native containers. Please refer to Figure 1 , Figure 1 The present specification embodiment provides a schematic diagram of a container state management system. The container state management system can include a container runtime of a cloud-native container platform, and a snapshot controller and a snapshot execution component in communication connection with the container runtime.

[0022] In the present scenario example, in order to realize efficient saving of the cloud-native container state, the cloud-native container platform in the container state management system can refer to a software platform based on cloud-native architecture for deploying, running and managing containerized applications. Illustratively, the cloud-native container platform can be a Kubernetes cluster.

[0023] The container runtime can refer to the underlying management software responsible for the container lifecycle, such as Containerd or CRI-O, which can perform functions including pulling images, creating, starting, stopping, and destroying containers.

[0024] In the present scenario example, the snapshot controller can be a logically independent component running on the host or master node, which can be implemented in the form of a Kubernetes controller, for example, to receive snapshot requests, formulate snapshot strategies, and issue control instructions.

[0025] By way of example, the container state management system can further include a CRD component in the cloud-native container platform. The CRD component can be used to configure the persistent path, for example, by the "spec.upperdirPath" instruction. As an example, the CRD component can also be used to configure the base image layer list and other fields, for example, by configuring the base image layer through the spec.baseImageLayers instruction. As an example, the CRD component can also be used to configure the snapshot strategy to snapshot and restore the container state for different tasks.

[0026] In the present scenario example, the snapshot execution component can be a component or agent program that performs snapshot operations independently of the container runtime. By way of example, the snapshot execution component can be a separate daemon process deployed on the same node as the container runtime, which can communicate with the container runtime through the application programming interface provided by the container runtime, receive and execute instructions from the snapshot controller.

[0027] In the present scenario example, the joint file system of the node or host where the container runtime is located can include a base image layer, which can include a read-only layer Lowerdir and a writable layer Upperdir. As an example, the read-only layer Lowerdir can include three layers, Layer0, Layer1, and Layer2, and the writable layer Upperdir can include Layer3. In the present scenario example, a layered storage strategy is adopted, that is, Lowerdir is multiplexed, and only the differential data of Upperdir is persisted, reducing storage occupancy.

[0028] This scenario demonstrates efficient recovery by specifying the Upperdir before container creation, eliminating the need for base image layer reconstruction and file synchronization. Recovery time is reduced by over 60% compared to existing solutions, making it particularly suitable for large container scenarios. Storage optimization is also achieved by snapshotting only the differences in the Upperdir, avoiding redundant storage of the base image layer and reducing storage usage by 30%-50% compared to existing solutions. Furthermore, the scenario exhibits strong compatibility with native implementations. A snapshot execution component is developed based on the native interface of the Containerd runtime, enhancing compatibility and stability compared to third-party tools like CRIU. Finally, automated management is implemented through the CRD component, automating snapshot policy execution and adapting to dynamic scaling scenarios in cloud-native clusters.

[0029] This specification provides a method for taking state snapshots of cloud-native containers. Please refer to [link / reference]. Figure 2 , Figure 2 This is a flowchart illustrating a cloud-native container state snapshot method provided in this embodiment. This embodiment provides the method operation steps shown in the flowchart, but based on conventional or non-creative labor, more or fewer operation steps may be included. The order of steps listed in this embodiment is merely one possible execution order among many, and does not represent the only possible execution order. In actual system or server product execution, the method can be executed sequentially as shown in the embodiment or in parallel (e.g., in a parallel processor or multi-threaded processing environment). This cloud-native container state snapshot method can be applied to the container runtime of a cloud-native container platform, specifically as follows... Figure 2 As shown, the state snapshot method may include the following steps.

[0030] Step S210: Receive a snapshot trigger command issued by the snapshot controller; wherein the snapshot trigger command carries a target container identifier, which is used to uniquely identify the target container.

[0031] In some cases, the container runtime Containerd can receive snapshot triggering instructions from the snapshot controller SnapshotterController, which are used to instruct the target container to perform a state snapshot operation.

[0032] Step S220: In response to the snapshot trigger command, obtain the writable layer path of the target container based on the target container identifier, wherein the writable layer is the upperdir layer of the base image layer in the union file system.

[0033] Specifically, the container runtime Containerd can obtain a writable layer path of the target container based on the target container identifier in response to the snapshot trigger instruction. The writable layer path refers to a directory path of a writable layer created for the target container on a union file system of a node or a host where the container runtime is located. The writable layer is an upperdir layer of a base image layer in the union file system.

[0034] In step S230, a snapshot execution component is invoked to perform a persistent operation on the writable layer based on the writable layer path of the target container, to generate snapshot data and associated snapshot metadata, and store them in a persistent storage system, so as to realize the state snapshot of the target container. The snapshot metadata at least includes the writable layer path, a base image layer identifier, and a snapshot identifier. The base image layer identifier is used to uniquely identify the base image layer on which the writable layer depends, and the snapshot identifier is used to uniquely identify the snapshot version of the snapshot data.

[0035] In this embodiment, the snapshot data can be copy data formed after a persistent operation is performed on all file and directory contents under the writable layer path, and can record the file system state of the target container at the snapshot time point completely or incrementally. The snapshot metadata is auxiliary information used to describe and index the snapshot data.

[0036] For example, the base image layer identifier can be a string used to uniquely identify the base image layer on which the writable layer depends, for example, it can be a digital digest of a container image, to ensure that the underlying read-only environment consistent with the snapshot time can be accurately located and restored during state recovery.

[0037] For example, the snapshot identifier can be a string used to uniquely identify the snapshot version of the snapshot data generated this time, for example, it can be a globally unique identity generated in the container state management process, to facilitate subsequent retrieval and management of the snapshot data of a specific snapshot version.

[0038] The persistent storage system can refer to a storage system for long-term and reliable storage of data. The persistent storage system can include a plurality of storage units that share storage. As an example, it can be an object storage service, such as Amazon S3. It can also be a distributed file system, such as Ceph. It can also be a network attached storage device. The persistent storage system can enable the snapshot data to exist independently of the local storage of the container runtime, thereby facilitating long-term storage and cross-node migration of the state, and facilitating subsequent state recovery of the target container. In this way, container state management can be deeply integrated with cloud-native container runtime, storage saving and support for automated management, improving the efficiency of container recovery, and improving the flexibility and reliability of container state management.

[0039] In some embodiments, the persistent operation can be an incremental persistent operation.

[0040] In the present embodiment, the persistent operation on the writable layer can include: comparing the current data of the writable layer with the snapshot data of the previous snapshot version of the writable layer to obtain difference data; and storing the difference data as incremental snapshot data and storing the associated snapshot metadata together.

[0041] In some cases, the incremental persistent operation can significantly reduce the amount of data processed, the storage space occupied, and the network bandwidth consumed for each snapshot, thereby improving the efficiency and frequency of snapshot operations and reducing the impact on system performance.

[0042] Specifically, the persistent operation on the writable layer includes the step of: comparing the current data of the writable layer with the snapshot data of the previous snapshot version of the writable layer to obtain difference data.

[0043] In the present embodiment, the current data of the writable layer can refer to the real-time state of the files and directories located in the writable layer path at the time of triggering the present snapshot. The snapshot data of the previous snapshot version can refer to the snapshot data generated by the nearest successful snapshot operation in time order before the current time point and stored in the persistent storage system. The persistent storage system maintains the snapshot identifier corresponding to each snapshot version as the unique index of the version of the snapshot data.

[0044] By way of example, the difference comparison can refer to analyzing the content difference between the current data of the writable layer and the snapshot data of the previous snapshot version by a specific algorithm or tool, and identifying which files have been added, modified or deleted since the previous snapshot version. For example, it can be implemented by calling the rsync tool and cooperating with its difference algorithm, or by traversing the data and comparing the timestamps and checksums of the data. By performing the difference comparison, the difference data can be obtained.

[0045] In the present embodiment, the difference data can be a collection of all the change contents identified in the above comparison process, and its specific form can be the content block of the modified file, the complete content of the new file, and the meta information list of the file to be deleted. In this way, the amount of change can be accurately located, and repeated storage of unchanged base data can be avoided, thereby achieving storage optimization.

[0046] In the present embodiment, the incremental snapshot data can refer to a data set composed of difference data representing the state change between two snapshot versions. Since the incremental snapshot data itself is not a complete, independently usable file system image, it must rely on the snapshot data of the previous snapshot version it references to restore the complete file system state. Therefore, the pointer or reference to the snapshot identifier of the previous snapshot version it depends on in the associated snapshot metadata can be used to logically form a snapshot version chain. The incremental snapshot data and its associated snapshot metadata are stored persistently together, and the two pieces of information are written as a logical unit to the persistent storage system. In this way, a snapshot chain based on version differences can be established in the persistent storage system, and each subsequent snapshot version only stores the incremental changes relative to the previous version, thereby achieving efficient use of storage space at the system level and supporting fast switching and backtracking of container state between different historical version points.

[0047] In some embodiments, to adapt to different operation and maintenance scenarios, the snapshot trigger instruction can be determined based on any of the following: a timing trigger, an event trigger, and a CRD component.

[0048] The timing trigger can be used to monitor whether the target container reaches a preset timing period, the event trigger can be used to monitor whether the size change of the writable layer path of the target container exceeds a preset threshold, and the CRD component can be used to respond to a snapshot request of a user.

[0049] By way of example, the timing trigger can be a scheduling module that periodically runs in the snapshot controller, and the preset timing period can be a preconfigured time interval rule, for example, an expression similar to CronJob can be configured to execute once every 30 minutes or at 2 a.m. every day. The timing trigger continuously checks the system time, and when it determines that the current time meets the condition defined by the preset timing period, it automatically generates and issues a snapshot trigger instruction. In this way, periodic and automated backup of the container state can be achieved without human intervention, and the consistency of the state of the key application at a fixed time point can be retained, which is suitable for scenarios that need to meet data protection service level agreements or perform periodic audits.

[0050] Exemplarily, the event trigger can be a monitoring module for listening to a specific system event and responding. As an example, the specific system event can be a change in the size of the writable layer path of the target container. The event trigger can perceive the data change in real time by periodically querying the disk usage of the writable layer path of the target container, or by listening to the file system. The preset threshold can be a threshold value preset for judging whether the change is significant, for example, it can be set to "100MB of new data has been added to the writable layer since the last snapshot" or "the total size of the writable layer exceeds 1GB", etc. When the event trigger detects that the size of the writable layer path of the target container changes beyond the preset threshold, the snapshot trigger instruction is triggered and generated immediately. In this way, a responsive snapshot strategy based on the amount of state change can be implemented, which can capture the scene in time when the container state changes dramatically, avoid unnecessary snapshot operations during the silent period, and also prevent the problem of too large difference from the previous snapshot version due to too large data write amount, thereby optimizing storage efficiency and capturing the key state change point.

[0051] Exemplarily, the snapshot trigger instruction is generated by the CRD component in response to the snapshot request of the user. The CRD component refers to an API resource object extended by a custom resource definition in the Kubernetes cluster, which allows the user to declare and manage the custom resource through a YAML file, just like managing the native Kubernetes resource. The CRD component is used to respond to the snapshot request of the user. For example, a YAML manifest file describing the expected snapshot operation can be pre-configured, which specifies the necessary information such as the target container identifier, and then submitted to the snapshot controller through a command line tool such as kubectl. The snapshot controller can continuously listen to the creation and update events of all object instances corresponding to the CRD component type. When the user creates such a CRD component instance, it is equivalent to initiating a user snapshot request. The snapshot controller generates and issues the corresponding snapshot trigger instruction according to the event after listening to it. In this way, a direct and declarative API interface can be provided for the user, so that the snapshot operation can be seamlessly integrated into the automated operation and maintenance process of the container state management system, or in response to the user's temporary manual backup needs, the state snapshot can be given high flexibility and deep integration capability with the cloud-native container platform.

[0052] The state recovery method of the cloud-native container provided in the embodiments of the present specification can be applied to the container runtime of the cloud-native container platform. Please refer to Figure 3 The state recovery method can include the following steps.

[0053] Step S310: receiving the container recovery instruction issued by the snapshot controller; wherein the container recovery instruction carries a target snapshot identifier.

[0054] In some cases, to achieve fast recovery of the state of the cloud-native container, the container runtime can listen and obtain a container recovery instruction carrying a target snapshot identifier from the snapshot controller through a predefined communication channel, so as to restore the target container to the corresponding historical state point.

[0055] Step S320: In response to the container recovery instruction, the snapshot execution component is invoked to obtain the target snapshot metadata corresponding to the target snapshot identifier and the target snapshot data associated therewith from the persistent storage system based on the target snapshot identifier; wherein the persistent storage system comprises at least one snapshot data, each snapshot data being associated with corresponding snapshot metadata, the snapshot metadata comprising a snapshot identifier, a writable layer path, and a base image layer identifier, the snapshot identifier being used to uniquely identify the snapshot version of the snapshot data, and the base image layer identifier being used to uniquely identify the base image layer on which the writable layer to which the snapshot data belongs depends.

[0056] Illustratively, the snapshot execution component can be invoked to enable the snapshot execution component to query among a plurality of snapshot identifiers in the persistent storage system based on the target snapshot identifier, and the snapshot execution component can accurately retrieve the target snapshot metadata matching the target snapshot identifier and the target snapshot data associated therewith from the persistent storage system. In this way, the snapshot data and the description information thereof representing a historical state stored in the remote persistent storage system can be pulled to the local, and data preparation is made for subsequent container creation, facilitating subsequent state recovery.

[0057] Step S330: A target container is created based on the target snapshot metadata and the target snapshot data associated therewith, to achieve state recovery of the target container.

[0058] Illustratively, when creating the container, the container runtime can read the base image layer identifier in the target snapshot metadata to locate and use the correct base image layer, and can restore the target snapshot data to the writable layer position of the union file system according to the information in the target snapshot metadata, such as the guidance of the writable layer path. In this way, the step of creating an empty writable layer can be omitted, and the historical state of the persistent storage system is directly loaded as the writable layer of the newly created target container, so that after the target container is started, the file system state thereof is highly consistent with the state at the time when the snapshot is created, fast and accurate state recovery is achieved, and the application can continue to run seamlessly from the specified historical state point, greatly shortening the recovery time of the container state.

[0059] In some embodiments, creating the target container based on the target snapshot metadata and the target snapshot data associated therewith can comprise the following steps.

[0060] Step S410: according to the base image layer identifier in the target snapshot metadata, load the corresponding base image layer as the base image layer of the union file system mounted by the target container, denoted as the target base image layer.

[0061] Specifically, after the snapshot execution component obtains the target snapshot metadata and its associated target snapshot data, it can save them to the node or host where the container runtime is located, and according to the base image layer identifier in the target snapshot metadata, load the corresponding base image layer as the base image layer of the union file system mounted by the target container to be restored or created, denoted as the target base image layer. Illustratively, loading the corresponding base image layer can mean that the container runtime searches for it from its local image storage according to the base image layer identifier, or pulls the read-only image layer corresponding or consistent with it from the remote image repository if it does not exist locally. This read-only image layer is used as the base image layer of the union file system mounted by the target container, that is, when preparing the union file system of the container, the read-only layer can be set as the Lowerdir of the union file system. This specific base image layer that is loaded and used is denoted as the target base image layer to distinguish from other possible image layers. In this way, the underlying read-only environment that the container runtime depends on and is completely consistent with when creating the snapshot can be accurately reconstructed, which is the basis for ensuring consistency of application program dependencies and running environment, and is also the prerequisite for accurate state recovery.

[0062] Step S420: in the target base image layer, according to the storage location indicated by the writable layer path in the target snapshot metadata, restore the target snapshot data to realize state recovery of the target container.

[0063] Specifically, when the container runtime reads the writable layer path in the target snapshot metadata, it can determine the specific storage directory of the Upperdir of the original container on the snapshot node, and thus determine the specific directory location on the current node to which the target snapshot data should be restored, which will become the Upperdir of the union file system of the new container.

[0064] Illustratively, when restoring the target snapshot data, the target snapshot data can be released to the storage location indicated by the writable layer path. If the target snapshot data is incremental data, it can be first merged and reconstructed with the dependent old snapshot data at the specified location, so that the state of the container writable layer at a certain historical time point can be completely and directly covered to the writable layer of the new container, thereby making the state of the union file system of the new container, i.e., the target container, completely consistent with that at the snapshot time when starting, and further enabling efficient and accurate state recovery of the target container, saving the lengthy process of reconstructing the running environment from the base image and then gradually synchronizing the data.

[0065] In some embodiments, before creating the target container based on the target snapshot data and its associated target snapshot metadata, the state recovery method of the cloud-native container can further include: performing a permission repair operation on the target snapshot data to be recovered, so that the file permissions thereof are consistent with the environment requirements of the container runtime.

[0066] Through the permission repair operation, the problem of inconsistent file system permissions that can be caused by data migration or environment differences can be solved. When the target snapshot data is recovered from the persistent storage system, the initial user and group identity thereof on the host file system can not match the permissions expected inside the container runtime.

[0067] The environment requirements of the container runtime can refer to specific constraints and expectations of the container runtime on the file system permissions inside the container when creating and running the container, for example, certain processes inside the container can need to run as a specific non-root user, and the files accessible thereby are required to have corresponding ownership and permissions. By performing the permission repair operation, it can be ensured that each file and directory in the recovered target snapshot data has correct user, group ownership and access permissions that are consistent with the expectations of the application inside the container. Thus, the failure of the container to start or the error of the application running inside the container due to insufficient permissions can be avoided, and the success rate and reliability of the state recovery process are guaranteed.

[0068] The embodiments of the present specification provide a state snapshot device of a cloud-native container. The state snapshot device can be applied to a container runtime of a cloud-native container platform. The state snapshot device can include a snapshot instruction receiving module, a path obtaining module and a snapshot executing module.

[0069] The snapshot instruction receiving module is configured to receive a snapshot trigger instruction issued by a snapshot controller; wherein the snapshot trigger instruction carries a target container identifier, and the target container identifier is configured to uniquely identify a target container; The path obtaining module is configured to obtain a writable layer path of the target container based on the target container identifier in response to the snapshot trigger instruction, wherein the writable layer is an upperdir layer of a base image layer in a union file system; The snapshot executing module is configured to call a snapshot executing component to perform a persistent operation on the writable layer based on the writable layer path of the target container, to generate snapshot data and associated snapshot metadata, and to store the snapshot data and the associated snapshot metadata to a persistent storage system, so as to realize state snapshot of the target container; wherein the snapshot metadata at least includes the writable layer path, a base image layer identifier and a snapshot identifier, the base image layer identifier is configured to uniquely identify a base image layer relied on by the writable layer, and the snapshot identifier is configured to uniquely identify a snapshot version of the snapshot data.

[0070] The embodiment of the present specification provides a state recovery device of a cloud-native container, which is applied to a container runtime of a cloud-native container platform, and the state recovery device comprises a recovery instruction receiving module, a data acquisition module and a container creation module.

[0071] The recovery instruction receiving module is configured to receive a container recovery instruction issued by a snapshot controller; and the container recovery instruction carries a target snapshot identifier. The data acquisition module is configured to, in response to the container recovery instruction, call a snapshot execution component to acquire target snapshot metadata and associated target snapshot data corresponding to the target snapshot identifier from a persistent storage system based on the target snapshot identifier; the persistent storage system comprises at least one snapshot data, each snapshot data is associated with corresponding snapshot metadata, and the snapshot metadata comprises a snapshot identifier, a writable layer path and a base image layer identifier; the snapshot identifier is used to uniquely identify a snapshot version of the snapshot data; and the base image layer identifier is used to uniquely identify a base image layer on which a writable layer to which the snapshot data belongs depends. The container creation module is configured to create a target container based on the target snapshot metadata and the associated target snapshot data, so as to realize state recovery of the target container.

[0072] The specific functions and effects of the state snapshot device or the state recovery device of the cloud-native container can be explained by referring to other embodiments of the present specification, and will not be described here. Each module in the state snapshot device or the state recovery device can be realized by software, hardware and a combination thereof in whole or in part. Each module can be embedded in or independent of a processor in a computer device in a hardware form, or can be stored in a memory in a computer device in a software form, so as to be called and executed by a processor to perform the operations corresponding to each module.

[0073] The embodiment of the present specification further provides a computer readable storage medium having a computer program stored thereon, and the computer program is executed by a computer to implement the state snapshot method or the state recovery method in any of the above embodiments.

[0074] The embodiment of the present specification further provides a computer program product comprising instructions which, when executed by a computer, cause the computer to implement the state snapshot method or the state recovery method in any of the above embodiments.

[0075] The embodiment of the present specification further provides a computer device comprising a memory and a processor, and the memory stores a computer program which, when executed by the processor, implements the state snapshot method or the state recovery method in any of the above embodiments.

[0076] In some embodiments, referring to Figure 4 The computer device can be a terminal, and an internal structure diagram thereof can be as shown inFigure 4 The computer device shown in the figure includes a processor, a memory, a communication interface connected by a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The communication interface of the computer device is used to communicate with external terminals in a wired or wireless manner. The wireless manner can be achieved through WIFI, operator network, NFC (Near Field Communication) or other technologies. The computer program is executed by the processor to implement the state snapshot method or the state recovery method.

[0077] It can be understood that the specific examples herein are only to help those skilled in the art better understand the embodiments of the present specification, and do not limit the scope of the present application.

[0078] It can be understood that in various embodiments of the present specification, the size of the serial number of each process does not mean the order of execution, and the execution order of each process should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present specification.

[0079] It can be understood that the various embodiments described in the present specification can be implemented alone or in combination, and the embodiments of the present specification do not limit this.

[0080] Unless otherwise specified, all technical and scientific terms used in the embodiments of the present specification have the same meanings as those commonly understood by those skilled in the art of the present specification. The terms used in the present specification are only for the purpose of describing the specific embodiments and are not intended to limit the scope of the present specification. The term "and / or" used in the present specification includes any and all combinations of one or more related listed items. The singular forms "a", "an" and "the" used in the embodiments of the present specification and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise.

[0081] It can be understood that the processor of the embodiments of the present specification can be an integrated circuit chip with processing capability. In the implementation process, each step of the method embodiments described above can be completed by integrated logic circuits in hardware or instructions in software form in the processor. The processor described above can be a general processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. Each method, step and logic block disclosed in the embodiments of the present specification can be implemented or executed. The general processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in combination with the embodiments of the present specification can be directly embodied as a hardware code processor for execution, or a combination of hardware and software modules in the code processor for execution. The software module can be located in a random access memory, a flash memory, a read only memory, a programmable read only memory or an electrically erasable programmable memory, a register or other mature storage medium in the art. The storage medium is located in the memory, and the processor reads the information in the memory, and combines the hardware to complete the steps of the above method.

[0082] It can be understood that the memory in the embodiments of the present specification can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read only memory (ROM), a programmable read only memory (PROM), an erasable programmable read only memory (EPROM), an electrically erasable programmable read only memory (EEPROM) or a flash memory. The volatile memory can be a random access memory (RAM). It should be noted that the memory of the system and method described herein is intended to include but not limited to these and any other suitable type of memory.

[0083] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized in electronic hardware or a combination of computer software and electronic hardware. Whether the functions are executed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present specification.

[0084] Those skilled in the art can clearly understand the specific working process of the system, device and unit described above for the convenience and brevity of description, which can refer to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0085] The above is only a specific embodiment of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical range disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method for taking a snapshot of the state of a cloud-native container, characterized in that, A container runtime applied to a cloud-native container platform, wherein the cloud-native container platform further includes a snapshot controller and a snapshot execution component communicatively connected to the container runtime; the method includes: Receive a snapshot trigger command issued by the snapshot controller; wherein the snapshot trigger command carries a target container identifier, which is used to uniquely identify the target container; In response to the snapshot trigger command, the writable layer path of the target container is obtained based on the target container identifier, wherein the writable layer is the upperdir layer of the base image layer in the union file system; Based on the writable layer path of the target container, the snapshot execution component is invoked to perform persistence operations on the writable layer, generating snapshot data and associated snapshot metadata, and storing them in a persistent storage system to realize a state snapshot of the target container; wherein, the snapshot metadata includes at least the writable layer path, the base image layer identifier, and the snapshot identifier, the base image layer identifier is used to uniquely identify the base image layer on which the writable layer depends, and the snapshot identifier is used to uniquely identify the snapshot version of the snapshot data.

2. The method according to claim 1, characterized in that, The persistence operation is an incremental persistence operation; The persistence operation on the writable layer includes: The difference data is obtained by comparing the current data of the writable layer with the snapshot data of the previous snapshot version of the writable layer. The difference data is used as incremental snapshot data and persistently stored together with the associated snapshot metadata.

3. The method according to claim 1 or 2, characterized in that, The snapshot trigger command is determined based on any of the following methods: A timer trigger; wherein the timer trigger is used to monitor whether the target container has reached a preset timer period; Event trigger; wherein, the event trigger is used to monitor whether the change in the writable layer path size of the target container exceeds a preset threshold; The CRD component is used to respond to user snapshot requests.

4. A method for restoring the state of a cloud-native container, characterized in that, A container runtime applied to a cloud-native container platform, wherein the cloud-native container platform further includes a snapshot controller and a snapshot execution component communicatively connected to the container runtime; the method includes: Receive a container recovery command issued by the snapshot controller; wherein the container recovery command carries a target snapshot identifier; In response to the container recovery command, the snapshot execution component is invoked based on the target snapshot identifier to retrieve the target snapshot metadata corresponding to the target snapshot identifier and its associated target snapshot data from the persistent storage system; wherein, the persistent storage system includes at least one snapshot data, each snapshot data is associated with corresponding snapshot metadata, the snapshot metadata includes a snapshot identifier, a writable layer path, and a base image layer identifier, the snapshot identifier is used to uniquely identify the snapshot version of the snapshot data, and the base image layer identifier is used to uniquely identify the base image layer on which the writable layer to which the snapshot data belongs depends; A target container is created based on the target snapshot metadata and its associated target snapshot data to achieve state restoration of the target container.

5. The method according to claim 4, characterized in that, The creation of the target container based on the target snapshot metadata and its associated target snapshot data includes: Based on the base image layer identifier in the target snapshot metadata, the corresponding base image layer is loaded as the base image layer of the union file system mounted by the target container, and is denoted as the target base image layer; In the target base image layer, the target snapshot data is restored according to the storage location indicated by the writable layer path in the target snapshot metadata, thereby realizing the state restoration of the target container.

6. The method according to claim 5, characterized in that, Before creating the target container based on the target snapshot data and its associated target snapshot metadata, the method further includes: Perform a permission restoration operation on the target snapshot data to be restored, so that its file permissions are consistent with the environment requirements of the container runtime environment.

7. A state snapshot device for cloud-native containers, characterized in that, A container runtime applied to a cloud-native container platform, wherein the cloud-native container platform further includes a snapshot controller and a snapshot execution component communicatively connected to the container runtime; the apparatus includes: A snapshot instruction receiving module is used to receive a snapshot trigger instruction issued by the snapshot controller; wherein, the snapshot trigger instruction carries a target container identifier, and the target container identifier is used to uniquely identify the target container; The path acquisition module is used to obtain the writable layer path of the target container based on the target container identifier in response to the snapshot triggering command, wherein the writable layer is the upperdir layer of the base image layer in the union file system; The snapshot execution module is used to call the snapshot execution component to perform persistence operations on the writable layer based on the writable layer path of the target container, generate snapshot data and associated snapshot metadata, and store them in the persistent storage system to realize the state snapshot of the target container; wherein, the snapshot metadata includes at least the writable layer path, the base image layer identifier, and the snapshot identifier, the base image layer identifier is used to uniquely identify the base image layer on which the writable layer depends, and the snapshot identifier is used to uniquely identify the snapshot version of the snapshot data.

8. A state recovery device for cloud-native containers, characterized in that, A container runtime applied to a cloud-native container platform, wherein the cloud-native container platform further includes a snapshot controller and a snapshot execution component communicatively connected to the container runtime; the apparatus includes: A recovery instruction receiving module is used to receive a container recovery instruction issued by the snapshot controller; wherein the container recovery instruction carries a target snapshot identifier; The data acquisition module is used to respond to the container recovery command and, based on the target snapshot identifier, call the snapshot execution component to obtain the target snapshot metadata corresponding to the target snapshot identifier and its associated target snapshot data from the persistent storage system; wherein, the persistent storage system includes at least one snapshot data, each snapshot data is associated with corresponding snapshot metadata, the snapshot metadata includes a snapshot identifier, a writable layer path, and a base image layer identifier, the snapshot identifier is used to uniquely identify the snapshot version of the snapshot data, and the base image layer identifier is used to uniquely identify the base image layer on which the writable layer to which the snapshot data belongs depends; The container creation module is used to create a target container based on the target snapshot metadata and its associated target snapshot data, so as to realize the state restoration of the target container.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 6.

Images