Data storage method and device, server and computer readable storage medium

Abstract

The invention relates to the technical field of cloud services, in particular to a data storage method and device, a server and a computer readable storage medium. According to the method, the global mounting directory on which the target storage volume is mounted is associated with the file system of the container, specifically, the mounting path of the target storage volume under the global mounting directory is bound with at least one of a writable layer and a working directory layer included in the file system corresponding to the container; therefore, the data generated in the operation process of the container is directly stored in the target storage volume, persistent storage of the operation data of the container in the cloud disk is realized on the premise that the use mode of the container is not changed, manual intervention of a user is not needed, and the efficiency and accuracy of data persistent storage are improved.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of cloud service, and particularly relates to a data storage method and device, a server and a computer readable storage medium. BACKGROUND

[0002] A container is a lightweight virtualization technology, which enables multiple application instances to run on the same operating system kernel of a cloud server in isolation from each other.

[0003] In the current cloud native environment, a container has the characteristics of short life cycle and easy replacement. If a user needs the running data in the container to be retained after the container is destroyed, an elastic block store (EBS) can be used, and the user explicitly declares the storage requirement in the deployment file of a pod, and binds the existing persistent volume storage resource to the pod based on the deployment file.

[0004] However, the configuration process of declaring the storage requirement in the deployment file is very complex, and the manual operation process of the user is prone to errors, resulting in low efficiency and accuracy of data persistent storage. SUMMARY

[0005] To solve the above technical problems, the present disclosure provides a data storage method and device, a server and a computer readable storage medium to improve the efficiency and accuracy of data persistent storage.

[0006] In a first aspect, the embodiments of the present disclosure provide a data storage method, comprising: receiving a first creation request of a container; In response to the first creation request, creating a target storage volume, mounting the target storage volume to a global mounting directory of a server node, and binding a mounting path of the target storage volume under the global mounting directory to at least one of a writable layer and a working directory layer included in a file system corresponding to the container, so as to store running data of the container into the target storage volume, wherein the global mounting directory is used to store data of all storage volumes mounted to the server node.

[0007] In a second aspect, the embodiments of the present disclosure provide a data storage device, comprising: a first receiving module configured to receive a first creation request of a container; The mounting module is configured to, in response to the first creation request, create a target storage volume, mount the target storage volume to a global mounting directory of a server node, and bind a mounting path of the target storage volume under the global mounting directory to at least one of a writable layer and a working directory layer included in a file system corresponding to the container, so as to store running data of the container into the target storage volume. The global mounting directory is configured to store data of all storage volumes mounted to the server node.

[0008] In a third aspect, the embodiments of the present disclosure provide a server, comprising: a memory; a processor; and a computer program; The computer program is stored in the memory and configured to be executed by the processor to implement the method of the first aspect.

[0009] In a fourth aspect, the embodiments of the present disclosure provide a computer readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the method of the first aspect.

[0010] In a fifth aspect, the embodiments of the present disclosure further provide a computer program product comprising a computer program or instructions, which, when executed by a processor, implement the data storage method as described above.

[0011] The data storage method, device, server and computer readable storage medium provided by the embodiments of the present disclosure associate the global mounting directory mounted with the target storage volume with the file system of the container, specifically, bind the mounting path of the target storage volume under the global mounting directory to at least one of the writable layer and the working directory layer included in the file system corresponding to the container, so that the data generated during the running of the container is directly saved to the target storage volume. Without changing the usage mode of the container, the running data of the container is realized to be persistently stored in the cloud disk, without manual intervention of the user, and the efficiency and accuracy of the data persistent storage are improved. BRIEF DESCRIPTION OF DRAWINGS

[0012] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and serve to explain the principles of the present disclosure together with the specification.

[0013] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, for those skilled in the art, other drawings can also be obtained based on these drawings without creative labor.

[0014] Figure 1 A flowchart illustrating the data storage method provided in this embodiment of the disclosure; Figure 2 A flowchart illustrating a data storage method provided in another embodiment of this disclosure; Figure 3 A schematic diagram of the structure of the data storage device provided in the embodiments of this disclosure; Figure 4 This is a schematic diagram of the server structure provided in an embodiment of this disclosure. Detailed Implementation

[0015] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0016] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0017] This disclosure provides a data storage method, which will be described below with reference to specific embodiments.

[0018] Figure 1 This is a flowchart illustrating a data storage method provided in an embodiment of this disclosure. This method can be applied to a container runtime (e.g., a container). The container runtime is responsible for the lifecycle management of the container, such as image download, storage, container creation, and execution. It is understood that the data storage method provided in this disclosure can also be applied to other scenarios.

[0019] The following is about Figure 1 The data storage method shown is described below, and the specific steps of this method are as follows: S101, Receive the first creation request for the container.

[0020] The first creation request refers to a container creation request initiated by a user or container orchestration system (such as Kubernetes) to the container runtime through the Container Runtime Interface (CRI), used to create the container for the first time. The first creation request contains basic configuration information of the container, such as the container image and resource quotas.

[0021] The container runtime listens for and retrieves the first creation request.

[0022] S102. In response to the first creation request, create a target storage volume, mount the target storage volume to the global mount directory of the server node, and bind the mount path of the target storage volume in the global mount directory to at least one of the writable layer and working directory layer included in the file system corresponding to the container, so as to store the container's running data into the target storage volume.

[0023] The global mount directory is used to store data for all storage volumes mounted to the server node.

[0024] A server node is the actual server instance where the container runs. A server node includes a global mount directory managed by the container orchestration system for mounting external storage volumes.

[0025] Mounting the target storage volume to the global mount directory means establishing an association between the target storage volume and a subpath (such as the mount path) under the global mount directory through the mount mechanism. After the target storage volume is mounted to the global mount directory, server nodes can read and write data in the storage volume through the mount path.

[0026] A target storage volume refers to an external storage medium with persistent storage capabilities allocated to a currently created container. Its lifecycle is independent of the container; even if the container is destroyed, the target storage volume and its internal data are still retained. Based on the container's storage requirements, the container runtime invokes the cloud platform's storage service capabilities to create the target storage volume.

[0027] The file system corresponding to a container consists of a read-only layer, a writable layer, and a working directory layer. The read-only layer stores the base image layer, including the basic files required for container operation; the writable layer records new or modified content during container operation, such as configuration files and logs; and the working directory layer stores temporary files and intermediate data during container operation.

[0028] After binding the mount path of the target storage volume under the global mount directory to at least one of the writable layer and working directory layer included in the file system corresponding to the container, the container's read and write operations on the writable layer and working directory layer will be mapped to the target storage volume, thereby making the files in the writable layer and the files in the working directory layer persist to the target storage volume.

[0029] Specifically, at least one of the following is constructed under the mount path: a first subdirectory corresponding to the writable layer and a second subdirectory corresponding to the working directory layer.

[0030] The first subdirectory is used to store files that have changed during container runtime, i.e., data written to the writable layer during container runtime. For example, if a file from the read-only layer is modified during container runtime, the modified version will be stored in the first subdirectory.

[0031] The second subdirectory is used to store temporary data during container operation. For example, when a container modifies a file, a temporary file corresponding to the modified file is first created in the second subdirectory, and then the temporary file is moved to the first subdirectory after modification.

[0032] Optionally, the mount path of the target storage volume under the global mount directory can be bound to at least one of the writable layer and working directory layer included in the file system corresponding to the container through the bind mount mechanism of the Linux system.

[0033] This embodiment of the disclosure associates the global mount directory on which the target storage volume is mounted with the container's file system. Specifically, it binds the mount path of the target storage volume under the global mount directory with at least one of the writable layer and working directory layer included in the container's file system. This allows data generated during container operation to be directly saved to the target storage volume. Without changing the way the container is used, persistent storage of the container's runtime data in the cloud disk is achieved without manual intervention from the user, thus improving the efficiency and accuracy of persistent data storage.

[0034] In some embodiments, the container runtime determines whether the currently created container needs to enable data persistence by recognizing the information carried in the first creation request. Data persistence is the function of storing the container's runtime data to a target storage volume.

[0035] One possible implementation is that the first creation request carries storage function configuration items and pseudo-path configuration items. Before mounting the storage volume to the global mount directory of the server node and binding the mount path of the target storage volume under the global mount directory to at least one of the writable layer and working directory layer included in the file system corresponding to the container, the first creation request is parsed to obtain the storage function configuration items and pseudo-path configuration items corresponding to the first creation request.

[0036] The storage function configuration item indicates that the container enables the data persistence function, and the pseudo path configuration item indicates the pseudo path corresponding to the container.

[0037] During container runtime, the structured information of the received first creation request is extracted to obtain the storage function configuration items and pseudo-path configuration items carried therein. If the storage function configuration items and pseudo-path configuration items corresponding to the first creation request are successfully obtained, it is determined that the container currently being created needs to enable data persistence. Then, the operation of mounting the storage volume to the global mount directory of the server node is performed, and the mount path of the target storage volume under the global mount directory is bound to at least one of the writable layer and working directory layer included in the file system corresponding to the container is executed.

[0038] It's understandable that both storage configuration options and pseudo-path configuration options are used by the container to identify whether the currently created container needs to enable data persistence. Furthermore, to prevent users from mistakenly using pseudo-paths as file read / write paths within the container when operating on it, pseudo-paths are hidden inside the container to avoid misidentification or misoperation during container operation.

[0039] Optionally, the specific parameters for the storage feature configuration item and the pseudo-path configuration item are specified when creating the container group to which the container belongs.

[0040] For example, the storage function configuration item is configured as "containerd.io / snapshot.rw.ebs.container"; the pseudo path configuration item is configured as " / containerd.io / snapshot / rw / ebs / pseudo / path".

[0041] This embodiment of the disclosure uses two different configuration items, storage function configuration item and pseudo path configuration item, as identifiers to enable data persistence function for the container. Only when both different configuration items exist in the first creation request is it determined that the data persistence function of the container is enabled. The dual verification mechanism effectively reduces the probability of erroneous operation. At the same time, the data persistence function of the container can be enabled without modifying the runtime of the container or the running logic of the container orchestration system, which further improves the efficiency and accuracy of data persistence storage.

[0042] In addition, by hiding the pseudo-path inside the container, the embodiments of this disclosure isolate user operations from the runtime logic of the container, avoid user misoperation inside the container, and ensure the stability of the container operation.

[0043] Building upon the above embodiments, each server node includes at least one container group (Pod). A container group is the smallest scheduling unit in a cloud-native environment, comprising multiple associated containers. In a cloud-native environment, the allocation granularity of storage resources such as storage volumes is at the container group level. That is, each container group corresponds to one storage volume.

[0044] Based on this, the steps for creating a target storage volume in the above embodiments include: determining the container group to which the container belongs based on the container name carried in the first creation request; sending a storage volume allocation request to the cloud platform by calling a preset storage service interface, wherein the target storage volume allocation request includes a storage requirement declaration for the container group; and obtaining the volume identifier returned by the cloud platform, wherein the volume identifier is used to uniquely identify the target storage volume and the storage attributes of the target storage volume conform to the storage requirement declaration.

[0045] The container name carried in the first creation request refers to the string information used to uniquely identify a single container in the container creation instruction received by the container runtime. The container runtime determines the mapping relationship between containers and container groups by parsing the structured information of the container name or querying the metadata interface of the container orchestration system, thereby determining the container group to which the container belongs.

[0046] The container runtime interacts with the cloud platform's storage services by calling a pre-defined storage service interface, such as the Container Storage Interface (CSI). The container runtime calls the pre-defined storage service interface to send a storage volume allocation request to the cloud platform's storage service, requesting the cloud platform's storage service to create the target storage volume for the container group to which the container belongs.

[0047] The storage volume allocation request includes a storage requirement declaration for the container group, representing the container group's requirements for the storage volume's performance, capacity, reliability, and other attributes. The cloud platform storage service creates a target storage volume based on the container group's storage requirement declaration, assigns it a volume identifier as a unique identifier, and returns the volume identifier to the container runtime. This allows the container runtime to mount the target storage volume corresponding to the volume identifier based on the first creation request. Thus, data generated by containers with data persistence enabled within the container group can be directly stored in the target storage volume.

[0048] Optionally, when creating a container group, the user can specify the name of the container that can enable data persistence. When the container runtime receives the first creation request, it first determines whether the container name carried in the first creation request is the container name specified when creating the container group, and then continues to perform subsequent operations; if the container name carried in the creation request received by the container runtime is not the container name specified when creating the container group, then it refuses to enable data persistence for that container.

[0049] This disclosed embodiment declares storage requirements based on container groups, automatically applies for target storage volumes from cloud platform storage services through a preset storage service interface, and finally obtains the volume identifier to complete the creation of the target storage volume corresponding to the container group. The entire process requires no manual intervention and conforms to the container group-level management architecture in a cloud-native environment. This makes the solution adaptable to different cloud platforms and does not require redevelopment due to environmental changes, thus improving the universality of data storage methods.

[0050] The following describes the specific steps for unloading the target storage volume. Specifically, when the container's lifecycle ends, an unloading operation is performed on the target storage volume to store the cached data from the file system into the target storage volume. Afterward, the writable layer and the working directory layer are deleted.

[0051] The unloading operation includes unbinding the mount path of the target storage volume under the global mount directory from the writable layer in the file system corresponding to the container.

[0052] The end of a container's lifecycle refers to the container transitioning from a running state to a terminated state, including normal termination and abnormal termination. Normal termination includes the application within the container exiting voluntarily after completing its tasks, or a user executing a stop command on the container. Abnormal termination includes situations such as the container being killed due to server node resources being exhausted.

[0053] At this point, an unloading operation is performed on the target storage volume, triggering a data flushing action at the container runtime or operating system. This forces the cached data in the file system corresponding to the container that has not been written to the target data volume to be written to the target storage volume, thus preventing data loss.

[0054] After the data flushing is complete, the container runtime undies the binding between the target storage volume's mount path in the global mount directory and the writable layer included in the container's file system. For example, the container runtime uses operating system commands to disconnect the mapping between the target storage volume's mount path in the global mount directory and the path containing the writable layer in the container's file system, ensuring that subsequent data changes within the container are not mapped to the target storage volume.

[0055] Optionally, the binding relationship between the mount path of the target storage volume under the global mount directory and the working directory layer included in the file system corresponding to the container can be released at container runtime; or, the binding relationship between the mount path of the target storage volume under the global mount directory and the working directory layer included in the file system corresponding to the container can be automatically released when the container is destroyed.

[0056] Since the working directory layer is used to store temporary files during container operation, the data in it usually does not have the value of persistent storage. Therefore, the binding relationship between the mount path of the target storage volume under the global mount directory and the writable layer is removed first. The binding relationship between the mount path of the target storage volume under the global mount directory and the working directory layer can be automatically removed when the container is destroyed.

[0057] Furthermore, the container runtime removes the local directories corresponding to the writable layer and the working directory layer, releasing the corresponding disk space, thereby enabling the deletion operation of the writable layer and the working directory layer.

[0058] This embodiment of the disclosure first unloads the target storage volume, thereby decoupling the lifecycle of the data in the target storage volume from the lifecycle of the container by removing the mount path of the target storage volume from the writable layer. This ensures that the data can still be saved to the target storage volume when the container terminates abnormally, thus ensuring the data security at the end of the lifecycle of all containers.

[0059] In addition, this embodiment of the present disclosure prioritizes unbinding the target storage volume's mount path under the global mount directory from the writable layer, so that temporary data in the writable layer can also be saved to the target storage volume, thus ensuring the reliability of persistent data storage.

[0060] Based on the above embodiments, if a container creation request is received again, the target storage volume can be directly bound to it without recreating the storage volume.

[0061] Specifically, after performing an unmount operation on the target storage volume, a second creation request from the container is received; in response to the second creation request, the target storage volume is mounted to the global mount directory of the server node, and the mount path of the target storage volume in the global mount directory is bound to at least one of the writable layer and working directory layer included in the file system corresponding to the container.

[0062] The second creation request refers to the rebuild request initiated by the user or container orchestration system after the container's lifecycle ends.

[0063] The second creation request carries the same container name as the first creation request, so that the container runtime can recognize that the second creation request is a reconstruction request for the container corresponding to the first creation request.

[0064] Upon receiving the second creation request, the container runtime determines the container group to which the container belongs based on the container name carried in the request. It then determines the volume identifier of the target storage volume corresponding to the container group, identifies the target storage volume based on the volume identifier, mounts the target storage volume to the global mount directory of the server node, and binds the mount path of the target storage volume under the global mount directory to the writable layer and working directory layer included in the container's corresponding file system. Thus, the container can continue to run based on the data stored in the target storage volume.

[0065] Optionally, the container runtime may verify the availability of the target storage volume before mounting it to the global mount directory of the server node. This includes verifying, for example, whether the target storage volume corresponding to the volume identifier exists and whether the data within the target storage volume is complete. Once the target storage volume is confirmed to be available, it is then mounted to the global mount directory of the server node.

[0066] Optionally, if the container group containing the container is scheduled to a new server node, in response to the second creation request, the target storage volume is mounted to the global mount directory of the new server node, and the mount path of the target storage volume under the global mount directory is bound to at least one of the writable layer and working directory layer included in the file system corresponding to the container, so as to store the running data of the container into the target storage volume.

[0067] This embodiment of the disclosure achieves data reuse during container reconstruction by directly binding the target storage volume corresponding to the container group to which the container belongs when the container is recreated, i.e. the target storage volume bound when the container was last created. Moreover, the mounting logic in this process is the same as that in the first mounting, so there is no need to redevelop the mounting mechanism, which reduces the complexity of data storage and reuse and improves stability.

[0068] Figure 2 This is a flowchart illustrating a data storage method according to another embodiment of the present disclosure, which is applied to a container runtime. Figure 2 As shown, the method includes the following steps: S201, Receive the container creation request.

[0069] The container creation request includes either a first creation request or a second creation request.

[0070] S202. Parse the sandbox information in the creation request.

[0071] The sandbox information includes storage function configuration items and pseudo-path configuration items.

[0072] S203, Obtain storage function configuration items and pseudo path configuration items.

[0073] The storage function configuration item indicates that the container enables the data persistence function, which is the function of storing the container's running data to the target storage volume. The pseudo path configuration item indicates the pseudo path corresponding to the container.

[0074] S204. Determine whether the container has enabled data persistence.

[0075] If yes, proceed to S205. If no, proceed to S206.

[0076] S205. Create a container following the normal container creation process.

[0077] S206. Adjust the mount information to hide the pseudo-path inside the container.

[0078] Specifically, the container runtime builds a file system view of the container based on OverlayFS, called RootFS. OverlayFS includes a read-only layer, a writable layer, and a working directory layer.

[0079] In RootFS, when a container runs, the target storage volume is mounted to the global mount directory of the server node, and the global mount directory is mapped to the path where the writable layer and working directory layer are located in OverlayFS. As a result, write operations generated during container operation will be directly written to the target storage volume, rather than to the local disk of the server node, thereby achieving data persistence.

[0080] When generating mount information for RootFS during container runtime, the container identifies and filters out pseudo-paths corresponding to pseudo-path configuration items to ensure that the path does not appear inside the container and to prevent accidental user operations.

[0081] It is understandable that if the container creation request is the first creation request, then the target storage volume needs to be created first, and then the mount operation can be performed.

[0082] S207. Mount the target storage volume to the global mount directory of the server node, and bind the mount path of the target storage volume in the global mount directory to the writable layer and working directory layer included in the file system corresponding to the container.

[0083] S208, Start the container.

[0084] This embodiment of the disclosure associates a global mount directory containing the target storage volume with the container's file system, thereby directly saving data generated during container operation to the target storage volume. Without changing the way the container is used, it achieves persistent storage of the container's runtime data in the cloud disk, without requiring manual user intervention, thus improving the efficiency and accuracy of persistent data storage.

[0085] Figure 3 This is a schematic diagram of the structure of a data storage device provided in an embodiment of this disclosure. The data storage device may be a container runtime as described in the above embodiment, or it may be a component or part within the container runtime. The data storage device provided in this embodiment can execute the processing flow provided in the data storage method embodiment, such as... Figure 3 As shown, the data storage device 30 includes: a first receiving module 31 and a mounting module 32; the first receiving module 31 is used to receive a first creation request of the container; the mounting module 32 is used to respond to the first creation request, create a target storage volume, mount the target storage volume to the global mount directory of the server node, and bind the mount path of the target storage volume under the global mount directory to at least one of the writable layer and working directory layer included in the file system corresponding to the container, so as to store the running data of the container into the target storage volume, wherein the global mount directory is used to store the data of all storage volumes mounted to the server node.

[0086] Optionally, the data storage device 30 further includes a parsing module, used to parse the first creation request before mounting the storage volume to the global mount directory of the server node and binding the mount path of the target storage volume under the global mount directory to at least one of the writable layer and working directory layer included in the file system corresponding to the container, to obtain the storage function configuration item and pseudo path configuration item corresponding to the first creation request. The storage function configuration item indicates that the container enables the data persistence function, which is the function of storing the container's running data to the target storage volume, and the pseudo path configuration item indicates the pseudo path corresponding to the container.

[0087] Optionally, the data storage device 30 also includes a hiding module for hiding pseudo-paths inside the container.

[0088] Optionally, the mounting module 32 includes a storage volume creation unit, used to determine the container group to which the container belongs based on the container name carried in the first creation request; call a preset storage service interface to send a storage volume allocation request to the cloud platform, the target storage volume allocation request including the storage requirement declaration of the container group; obtain the volume identifier returned by the cloud platform, the volume identifier is used to uniquely identify the target storage volume, and the storage attributes of the target storage volume conform to the storage requirement declaration.

[0089] Optionally, the mounting module 32 includes a directory building unit for building at least one of a first subdirectory corresponding to the writable layer and a second subdirectory corresponding to the working directory layer under the mount path. The first subdirectory is used to store files that change during container operation, and the second subdirectory is used to store temporary data during container operation.

[0090] Optionally, the data storage device 30 also includes an unloading module for performing an unloading operation on the target storage volume when the container's lifecycle ends, so as to store the cached data in the file system into the target storage volume. The unloading operation includes unbinding the mount path of the target storage volume under the global mount directory from the writable layer in the file system corresponding to the container; deleting the writable layer and the working directory layer.

[0091] Optionally, the data storage device 30 further includes a second receiving module for receiving a second creation request from the container; the mounting module 32 is further configured to, in response to the second creation request, mount the target storage volume to the global mount directory of the server node, and bind the mount path of the target storage volume in the global mount directory to at least one of the writable layer and working directory layer included in the file system corresponding to the container.

[0092] Figure 3 The data storage device shown in the embodiment can be used to execute the technical solution of the above method embodiment. Its implementation principle and technical effect are similar, and will not be repeated here.

[0093] Figure 4This is a schematic diagram of the structure of a server provided in an embodiment of this disclosure. The server may be a server node including the container runtime described in the previous embodiment. The server provided in this embodiment of the disclosure can execute the processing flow provided in the data storage method embodiment, such as... Figure 4 As shown, server 40 includes: memory 41, processor 42, computer program and communication interface 43; wherein, the computer program is stored in memory 71 and configured to be executed by processor 72 using the data storage method described above.

[0094] In addition, this disclosure also provides a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the data storage method described in the above embodiments.

[0095] Furthermore, this disclosure also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, implement the data storage method described above.

[0096] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0097] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A data storage method, characterized in that, The method includes: Receive the first creation request for the container; In response to the first creation request, a target storage volume is created, the target storage volume is mounted to the global mount directory of the server node, and the mount path of the target storage volume under the global mount directory is bound to at least one of the writable layer and working directory layer included in the file system corresponding to the container, so as to store the running data of the container into the target storage volume. The global mount directory is used to store the data of all storage volumes mounted to the server node.

2. The method according to claim 1, characterized in that, Before mounting the storage volume to the global mount directory of the server node and binding the mount path of the target storage volume under the global mount directory to at least one of the writable layer and working directory layer included in the file system corresponding to the container, the method further includes: The first creation request is parsed to obtain the storage function configuration item and pseudo path configuration item corresponding to the first creation request. The storage function configuration item indicates that the container enables the data persistence function, which is the function of storing the container's running data to the target storage volume. The pseudo path configuration item indicates the pseudo path corresponding to the container.

3. The method according to claim 2, characterized in that, The method further includes: The pseudo-path is hidden inside the container.

4. The method according to claim 1, characterized in that, Creating the target storage volume includes: Based on the container name carried in the first creation request, determine the container group to which the container belongs; Call the preset storage service interface to send a storage volume allocation request to the cloud platform. The target storage volume allocation request includes the storage requirement declaration of the container group. Obtain the volume identifier returned by the cloud platform. The volume identifier is used to uniquely identify the target storage volume, and the storage attributes of the target storage volume conform to the storage requirement declaration.

5. The method according to any one of claims 1-4, characterized in that, The step of binding the mount path of the target storage volume under the global mount directory to at least one of the writable layer and working directory layer included in the file system corresponding to the container includes: At least one of a first subdirectory corresponding to the writable layer and a second subdirectory corresponding to the working directory layer is constructed under the mount path. The first subdirectory is used to store files that change during the operation of the container, and the second subdirectory is used to store temporary data during the operation of the container.

6. The method according to any one of claims 1-4, characterized in that, The method further includes: When the lifecycle of the container ends, an unloading operation is performed on the target storage volume to store the cached data in the file system into the target storage volume. The unloading operation includes unbinding the mount path of the target storage volume under the global mount directory from the writable layer in the file system corresponding to the container. Delete the writable layer and the working directory layer.

7. The method according to claim 6, characterized in that, After performing an unmount operation on the target storage volume, the method further includes: Receive the second creation request for the container; In response to the second creation request, the target storage volume is mounted to the global mount directory of the server node, and the mount path of the target storage volume under the global mount directory is bound to at least one of the writable layer and working directory layer included in the file system corresponding to the container.

8. A data storage device, characterized in that, include: The first receiving module is used to receive the first creation request of the container; The mounting module is used to respond to the first creation request, create a target storage volume, mount the target storage volume to the global mount directory of the server node, and bind the mount path of the target storage volume under the global mount directory to at least one of the writable layer and working directory layer included in the file system corresponding to the container, so as to store the running data of the container into the target storage volume. The global mount directory is used to store the data of all storage volumes mounted to the server node.

9. A server, characterized in that, include: Memory; processor; as well as Computer programs; The computer program is stored in the memory and configured to be executed by the processor to implement the method as described in any one of claims 1-7.

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

Images