Cross-life-cycle processing method and device for container operation data and electronic equipment

Abstract

The invention provides a cross-life-cycle processing method and device for container operation data and electronic equipment, and relates to the technical fields of containerization, container migration, persistent storage and the like. The method comprises the steps of obtaining a migration or reconstruction instruction for a target container, wherein a target persistent volume serving as a writable layer is mounted on the target container; according to the migration or reconstruction instruction, unloading the target persistent volume to obtain the target persistent volume in a to-be-mounted state; and in response to successful migration of the target container to the target address or completion of reconstruction at the target address, re-mounting the target persistent volume in the to-be-mounted state to a parent directory of a writable layer of the successfully migrated or successfully reconstructed target container. By means of the method, the container can obtain the capacity similar to that of virtual machine type startup and shutdown, the system disk data stored persistently can be reused for a long time, the environment preparation time can be remarkably shortened, and the container can be rapidly recovered to the state before shutdown after being rebuilt or migrated.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to the fields of containerization, container migration, persistent storage, etc., and in particular to a method, apparatus, electronic device, computer-readable storage medium, and computer program product for cross-lifecycle processing of container runtime data. Background Technology

[0002] In cloud computing and containerized environments, users often want to use containers as "development machines," similar to virtual machines that can be turned on and off, and whose contents (such as operating system-level software installations, configuration changes, etc.) and data disks are not lost after a restart.

[0003] However, when containers created or managed through Docker (a containerization platform), Kubernetes (a containerization orchestration system), or other common containerization-related applications have their upperdir data automatically cleared due to restarts, Pod (the smallest unit of deployment in Kubernetes, which can contain multiple containers) rebuilds, or migration to other nodes due to failures, the data on the upperdir will be lost, leading to the loss of the system disk and its data. Summary of the Invention

[0004] This disclosure provides a method, apparatus, electronic device, computer-readable storage medium, and computer program product for cross-lifecycle processing of container runtime data.

[0005] In a first aspect, embodiments of this disclosure propose a method for cross-lifecycle processing of container runtime data, comprising: obtaining migration or reconstruction instructions for a target container; wherein a target persistent volume acting as a writable layer is mounted on the target container; according to the migration or reconstruction instructions, unloading the target persistent volume to obtain a target persistent volume in a state of pending mounting; in response to the target container being successfully migrated to a target address or being reconstructed at the target address, remounting the target persistent volume in the state of pending mounting to the parent directory of the writable layer of the successfully migrated or reconstructed target container.

[0006] Secondly, embodiments of this disclosure propose a cross-lifecycle processing apparatus for container runtime data, comprising: a migration / reconstruction instruction acquisition unit configured to acquire migration or reconstruction instructions for a target container; wherein a target persistent volume serving as a writable layer is mounted on the target container; a persistent volume unmounting processing unit configured to unmount the target persistent volume according to the migration or reconstruction instructions, thereby obtaining a target persistent volume in a pending mounting state; and a remounting unit configured to remount the target persistent volume in the pending mounting state to the parent directory of the writable layer of the successfully migrated or reconstructed target container in response to the successful migration of the target container to the target address or the successful reconstruction of the target container.

[0007] Thirdly, embodiments of this disclosure provide an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement a cross-lifecycle processing method for container runtime data as described in the first aspect.

[0008] Fourthly, embodiments of this disclosure provide a non-transitory computer-readable storage medium storing computer instructions that enable a computer to perform a cross-lifecycle processing method for container runtime data as described in the first aspect.

[0009] Fifthly, embodiments of this disclosure provide a computer program product including a computer program that, when executed by a processor, can implement the steps of the cross-lifecycle processing method for container runtime data as described in the first aspect.

[0010] The cross-lifecycle processing solution for container runtime data provided in this disclosure mounts a persistent volume in a pending mounting state to the parent directory of the container's writable layer before the container has configured its writable layer. This allows the persistent volume to act as the container's writable layer, and all subsequent system disk data written to the writable layer is actually written to the persistent volume. Once the container faces reconstruction or migration, the persistent volume can be unmounted to detach from the container, thus ensuring that the system disk data previously stored in the persistent volume is persistently stored. This gives the container a "virtual machine-like power on / off" capability. The persistently stored system disk data can not only be reused for a long time, but also significantly shorten the environment preparation time, allowing the container to quickly recover to its "pre-shutdown" state after reconstruction or migration.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0012] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is an exemplary system architecture to which this disclosure can be applied; Figure 2 A flowchart illustrating a method for cross-lifecycle processing of container runtime data provided in this disclosure embodiment; Figure 3 A flowchart illustrating a method for creating a target container, as provided in this embodiment of the disclosure; Figure 4 For the embodiments disclosed herein Figure 3 A flowchart of a specific implementation method provided in step 303; Figure 5 A flowchart illustrating a method for determining a target persistent volume based on a persistent volume declaration and its usage scenario, provided as an embodiment of this disclosure; Figure 6 A flowchart illustrating a snapshot generation and management method provided in this disclosure embodiment; Figure 7 A flowchart illustrating a method for handling traffic during migration using alternative containers, provided as an embodiment of this disclosure; Figure 8-1 This is a schematic diagram of a container creation process provided in an embodiment of the present disclosure; Figure 8-2 This is a schematic diagram of a container removal process provided in an embodiment of this disclosure; Figure 9 A structural block diagram of a cross-lifecycle processing device for container runtime data provided in this disclosure embodiment; Figure 10 This is a schematic diagram of the structure of an electronic device suitable for performing cross-lifecycle processing methods for container runtime data, provided in an embodiment of this disclosure. Detailed Implementation

[0013] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding; these should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0014] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0015] Figure 1 An exemplary system architecture 100 is shown, illustrating embodiments of methods, apparatuses, electronic devices, and computer-readable storage media for processing container runtime data across the lifecycle of this disclosure.

[0016] like Figure 1 As shown, the system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server cluster 105. The network 104 serves as the medium for providing communication links between the terminal devices 101, 102, and 103 and the server cluster 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. The server cluster 105 runs a multi-node containerized management platform, on which arbitrarily distributed containers 1051, 1052, and 1053 run.

[0017] Users can use terminal devices 101, 102, and 103 to interact with the server cluster 105 via network 104 to send commands for managing containers 1051, 1052, and 1053 and receive returned messages. Various applications can be installed on the terminal devices 101, 102, and 103 and the server cluster 105 to enable communication between them, such as container management applications, container orchestration applications, and instant messaging applications.

[0018] Terminal devices 101, 102, and 103 and server cluster 105 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices, and can be implemented as multiple software programs or software modules, or as a single software program or software module; no specific limitation is made here. When server cluster 105 is hardware, it can be implemented as a distributed server cluster composed of multiple servers, or as a single server. When the server is software, it can be implemented as multiple software programs or software modules, or as a single software program or software module; no specific limitation is made here.

[0019] Server cluster 105 can provide various services through its built-in applications. Taking a container management application that provides writable persistent layer services for containers during rebuilding or migration as an example, server cluster 105 can achieve the following effects when running this container management application: First, it receives migration instructions (here, migration instructions are used as an example, but it could also be a rebuild instruction) for container 1051 from terminal devices 101, 102, and 103 via network 104. At this time, container 1051 has a target persistent volume mounted as the writable layer. Next, according to the migration instructions, the target persistent volume is unmounted, resulting in a target persistent volume in a state of waiting to be mounted. In the next step, after container 1051 is successfully migrated to the target address, the target persistent volume in the state of waiting to be mounted is remounted to the parent directory of the writable layer of the successfully migrated or rebuilt target container.

[0020] It should be noted that, in addition to being obtained from terminal devices 101, 102, and 103 via network 104, rebuild or migration instructions can also be generated automatically by container management applications running on server cluster 105 by sensing the real-time status of each container maintained thereon according to preset rules. In this case, the exemplary system architecture 100 may not include terminal devices 101, 102, and 103 and network 104.

[0021] The container runtime data cross-lifecycle processing method provided in the subsequent embodiments of this disclosure is generally executed by a server cluster 105 with strong computing power and abundant computing resources. Correspondingly, the container runtime data cross-lifecycle processing device is also generally set in the server cluster 105. However, it should also be noted that when terminal devices 101, 102, and 103 also have sufficient computing power and resources, terminal devices 101, 102, and 103 can also complete the various calculations that were previously delegated to the server cluster 105 through the container management application installed on them, and thus output the same results as the server cluster 105. Especially when there are multiple terminal devices with different computing capabilities, but the container management application determines that the terminal device has strong computing power and abundant remaining computing resources, it can let the terminal device perform the above calculations, thereby appropriately reducing the computing pressure on the server cluster 105. Correspondingly, the container runtime data cross-lifecycle processing device can also be set in the terminal devices 101, 102, and 103. In this case, the exemplary system architecture 100 may also not include the server cluster 105 and the network 104.

[0022] It should be understood that Figure 1 The number of terminal devices, networks, servers, and containers included in the server cluster is merely illustrative. Depending on implementation needs, there can be any number of terminal devices, networks, servers, and containers.

[0023] Please refer to Figure 2 , Figure 2 A flowchart of a method for cross-lifecycle processing of container runtime data provided in this disclosure embodiment is included, wherein process 200 includes the following steps: Step 201: Obtain the migration or rebuild instructions for the target container; This step aims to address the execution of cross-lifecycle data processing methods by the container's runtime (e.g., Figure 1 The server cluster 105 shown obtains migration or rebuild instructions for the target container (e.g., from...). Figure 1 The terminal device 101 shown is used by the user.

[0024] The "target container" described in this step is not an ordinary container; it's a special case. Its special characteristic lies in the fact that its "writable layer" is not the temporary storage allocated by default when the container is created, but rather is played by an external "target persistent volume" with an independent lifecycle. In practice, this "target persistent volume" typically refers to a piece of network storage, such as a cloud disk, requested through Kubernetes' persistent volume declaration mechanism. This cloud disk can be associated with the location originally belonging to the writable layer in the container's root file system (Rootfs) structure at the beginning of container creation through an operation called "bind-mount." This means that any system-level modifications made by the user inside the container, such as installing software to the / usr directory via apt-get or modifying system configuration files, will not be written to the container's own temporary storage, but will be directly written to this remote cloud disk.

[0025] The entity that obtains the migration or rebuild instructions mentioned in this step can be the cluster's control plane component, such as the Kubernetes controller manager. It typically monitors the cluster's status continuously and generates rebuild or migration instructions when it detects events such as insufficient node resources, node maintenance requirements, or user-triggered rolling updates. Migration usually refers to moving a container from one physical or virtual node to another, often to address node failures or achieve load balancing. Rebuilding can occur when a Pod's template definition changes, terminating the old Pod and creating a new Pod instance on a node conforming to the new definition. In either case, the core objective is to start a container in the new location, ensuring it inherits the entire state of the original container, which naturally includes all changes to the system disk.

[0026] Furthermore, a pre-check mechanism can be established to proactively verify whether the target persistent volume, which serves as the writable layer, is currently in a healthy and available state before performing a migration or rebuild. Even further, the most suitable persistent volume can be intelligently selected based on the specific reason for the migration and the characteristics of the target node. For example, in a planned data archiving migration, a lower-cost but slightly slower storage type might be chosen; conversely, in an emergency migration due to node failure, a snapshot or cloned volume in the same region and availability zone as the source node would be prioritized to ensure the lowest network latency and the fastest recovery speed. This ensures that in a dynamic and complex production environment, the container state can reliably follow instructions for transfer.

[0027] The solution provided in this embodiment of the instruction manual is aimed at a special container (i.e., the target container) that has hosted the system disk data on an external persistent storage, and is based on the ability to sensitively capture scheduling instructions that require the container to change its running location.

[0028] Step 202: According to the migration or rebuild instructions, unload the target persistent volume to obtain the target persistent volume in the state of waiting to be mounted; Building upon step 201, this step aims to have the aforementioned executing entity unload the target persistent volume according to migration or rebuild instructions, resulting in a target persistent volume in a state awaiting mounting. Its core objective is to remove the persistent volume, which carries all system disk change data of the container, from the soon-to-be-terminated container instance in a controllable and lossless manner.

[0029] The "unmounting process" described in this step technically refers to executing the `umount` system call or command. Logically, this is similar to safely ejecting a USB drive. Its purpose is to sever the association between the file system and the container's runtime directory, ensuring all written data is synchronized to the storage medium and preparing for the next mount. It's important to note that the "unmounting" object here refers to the persistent volume mounted via "bind mount," not the complex Rootfs structure within the container composed of OverlayFS (a union file system that allows multiple directories—read-only and writable layers—to be overlaid into a unified view, forming the basis of the container's root file system). Therefore, after unmounting this underlying persistent volume, the OverlayFS directories built by the container runtime (such as Upperdir, Workdir, and Merged) will naturally become invalid due to the loss of their underlying support. However, this does not affect the integrity of the persistent volume's own data.

[0030] In practical terms, this operation is typically performed by a custom component within the container runtime that listens for container deletion events from the orchestration system (such as Kubernetes). It is triggered as a "hook" after the container stops but before the container runtime's default cleanup logic (which usually deletes writable layers) is executed. This process should be atomic, ensuring that no other process is simultaneously reading or writing to the persistent volume during unmounting to prevent data corruption. Crucially, after unmounting, the persistent volume itself and all its internal data are intact and preserved, entering a ready-to-mount state. At this point, the volume functions like an "external hard drive" containing the complete system state, and can be safely transported or used in a new location.

[0031] Furthermore, a pre-uninstallation synchronization mechanism can be introduced. This involves forcibly flushing all data not yet written to disk from the operating system cache to the persistent volume before issuing the uninstallation command. A soft uninstallation strategy can also be designed: if the first uninstallation operation fails for some reason, the system will not immediately give up but will attempt to log, issue alerts, and may retry after a certain delay. Additionally, a snapshot can be created immediately after successful uninstallation. This snapshot serves as a high-value copy of the data, allowing for rapid rollback to the current state should unexpected events occur during subsequent migration or mounting. This provides additional security for the entire process.

[0032] This step essentially follows a principle of separation without destruction. Instead of simply deleting temporary data, it decouples the persistent storage volume that records all state changes at the end of the container's lifecycle, making it an independent and portable data carrier. This ensures that the "soul" of the container can be completely preserved and subsequently injected into a new body.

[0033] Step 203: In response to the successful migration of the target container to the target address or the completion of reconstruction at the target address, remount the target persistent volume that is in the pending mount state to the parent directory of the writable layer of the successfully migrated or reconstructed target container.

[0034] Building upon step 202, this step aims to have the aforementioned execution entity remount the target persistent volume, which is in a pending mounting state, to the parent directory of the writable layer of the successfully migrated or rebuilt target container once the target container has been successfully migrated to the target address (which can also be understood as the location of the target node) or rebuilt at the target address.

[0035] In this step, the target persistent volume in the pending mount state refers to the external storage volume that already contains all the previous system disk data of the container. It has been detached from the old container instance and is waiting to be mounted to the new container to act as a write layer again. The target address is the node that the container orchestration system has newly scheduled for the new container instance. Successful migration or reconstruction means that the new container instance has completed the most basic creation on it and is at the critical point of waiting to mount its dedicated file system.

[0036] At the technical level, this step essentially replicates the ingenious mount point entry point from the initial creation during the new container startup process. Specifically, when the container is running on a new node and preparing to build its rootfs, it follows the same logic: after creating the writable parent directory for the OverlayFS layer, it pauses the default mount process. At this point, it recognizes that the container needs an existing persistent volume to restore its state, and thus accurately places this "to be mounted" volume at the reserved parent directory location through a binding mount. When the container actually starts subsequently, its file system state reverts to the moment of the last "shutdown," ensuring that all installed software and modified configurations are fully preserved.

[0037] In practical terms, the entire process can be coordinated by a cluster-wide controller: when an event is detected that a new container instance has been successfully created on a new node, a critical verification step is triggered, which is to check whether the digest of the container image currently being used is consistent with the image digest recorded when the persistent volume was created. This is to prevent system environment chaos or software incompatibility caused by different base images. Only after the verification is passed will the actual mount command be executed to associate the remote storage volume with the local directory of the new container.

[0038] Furthermore, to ensure success, a quick confirmation of the mount status can be performed after successful mounting. For example, check whether the target directory has been successfully converted to a persistent volume file system type and report a "status recovery successful" signal to the management system, thereby completing the entire migration or rebuild lifecycle.

[0039] The cross-lifecycle processing method for container runtime data provided in this disclosure mounts a persistent volume in a pending mounting state to the parent directory of the container's writable layer before the container has configured its writable layer. This allows the persistent volume to act as the container's writable layer, and all subsequent system disk data written to the writable layer is actually written to the persistent volume. Once the container faces reconstruction or migration, the persistent volume can be unmounted to detach from the container, thus ensuring that the system disk data previously stored in the persistent volume is persistently stored. This gives the container a "virtual machine-like power on / off" capability. The persistently stored system disk data can not only be reused for a long time, but also significantly shorten the environment preparation time, allowing the container to quickly recover to its "pre-shutdown" state after reconstruction or migration.

[0040] The above embodiments mainly describe how the target container maintains the persistence of the writable layer when facing reconstruction or migration operations. To deepen the understanding of this target container, please refer to [the relevant documentation / reference]. Figure 3 , Figure 3 A flowchart of a method for creating a target container in a usable state, provided for embodiments of this disclosure, includes the following steps in process 300: Step 301: When creating a container in a containerized orchestration system, declare a persistent volume in the creation configuration by using annotations or by pointing the mount volume configuration item to a preset path; This step aims to enable persistent volume declarations in the containerization configuration by the aforementioned execution entity when creating containers in a containerized orchestration system, either through annotations or by setting the mount volume configuration item to a preset path. In other words, when creating containers in a containerized orchestration system (such as Kubernetes), users need to indicate in the Pod's configuration file that they wish to enable Rootfs persistence in a specific way.

[0041] One approach is to use annotations, which are metadata appended to the configuration as key-value pairs to pass additional instructions to the system, such as setting io.kubernetes.cri.rootfs-persistence:"true"; another approach is to use the VolumeMounts configuration item, but point its mountPath to a pre-defined special path, such as " / .rootfs". This path itself is usually not visible inside the container, and its core function is to signal to the underlying container runtime that a special, persistent, writable layer should be prepared for this container.

[0042] As a more scalable and declarative advanced alternative, when the orchestration system is Kubernetes, a new type of API object called PersistentRootfs can be defined using Custom Resource Definition (CRD) technology. This allows for the use of custom resource technology to declare persistent volumes for the containers created, thereby further standardizing the declaration and management.

[0043] Step 302: Based on the persistent volume declaration, determine the target persistent volume that is in the state of waiting to be mounted; Building upon step 301, this step aims to determine the target persistent volume in the pending mount state based on the persistent volume declaration. This is a process of transforming an abstract persistent volume declaration into a concrete storage entity.

[0044] The technical principle behind the solution provided in this step can be simply understood as follows: the container orchestration system interacts with its storage subsystem, which finds or creates a persistent storage volume that meets the requirements based on the declared content and ensures that it is in a ready state, that is, a "waiting to be mounted" state. This means that the storage volume has been formatted and mounted to a temporary path on the host machine, but its internal data is empty and it is waiting to be assigned a new mission.

[0045] In practical terms, this can be accomplished through Kubernetes' CSI (Container Storage Interface) driver, for example, by allocating a cloud disk of a specified size and performance and attaching it to the current host node.

[0046] Step 303: Mount the target persistent volume, which is in the pending mounting state, to the parent directory of the writable layer of the container that has completed the read-only layer data configuration using the creation configuration, and obtain the target container.

[0047] Building upon step 302, this step aims to have the aforementioned execution entity mount the target persistent volume, which is in a pending mounting state, to the parent directory of the writable layer of the container that has completed the read-only layer data configuration using the creation configuration. In other words, the configuration of the read-only layer data needs to be completed before the writable layer can be mounted.

[0048] At the technical level, before mounting OverlayFS to the container at runtime, a binding and mounting operation directly associates the prepared persistent cloud disk with the writable layer parent directory created for this container. This way, all subsequent system-level changes that would otherwise fall into the temporary writable layer will be transparently redirected to this persistent cloud disk. From a practical perspective, this step can be implemented by a plugin integrating Containerd (a tool for managing containers), which is invisible to the upper-level orchestration system. Finally, the target container is obtained in a "usable state."

[0049] Furthermore, intelligent recommendation logic can be introduced when declaring persistent volumes, automatically suggesting or selecting the most suitable storage volume type and capacity based on factors such as the size of the container image and the expected scale of software installation. Even further, recently used or critical system files and directories can be loaded first during container startup, while other less urgent data is loaded asynchronously in the background, significantly optimizing container startup speed and improving user experience.

[0050] This embodiment provides a specific implementation scheme for constructing a usable, writable, persistent target container through the solutions provided in steps 301-303. It covers the entire process from declaring the persistence intention to finally constructing a usable container with a persistent writable layer, ensuring that the existence state of the writable layer data is independent of the existence state of the container.

[0051] To further deepen your understanding of the specific implementation process of step 303, please refer to [link / reference needed]. Figure 4 , Figure 4 A specific implementation method is given, and its process 400 includes the following steps: Step 401: Based on the read-only layer configuration item in the creation configuration, call the corresponding preset container image to complete the configuration of read-only layer data for the initialization container, and obtain the first intermediate state container; In Kubernetes, the read-only configuration item primarily refers to the `image` field in the Pod configuration. From a technical perspective: when a container receives an instruction, it downloads the image from the specified image repository and unfolds all its layered file systems on the host machine. At this first intermediate state, the container can be understood as an empty shell machine that already has an identity and blueprint, but hasn't yet installed an operating system or software. At this point, the file data that forms the foundation of the container is in place, but it is completely static and immutable.

[0052] Step 402: Mount the target persistent volume in the pending mount state to the parent directory of the writable layer of the intermediate state container according to the persistent volume declaration, and obtain the second intermediate state container. Building upon step 401, this step is the core of enabling system disk persistence. In practice, the container runtime will recognize the existence of a special persistent volume declaration in the Pod configuration and then perform a crucial binding and mounting operation. This operation directly associates the prepared physical storage (such as a cloud disk) called the target persistent volume with the writable parent directory reserved for this container.

[0053] In simple terms: before installing the internal hard drive (a traditional temporary writable layer) into this empty shell machine, an external hard drive is first connected to the reserved hard drive interface on the motherboard. From then on, all write operations to the system disk are physically directed to this independent, persistent storage device. This creates a crucial second intermediate state container, essentially implanting a "heart" capable of permanently recording everything within the previous "skeleton."

[0054] Step 403: Complete other file system mounting operations on the second intermediate state container according to the file system configuration items in the creation configuration to obtain the target container.

[0055] Building upon step 402, this step aims to have the aforementioned execution entity perform other file system mounting operations on the second intermediate state container based on the file system configuration items in the creation configuration, ultimately resulting in the target container. These other mounting operations may include mounting other types of storage volumes to paths such as / data within the container to store business data. Only when all these mountings are successfully completed can the container be truly started and begin providing services.

[0056] This embodiment describes, through steps 401-403, the process of combining a static container image with an empty persistent volume into a live container that is immediately usable and stateful.

[0057] Step 302 describes how, in addition to determining the target persistent volume based on the persistent volume declaration, the use case of the created container can also be considered to determine a target persistent volume that better matches the actual application. For details, please refer to [link to relevant documentation]. Figure 5 , Figure 5 A flowchart of a method for determining a target persistent volume based on a persistent volume declaration and its use case, provided for embodiments of this disclosure, is provided. The process 500 includes the following steps; Step 501: Based on the persistent volume declaration, filter out the persistent volumes that are in the state of being ready to be mounted from all the candidate persistent volumes; The alternative persistent volume refers to a pool of persistent storage resources that conforms to general specifications and is available for use in the current cluster. Technically, the container orchestration system queries its storage subsystem to filter out "free" volumes that have been successfully created and attached to the current node but have not yet been allocated to a specific application. In practice, this may be achieved through Kubernetes' StorageClass (a core component in Kubernetes used to implement dynamic storage provisioning) and the dynamic provisioning mechanism, which can initially identify a batch of candidates based on declared basic requirements (such as access mode and capacity).

[0058] Step 502: Determine the target type of the storage volume based on the use case of the created container; The types of storage volumes can include block storage, streaming storage, file storage, or object storage. This use case is a prediction of the workload that the container will handle. For example, an IDE (Integrated Development Environment) workbench used for interactive development is characterized by a large number of fragmented small file reads and writes; while a task used for AI model training requires stable and efficient sequential read and write capabilities for large files.

[0059] Block storage offers low latency and high throughput, making it suitable as the root file system of an operating system. File storage, as a mature file system, is better suited for sharing data among multiple containers, but if used as a private system disk for a single container, it may introduce unnecessary protocol overhead. Object storage excels at storing massive amounts of unstructured data, but its high latency makes it completely unsuitable as a root file system that requires frequent random reads and writes. Streaming storage is designed for continuous streaming data, which is inconsistent with the random access mode of the system disk, and is suitable for matching use cases.

[0060] Step 503: Among all persistent volumes in the pending mount state, identify the persistent volume of type target as the target persistent volume in the pending mount state.

[0061] This step is essentially an intersection operation: combining the "set of available volumes" obtained in the first step with the "target type" determined in the second step to filter out the storage volumes that both meet the conditions and are most suitable for the current task.

[0062] In practice, this can be achieved by defining a more granular strategy in the Pod annotation, such as io.example / storage-scenario: "ai-training", which is then interpreted and executed by an admission controller or a dedicated scheduler plugin.

[0063] Furthermore, in addition to determining the storage type, it can also recommend specific performance levels based on the scenario. For a development machine in the debugging phase, a general-purpose solid-state cloud disk may be sufficient; however, for an online inference service about to be deployed to production, it may be necessary to automatically bind a high-performance NVMe (Non-Volatile Memory Express) solid-state cloud disk to ensure service response speed.

[0064] Furthermore, it can monitor the space utilization of persistent volumes and work in conjunction with horizontal Pod autoscalers to automatically initiate expansion when capacity is about to run out, or gracefully migrate containers to a larger empty volume when expansion fails, thereby ensuring business continuity.

[0065] The core idea of ​​steps 501-503 provided in this embodiment is to determine the expected use case of the container by introducing context-aware capabilities, under the premise of satisfying the basic declaration, so as to automatically match the most suitable storage backend for different container tasks, thereby achieving the best balance between performance, cost and functionality.

[0066] Based on any of the above embodiments, in order to enhance the resilience and anomaly resistance of the data stored in the target persistent volume, a snapshot mechanism for the target persistent volume can be further introduced, as detailed in [reference needed]. Figure 6 , Figure 6 A flowchart of a snapshot generation and management method provided in this disclosure embodiment is included in process 600, which includes the following steps: Step 601: For the writable layer on the target container, which is served by the mounted target persistent volume, generate a writable layer snapshot according to the preset writable layer snapshot triggering rules; The snapshot triggering rules for the writable layer include at least one of the following: whether the amount of new data added to the writable layer reaches a first preset data amount, whether the cumulative amount of data in the writable layer reaches a second preset data amount, whether the writable layer adds preset sensitive information, whether the amount of information of the cumulative sensitive information stored in the writable layer reaches a third preset data amount, whether the time interval since the last snapshot generation meets a preset time interval, and the remaining lifetime of the target persistent volume.

[0067] The snapshot described in this step refers to a read-only copy of the persistent volume that acts as the writable layer of the container at a specific point in time. The triggering rule describes the conditions under which a snapshot of the current system disk state needs to be saved, and can be automatically triggered based on multiple dimensions. For example, it can monitor whether the amount of data newly written to the writable layer since the last snapshot has reached a threshold (first preset data amount) to avoid losing too much data during periods of frequent writes; it can also monitor whether the total volume of the writable layer is approaching a preset safety limit (second preset data amount) to prevent potential problems; from a security and compliance perspective, the rule can also be set to immediately create a snapshot for isolation and preservation once preset sensitive information (such as key files) is detected to be stored; in addition, time-based periodic backups (such as every 24 hours) can also be one of the rules; the rule can also be expressed as the remaining lifespan of the target persistent volume, that is, before the disk lifespan decays to the warning line, a last complete snapshot can be forcibly generated and the container can be switched to a new volume, thereby achieving hardware-level fault prevention.

[0068] Step 602: Store the generated writable layer snapshot in the snapshot storage area of ​​the target persistent volume or in a preset writable layer snapshot storage volume; This step aims to store the generated writable layer snapshot in a specified location, such as a snapshot storage area in the target persistent volume or another specified writable layer snapshot storage volume.

[0069] At the technical implementation level, this step can rely on the native snapshot API provided by the underlying storage system (such as the block storage service of cloud vendors). In practice, for the backup of a single container, the snapshot can be stored in place in an isolated partition of the original persistent volume. For scenarios that focus more on management and isolation, all snapshots can be stored in a dedicated, independent "writable layer snapshot storage volume". This approach is more conducive to unified management and lifecycle control across volumes.

[0070] Step 603: Form a snapshot management chain from the generated multiple writable layer snapshots in chronological order; This step aims to chain these snapshots together in chronological order of their creation, forming this snapshot management chain. This chain clearly demonstrates the complete history of the container system disk's evolution over time.

[0071] Step 604: Clean up useless snapshots in the snapshot management chain according to the preset snapshot management rules.

[0072] Based on step 603, this step aims to clean up useless snapshots in the snapshot management chain according to preset snapshot management rules, so as to effectively reclaim space as the number of snapshots continues to accumulate.

[0073] Which snapshots are useless can be determined using a set of strategies, such as a classic rotation strategy that keeps only the most recent 7 daily snapshots, the most recent 4 weekly snapshots, and the most recent 12 monthly snapshots, while the rest can be safely deleted; it can also be defined as "deleting all snapshots older than 30 days, except for the first snapshot of each month".

[0074] In practice, this can be done by a separate daemon or Kubernetes Operator, which periodically scans the snapshot chain and performs cleanup tasks according to rules, while ensuring that the latest recovery point in the chain is never deleted.

[0075] Furthermore, we can explore introducing instant rollback capabilities. This means that when users discover recent system changes have caused environmental instability, they can restore the system disk state to any historical snapshot point in this chain with a single click. This provides significant safety margins for experimental software installations or configuration changes. Even further, we can try enabling the system to learn container activity patterns and automatically perform faster deep backups during periods of low business activity. We could even explore implementing snapshot merging functionality, merging multiple incremental snapshots into a single new base snapshot to further reduce the time required for future rollback operations.

[0076] This embodiment, while achieving basic persistence, is designed to further enhance data security, recoverability, and storage efficiency. It provides the container's "system disk" with an advanced backup and restore mechanism similar to that of a modern virtual machine. The introduction of a snapshot management chain upgrades simple data persistence to state traceability and recoverability, not only solving the problem of data loss but also further addressing issues such as data errors, environmental contamination, or configuration degradation. Through automated, policy-driven lifecycle management, it provides robust data protection while maintaining the efficiency and cleanliness of the storage system. Ultimately, this allows containers to maintain not only spatial continuity but also temporal reversibility, significantly enhancing their reliability in production environments.

[0077] The above embodiments mainly describe the unloading operations during container construction, migration / reconstruction, etc. However, ensuring uninterrupted service during the complex process of container migration is a critical challenge, especially during the period after the migration command is issued but before the new container is fully ready. If traffic sent to the original container address is not properly handled, it can lead to request failures, affecting user experience and even the correctness of business logic. To solve this problem, two complementary traffic management strategies can be adopted: Firstly, during the migration of the target container, traffic sent to the original address of the target container is temporarily stored, and the temporarily stored traffic is sent to the target container after successful migration according to the storage time sequence.

[0078] The core idea of ​​this strategy is temporary storage and replay. When a migration instruction for the target container is received, a traffic buffer is immediately activated. All subsequent network requests destined for the container's original address are not simply dropped, but are temporarily intercepted and stored in this buffer in an orderly manner. Technically, this is typically implemented at the network gateway or service mesh layer. By marking the original service endpoint, all arriving requests are serialized and temporarily stored instead of being processed immediately. Once the system confirms that the target container has successfully started on the new node and restored its persistent writable state, this buffer forwards the requests to the new container instance one by one in strict order of arrival. In practice, this can be accomplished using message queues or specific traffic broker services, ensuring that no requests are lost during the black-box phase of the migration. After the migration is complete, the stored traffic, like a tape played back, is delivered intact to its destination, thus guaranteeing data integrity and transaction continuity.

[0079] Secondly, you can refer to Figure 7 , Figure 7 A flowchart of a method for handling traffic during migration using an alternative container, provided as an embodiment of this disclosure, is provided. The process 700 includes the following steps: Step 701: In response to receiving migration instructions for the target container, determine an alternative container that has the same functionality as the target container; Step 702: Redirect traffic destined for the original address of the target container to the address of the alternative container until the target container is successfully migrated to the new address; Step 703: Extract the traffic processing results of the target container that is in the process of migration from the alternative container; Step 704: Send the traffic processing results to the target container at the new address.

[0080] The second strategy, consisting of steps 701-704, is more proactive and intelligent than the first strategy. Its process can be summarized as "traffic acquisition, processing, and convergence." Specifically, when the migration begins, the control system quickly finds or launches a "replacement container" with the same service functions as the target container. This replacement container is like a temporarily set-up shop of the same type; it may not have all the personalized system states of the original container, but it can provide core business function responses.

[0081] The specific steps are as follows: First, all traffic originally destined for the target container is redirected to this alternative container through a momentary adjustment of routing rules. During this period, the alternative container assumes the responsibility of processing all traffic. However, since it may not have a complete historical state, the processing results it generates may differ from the final state. Therefore, these results are recorded but not immediately returned. Instead, they are sent to the target container only after the new address is fully ready, allowing it an opportunity to perform necessary state synchronization or correction. Essentially, this approach uses a lightweight, stateless surrogate to maintain the illusion of service online.

[0082] The two strategies mentioned above can be used independently or combined to build a more robust protection system.

[0083] Building upon the above solutions, a traffic coloring mechanism can be introduced. This involves creating a brief offloading window at the start of the migration and marking specific batches of requests that arrive afterward. Regardless of the strategy employed, these colored requests and their results can ultimately be handled by the new container, achieving a smooth transition. Furthermore, based on the estimated migration duration and current traffic pressure, the system can intelligently decide whether to enable the more costly temporary replay solution, initiate a faster alternative container solution, or combine both. In the initial stages of migration, an alternative container can maintain low-latency response while silently performing final state synchronization in the background, thus balancing immediate response with ultimate consistency.

[0084] This embodiment better matches the actual situation by implementing fine-grained traffic management during container migration. Whether it's temporary storage and replay or using alternative containers, the fundamental purpose is to mask changes in the underlying infrastructure and provide a seamless service experience for upstream callers. This not only improves system availability and resilience but also allows Rootfs persistence technology to maximize its value in real-world business scenarios, making container migration virtually imperceptible to users.

[0085] Based on any of the above embodiments, in order to ensure the stability and efficiency of the container's long-term operation after the container's rootfs persistence is implemented, the performance indicators of the target persistent volume can be determined, and a visualization window for displaying the performance indicators can be provided for the target persistent volume, and performance adjustment instructions passed from the visualization window can be received and executed.

[0086] This performance metric can be a set of data used to quantify the operating status of storage devices, and can come from two levels: first, statistical information exposed by the storage hardware itself through the operating system (such as Linux), such as read / write operations per second, throughput, and average response latency; second, for managed storage such as cloud disks, its performance metrics are usually provided by cloud service providers through their monitoring services, which may include whether the pre-configured IOPS (Input / Output Operations Per Second) has reached its limit, or whether throughput has encountered a bottleneck. Specifically, common performance metrics include IOPS, which measures the agility of the storage device when processing a large number of small, scattered files; throughput, which reflects the bandwidth capacity when continuously transferring large files; and latency, which is the time required for each read / write request to be sent and receive a response, and is crucial for system smoothness. In addition, the percentage of storage capacity used and the I / O queue length are also important indicators for judging whether the storage is overloaded.

[0087] Once these metrics are defined, this visualization window can be more than just a simple data display interface; it can integrate analysis and alerting functions on top of metric monitoring. In practice, this can be a Grafana dashboard, integrating with monitoring systems like Prometheus to capture and display data in real time. Furthermore, this window can be interactive, allowing users to submit performance tuning commands directly from the visualization. For example, a user might see that the current cloud disk's IOPS utilization consistently exceeds 90%, prompting the system to issue a warning. The user can then issue a performance tuning command, such as upgrading the cloud disk's performance level from normal to high performance.

[0088] Building on this, we can also try to implement prediction-based automatic scaling. This means continuously analyzing historical trends in performance metrics and learning from the activity patterns of processes within the container. For example, if it is predicted that an upcoming AI training task will start at 2 PM and generate significant storage I / O pressure, it can automatically increase the performance specification of the persistent volume by one level in advance, and then automatically reduce it back down after the peak business period to save costs. From another perspective, we can try to trace performance bottlenecks. When the rootfs of a container becomes slow, it should not only report high storage latency, but should also be further analyzed to point out that this is due to a specific container frequently performing a large number of small file compilation operations, thus providing a precise direction for optimization.

[0089] This embodiment attempts to further empower the persistent rootfs of containers, transforming the system disk from a static, passive storage device into an observable, interactive, and optimizable intelligent entity. By tightly integrating real-time monitoring with dynamic control, it not only ensures the continuity of container state after migration or reconstruction but also guarantees the continuity and optimizability of its performance. This enables administrators or users to proactively manage storage resources, fine-tuning them according to actual workloads to achieve the optimal balance between cost and performance while ensuring smooth business operations.

[0090] To enhance understanding, this disclosure also provides a specific implementation scheme for enabling containers to achieve a "virtual machine power-on / off" effect, using a concrete application scenario as an example: The core idea of ​​this implementation scheme is as follows: After Containerd creates a writable rootfs layer directory for the container and before executing OverlayFS mounting, the volume from the Kubernetes PVC (PersistentVolumeClaim) / PV (PersistentVolume) (e.g., cloud disk) is bound-mounted to the parent directory of the writable layer, so that the subsequently generated Upperdir, Workdir, and Merged all fall within this persistent volume; when the container is deleted, it is only unloaded according to custom semantics without being cleared, thereby realizing the persistence and reuse of the rootfs.

[0091] To achieve this core idea, the following key paths can be referenced in the practical process: 1. Orchestration Layer (Kubernetes): Mounting is declared via the Pod annotation or the convention `volumeMounts.mountPath=" / .rootfs"`, instructing the container to enable rootfs persistence and bind to the specified PVC.

[0092] 2. The container runtime layer (Containerd / CRI, Container Runtime Interface) is further divided into the creation process and the deletion process.

[0093] The creation process follows the following sequence: 1) Pull the image → The node has a read-only layer locally; 2) Create an OverlayFS writable layer parent directory for the container (not yet mounted); 3) Parse the annotations, obtain the mount point of the Pod Volume on the host machine, and execute `mount -B`. <pod-volume-path> <upper-parent>Bind the persistent volume to the container's writable parent directory; 4) Continue the normal OverlayFS preparation process. After creating Upperdir, Workdir, and Merged, all writes will be performed on the persistent volume. The deletion process, after the SnapShotter / Remove hook reads the tag, first unmounts (unmounts) instead of deleting the writable layer content to avoid persistent data being cleaned up by the Runtime. If necessary, persistent metadata (such as image digest) is used for consistency verification and subsequent reuse.

[0094] 3. Storage and Data Layer: Cloud disks / distributed block storage are exposed as PVCs / PVs via CSI, with independent lifecycles and quotas; multiple container Pods can each declare their own Rootfs volume.

[0095] The key features expected to be achieved include: 1) Image consistency verification: Record and verify Image Digest to ensure that the image is consistent when reusing the old Rootfs; if inconsistent, you can choose to refuse mounting or trigger migration. 2) Stable path structure: A stable rootfs path structure is generated based on Namespace / Pod / Container to ensure locatability after reconstruction / drift; 3) Multi-container support: Each container can independently choose whether to enable Rootfs persistence (without affecting each other). A specific example can be shown as follows: Single-container Pod: Specify " / .rootfs" in the container's volumeMounts and use the corresponding PVC as the rootfs persistent device; For multi-container Pods, similarly, specify " / .rootfs" for each container; Usage restrictions: When reusing an old Rootfs to create a new Pod, the image must be identical and the relative path of the Rootfs Volume must be identical (including the SubPath).

[0096] The following provides a complete example using a specific operating environment, taking Kubernetes as an example, including Kubernetes Pod configuration, snapshotter mounting information, CRI mounting configuration, and the container creation / deletion process.

[0097] Pod Spec (Kubernetes Pod Configuration)

[0098] This is a Kubernetes Pod definition file used to describe the container's runtime configuration. Key fields are explained below: apiVersion: v1 (Indicates that version v1 of the Kubernetes API is being used) kind: Pod (indicates that the resource type is Pod, i.e., a container group) metadata (representing metadata) name: test-rootfs-pod-single (This indicates the naming of the Pod) labels: (representing labels) app: test-rootfs-pod-single (tags pods for filtering or management) spec: (Indicates the specifications and the core configuration described below) containers (representing a list of containers) name: test-rootfs-pod-1 (This indicates the name of the container) Image: registry.baidu.com / public / nginx-alpine-go (This indicates the image used by the container, i.e., the Nginx+Alpine+Go environment). ports: (represents port numbers) - containerPort: 80 (indicates that port 80 is specifically exposed for HTTP services) volumeMounts: (Indicates the volume mount configuration within the container) name: cds-pvc (This represents the volume name, corresponding to the volumes field below) mountPath: " / .rootfs" (This indicates that the volume is mounted to the / .rootfs path inside the container, telling the container runtime that this volume needs to be used as the parent directory of the writable layer to achieve system disk persistence) nodeSelector: (Represents a node selector) kubernetes.io / hostname: 10.2.7.112 (specifies that the Pod runs on the node with hostname 10.2.7.112) volumes: (represents a volume definition) name: cds-pvc (This represents the volume name, corresponding to volumeMounts above) persistentVolumeClaim: (Indicates the use of persistent volume to declare a PVC) claimName: csi-pvc-cds: (This indicates that its name is csi-pvc-cds, which corresponds to the underlying persistent storage such as Cloud Defined Storage, CDS, also known as cloud disk, and is the actual storage carrier of the container writable layer).

[0099] After completing the above parameter definitions, you can first refer to, for example... Figure 8-1 The container creation process shown: Step 1: Create container, which is used to trigger container runtime initialization.

[0100] Step 2: create Active snapshotter(Overlay) (create an Active snapshotter of type Overlay), which initializes the directory structure of OverlayFS (lowDir, upperDir, workDir).

[0101] This step refers to the Snapshotter Mount Info on the left. Snapshotter is a core component of Containerd (the container runtime) and is used to manage the OverlayFS directory of the container file system. It specifically shows the three key directories of OverlayFS: lowDir: parentPath=parentPath (read-only layer parent directory) is the underlying layer of OverlayFS, containing the read-only layer of container images; upperDir: / var / lib / containerd / yyy / fs (writable layer directory) is the upper layer of OverlayFS and is used to store modifications made during container runtime. This directory is located under the mount path of the persistent volume (PVC), so all system disk modifications of the container (such as installing software and modifying configurations) will be written to the PVC to achieve persistence. workDir: / var / lib / containerd / yyy / work (working directory) is the temporary workspace of OverlayFS, used to merge read-only and writable layers.

[0102] Step 3: Mount CDS to snapshotter path. By binding the mount, the PVC (such as CDS cloud disk) is mounted to the upperDir parent directory of the snapshotter (i.e., the parent path of / var / lib / containerd / yyy / fs). At this time, the writable layer (upperDir) of the container is located on the PVC, and all modifications will be written to the PVC.

[0103] This step refers to CRI Mounts (Container Runtime Interface Mount Configuration) on the left. CRI is the communication protocol between Kubernetes and the container runtime, and it shows the mount mapping between the host machine and the container: ContainerPath: / .rootfs (represents the mount path within the container, consistent with the mountPath in the Pod Spec); HostPath: / var / lib / kubelet / pods / cb34a125-7eb7…… (represents the path on the host machine, the location where Kubelet mounts the PVC on the host machine), is used to map the PVC path on the host machine to / .rootfs inside the container via Bind Mount, so that the container runtime can recognize that this path needs to be used as the parent directory of the writable layer.

[0104] Step 4: Set label to snapshotter mount, which marks this mount as "containerd.io / snapshot / rootfs.volume.mount": "true", for identification during subsequent unmounting.

[0105] Step 5: Start container, which means starting the container process when the container is running.

[0106] Step 6: Overlay mount (mounting OverlayFS) refers to merging the read-only layer (lowDir) and the writable layer (upperDir) to form the container's root file system (rootfs).

[0107] Step 7: pivot_root (switch root directory), which means switching the container's root directory to the merge directory of OverlayFS to complete the container startup.

[0108] You can then continue to see, for example... Figure 8-2 The container removal process (or deletion process) shown is as follows: Step 1: Remove container, which is used to trigger container runtime cleanup.

[0109] Step 2: Remove snapshotter, which means cleaning up the temporary directories of OverlayFS (lowDir, workDir).

[0110] Step 3: unmount snapshotter path by label (meaning unmount the snapshotter path based on the label). Based on the label set during creation (containerd.io / snapshot / rootfs.volume.mount: "true"), the mount path of the PVC is unmounted. At this time, the writable layer data (modified by the system disk) in the PVC will be preserved and can be remounted and restored the state when the container is created again.

[0111] The algorithm framework for persistent rootfs writable layers provided in this embodiment is applicable to the following fields: 1) Cloud-based development machine / IDE workstation: Developers require that system-level changes made within the container (package management, toolchain, third-party developer toolkits) be persistent and can be powered on and off multiple times; 2) AI Notebook / Model Fine-tuning and Inference Workbench: Interactive sessions such as Jupyter / VSCode-Server need to retain system-level environments such as Pip / Conda / CUDA; 3) HPC (High Performance Computing) / Interactive Research Jobs: Long-lifecycle sessions require a recoverable system disk experience to avoid environment reconstruction after job interruption; 4) Enterprise-wide multi-tenant PaaS (Platform as a Service) workbench: isolates tenants' Rootfs workspaces, implements capacity / IO limits and lifecycle governance; 5) Education / experimental teaching environment: Course image + persistent rootfs, to achieve "configuration once, reuse for multiple rounds of experiments".

[0112] The technical effects that can be achieved by applying the technical solution provided in this embodiment include: Containers will gain "virtual machine-style power on / off" capabilities, and system-level installation / configuration (package management, kernel module dependencies, language runtime, etc.) can be persisted; development machines, data science workbenches, notebooks, etc. can be configured once and reused for a long time, significantly shortening environment preparation time; containers can quickly recover to the "pre-shutdown" state after a crash / node maintenance; combined with image verification, environment drift is avoided; and the Kubernetes / CSI standard stack is continued, eliminating the need to introduce virtual machine isolation, and enabling unified operation and maintenance and observable governance.

[0113] Further reference Figure 9 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a cross-lifecycle processing apparatus for container runtime data, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0114] like Figure 9 As shown, the container runtime data cross-lifecycle processing apparatus 900 of this embodiment may include: a migration / rebuild instruction acquisition unit 901, a persistent volume unmounting processing unit 902, and a remounting unit 903. The migration / rebuild instruction acquisition unit 901 is configured to acquire migration or rebuild instructions for a target container; wherein a target persistent volume, acting as a writable layer, is mounted on the target container; the persistent volume unmounting processing unit 902 is configured to unmount the target persistent volume according to the migration or rebuild instructions, resulting in a target persistent volume in a pending mount state; the remounting unit 903 is configured to remount the target persistent volume in the pending mount state to the parent directory of the writable layer of the successfully migrated or rebuilt target container in response to the target container successfully migrating to the target address or successfully rebuilding at the target address.

[0115] In this embodiment, the specific processing of the migration / rebuild instruction acquisition unit 901, the persistent volume unloading processing unit 902, and the remounting unit 903 in the cross-lifecycle processing device 900 for container runtime data, and the resulting technical effects, can be found in the following references: Figure 2 The relevant descriptions of steps 201-203 in the corresponding embodiments will not be repeated here.

[0116] In some other optional implementations of this embodiment, a target container creation unit configured to create the target container is also included. The target container creation unit may include: The persistent volume declaration subunit is configured to declare persistent volumes in the creation configuration by means of annotations or by pointing the mount volume configuration item to a preset path when a container is created in a containerization orchestration system. The target persistent volume determination subunit is configured to determine the target persistent volume in the pending mount state based on the persistent volume declaration; The writable layer mount subunit is configured to mount the target persistent volume, which is in a pending mount state, to the parent directory of the writable layer of the container that has completed the read-only layer data configuration using the creation configuration, thus obtaining the target container.

[0117] In some other optional implementations of this embodiment, the writable layer mounting subunit is further configured as follows: Based on the read-only layer configuration item in the creation configuration, the corresponding preset container image is called to complete the configuration of read-only layer data for the initialization container, and the first intermediate state container is obtained. Based on the persistent volume declaration, the target persistent volume in the pending mount state is mounted to the parent directory of the writable layer of the intermediate state container, thus obtaining the second intermediate state container. Complete other file system mounting operations on the second intermediate state container based on the file system configuration items in the creation configuration to obtain the target container.

[0118] In some other alternative implementations of this embodiment, in response to the containerization orchestration system being Kubernetes, custom resource technology can also be used to declare persistent volumes for the created containers.

[0119] In some other optional implementations of this embodiment, the target persistent volume determination subunit includes: The target persistent volume determination module is configured to determine the target persistent volume in the pending mount state based on the persistent volume declaration and the use case of the created container.

[0120] In some other optional implementations of this embodiment, the target persistent volume determination module is further configured to: Based on the persistent volume declaration, the persistent volumes that are in the pending mounting state are selected from all the candidate persistent volumes. Determine the target type of the storage volume based on the use case of the created container; the storage volume type includes: block storage, streaming storage, file storage, or object storage. Among all persistent volumes in the pending mount state, the persistent volume of type target is identified as the target persistent volume in the pending mount state.

[0121] In some other optional implementations of this embodiment, the cross-lifecycle processing apparatus 900 for container runtime data may further include: The snapshot generation unit is configured to generate a writable layer snapshot on the target container, which is a writable layer served by the mounted target persistent volume, according to a preset writable layer snapshot triggering rule, and store the generated writable layer snapshot in the snapshot storage area of ​​the target persistent volume or a preset writable layer snapshot storage volume.

[0122] In some other optional implementations of this embodiment, the writable layer snapshot triggering rule includes at least one of the following: The criteria are: whether the amount of new data added to the writable layer has reached the first preset data amount; whether the cumulative amount of data in the writable layer has reached the second preset data amount; whether the writable layer has added preset sensitive information; whether the cumulative amount of sensitive information stored in the writable layer has reached the third preset data amount; whether the time interval since the last snapshot was generated meets the preset time interval; and the remaining lifespan of the target persistent volume.

[0123] In some other optional implementations of this embodiment, the cross-lifecycle processing apparatus 900 for container runtime data may further include: The snapshot management chain forming unit is configured to form a snapshot management chain from multiple generated writable layer snapshots in chronological order. The useless snapshot cleanup unit is configured to clean up useless snapshots in the snapshot management chain according to preset snapshot management rules.

[0124] In some other optional implementations of this embodiment, the cross-lifecycle processing apparatus 900 for container runtime data may further include: During the migration process, the traffic temporary storage processing unit is configured to, in response to receiving a migration instruction for the target container, temporarily store the traffic sent to the original address of the target container during the migration process, and send the temporarily stored traffic to the target container after successful migration according to the storage time sequence.

[0125] In some other optional implementations of this embodiment, the cross-lifecycle processing apparatus 900 for container runtime data may further include: During the migration process, the traffic transfer processing unit is configured to, in response to receiving a migration instruction for the target container, determine a replacement container with the same function as the target container, and redirect traffic pointing to the original address of the target container to the address of the replacement container until the target container is successfully migrated to the new address. The alternative processing result extraction unit is configured to extract the traffic processing results of the target container that is in the process of migration from the alternative container; The alternative processing result return unit is configured to send the traffic processing result to the target container at the new address.

[0126] In some other optional implementations of this embodiment, the cross-lifecycle processing apparatus 900 for container runtime data may further include: The performance metric determination unit is configured to determine the performance metrics of the target persistent volume. The visualization window provider and instruction receiving unit is configured to provide a visualization window for displaying performance metrics for the target persistent volume, and to receive and execute performance tuning instructions passed from the visualization window.

[0127] This embodiment exists as a device embodiment corresponding to the above method embodiment. The container runtime data cross-lifecycle processing device provided in this embodiment mounts the persistent volume in the pending mounting state to the parent directory of the container's writable layer before the container has completed the configuration of the writable layer. This allows the persistent volume to act as the container's writable layer. All subsequent system disk data written to the writable layer is actually written to the persistent volume. Once the container faces reconstruction or migration, the persistent volume can be unloaded from the container, thereby ensuring that the system disk data previously stored in the persistent volume is persistently stored. This gives the container a "virtual machine-like power on / off" capability. The persistently stored system disk data can not only be reused for a long time, but also significantly shorten the environment preparation time, allowing the container to quickly recover to the "pre-shutdown" state after reconstruction or migration.

[0128] According to embodiments of this disclosure, this disclosure also provides an electronic device, the electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the cross-lifecycle processing method of container runtime data described in any of the above embodiments to be implemented when the at least one processor executes the instructions.

[0129] According to embodiments of this disclosure, this disclosure also provides a readable storage medium storing computer instructions that enable a computer to implement the cross-lifecycle processing method for container runtime data described in any of the above embodiments when executed.

[0130] According to embodiments of this disclosure, this disclosure also provides a computer program product that, when executed by a processor, can implement the steps of the cross-lifecycle processing method for container runtime data described in any of the above embodiments.

[0131] Figure 10 A schematic block diagram of an example electronic device 1000 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0132] like Figure 10 As shown, device 1000 includes a computing unit 1001, which can perform various appropriate actions and processes according to a computer program stored in read-only memory (ROM) 1002 or a computer program loaded into random access memory (RAM) 1003 from storage unit 1008. The RAM 1003 may also store various programs and data required for the operation of device 1000. The computing unit 1001, ROM 1002, and RAM 1003 are interconnected via bus 1004. Input / output (I / O) interface 1005 is also connected to bus 1004.

[0133] Multiple components in device 1000 are connected to I / O interface 1005, including: input unit 1006, such as keyboard, mouse, etc.; output unit 1007, such as various types of monitors, speakers, etc.; storage unit 1008, such as disk, optical disk, etc.; and communication unit 1009, such as network card, modem, wireless transceiver, etc. Communication unit 1009 allows device 1000 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0134] The computing unit 1001 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1001 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1001 performs the various methods and processes described above, such as the cross-lifecycle processing method for container runtime data. For example, in some embodiments, the cross-lifecycle processing method for container runtime data can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1008. In some embodiments, part or all of the computer program can be loaded and / or installed on device 1000 via ROM 1002 and / or communication unit 1009. When the computer program is loaded into RAM 1003 and executed by the computing unit 1001, one or more steps of the cross-lifecycle processing method for container runtime data described above can be performed. Alternatively, in other embodiments, computing unit 1001 may be configured by any other suitable means (e.g., by means of firmware) to perform cross-lifecycle processing methods for container runtime data.

[0135] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0136] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0137] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0138] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0139] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0140] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and Virtual Private Server (VPS) services, such as high management difficulty and weak business scalability.

[0141] According to the technical solution of this disclosure, by mounting a persistent volume in a state to be mounted to the parent directory of the container's writable layer before the container has configured a writable layer, the persistent volume can act as the container's writable layer. All subsequent system disk data written to the writable layer is actually written to the persistent volume. Once the container faces reconstruction or migration, the persistent volume can be unloaded from the container, thereby ensuring that the system disk data previously stored in the persistent volume is persistently stored. This gives the container a "virtual machine-like power on / off" capability. The persistently stored system disk data can not only be reused for a long time, but also significantly shorten the environment preparation time, allowing the container to quickly recover to the "pre-shutdown" state after reconstruction or migration.

[0142] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0143] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure. < / pod-volume-path>

Claims

1. A method for handling container runtime data across its lifecycle, comprising: Obtain migration or rebuild instructions for a target container; wherein the target container has a target persistent volume that acts as a writable layer. According to the migration or rebuild instruction, the target persistent volume is unloaded to obtain the target persistent volume in the state of waiting to be mounted. In response to the successful migration of the target container to the target address or the completion of reconstruction at the target address, the target persistent volume in the pending mount state is remounted to the parent directory of the writable layer of the successfully migrated or reconstructed target container.

2. The method according to claim 1, wherein, The creation process of the target container includes: When creating a container in a containerized orchestration system, persistent volumes are declared in the creation configuration by using annotations or by pointing the mount volume configuration item to a preset path. Based on the persistent volume declaration, the target persistent volume in the pending mount state is determined; Mount the target persistent volume, which is in a state of waiting to be mounted, to the parent directory of the writable layer of the container that has been configured with read-only layer data using the creation configuration, and obtain the target container.

3. The method according to claim 2, wherein, The step of mounting the target persistent volume in the pending mounting state to the parent directory of the writable layer of the container that has completed the read-only layer data configuration using the creation configuration, to obtain the target container, includes: Based on the read-only layer configuration item in the creation configuration, the corresponding preset container image is called to initialize the container and complete the configuration of read-only layer data, thus obtaining the first intermediate state container. According to the persistent volume declaration, the target persistent volume in the pending mounting state is mounted to the parent directory of the writable layer of the intermediate state container to obtain the second intermediate state container. Complete other file system mounting operations on the second intermediate state container according to the file system configuration items in the creation configuration to obtain the target container.

4. The method according to claim 2, further comprising: In response to the containerization orchestration system being Kubernetes, persistent volume declarations are made for the created containers using custom resource technology.

5. The method according to claim 2, wherein, The step of determining the target persistent volume in a pending mount state based on the persistent volume declaration includes: Based on the persistent volume declaration and the use case of the created container, determine the target persistent volume that is in a pending mounting state.

6. The method according to claim 5, wherein, The step of determining the target persistent volume in the pending mount state based on the persistent volume declaration and the usage scenario of the created container includes: Based on the persistent volume declaration, the persistent volumes that are in the pending mounting state are selected from all the candidate persistent volumes. Determine the target type of the storage volume based on the use case of the created container; the storage volume type includes: block storage, streaming storage, file storage, or object storage. Among all persistent volumes in the pending mount state, the persistent volume of type described in the target type is identified as the target persistent volume in the pending mount state.

7. The method according to claim 1, further comprising: For the writable layer on the target container, which is served by the mounted target persistent volume, a writable layer snapshot is generated according to the preset writable layer snapshot triggering rules, and the generated writable layer snapshot is stored in the snapshot storage area of ​​the target persistent volume or the preset writable layer snapshot storage volume.

8. The method according to claim 7, wherein, The writable layer snapshot triggering rule includes at least one of the following: The criteria are: whether the amount of newly added data in the writable layer reaches the first preset data amount; whether the cumulative amount of data in the writable layer reaches the second preset data amount; whether the writable layer has added preset sensitive information; whether the amount of information of the cumulative stored sensitive information in the writable layer reaches the third preset data amount; whether the time interval since the last snapshot generation meets the preset time interval; and the remaining lifespan of the target persistent volume.

9. The method according to claim 7, further comprising: The generated multiple writable layer snapshots are arranged into a snapshot management chain in chronological order; The useless snapshots in the snapshot management chain are cleaned up according to the preset snapshot management rules.

10. The method according to claim 1, further comprising: In response to receiving a migration instruction for the target container, the traffic sent to the original address of the target container is temporarily stored during the migration process, and the temporarily stored traffic is sent to the successfully migrated target container in the storage order.

11. The method according to claim 1, further comprising: In response to receiving a migration instruction for the target container, a replacement container with the same function as the target container is determined, and traffic pointing to the original address of the target container is redirected to the address of the replacement container until the target container is successfully migrated to the new address; Extract the traffic processing results of the target container that is in the migration process from the alternative container; The traffic processing result is sent to the target container located at the new address.

12. The method according to any one of claims 1-11, further comprising: Determine the performance metrics of the target persistent volume; Provide a visualization window for displaying the performance metrics to the target persistent volume, and receive and execute performance tuning instructions passed from the visualization window.

13. A device for processing container runtime data across its lifecycle, comprising: The migration / rebuild instruction acquisition unit is configured to acquire migration or rebuild instructions for a target container; wherein the target container has a target persistent volume that acts as a writable layer mounted on it. The persistent volume unloading processing unit is configured to unload the target persistent volume according to the migration or rebuild instruction, so as to obtain the target persistent volume in the state of waiting to be mounted. The remount unit is configured to remount the target persistent volume in the pending mount state to the parent directory of the writable layer of the successfully migrated or rebuilt target container in response to the successful migration of the target container to the target address or the successful reconstruction of the target container.

14. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the cross-lifecycle processing method for container runtime data according to any one of claims 1-12.

15. A non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform a cross-lifecycle processing method for container runtime data according to any one of claims 1-12.

16. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the cross-lifecycle processing method for container runtime data according to any one of claims 1-12.

Images