Data management method and device and data management platform

Abstract

The invention provides a data management method and device and a data management platform. The method comprises the following steps: distributing podno for Pod of a Kubernetes cluster; a storage bucket and a corresponding object key are created in the cloud storage system by adopting a CSI plug-in, the object key is a directory structure of a target path-podno-application data directory, the application data directory is index information of the storage bucket in the cloud storage system, and the target path is a path of a Kubernetes node of a Kubernetes cluster; the storage bucket is mounted on the target path, and the target path is mounted on the Pod; according to the method and the device, the application data of the Pod is stored through the storage bucket corresponding to the Pod, so that the container of the Pod can access the application data stored in the storage bucket corresponding to the Pod according to the object key corresponding to the podno, and the problem of data chaos between the Pods of the Kubernetes cluster in the prior art is solved.

Description

Technical Field

[0001] The present invention relates to the field of data management, and in particular to a data management method, device and data management platform. Background Art

[0002] With the widespread application of cloud computing and microservice architecture, containerization technology has increasingly become the first choice for enterprises and developers. As the most popular container orchestration platform today, Kubernetes provides users with powerful container management and scheduling capabilities. Deploying stateless applications in Kubernetes clusters has become a common practice. However, stateless applications may need to access persistent storage to share files or data during operation. Although Kubernetes provides PersistentVolume (PV) and PersistentVolumeClaim (PVC) mechanisms to support container persistent storage, these mechanisms may face performance bottlenecks and data consistency issues when using shared storage.

[0003] To solve these problems, developers usually use cloud storage systems (such as cloud storage systems, Ceph, etc.) as shared storage. However, distributed file systems such as cloud storage systems require additional configuration and management work, such as manually creating and mounting shared file directories, and dealing with data consistency issues of shared file directories between multiple Pods. In addition, when mounting shared storage, the existing Kubernetes Container Storage Interface (CSI) plug-in usually allocates the same directory to each Pod, which may cause data confusion between Pods, thereby affecting the normal operation of the application.

[0004] In order to improve the efficiency of mounting and managing shared storage, researchers and engineers have tried a variety of solutions, such as introducing initContainer, SidecarContainer, etc. However, these solutions often involve complex configuration and deployment, and it is difficult to ensure the independence and consistency of data. In addition, existing solutions usually only focus on how to achieve the mounting and management of shared storage, but ignore how to achieve data inheritance between Pods. In stateless applications, when a Pod is deleted and replaced with a new Pod, users usually hope that the new Pod can inherit the data of the old Pod to ensure the continuity of the application. Summary of the invention

[0005] The main purpose of this application is to provide a data management method, device and data management platform to at least solve the problem of data confusion between Pods of a Kubernetes cluster in the prior art.

[0006] In order to achieve the above-mentioned purpose, according to one aspect of the present application, a data management method is provided, including: assigning pod_no to the Pod of the Kubernetes cluster so that the Pod corresponds to the pod_no one-to-one; using a CSI plug-in to create a bucket and a corresponding object key in a cloud storage system, wherein the object key is a directory structure of a target path-pod_no-application data directory, the application data directory is index information of the bucket in the cloud storage system, and the target path is the path of the Kubernetes node of the Kubernetes cluster; mounting the bucket to the target path, and mounting the target path to the Pod; storing the application data of the Pod through the bucket corresponding to the Pod, so that the container of the Pod can access the application data stored in the bucket corresponding to the Pod according to the object key corresponding to the pod_no.

[0007] Optionally, assigning pod_no to the Pod of the Kubernetes cluster includes: obtaining a request for obtaining pod_no from the target Pod, the request including the IP and Pod name of the target Pod, and the target Pod is any Pod of the Pod of the Kubernetes cluster; when the requested IP has been used and the requested Pod name has not changed, obtaining the pod_no corresponding to the IP and assigning it to the target Pod; when the requested IP has been used and the requested Pod name has changed, unbinding the requested IP from the corresponding pod_no, and obtaining a new pod_no and assigning it to the target Pod; when the requested IP has not been used, obtaining a new pod_no and assigning it to the target Pod.

[0008] Optionally, obtaining the new pod_no and assigning it to the target Pod includes: when there is an available pod_no in the existing pod_no, assigning the smallest available pod_no to the target Pod, the available pod_no being the unbound pod_no; when there is no available pod_no in the existing pod_no, creating a pod_no and assigning it to the target Pod, and the creation rule of the pod_no is to create from small to large.

[0009] Optionally, a CSI plug-in is used to create a storage bucket and a corresponding object key in the cloud storage system, including: when the new pod_no is obtained and assigned to the target Pod, the Controller service of the CSI plug-in is used to create the new storage bucket and the object key corresponding to the pod_no in the cloud storage system.

[0010] Optionally, mounting the storage bucket to the target path, and mounting the target path to the Pod, includes: using the Node service of the CSI plug-in to mount the storage bucket to the target path, and mapping the target path to the inside of the container of the Pod.

[0011] Optionally, after storing the application data of the Pod in the storage bucket corresponding to the Pod, the method further includes: when the Pod needs to be shut down gracefully, unbinding the Pod from the application data in the storage bucket and deleting the Pod; when it is detected that the Pod is shut down ungracefully, unbinding the Pod from the application data in the storage bucket.

[0012] Optionally, unbinding the Pod from the application data in the storage bucket includes: using the Node service of the CSI plug-in to uninstall the storage bucket from the target path, and deleting the target path from the container of the Pod to unbind the Pod from the application data in the storage bucket.

[0013] Optionally, after storing the application data of the Pod through the storage bucket corresponding to the Pod, the method also includes: setting a PersistentVolume and a PersistentVolumeClaim, the PersistentVolumeClaim being used to request the storage resources of the PersistentVolume; mounting the PersistentVolumeClaim to the target path corresponding to the Pod, so that the container of the Pod can access the data of the PersistentVolume and use the storage resources of the PersistentVolume.

[0014] According to another aspect of the present application, a data management method is provided, including: an allocation unit, used to allocate pod_no to the Pod of the Kubernetes cluster, so that the Pod corresponds to the pod_no one by one; a creation unit, used to use a CSI plug-in to create a storage bucket and a corresponding object key in a cloud storage system, wherein the object key is a directory structure of a target path-pod_no-application data directory, the application data directory is index information of the storage bucket in the cloud storage system, and the target path is the path of the Kubernetes node of the Kubernetes cluster; a first mounting unit, used to mount the storage bucket to the target path, and mount the target path to the Pod; a storage unit, used to store the application data of the Pod through the storage bucket corresponding to the Pod, so that the container of the Pod can access the application data stored in the storage bucket corresponding to the Pod according to the object key corresponding to the pod_no.

[0015] According to another aspect of the present application, a data management platform is provided, comprising: a Kubernetes cluster, a cloud storage system, one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the one or more programs include methods for executing any one of the methods described.

[0016] By applying the technical solution of the present application, in the above-mentioned data management method, by assigning a unique pod_no to the Pod of the Kubernetes cluster, and using the CSI plug-in to create a storage bucket and a corresponding object key in the cloud storage system, the Pod can be bound to the storage bucket corresponding to its pod_no by mounting the storage bucket to the target path and mounting the target path to the Pod. By storing the application data of the Pod in the storage bucket corresponding to the Pod, persistent storage of the application data of the Pod can be achieved. The container of the Pod can access the application data stored in the storage bucket corresponding to the Pod according to the object key corresponding to the pod_no, providing an independent storage directory for each Pod, avoiding data confusion, and solving the problem of data confusion between Pods of the Kubernetes cluster in the prior art. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 A hardware structure block diagram of a mobile terminal for executing a data management method provided in an embodiment of the present application is shown;

[0018] Figure 2 A schematic diagram showing a flow chart of a data management method provided according to an embodiment of the present application;

[0019] Figure 3 A schematic diagram of a process of a pod_no management service provided according to an embodiment of the present application is shown;

[0020] Figure 4 A CSI plug-in interaction diagram provided according to an embodiment of the present application is shown;

[0021] Figure 5 A schematic diagram of pod inheritance provided according to an embodiment of the present application is shown;

[0022] Figure 6 A schematic diagram showing key matters of pod unbinding and releasing provided according to an embodiment of the present application is shown;

[0023] Figure 7 A schematic diagram showing a flow chart of another data management method provided according to an embodiment of the present application;

[0024] Figure 8 A schematic diagram of a process of a getMaxPodNo method provided according to an embodiment of the present application is shown;

[0025] Fig. 9 A schematic diagram of a pod update process provided according to an embodiment of the present application is shown;

[0026] Fig.10 A structural block diagram of a data management device provided according to an embodiment of the present application is shown.

[0027] The above drawings include the following reference numerals:

[0028] 102, processor; 104, memory; 106, transmission device; 108, input and output devices. DETAILED DESCRIPTION

[0029] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0030] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0031] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present application described here. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0032] For the convenience of description, some nouns or terms involved in the embodiments of the present application are explained below:

[0033] pod_no: A unique number assigned to each Pod, used to identify the Pod's data directory.

[0034] CSI: Kubernetes container storage interface, used to manage container storage mounts.

[0035] PersistentVolume (PV): Persistent volume, an abstraction representing storage in Kubernetes, is not bound to the life cycle.

[0036] PersistentVolumeClaim (PVC): declares the required PV resources and is bound to the Pod lifecycle.

[0037] Kubernetes: An open source platform for container orchestration and management.

[0038] Deployment: A Kubernetes resource object used to deploy and manage Pods.

[0039] Docker: The popular container runtime.

[0040] Containerd: A container runtime from the CNCF foundation.

[0041] Pod: The basic scheduling unit of Kubernetes, encapsulating the container.

[0042] Node: A working node in a Kubernetes cluster.

[0043] KubernetesServiceAccount: Account identification in Kubernetes.

[0044] Sidecar container: A secondary container deployed with the main container.

[0045] Kubelet: An agent running on a Node, responsible for the Pod lifecycle.

[0046] Cloud storage system: high-performance distributed object storage.

[0047] cloud-storage-go-client: A Go client library for accessing cloud-storage services.

[0048] Cloud storage system buckets: Buckets in the cloud storage system are used to store objects.

[0049] Cloud storage system objects: Objects stored in cloud storage system buckets.

[0050] Ceph: An open source distributed storage system that provides high performance, reliability, and scalability. It is a storage system designed to handle large amounts of data and supports object storage, block storage, and file systems.

[0051] CephOSD: ObjectStorageDaemon, stores data and handles data replication, recovery, backfill, and rebalancing.

[0052] ConfigMap: Kubernetes centralized configuration management object.

[0053] MutatingAdmissionWebhook: Admission control hook for Kubernetes.

[0054] Informer: Kubernetes client library for monitoring resource changes.

[0055] mount: Mount the storage to the file system.

[0056] umount: Unmount storage from the file system.

[0057] exec.Command: A library for executing commands in Go language.

[0058] envoyfilter: A resource object used to modify the Envoy proxy configuration.

[0059] As introduced in the background technology, in the prior art, there is data confusion between Pods of a Kubernetes cluster. To solve this technical problem, the embodiments of the present application provide a data management method, device, and data management platform.

[0060] The technical solutions in the embodiments of the present invention will be described clearly and completely below in conjunction with the accompanying drawings in the embodiments of the present invention.

[0061] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking running on a mobile terminal as an example, Figure 1 FIG. 1 is a hardware structure block diagram of a mobile terminal of a data management method according to an embodiment of the present invention. Figure 1 As shown, the mobile terminal may include one or more ( Figure 1 Only one is shown in the figure) a processor 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data, wherein the mobile terminal may also include a transmission device 106 and an input / output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the mobile terminal. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations shown.

[0062] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the Z method in the embodiment of the present invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, the above method is implemented. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof. The transmission device 106 is used to receive or send data via a network. The above-mentioned specific examples of the network may include a wireless network provided by a communication provider of the mobile terminal. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0063] In this embodiment, a method for managing data running on a mobile terminal, a computer terminal or a similar computing device is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0064] Figure 2 is a flow chart of a data management method according to an embodiment of the present application. Figure 2 As shown, the method comprises the following steps:

[0065] Step S201, assigning pod_no to the Pod of the Kubernetes cluster, so that the above Pod corresponds to the above pod_no one by one;

[0066] Step S202, using the CSI plug-in to create a storage bucket and a corresponding object key in the cloud storage system, where the object key is a directory structure of target path-pod_no-application data directory, the application data directory is index information of the storage bucket in the cloud storage system, and the target path is the path of the Kubernetes node of the Kubernetes cluster;

[0067] Step S203, mounting the storage bucket to the target path, and mounting the target path to the Pod;

[0068] Step S204, storing the application data of the Pod in the storage bucket corresponding to the Pod, so that the container of the Pod can access the application data stored in the storage bucket corresponding to the Pod according to the object key corresponding to the pod_no.

[0069] In the above data management method, by assigning a unique pod_no to the Pod of the Kubernetes cluster and using the CSI plug-in to create a storage bucket and a corresponding object key in the cloud storage system, the Pod can be bound to the storage bucket corresponding to its pod_no by mounting the storage bucket to the above target path and mounting the target path to the Pod. By storing the application data of the Pod in the storage bucket corresponding to the Pod, persistent storage of the application data of the Pod can be achieved. The container of the Pod can access the application data stored in the storage bucket corresponding to the Pod according to the object key corresponding to the pod_no, providing an independent storage directory for each Pod to avoid data confusion, thereby solving the problem of data confusion between Pods of the Kubernetes cluster in the prior art.

[0070] In order to ensure that the pod_no allocated to the Pod is unique, in an optional implementation manner, the above step S201 includes:

[0071] Step S2011, obtaining a request for obtaining pod_no of the target Pod, the request including the IP and Pod name of the target Pod, the target Pod being any Pod of the Pod of the Kubernetes cluster;

[0072] Step S2012, when the requested IP has been used and the requested Pod name has not changed, obtain the pod_no corresponding to the IP and assign it to the target Pod;

[0073] Step S2013, when the requested IP has been used and the requested Pod name has changed, unbinding the requested IP from the corresponding pod_no, and obtaining a new pod_no to assign to the target Pod;

[0074] Step S2014, when the requested IP has not been used, obtain the new pod_no and assign it to the target Pod.

[0075] In the above implementation, the pod_no management service is responsible for the dynamic allocation and recovery of pod_no. pod_no is a unique integer number in the application (deployment) assigned to the service (pod) by the pod management service, and it increases sequentially from 0. When the pod is restarted, the original number will be inherited, and it is used to identify a Pod's directory in the shared storage. The pod_no management service is tightly integrated with the scheduling and management system of the Kubernetes cluster, and can automatically respond to the creation, deletion and update events of the Pod to realize the dynamic allocation and recovery of pod_no. Through the pod_no management service, the present invention realizes the independence of data between Pods.

[0076] Specifically, Figure 3 As shown in the figure, the key designs of the pod_no management service are described as follows:

[0077] 1) The request to obtain pod_no first reaches envoy, which directs the traffic to the main pod management service.

[0078] 2) When the request to get pod_no reaches the main pod management service, the Pod Management Service first checks whether the requested IP is already in use.

[0079] 3) If the IP is already in use, you need to determine whether the Pod name has changed:

[0080] a. If the Pod name changes, unbind the old data and rebind it. The new Pod will get a new pod_no from the table and return it.

[0081] b. If the Pod name has not changed, directly query the database for the pod_no associated with the Pod name and return it.

[0082] 4) If the IP has not been used, the Pod Management Service will try to obtain an available pod_no.

[0083] In order to achieve the reuse of pod_no, in an optional implementation manner, the above step S2014 includes:

[0084] Step S20141, when there is an available pod_no in the existing pod_no, the smallest available pod_no is allocated to the target Pod, and the available pod_no is the unbound pod_no;

[0085] Step S20142: if there is no available pod_no in the existing pod_no, create one pod_no and assign it to the target Pod. The creation rule of the pod_no is to create from small to large.

[0086] In the above implementation, if the IP has not been used, the Pod management service will try to obtain an available pod_no. a. First, execute the UPDATE statement to try to bind the Pod to the record with the smallest available pod_no. b. If the UPDATE operation returns a record, it means that the binding is successful. In this case, it is necessary to check whether the pod_no is only in the unbinding state but has not been released. The reason may be that the old Pod has not completely exited and still occupies the pod_no. If this is the case, a failure should be returned to the CSI client, allowing the CSI to try to obtain the pod_no again after 2 seconds. If the resources are released, it will be obtained directly. If it has not been obtained for more than 2 minutes, considering that the forced offline time is 30 seconds. c. If the UPDATE operation does not return any records, it means that there is no available pod_no. At this time, a new pod_no can be assigned to the new Pod and returned by executing the INSERT statement.

[0087] In order to implement the Controller service, in an optional implementation, the above step S202 includes:

[0088] Step S2021, when the new pod_no is obtained and assigned to the target Pod, the Controller service of the CSI plug-in is used to create the new storage bucket and the object key corresponding to the pod_no in the cloud storage system.

[0089] In the above implementation, a custom CSI plug-in is used to automatically mount shared storage. This plug-in can create an independent directory for each Pod under the storage bucket of the cloud storage system (such as: cloud storage system, Ceph) according to pod_no, so as to achieve data isolation between Pods. At the same time, the plug-in is tightly integrated into the scheduling and management system of the Kubernetes cluster, and can automatically respond to Pod life cycle events such as creation, deletion and update. In this way, the cloud storage system is used as the backend persistent storage, and an independent storage directory is provided for each Pod, so that the new pod can reuse the data of the old pod. Figure 4 As shown, the Controller service interacts with the cloud storage system server through the cloud storage system client library to perform operations such as creating cloud storage system buckets and objects. Specifically, the Controller interface is one of the core components of the custom CSI plug-in, and its main responsibility is to handle operations related to cloud storage system buckets. In order to implement this service, in the relevant methods such as CreateVolume, DeleteVolume, and ListVolumes in the CSI interface, interaction with the pod_no management service is implemented to obtain and release the pod_no number, and the cloud storage system client library is used to communicate with the cloud storage system server to perform bucket and object key operations, such as creating, deleting, and listing buckets, and using slashes (` / `) in object keys to simulate directory structures. The URL address of the pod management service is passed to the environment variables of the CSI interface through configmap, and the CSI interface then obtains the pod management service address from the environment variables. When Kubernetes needs to prepare a volume for a new Pod, it obtains the pod_no number from the pod management service. And call CreateVolume according to the pod_no number to create a new storage bucket and object key on the cloud storage system. When Kubernetes needs to restart the Pod, it will delete the old pod and start the new pod. When the old pod is deleted, the binding relationship between pod_no, pod and storage volume will be released, and the new pod will reuse the pod_no number of the old pod. After the new pod obtains the pod_no number, it will call CreateVolume to reuse the object key (path) of the storage bucket of the old pod on the cloud storage system.

[0090] In order to implement the Node service, in an optional implementation, the above step S203 includes:

[0091] Step S2031, using the Node service of the CSI plug-in to mount the storage bucket to the target path, and map the target path to the inside of the container of the Pod.

[0092] In the above implementation, if Figure 4 As shown in the figure, after defining Volume and VolumeMount in the Deployment or Pod configuration file, the Node service will mount the cloud storage system bucket to the host target path through the mount command on the host when receiving the mount request. Then, the CSI plug-in mounts this host target path to the KubernetesPod, and the unmounting process is similar to the mounting process. In this way, the container runtime will map the mount point on the host to the inside of the container, so that the container can access the files in the cloud storage system bucket. Specifically, the Node interface is another core component, which is mainly responsible for performing operations related to goofys mounting and unmounting on the Kubernetes node. In order to implement this service, we use the exec.Command method in the NodePublishVolume method to execute commands such as goofys and mount to mount the cloud storage system bucket to the target path on the node, and then use the goofys and umount unmounting commands in the NodeUnpublishVolume method to unmount it. When the container is running (such as Docker or containerd), the mount point on the host is mapped to the inside of the container, so that the container can access files in the cloud storage system bucket.

[0093] It should be noted that since the stateless Pods under the same Deployment have the same properties and may drift, traditional solutions cannot guarantee data sharing between new and old Pods, which affects application continuity. To solve this pain point, this solution uses volume mounting technology to enable new Pods to reuse the data volumes of old Pods (the storage bucket includes at least one data volume) to ensure seamless takeover of the old Pod's data. At the same time, this solution makes full use of the high availability and distributed characteristics of the cloud storage system's object storage to persist Pod data in the cloud storage system, further enhancing data persistence and reliability.

[0094] like Figure 5 As shown, the specific implementation process of Pod data inheritance is as follows:

[0095] 1) Pod_no management: When a new Pod is created, the pod_no management service assigns a unique pod_no to the new Pod. When an old Pod is deleted, its pod_no is not deleted directly, but released so that the new Pod can reuse the pod_no.

[0096] 2) Cloud Storage System Bucket and Object Creation: When a new Pod is created, the Controller service of the CSI plugin uses pod_no to create a new object key in the cloud storage system bucket, forming a directory structure of `{mount_patch}-{pod_no}-{application data directory}`. The object key here is actually a file in the cloud storage system bucket, but we simulate the directory structure by using slashes (` / `) in the object key.

[0097] 3) Data inheritance: When the old Pod is deleted and replaced by a new Pod, the pod_no of the old Pod will be released and assigned to the new Pod, while the data associated with the old Pod in the cloud storage system bucket will not be deleted. In this way, the new Pod can use this pod_no to access the same path as the old Pod in the cloud storage system bucket, thereby achieving data inheritance. If you need to delete data on the cloud storage system, this needs to be done manually by the administrator.

[0098] 4) Data access: In order to allow applications in Pod to access data in the cloud storage system bucket, the Node service of the CSI plug-in will execute the goofys command on the Kubernetes node to mount the directory corresponding to pod_no in the cloud storage system bucket to the target path of the node. Then, the CSI plug-in will map the mount point on the host to the Kubernetes Pod. In this way, applications in the Pod can continue to access the generated files in the cloud storage system bucket just like accessing local files.

[0099] In order to achieve unbinding and releasing, in an optional implementation manner, after storing the application data of the Pod in the storage bucket corresponding to the Pod, the method further includes:

[0100] Step S301, when the Pod needs to be shut down gracefully, unbinding the Pod from the application data in the storage bucket, and deleting the Pod;

[0101] Step S302: when it is detected that the Pod is shut down ungracefully, unbinding the Pod from the application data in the storage bucket.

[0102] In the above implementation, a custom CSI plug-in is used to automate the mounting, unbinding, and releasing of storage resources in the Pod lifecycle management. To enhance this mechanism, we prefer the CSI solution to ensure that shared storage can correctly release resources through standardized interfaces when the Pod is deleted or updated. Figure 6As shown in the figure, several key items are listed in order. The design of the event will be introduced in detail below: 1) CSI plug-in triggers the start event: After receiving the pod start request, call the pod_no service to obtain pod_no, and call the cloud storage system service to obtain the bucket and shared directory. 2) MutatingAdmissionWebhook triggers the unbinding event: triggers the custom logic when the normal Pod is deleted, calls the Pod number management service to unbind the Pod number, and triggers the CSI plug-in to release the storage resources, and calls the Pod number management service to unbind the number. 3) CSI plug-in triggers the release event: After receiving the release request, automatically unmount the shared storage mounted by the Pod, release the storage resources, and call the Pod number management service to release the number. 4) Informer service triggers the termination event: listens to the Pod termination event, and can also trigger the release process in non-elegant shutdown situations such as unexpected host downtime and network interruption, and calls the Pod number management service to release the number.

[0103] As a supplementary solution, we also considered using the init and preStop events of KubernetesDeployment and external Sidecar containers in specific scenarios such as insufficient permissions. This approach allows us to handle Pod lifecycle events, including mounting storage, unbinding, and releasing resources, without using CSI plugins. Although this may require additional resources and management work, it provides an alternative solution to ensure the flexibility and maintainability of the system in special cases where the CSI solution is not applicable.

[0104] In order to achieve unbinding, in an optional implementation, the above step S301 includes:

[0105] Step S3011, using the Node service of the CSI plug-in to uninstall the storage bucket from the target path, and delete the target path from the container of the Pod to release the binding of the Pod with the application data of the storage bucket.

[0106] In the above implementation, the uninstallation is performed in a manner similar to the mounting, so as to release the binding between the Pod and the application data in the storage bucket.

[0107] In order to implement the mounting and management of shared storage, in an optional implementation manner, after storing the application data of the Pod in the storage bucket corresponding to the Pod, the method further includes:

[0108] Step S401, setting a PersistentVolume and a PersistentVolumeClaim, wherein the PersistentVolumeClaim is used to request storage resources of the PersistentVolume;

[0109] Step S402, mount the above-mentioned PersistentVolumeClaim to the above-mentioned target path corresponding to the above-mentioned Pod, so that the container of the above-mentioned Pod can access the data of the above-mentioned PersistentVolume and use the storage resources of the above-mentioned PersistentVolume.

[0110] In the above implementation, the corresponding storage resources are created in the Kubernetes cluster. This process includes pre-configuring a PersistentVolume (PV) and specifying that the PV uses a custom CSI plug-in as the storage driver. Next, the corresponding storage resources are requested by creating a PersistentVolumeClaim (PVC). In the Pod's configuration file, we declare the use of the PVC and mount it to the specified path of the Pod. In this way, the Pod can access and use shared storage resources through this path.

[0111] In order to enable those skilled in the art to more clearly understand the technical solution of the present application, the implementation process of the data management method of the present application will be described in detail below in conjunction with specific embodiments.

[0112] This embodiment relates to a specific data management method, including the following steps:

[0113] Phase 1: Preparation, such as Figure 7 As shown, including:

[0114] (1) Implement a custom CSI plug-in:

[0115] The CSI plug-in is mainly used to apply for and release pod_no, and synchronize the use of pv / pvc to the shared block of the cloud storage system. To achieve this goal, the key design of the CSI plug-in is to implement the Controller service and the Node service. The Controller service is responsible for managing persistent volumes at the cluster level, while the Node service is responsible for operating persistent volumes at the node level. The collaboration between the two enables the CSI plug-in to effectively manage and operate persistent volume resources. The specific implementation is as follows:

[0116] 1. Implement Controller service:

[0117] Use a cloud storage system client library (such as cloud storage system-go) to communicate with the cloud storage system server and perform bucket operations (such as creating, deleting, and listing buckets).

[0118] The specific implementation method is as follows:

[0119] 1) In the CreateVolume method, we use the cloud storage system SDK to create a new bucket. We initialize a cloud storage system client and then use this client to create a new bucket in the specified location.

[0120] 2) In the DeleteVolume method, we use the cloud storage system SDK to delete the specified bucket. We initialize a cloud storage system client and then use this client to delete the specified bucket.

[0121] 3) In the getMaxPodNo method, we use the following steps to obtain the Pod number from the Pod Number Management Service via HTTPS.

[0122] like Figure 8 As shown in the figure, the main implementation content of the getMaxPodNo method is introduced, which will be explained in detail below:

[0123] ① The deployer stores the Pod number management service address in ConfigMap. The csi plug-in obtains the ConfigMap through environment variables and obtains the Pod number management service address from it.

[0124] ②Multiple instance addresses of the Pod number management service are configured in ConfigMap, divided into four groups by "|", and each group is further divided into multiple instance addresses by "#". The four groups represent instances in the same cluster, the same center, the same city, and different locations respectively.

[0125] ③ When obtaining the Pod number, we first obtain the group information in sequence, randomly obtain the address in the group, first detect whether the address is reachable, and then detect readiness. If the instance is unreachable or not ready, skip the address and continue to detect the next address. If all instances are unavailable, a retry mechanism is used, and sleep retries are performed at exponentially increasing time intervals to avoid too frequent requests.

[0126] ④ For the ready instance, we further determine its primary and backup roles. If it is a backup instance, we continue to try the next instance in the group until an available primary instance is found. The four groups of instance addresses are configured with different weights. The weight ratio of the cluster, the same center, the same city, and the remote location is 3:2:1:1. The polling order is from high to low according to the weight. The overall retry and sleep mechanism is adopted to ensure the successful acquisition of the Pod number.

[0127] 4) In the releasePodNo method, we use https request to unbind the pod_no number from the pod management service. The parameter acquisition method is basically the same as the method of accessing the pod management service.

[0128] 2. Implement Node service:

[0129] In the NodePublishVolume method, use the goofys command to mount the cloud storage system bucket to the target path on the node. In the NodeUnpublishVolume method, use the goofys uninstall command to uninstall the cloud storage system bucket from the target path on the node. In the container runtime (such as Docker or containerd), map the mount point on the host to the container so that the container can access the files in the cloud storage system bucket.

[0130] The specific implementation method is as follows:

[0131] In the NodePublishVolume method, we construct a goofys mount command. We get the target path and then use the goofys mount command to mount the bucket to this target path.

[0132] In the NodeUnpublishVolume method, we construct an unmount command. We obtain the target path and then use the Unix umount command to unmount the bucket from this target path.

[0133] 3. Write the plug-in configuration file:

[0134] The configuration file is mainly written to deploy our CSI plug-in in the Kubernetes cluster. The resources that need to be included are the Deployment and DaemonSet of the CSI plug-in, which are used to deploy the Controller service and the Node service respectively.

[0135] In the configuration file, a ServiceAccount with permissions is set, the appropriate container name and image path are configured, and parameters are set to start the Controller service. At the same time, environment variables and mount paths are set to ensure that the CSI plugin can run properly. The configuration method of this part is basically the same as the configuration method of the ceph-csi plugin.

[0136] (2) Deploy a custom CSI plug-in:

[0137] Deploy the CSI plug-in in the Kubernetes cluster, and the number of deployed CSI plug-in services is not less than 2. After the deployment is complete, the custom CSI plug-in will run as an independent service in the cluster, responsible for processing shared storage mount and unmount requests.

[0138] (3) Implement Pod number management service:

[0139] The next step is to deploy the Pod Number Management Service. We need to deploy the Pod Number Management Service in the Kubernetes environment of the main cluster, the same-center main cluster, the same-city backup cluster, and the remote backup cluster. After the deployment is complete, the address information of these services needs to be synchronized to ConfigMap for the convenience of the Pod Number Client. Once deployed, the Pod Number Management Service will run independently in the cluster and will be responsible for allocating and reclaiming Pod Number requests. This service has three main functions:

[0140] 1. Implement the Pod number management function: The envoyfilter of the Pod number management service first receives the request and then forwards it to the Pod number master service with the smallest available number. This step implements the acquisition and release of the Pod number sequence pool, as well as the synchronization of the Pod number sequence pool and the allocation table data. In this process, the principle of obtaining the Pod number is to use the smallest sequence number as the basis and ensure that there is no duplication.

[0141] 2. Graceful shutdown of application service processing function: When shutting down the service normally, we add a MutatingAdmissionWebhook hook to the Pod's namespace. When the Pod needs to be shut down gracefully, the hook will be triggered and our custom unbinding logic will be executed. The processing function decodes the Pod object from the request. If the decoding fails, the function returns an error response. If successful, the function checks the DeletionTimestamp field of the Pod object. If this field is not empty, it means that the Pod is being deleted. We will execute the cleanup or unbinding logic and call the unbinding function of the Pod number management service. Finally, regardless of whether the unbinding operation is performed, the processing function will return a response that allows the Pod to be deleted.

[0142] 3. Non-elegant shutdown of application services: In the event of abnormal shutdown of application services, we set up a KubernetesInformer service to listen for Pod deletion events. When the Informer service detects Pod deletion events, it performs corresponding operations based on these events. We added a processor to the Informer service that specifically handles Pod deletion events. When a Pod is deleted, the deletion event processor receives the deletion event. When processing this event, we will notify the Pod number management service to perform the unbinding operation. In this way, no matter what shutdown scenario, our CSI plug-in can maintain normal operation.

[0143] (4) Create and use shared storage:

[0144] In order to mount and manage shared storage, we created the corresponding storage resources in the Kubernetes cluster. This process includes pre-configuring a PersistentVolume (PV) and specifying that the PV uses a custom CSI plug-in as the storage driver. Next, request the corresponding storage resources by creating a PersistentVolumeClaim (PVC). In the Pod's configuration file, we declare the use of the PVC and mount it to the specified path of the Pod. In this way, the Pod can access and use shared storage resources through this path.

[0145] Phase 2: Creating and using shared storage and authorization includes:

[0146] 1. The administrator creates a storage class (StorageClass): The storage class defines the storage allocator (custom CSI plug-in) used to create PV. The storage class should include other parameters, such as the ID of the cloud storage system cluster, the name of the cloud storage system bucket, etc.

[0147] 2. The administrator creates an authorization object (ServiceAccount): grants permissions to the MutatingAdmissionWebhook, custom CSI plug-in, and API server that creates PV / PVC.

[0148] 3. User creates PVC: Users specify the storage capacity and access mode they need in PVC, and may specify a storage class. If PVC specifies a storage class, Kubernetes uses the storage allocator of this storage class to create a new PV to meet the request of this PVC (i.e. dynamic storage allocation).

[0149] 4. The user uses PVC in the Pod configuration: The user specifies the use of PVC in the Pod configuration file. Kubernetes will ensure that the Pod runs on a node that can access the corresponding PV and mount the PV to the Pod.

[0150] Phase 3: Pod creation process includes:

[0151] 1. The Kubernetes cluster receives a request to create a Pod. The cluster scheduler selects a suitable node to run the Pod based on the Pod's resource requirements and the cluster's resource status. On the selected node, the Kubelet component creates a container based on the Pod's configuration file.

[0152] 2. Before the pod service is started, Kubelet will call the CSI plug-in. The CSI plug-in requests an available pod_no from the pod_no sequence pool of the pod_no management service and records it in the pod_no sequence pool and allocation table of the pod_no management service.

[0153] 3. The CSI plug-in creates a separate directory for the Pod in the shared storage based on pod_no and mounts it to the specified location of the Pod.

[0154] 4. After the container is created, Kubelet starts the container and adds it to the Pod.

[0155] Phase 4: Pod update process, such as Fig. 9 As shown, specifically including:

[0156] 1. Pod update is completed by deletion and creation. Before the Pod service is deleted, MutatingAdmissionWebhook receives the deletion request from the api-server. MutatingAdmissionWebhook initiates the unbinding function of the pod management service. The unbinding function also includes changing the pod_no status and filling in the detention time. At this time, the pod_no number can only be occupied but cannot be used.

[0157] 2. The Kubernetes cluster receives a request to update the Pod. The cluster scheduler determines the Pod that needs to be updated based on the Pod configuration file and the cluster's resource status. On the selected node, the Kubelet component is responsible for pulling up the new Pod.

[0158] 3. When the new pod is started, the CSI plug-in applies for the pod_no number from the pod management service. The pod management service registers the pod_no number to the new pod and modifies the detention time and IP address of the pod_no number. However, the pod_no number is not sent down. Instead, the re-retrieval information is returned, requiring the pod_no number to be re-applied every 2 seconds.

[0159] 4. The CSI plug-in uninstalls the shared storage according to the pod_no of the old Pod and releases the corresponding pod_no back to the system. At this time, the data generated by the old pod is still retained in the shared storage directory and can be found through pod_no.

[0160] 5. The CSI plug-in submits the pod_no number of the old Pod to the pod_no management service, requesting the release of pod_no.

[0161] 6. The pod management service releases the pod_no. At this time, the pod management service will clear the detention time and retain the IP in the allocation table, and send the pod_no number to the CSI plug-in of the new pod.

[0162] 7. After the CSI plug-in obtains the pod_no number, it generates a data directory path based on the pod_no number. The data of the old pod is stored under this directory path, and the data inheritance function is realized by reusing the shared directory path.

[0163] 8. After the container is created, Kubelet starts the container and adds it to the new Pod.

[0164] Phase 5: Pod deletion process:

[0165] 1. MutatingAdmissionWebhook monitors the deletion event of api-server. After receiving the deletion event, MutatingAdmissionWebhook calls the unbinding function of the pod management service.

[0166] 2. The Kubernetes cluster receives a request to delete the Pod.

[0167] 3. Kubelet sends a request to the CSI plug-in to unload the shared storage.

[0168] 4. The CSI plug-in uninstalls the shared storage according to pod_no and releases the corresponding resources back to the system.

[0169] 5. The CSI plug-in returns the Pod's pod_no to the pod_no management service, requesting the release of the pod_no.

[0170] 6. The pod_no management service removes the recycled pod_no from the allocation table and adds it to the available pod_no sequence pool.

[0171] It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and that, although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0172] The present application embodiment also provides a kind of data management device, it should be noted that the data management device of the present application embodiment can be used to execute the management method for data provided by the present application embodiment. The device is used to implement the above-mentioned embodiment and preferred implementation mode, and the description has been made no further details. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the device described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware is also possible and conceived.

[0173] The following is an introduction to the data management device provided in the embodiment of the present application.

[0174] Fig.10 is a structural block diagram of a data management device according to an embodiment of the present application. Fig.10 As shown, the device comprises:

[0175] An allocating unit 10 is used to allocate pod_no to the Pod of the Kubernetes cluster, so that the Pod corresponds to the pod_no one by one;

[0176] A creation unit 20 is used to create a storage bucket and a corresponding object key in the cloud storage system by using a CSI plug-in, wherein the object key is a directory structure of a target path-pod_no-application data directory, the application data directory is index information of the storage bucket in the cloud storage system, and the target path is a path of a Kubernetes node of the Kubernetes cluster;

[0177] A first mounting unit 30 is used to mount the storage bucket to the target path, and to mount the target path to the Pod;

[0178] The storage unit 40 is used to store the application data of the Pod through the storage bucket corresponding to the Pod, so that the container of the Pod can access the application data stored in the storage bucket corresponding to the Pod according to the object key corresponding to the pod_no.

[0179] In the above data management device, by assigning a unique pod_no to the Pod of the Kubernetes cluster and using the CSI plug-in to create a storage bucket and a corresponding object key in the cloud storage system, the Pod can be bound to the storage bucket corresponding to its pod_no by mounting the storage bucket to the above target path and mounting the target path to the Pod. By storing the application data of the Pod in the storage bucket corresponding to the Pod, persistent storage of the application data of the Pod can be achieved. The container of the Pod can access the application data stored in the storage bucket corresponding to the Pod according to the object key corresponding to the pod_no, providing an independent storage directory for each Pod to avoid data confusion, thereby solving the problem of data confusion between Pods of the Kubernetes cluster in the prior art.

[0180] In order to ensure that the pod_no allocated to the Pod is unique, in an optional implementation manner, the allocation unit includes:

[0181] The first acquisition module is used to obtain a request for obtaining pod_no of the target Pod, wherein the request includes the IP address and Pod name of the target Pod, and the target Pod is any Pod of the Pod of the Kubernetes cluster;

[0182] The second acquisition module is used to obtain the pod_no corresponding to the IP and assign it to the target Pod when the requested IP has been used and the requested Pod name has not changed;

[0183] The third module is used to release the binding between the requested IP and the corresponding pod_no when the requested IP has been used and the requested Pod name has changed, and obtain the new pod_no to be assigned to the target Pod;

[0184] The fourth acquisition module is used to obtain the new pod_no and assign it to the target Pod when the requested IP has not been used.

[0185] In the above implementation, the pod_no management service is responsible for the dynamic allocation and recovery of pod_no. pod_no is a unique integer number in the application (deployment) assigned to the service (pod) by the pod management service, and it increases sequentially from 0. When the pod is restarted, the original number will be inherited, and it is used to identify a Pod's directory in the shared storage. The pod_no management service is tightly integrated with the scheduling and management system of the Kubernetes cluster, and can automatically respond to the creation, deletion and update events of the Pod to realize the dynamic allocation and recovery of pod_no. Through the pod_no management service, the present invention realizes the independence of data between Pods.

[0186] Specifically, Figure 3 As shown in the figure, the key designs of the pod_no management service are described as follows:

[0187] 1) The request to obtain pod_no first reaches envoy, which directs the traffic to the main pod management service.

[0188] 2) When the request to get pod_no reaches the main pod management service, the Pod Management Service first checks whether the requested IP is already in use.

[0189] 3) If the IP is already in use, you need to determine whether the Pod name has changed:

[0190] a. If the Pod name changes, unbind the old data and rebind it. The new Pod will get a new pod_no from the table and return it.

[0191] b. If the Pod name has not changed, directly query the database for the pod_no associated with the Pod name and return it.

[0192] 4) If the IP has not been used, the Pod Management Service will try to obtain an available pod_no.

[0193] In order to achieve the reuse of pod_no, in an optional implementation manner, the fourth acquisition module includes:

[0194] A first allocation submodule is used to allocate the smallest available pod_no to the target Pod when there is an available pod_no in the existing pod_no, where the available pod_no is the unbound pod_no;

[0195] The second allocation submodule is used for creating a pod_no and allocating it to the target Pod if there is no available pod_no in the existing pod_no. The creation rule of the pod_no is to create it from small to large.

[0196] In the above implementation, if the IP has not been used, the Pod management service will try to obtain an available pod_no. a. First, execute the UPDATE statement to try to bind the Pod to the record with the smallest available pod_no. b. If the UPDATE operation returns a record, it means that the binding is successful. In this case, it is necessary to check whether the pod_no is only in the unbinding state but has not been released. The reason may be that the old Pod has not completely exited and still occupies the pod_no. If this is the case, a failure should be returned to the CSI client, allowing the CSI to try to obtain the pod_no again after 2 seconds. If the resources are released, it will be obtained directly. If it has not been obtained for more than 2 minutes, considering that the forced offline time is 30 seconds. c. If the UPDATE operation does not return any records, it means that there is no available pod_no. At this time, a new pod_no can be assigned to the new Pod and returned by executing the INSERT statement.

[0197] In order to implement the Controller service, in an optional implementation, the creation unit includes:

[0198] A creation module is used to, when obtaining the new pod_no assigned to the target Pod, use the Controller service of the CSI plug-in to create the new storage bucket and the object key corresponding to the pod_no in the cloud storage system.

[0199] In the above implementation, a custom CSI plug-in is used to automatically mount shared storage. This plug-in can create an independent directory for each Pod under the storage bucket of the cloud storage system (such as: cloud storage system, Ceph) according to pod_no, so as to achieve data isolation between Pods. At the same time, the plug-in is tightly integrated into the scheduling and management system of the Kubernetes cluster, and can automatically respond to Pod life cycle events such as creation, deletion and update. In this way, the cloud storage system is used as the backend persistent storage, and an independent storage directory is provided for each Pod, so that the new pod can reuse the data of the old pod. Figure 4As shown, the Controller service interacts with the cloud storage system server through the cloud storage system client library to perform operations such as creating cloud storage system buckets and objects. Specifically, the Controller interface is one of the core components of the custom CSI plug-in, and its main responsibility is to handle operations related to cloud storage system buckets. In order to implement this service, in the relevant methods such as CreateVolume, DeleteVolume, and ListVolumes in the CSI interface, interaction with the pod_no management service is implemented to obtain and release the pod_no number, and the cloud storage system client library is used to communicate with the cloud storage system server to perform bucket and object key operations, such as creating, deleting, and listing buckets, and using slashes (` / `) in object keys to simulate directory structures. The URL address of the pod management service is passed to the environment variables of the CSI interface through configmap, and the CSI interface then obtains the pod management service address from the environment variables. When Kubernetes needs to prepare a volume for a new Pod, it obtains the pod_no number from the pod management service. And call CreateVolume according to the pod_no number to create a new storage bucket and object key on the cloud storage system. When Kubernetes needs to restart the Pod, it will delete the old pod and start the new pod. When the old pod is deleted, the binding relationship between pod_no, pod and storage volume will be released, and the new pod will reuse the pod_no number of the old pod. After the new pod obtains the pod_no number, it will call CreateVolume to reuse the object key (path) of the storage bucket of the old pod on the cloud storage system.

[0200] In order to implement the Node service, in an optional implementation manner, the first mounting unit includes:

[0201] The mounting module is used to use the Node service of the CSI plug-in to mount the storage bucket to the target path and map the target path to the container of the Pod.

[0202] In the above implementation, if Figure 4As shown in the figure, after defining Volume and VolumeMount in the Deployment or Pod configuration file, the Node service will mount the cloud storage system bucket to the host target path through the mount command on the host when receiving the mount request. Then, the CSI plug-in mounts this host target path to the KubernetesPod, and the unmounting process is similar to the mounting process. In this way, the container runtime will map the mount point on the host to the inside of the container, so that the container can access the files in the cloud storage system bucket. Specifically, the Node interface is another core component, which is mainly responsible for performing operations related to goofys mounting and unmounting on the Kubernetes node. In order to implement this service, we use the exec.Command method in the NodePublishVolume method to execute commands such as goofys and mount to mount the cloud storage system bucket to the target path on the node, and then use the goofys and umount unmounting commands in the NodeUnpublishVolume method to unmount it. When the container is running (such as Docker or containerd), the mount point on the host is mapped to the inside of the container, so that the container can access files in the cloud storage system bucket.

[0203] It should be noted that since the stateless Pods under the same Deployment have the same properties and may drift, traditional solutions cannot guarantee data sharing between new and old Pods, which affects application continuity. To solve this pain point, this solution uses volume mounting technology to enable new Pods to reuse the data volumes of old Pods (the storage bucket includes at least one data volume) to ensure seamless takeover of the old Pod's data. At the same time, this solution makes full use of the high availability and distributed characteristics of the cloud storage system's object storage to persist Pod data in the cloud storage system, further enhancing data persistence and reliability.

[0204] like Figure 5 As shown, the specific implementation process of Pod data inheritance is as follows:

[0205] 1) Pod_no management: When a new Pod is created, the pod_no management service assigns a unique pod_no to the new Pod. When an old Pod is deleted, its pod_no is not deleted directly, but released so that the new Pod can reuse the pod_no.

[0206] 2) Cloud Storage System Bucket and Object Creation: When a new Pod is created, the Controller service of the CSI plugin uses pod_no to create a new object key in the cloud storage system bucket, forming a directory structure of `{mount_patch}-{pod_no}-{application data directory}`. The object key here is actually a file in the cloud storage system bucket, but we simulate the directory structure by using slashes (` / `) in the object key.

[0207] 3) Data inheritance: When the old Pod is deleted and replaced by a new Pod, the pod_no of the old Pod will be released and assigned to the new Pod, while the data associated with the old Pod in the cloud storage system bucket will not be deleted. In this way, the new Pod can use this pod_no to access the same path as the old Pod in the cloud storage system bucket, thereby achieving data inheritance. If you need to delete data on the cloud storage system, this needs to be done manually by the administrator.

[0208] 4) Data access: In order to allow applications in Pod to access data in the cloud storage system bucket, the Node service of the CSI plug-in will execute the goofys command on the Kubernetes node to mount the directory corresponding to pod_no in the cloud storage system bucket to the target path of the node. Then, the CSI plug-in will map the mount point on the host to the Kubernetes Pod. In this way, applications in the Pod can continue to access the generated files in the cloud storage system bucket just like accessing local files.

[0209] In order to achieve unbinding and releasing, in an optional implementation manner, the above device further includes:

[0210] A first releasing unit is used for, after storing the application data of the Pod in the storage bucket corresponding to the Pod, releasing the binding between the Pod and the application data in the storage bucket when the Pod needs to be shut down gracefully, and deleting the Pod;

[0211] The second releasing unit is used to release the binding between the Pod and the application data in the storage bucket when it is detected that the Pod is non-gracefully closed.

[0212] In the above implementation, a custom CSI plug-in is used to automate the mounting, unbinding, and releasing of storage resources in the Pod lifecycle management. To enhance this mechanism, we prefer the CSI solution to ensure that shared storage can correctly release resources through standardized interfaces when the Pod is deleted or updated. Figure 6As shown in the figure, several key items are listed in order. The design of the event will be introduced in detail below: 1) CSI plug-in triggers the start event: After receiving the pod start request, call the pod_no service to obtain pod_no, and call the cloud storage system service to obtain the bucket and shared directory. 2) MutatingAdmissionWebhook triggers the unbinding event: triggers the custom logic when the normal Pod is deleted, calls the Pod number management service to unbind the Pod number, and triggers the CSI plug-in to release the storage resources, and calls the Pod number management service to unbind the number. 3) CSI plug-in triggers the release event: After receiving the release request, automatically unmount the shared storage mounted by the Pod, release the storage resources, and call the Pod number management service to release the number. 4) Informer service triggers the termination event: listens to the Pod termination event, and can also trigger the release process in non-elegant shutdown situations such as unexpected host downtime and network interruption, and calls the Pod number management service to release the number.

[0213] As a supplementary solution, we also considered using the init and preStop events of KubernetesDeployment and external Sidecar containers in specific scenarios such as insufficient permissions. This approach allows us to handle Pod lifecycle events, including mounting storage, unbinding, and releasing resources, without using CSI plugins. Although this may require additional resources and management work, it provides an alternative solution to ensure the flexibility and maintainability of the system in special cases where the CSI solution is not applicable.

[0214] In order to achieve unbinding, in an optional implementation manner, the first unbinding unit includes:

[0215] An uninstallation module is used to uninstall the storage bucket from the target path using the Node service of the CSI plug-in, and delete the target path from the container of the Pod to release the binding of the Pod and the application data of the storage bucket.

[0216] In the above implementation, the uninstallation is performed in a manner similar to the mounting, so as to release the binding between the Pod and the application data in the storage bucket.

[0217] In order to realize the mounting and management of shared storage, in an optional implementation manner, the above-mentioned device further includes:

[0218] A setting unit is used to set a PersistentVolume and a PersistentVolumeClaim after storing the application data of the Pod in the storage bucket corresponding to the Pod, wherein the PersistentVolumeClaim is used to request storage resources of the PersistentVolume;

[0219] The second mounting unit is used to mount the above-mentioned PersistentVolumeClaim to the above-mentioned target path corresponding to the above-mentioned Pod, so that the container of the above-mentioned Pod can access the data of the above-mentioned PersistentVolume and use the storage resources of the above-mentioned PersistentVolume.

[0220] In the above implementation, the corresponding storage resources are created in the Kubernetes cluster. This process includes pre-configuring a PersistentVolume (PV) and specifying that the PV uses a custom CSI plug-in as the storage driver. Next, the corresponding storage resources are requested by creating a PersistentVolumeClaim (PVC). In the Pod's configuration file, we declare the use of the PVC and mount it to the specified path of the Pod. In this way, the Pod can access and use shared storage resources through this path.

[0221] The data management device includes a processor and a memory. The allocation unit, creation unit, first mounting unit and storage unit are stored in the memory as program units, and the processor executes the program units stored in the memory to implement corresponding functions. The modules are all located in the same processor; or, the modules are located in different processors in any combination.

[0222] The processor includes a kernel, which retrieves the corresponding program unit from the memory. One or more kernels can be set to solve the problem of data confusion between Pods in the Kubernetes cluster in the prior art by adjusting kernel parameters.

[0223] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0224] An embodiment of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium includes a stored program, wherein when the program is executed, a device where the computer-readable storage medium is located is controlled to execute the data management method.

[0225] Specifically, data management methods include:

[0226] Step S201, assigning pod_no to the Pod of the Kubernetes cluster, so that the above Pod corresponds to the above pod_no one by one;

[0227] Step S202, using the CSI plug-in to create a storage bucket and a corresponding object key in the cloud storage system, where the object key is a directory structure of target path-pod_no-application data directory, the application data directory is index information of the storage bucket in the cloud storage system, and the target path is the path of the Kubernetes node of the Kubernetes cluster;

[0228] Step S203, mounting the storage bucket to the target path, and mounting the target path to the Pod;

[0229] Step S204, storing the application data of the Pod in the storage bucket corresponding to the Pod, so that the container of the Pod can access the application data stored in the storage bucket corresponding to the Pod according to the object key corresponding to the pod_no.

[0230] An embodiment of the present invention provides a processor, and the processor is used to run a program, wherein the data management method is executed when the program is running.

[0231] Specifically, data management methods include:

[0232] Step S201, assigning pod_no to the Pod of the Kubernetes cluster, so that the above Pod corresponds to the above pod_no one by one;

[0233] Step S202, using the CSI plug-in to create a storage bucket and a corresponding object key in the cloud storage system, where the object key is a directory structure of target path-pod_no-application data directory, the application data directory is index information of the storage bucket in the cloud storage system, and the target path is the path of the Kubernetes node of the Kubernetes cluster;

[0234] Step S203, mounting the storage bucket to the target path, and mounting the target path to the Pod;

[0235] Step S204, storing the application data of the Pod in the storage bucket corresponding to the Pod, so that the container of the Pod can access the application data stored in the storage bucket corresponding to the Pod according to the object key corresponding to the pod_no.

[0236] An embodiment of the present invention provides a data management platform, including a Kubernetes cluster, a cloud storage system, a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, at least the following steps are implemented:

[0237] Step S201, assigning pod_no to the Pod of the Kubernetes cluster, so that the above Pod corresponds to the above pod_no one by one;

[0238] Step S202, using the CSI plug-in to create a storage bucket and a corresponding object key in the cloud storage system, where the object key is a directory structure of target path-pod_no-application data directory, the application data directory is index information of the storage bucket in the cloud storage system, and the target path is the path of the Kubernetes node of the Kubernetes cluster;

[0239] Step S203, mounting the storage bucket to the target path, and mounting the target path to the Pod;

[0240] Step S204, storing the application data of the Pod in the storage bucket corresponding to the Pod, so that the container of the Pod can access the application data stored in the storage bucket corresponding to the Pod according to the object key corresponding to the pod_no.

[0241] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing a program for initializing at least the following method steps:

[0242] Step S201, assigning pod_no to the Pod of the Kubernetes cluster, so that the above Pod corresponds to the above pod_no one by one;

[0243] Step S202, using the CSI plug-in to create a storage bucket and a corresponding object key in the cloud storage system, where the object key is a directory structure of target path-pod_no-application data directory, the application data directory is index information of the storage bucket in the cloud storage system, and the target path is the path of the Kubernetes node of the Kubernetes cluster;

[0244] Step S203, mounting the storage bucket to the target path, and mounting the target path to the Pod;

[0245] Step S204, storing the application data of the Pod in the storage bucket corresponding to the Pod, so that the container of the Pod can access the application data stored in the storage bucket corresponding to the Pod according to the object key corresponding to the pod_no.

[0246] Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order than here, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present invention is not limited to any specific combination of hardware and software.

[0247] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0248] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0249] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0250] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0251] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0252] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0253] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0254] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0255] From the above description, it can be seen that the above embodiments of the present application achieve the following technical effects:

[0256] 1) In the above data management method of the present application, by assigning a unique pod_no to the Pod of the Kubernetes cluster, and using the CSI plug-in to create a storage bucket and a corresponding object key in the cloud storage system, the storage bucket can be mounted to the above target path, and the target path can be mounted to the Pod to achieve the binding of the Pod and the storage bucket corresponding to its pod_no. By storing the application data of the Pod in the storage bucket corresponding to the Pod, the persistent storage of the application data of the Pod can be achieved. The container of the Pod can access the application data stored in the storage bucket corresponding to the Pod according to the object key corresponding to the pod_no, and an independent storage directory is provided for each Pod to avoid data confusion, thereby solving the problem of data confusion between Pods of the Kubernetes cluster in the prior art.

[0257] 2) In the data management device of the present application, by assigning a unique pod_no to the Pod of the Kubernetes cluster and using the CSI plug-in to create a storage bucket and a corresponding object key in the cloud storage system, the Pod can be bound to the storage bucket corresponding to its pod_no by mounting the storage bucket to the above-mentioned target path and mounting the target path to the Pod. By storing the application data of the Pod in the storage bucket corresponding to the Pod, persistent storage of the application data of the Pod can be achieved. The container of the Pod can access the application data stored in the storage bucket corresponding to the Pod according to the object key corresponding to the pod_no, providing an independent storage directory for each Pod to avoid data confusion, thereby solving the problem of data confusion between Pods of the Kubernetes cluster in the prior art.

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

Claims

1. A data management method, characterized in that: include: Assign pod_no to the Pod of the Kubernetes cluster so that the Pod corresponds to the pod_no one by one; A CSI plug-in is used to create a storage bucket and a corresponding object key in the cloud storage system, wherein the object key is a directory structure of target path-pod_no-application data directory, the application data directory is index information of the storage bucket in the cloud storage system, and the target path is the path of the Kubernetes node of the Kubernetes cluster; Mount the storage bucket to the target path, and mount the target path to the Pod; The application data of the Pod is stored in the storage bucket corresponding to the Pod, so that the container of the Pod can access the application data stored in the storage bucket corresponding to the Pod according to the object key corresponding to the pod_no.

2. The method according to claim 1, characterized in that Assign pod_no to the Pod of the Kubernetes cluster, including: Obtain a request for obtaining pod_no of the target Pod, the request including the IP address and Pod name of the target Pod, and the target Pod is any Pod of the Pod of the Kubernetes cluster; When the requested IP has been used and the requested Pod name has not changed, obtain the pod_no corresponding to the IP and assign it to the target Pod; If the requested IP has been used and the requested Pod name has changed, unbind the requested IP from the corresponding pod_no, and obtain a new pod_no to assign to the target Pod; In the case that the requested IP has not been used, a new pod_no is obtained and allocated to the target Pod.

3. The method according to claim 2, characterized in that Obtaining the new pod_no assigned to the target Pod includes: In the case where there is an available pod_no in the existing pod_no, the smallest available pod_no is allocated to the target Pod, and the available pod_no is the unbound pod_no; In the case that there is no available pod_no in the existing pod_no, create one pod_no and allocate it to the target Pod, and the creation rule of the pod_no is to create from small to large.

4. The method according to claim 2, characterized in that: Use the CSI plug-in to create buckets and corresponding object keys in the cloud storage system, including: In the case of obtaining the new pod_no assigned to the target Pod, the Controller service of the CSI plug-in is used to create the new storage bucket and the object key corresponding to the pod_no in the cloud storage system.

5. The method according to claim 1, characterized in that Mounting the storage bucket to the target path, and mounting the target path to the Pod, includes: The Node service using the CSI plug-in mounts the storage bucket to the target path and maps the target path to the inside of the container of the Pod.

6. The method according to claim 1, characterized in that After storing the application data of the Pod in the storage bucket corresponding to the Pod, the method further includes: When the Pod needs to be shut down gracefully, unbinding the Pod from the application data in the storage bucket and deleting the Pod; When it is detected that the Pod is shut down ungracefully, the Pod is unbound from the application data in the storage bucket.

7. The method according to claim 6, characterized in that Unbinding the Pod from the application data in the storage bucket includes: The Node service using the CSI plug-in uninstalls the storage bucket from the target path and deletes the target path from the container of the Pod to release the binding of the Pod and the application data of the storage bucket.

8. The method according to any one of claims 1 to 7, characterized in that After storing the application data of the Pod in the storage bucket corresponding to the Pod, the method further includes: Set a PersistentVolume and a PersistentVolumeClaim, where the PersistentVolumeClaim is used to request storage resources of the PersistentVolume; The PersistentVolumeClaim is mounted to the target path corresponding to the Pod, so that the container of the Pod can access the data of the PersistentVolume and use the storage resources of the PersistentVolume.

9. A data management device, characterized in that: include: An allocation unit, used to allocate pod_no to the Pod of the Kubernetes cluster, so that the Pod corresponds to the pod_no one by one; A creation unit, used to create a storage bucket and a corresponding object key in the cloud storage system by using a CSI plug-in, wherein the object key is a directory structure of a target path-pod_no-application data directory, the application data directory is index information of the storage bucket in the cloud storage system, and the target path is a path of a Kubernetes node of the Kubernetes cluster; A first mounting unit, configured to mount the storage bucket to the target path, and to mount the target path to the Pod; A storage unit is used to store the application data of the Pod through the storage bucket corresponding to the Pod, so that the container of the Pod can access the application data stored in the storage bucket corresponding to the Pod according to the object key corresponding to the pod_no.

10. A data management platform, characterized in that: include: A Kubernetes cluster, a cloud storage system, one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the one or more programs include methods for executing any one of claims 1 to 8.

Images