Temporary volume storage method, containerized cloud platform, and computer-readable medium

Abstract

The application provides a temporary volume storage method, a containerized cloud platform and a computer readable medium. The temporary volume storage method comprises the following steps: initiating to create a Pod which declares to use a temporary volume, saving attribute information of the created Pod; scheduling the Pod to an arbitrary worker node, calling a CSI temporary volume plug-in to create a temporary volume for the Pod, and calling the CSI temporary volume plug-in to initiate a request for creating a block device to a distributed storage system; the distributed storage system responds to the request for creating the block device to create the block device, mounts the block device to the worker node where the Pod is deployed, and mounts the temporary volume to the Pod. Through the application, the problem that too much local disk space is occupied due to the temporary volume and the Kubelet sharing a directory, thereby affecting the stability of the cluster, is effectively avoided.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of cloud computing, and in particular to a temporary volume storage method, a containerized cloud platform and a computer readable medium. BACKGROUND

[0002] Kubernetes (container orchestration system) is a container orchestration engine open sourced by Google, which supports automatic deployment, large-scale scalability and application container management. In Kubernetes, multiple containers can be created, each of which runs an application instance. Through the built-in load balancing strategy, the management, discovery and access of the group of application instances can be realized without complex manual configuration and processing by operation and maintenance personnel. The life cycle of a container in Kubernetes can be very short, and the container will be frequently created and deleted. When the container is destroyed, the data saved in the container will also be cleared. In order to persistently save the data in the container, Volume (data set) is introduced. Pod refers to a group of containers that share certain resources. Volume is a shared directory in a Pod that can be accessed by multiple containers. Volume is defined on a Pod and mounted to a specific file directory by multiple containers in a Pod. Kubernetes realizes data sharing between different containers in the same Pod through Volume.

[0003] EmptyDir (temporary volume) is used as a temporary space for storing, for example, temporary directories required by some application programs during runtime and does not need to be permanently stored, or a data directory that a container needs to obtain from another container. It is the most basic Volume type. EmptyDir is created when a Pod is allocated to a Node (worker node). When the Pod is destroyed, the data in the EmptyDir is permanently deleted. In the prior art, the data of EmptyDir is in the same directory as Kubelet. After the cluster is created, the data storage directory of EmptyDir is fixed.

[0004] The prior art described above has the problem that since EmptyDir is in the same directory as Kubelet, and subsequent data is stored in the same medium, in order to avoid conflicts between the data of EmptyDir and Kubelet, the storage path needs to be distinguished. As the storage data of EmptyDir gradually increases, the path becomes too long, which may occupy too much local disk space, thereby affecting the stability of the cluster. SUMMARY

[0005] The present application discloses a temporary volume storage method, a containerized cloud platform and a computer readable medium, which solves the problem of occupying too much local disk space and affecting the stability of the cluster due to the temporary volume being in the same directory as Kubelet in the prior art.

[0006] To achieve the above object, the application provides a temporary volume storage method, comprising: initiating a Pod for creating a declaration of using a temporary volume, saving attribute information of the created Pod;

[0007] scheduling the Pod to an arbitrary worker node, calling a CSI temporary volume plug-in to create a temporary volume for the Pod, and calling the CSI temporary volume plug-in to initiate a request for creating a block device to a distributed storage system;

[0008] The distributed storage system responds to the request for creating a block device to create a block device, mounts the block device to the worker node where the Pod is deployed, and mounts the temporary volume to the Pod.

[0009] As a further improvement of the application, the CSI temporary volume plug-in comprises a node driver registration program and a CSI driver, and the node driver registration program registers CSI driver information to a daemon process component to which the worker node belongs.

[0010] The Pod is deployed to an arbitrary worker node, the CSI driver is called to create a temporary volume for the Pod according to the declaration of using a temporary volume by the Pod, and the daemon process component detects that the corresponding worker node has a temporary volume to be mounted to the Pod, and then the CSI driver is called again to initiate a request for creating a block device to a distributed storage system.

[0011] As a further improvement of the application, the request for creating a block device comprises:

[0012] The daemon process component calls a node published volume interface of the CSI driver to initiate a request for creating a resource pool to the distributed storage system;

[0013] After the resource pool is created, the node published volume interface initiates a request for creating a target object of an iSCSI service end to the distributed storage system;

[0014] After the target object of the iSCSI service end is created, the node published volume interface initiates a request for creating a virtual disk to the distributed storage system;

[0015] After the virtual disk is created, the node published volume interface initiates a request for adding worker node information to the target object of the iSCSI service end to the distributed storage system;

[0016] After the worker node information is added to the target object of the iSCSI service end, the node published volume interface initiates a request for binding the virtual disk and the worker node to create a disk mapping to the distributed storage system;

[0017] The disk mapping is created, the node publishes a volume interface to initiate a request to the distributed storage system to configure the disk mapping to the worker node, and the creation of the block device request is completed after the configuration is completed.

[0018] As a further improvement of the application, the node publishes a volume interface to determine whether the Pod declares the use of a temporary volume;

[0019] If yes, create a temporary volume;

[0020] If no, proceed with the mounting process of the Pod and the persistent volume.

[0021] As a further improvement of the application, the Pod that declares the use of a temporary volume is initiated to delete the attribute information of the Pod;

[0022] The daemon component detects that there is a temporary volume mounted on the Pod to be deleted in the corresponding worker node, and calls the CSI driver to sequentially initiate the unmounting process of the temporary volume mounted in the Pod, the unmounting process of the block device mounted on the worker node, and the block device deletion request to the distributed storage system.

[0023] As a further improvement of the application, the block device deletion request includes:

[0024] The daemon component calls the node unpublishes volume interface of the CSI driver to initiate a request to the distributed storage system to unbind the virtual disk and the worker node;

[0025] The virtual disk and the worker node are unbound, and the node unpublishes volume interface initiates a request to the distributed storage system to delete the virtual disk.

[0026] As a further improvement of the application, the volume management program in the daemon component detects that there is a temporary volume that needs to be mounted or deleted in the corresponding worker node.

[0027] As a further improvement of the application, the daemon component initiates a node publishes volume interface call or a node unpublishes volume interface call to the CSI driver in the form of RPC or GRPC.

[0028] Based on the same inventive idea, the application also discloses a containerized cloud platform, comprising a master node, at least one worker node managed by the master node, and a distributed storage system;

[0029] The master node deploys a resource access component;

[0030] The worker node deploys a CSI temporary volume plug-in;

[0031] The user initiates a Pod using a temporary volume to a resource access component, the resource access component saves the attribute information of the created Pod to an ETCD component; the Pod is deployed to an arbitrary worker node, a CSI temporary volume plugin is called to create a temporary volume for the Pod, and the CSI temporary volume plugin is called to initiate a block device creation request to a distributed storage system; the distributed storage system responds to the block device creation request to create a block device, mounts the block device to the worker node where the Pod is deployed, and provides a file system for the Pod to provide storage service, and mounts the temporary volume to the Pod.

[0032] As a further improvement of the application, the CSI temporary volume plugin includes a node driver registration program and a CSI driver, and the node driver registration program registers information of the CSI driver to a daemon component of the worker node;

[0033] The Pod is deployed to an arbitrary worker node, the CSI driver is called to create a temporary volume for the Pod, and when the daemon component detects that the corresponding worker node has a temporary volume that needs to be mounted to the Pod, the CSI driver is called again to initiate a block device creation request to the distributed storage system.

[0034] As a further improvement of the application, the user initiates a Pod using a temporary volume to a resource access component, the resource access component saves the attribute information of the created Pod to an ETCD component; the Pod is deployed to an arbitrary worker node, a CSI temporary volume plugin is called to create a temporary volume for the Pod, and the CSI temporary volume plugin is called to initiate a block device creation request to a distributed storage system; the distributed storage system responds to the block device creation request to create a block device, mounts the block device to the worker node where the Pod is deployed, and provides a file system for the Pod to provide storage service, and mounts the temporary volume to the Pod.

[0035] When the daemon component detects that there are redundant mounted temporary volumes in the corresponding worker node, the CSI driver is called to sequentially initiate an unloading process of the mounted temporary volume in the Pod, an unloading process of the mounted block device in the worker node, and a block device deletion request to the distributed storage system.

[0036] The application further discloses a computer readable medium, wherein computer program instructions are stored in the computer readable medium, and the computer program instructions are read and run by a processor to execute the steps in the snapshot rollback method.

[0037] Compared with the prior art, the beneficial effects of the present application are: first, when a Pod declaring to use a temporary volume is created and the Pod is scheduled to any worker node, the CSI temporary volume plug-in is called to create a temporary volume for the Pod, then when it is identified that the newly created temporary volume in the worker node is not mounted to the Pod, the CSI temporary volume plug-in is called again to initiate a request for creating a block device to the distributed storage system, after the distributed storage system responds to the request of the temporary volume plug-in to create a block device, the block device is mounted to the worker node where the Pod is located, and then the temporary volume is mounted to the Pod. Through the above setting, the storage path of the temporary volume is transferred to the distributed storage system, and the block device used to store the temporary volume information is created along with the creation of the Pod, thereby effectively avoiding the problem of decline of cluster stability caused by occupation of too much local disk due to too long temporary volume storage path in the prior art.

[0038] Secondly, by storing the temporary volume information based on the iSCSI protocol, dynamic block device creation and mounting are performed along with the creation of the Pod, and dynamic storage is performed on the temporary volume information mounted to the Pod, so that the block device can be dynamically unloaded and deleted when the Pod is deleted, thereby improving the flexibility of temporary volume storage while avoiding occupation of too much local disk.

[0039] Finally, the CSI temporary volume plug-in includes a node driver registration program and a CSI driver, wherein the create volume interface of the CSI driver integrates temporary volume creation function and persistent volume creation function, the CSI driver can judge the create volume type declared by the Pod to perform persistent volume mounting process or create temporary volume respectively, and further perform block device creation process after the creation of the temporary volume is completed, thereby effectively avoiding mixing other types of data and improving the success rate of concurrent use of CSI. BRIEF DESCRIPTION OF DRAWINGS

[0040] Figure 1 is a whole flowchart for embodying the temporary volume storage method in the present application;

[0041] Figure 2 is a timing diagram for the whole process of creating a Pod declaring a temporary volume type, creating a temporary volume corresponding to the Pod, creating a block device, mounting the block device to the worker node where the Pod is deployed, and mounting the temporary volume to the corresponding Pod in the present application;

[0042] Figure 3 is a specific flowchart for creating and scheduling a Pod to a worker node, creating a temporary volume and a block device, and mounting the created block device to the worker node where the Pod is scheduled and mounting the temporary volume to the Pod in the present application;

[0043] Figure 4A specific flow timing diagram for the process of deleting a statement temporary volume type Pod, unloading a temporary volume mounted on the Pod, and detaching a block device from a worker node and deleting the block device in the application;

[0044] Figure 5 A specific flow block diagram for the process of deleting a Pod, unloading a temporary volume mounted on the Pod, and detaching a block device from a worker node and deleting the block device in the application;

[0045] Figure 6 A cloud platform architecture diagram in the application;

[0046] Figure 7 A computer readable medium flow block diagram in the application. DETAILED DESCRIPTION

[0047] The application will be described in detail below with reference to the embodiments shown in the accompanying drawings, but it should be noted that these embodiments are not a limitation on the application, and equivalent transformations or substitutions of functions, methods, or structures made by those of ordinary skill in the art based on these embodiments are within the scope of the application.

[0048] Before detailing the various embodiments of the application, the meanings of the main technical terms and English abbreviations involved in the embodiments are explained or defined as necessary.

[0049] Kubernetes cluster (hereinafter or simply "cluster") refers to an open source and used to manage containerized applications on multiple hosts in a cloud platform, CSI is a container storage interface for Kubernetes cluster, which is a standard interface defined by Kubernetes cluster, and pod refers to a tightly coupled container group, which is the basic unit of Kubernetes orchestration. In various application scenarios shown in the application, a CSI temporary volume plugin is introduced in the CSI node Pod by deploying a node driver registrar (Node-driver-registrar) and a CSI driver (CSI-driver) in a sidecar mode, so that the Kubernetes cluster cloud uses a distributed storage system.

[0050] The resource access component (kube-ApiServer) is the request entrance of the Kubernetes cluster, and is used for checking and screening the addition and deletion of resources; in various application scenarios shown in the application, the external volume manager (external-volume-manager) registers a custom resource object (CRD) to the resource access component (kube-ApiServer). The resource controller (controller-manager) is used for monitoring the resources and ensuring that the resources are maintained in a desired state. The ETCD component is the database of the Kubernetes cluster and is used for storing all related data of the Kubernetes cluster. The daemon component (Kubelet) is deployed on each worker node and is responsible for the specific creation process of the Pod.

[0051] The temporary volume (EmptyDir) is the most basic volume type, which is created when the Pod is assigned to the worker node, and the data in the temporary volume is completely deleted when the Pod is destroyed. The virtual disk (vdisk) refers to the resource application of the storage resource. The iSCSI is also called IP-SAN (IP network-based storage area network), which is a storage technology based on the Internet and SCSI-3 protocol, and is an industrial standard for transmitting SCSI block commands over the existing IP network. The iSCSI can transmit messages and block data simultaneously over the existing IP network without installing a separate fiber network.

[0052] Referring to Figures 1 to 5 As shown in the application, a CSI temporary volume plug-in composed of a driver registration program and a CSI driver is introduced in the CSI node Pod, wherein the driver registration program is used for registering the information of the CSI driver to the daemon component. The Pod using the temporary volume is created in the Kubernetes cluster, and after the Pod is scheduled to any worker node, the daemon component calls the CSI driver to create a temporary volume for the Pod according to the declaration of the Pod using the temporary volume. After the temporary volume is created, the daemon component detects that there is a temporary volume that is not mounted to the Pod in the worker node, and continues to call the CSI driver to initiate a block device creation request to the distributed system. The distributed storage system responds and creates a block device, mounts the block device to the scheduling node of the Pod, and then mounts the temporary volume to the Pod. Through the above process, compared with the fixed storage mode of the data storage directory of the temporary volume in the prior art, the data of the temporary volume is transferred to the distributed storage system, and the block device is created and mounted along with the creation of the Pod and the temporary volume, thereby effectively saving the local disk space and improving the stability of the Kubernetes cluster. In the application, the worker node can be understood as a computing node for deploying the Pod, and can be deployed through a computer device such as a physical machine.

[0053] In the embodiment, the temporary volume storage method includes steps S1-S3. Figure 1

[0054] S1, initiate the creation of a Pod declaring the use of a temporary volume, and save the attribute information of the created Pod.

[0055] S2, schedule the Pod to an arbitrary worker node, call the CSI temporary volume plugin to create a temporary volume for the Pod, and call the CSI temporary volume plugin to initiate the creation of a block device request to the distributed storage system.

[0056] S3, the distributed storage system 30 responds to the creation of a block device request to create a block device, mounts the block device to the worker node scheduling the Pod, and mounts the temporary volume to the Pod.

[0057] Specifically, referring to Figure 2 As shown, the CSI temporary volume plugin includes a node driver registration program 23 and a CSI driver 22, and the node driver registration program 23 registers the CSI driver 22 information to the daemon process component 21 to which the worker node belongs. The CSI driver 22 information includes the name of the CSI driver 22 and the interface information of the CSI driver 22. Multiple CSI drivers can be deployed in the same worker node, and the driver registration program 23 registers the name of the CSI driver 22 and the interface information of the CSI driver 22 to the daemon process component 21 to which the worker node belongs, so that the daemon process component 21 and the CSI driver 22 can communicate.

[0058] Referring to Figure 2 and Figure 3 , step S1 includes steps S11-S13:

[0059] S11, initiate the creation of a Pod declaring the use of a temporary volume.

[0060] S12, store the Pod information in the ETCD component 13.

[0061] S13, schedule the Pod to an arbitrary worker node.

[0062] Specifically, when creating a Pod to the Kubernetes cluster, the Pod information includes the type of declared volume and the declared use of the distributed storage system, and the created Pod information is stored in the ETCD component 13 of the Kubernetes cluster. The Pod whose declared volume type is a temporary volume is scheduled to an arbitrary worker node, and the daemon process component 21 of the worker node calls the CSI driver 22 to create a temporary volume for the Pod according to the declaration of the temporary volume used by the Pod.

[0063] Referring to​Figure 2 and Figure 3 The step S2 includes steps S21-S24.

[0064] S21, determining whether the Pod declared volume type is a temporary volume.

[0065] S22, if not, performing a persistent volume creation and mounting process.

[0066] S23, if yes, creating a temporary volume for the Pod.

[0067] S24, determining that there is a temporary volume to be mounted to the Pod in the worker node, and calling the CSI temporary volume plug-in to initiate a block device creation request to the distributed storage system.

[0068] In steps S21-S23, the CSI driver 22 determines the volume type according to the Pod declared volume type. If the Pod declared volume type is a persistent volume, the CSI driver 22 performs a persistent volume creation and mounting process for the Pod. Only when the Pod declared volume type is a temporary volume, the CSI driver 21 creates a temporary volume for the Pod and calls the node publishing volume interface to initiate a block device creation process to the distributed storage system 30. Through the above setting, first, the temporary volume creation function and the persistent volume creation function are integrated in the CSI driver 22, which effectively improves the work efficiency of the CSI plug-in. Moreover, through the judgment of the Pod declared volume type by the CSI driver 22, it can avoid mixing the Pod declared to use the persistent volume in the temporary volume creation, and avoid mixing the Pod declared to use the temporary volume in the persistent volume creation, which improves the accuracy of using the CSI plug-in.

[0069] Specifically, after the temporary volume is created in step S23, the daemon process component 21 detects that there is a temporary volume in the worker node to which it belongs and needs to be mounted to the Pod, and then calls the CSI driver 22 to initiate a block device creation request to the distributed storage 30 system, which is step S24, including steps S240-S245:

[0070] S240, the daemon component 21 calls a node publish volume interface (not shown) of the CSI driver 22 to initiate a resource pool creation request to the distributed storage system, and waits for the resource pool creation to be completed. In the embodiment, the resource pool is used to partition the storage resources in the distributed storage system. The resource pool can improve the storage performance. When the resource is requested, the resource pool is allocated to one, and then the resource is marked as busy (i.e., the resource cannot be allocated to a virtual disk), and the busy resource cannot be allocated for use again; when the use of a resource is completed, the resource pool clears the busy mark of the related resource, to indicate that the resource can be used by the next request. The node publish volume interface is logically deployed in the CSI driver 22, and the distributed storage system 30 is logically regarded as a collection of storage resources of the resource pool. It can be understood that other types of resources such as CPU can also be deployed in the storage pool.

[0071] S241, the resource pool creation is completed, the node publish volume interface initiates a target object creation request of the iSCSI service end to the distributed storage system, and waits for the target object of the iSCSI service end to be created. The iSCSI combines the existing SCSI interface with the Ethernet technology, connects the iSCSI service end (Target) and the client (Initiator) based on the TCP / IP protocol, and in the embodiment, the iSCSI service end is the distributed storage system, and the iSCSI client is the Kubernetes cluster. In this step, the targetcli command is used to abstract the configuration content of the iSCSI shared resource into a directory form, so as to fill the configuration information into the corresponding directory in the subsequent step.

[0072] S242, the target object creation of the iSCSI service end is completed, the node publish volume interface initiates a virtual disk creation request to the distributed storage system, and waits for the virtual disk to be created. In this step, the resource of the resource pool created in step S240 is called to create a virtual disk (vdisk).

[0073] S243, the virtual disk creation is completed, the node publish volume interface initiates a request of adding worker node information to the target object of the iSCSI service end to the distributed storage system, and waits for the node information to be added to the target object of the iSCSI service end to be completed. In the iSCSI, the server and the client can be addressed through the iqn (iscsi qualified name). The format of the iqn number is: iqn.date.domain name: domain name organization assigned name. In the embodiment, the iqn number of the worker node of the scheduling Pod is added to the target object, so that the target object allows the connection with the ip address of the worker node.

[0074] S244, the target object of the iSCSI service is added with the work node information, the node publishes a volume interface to initiate a request of binding a virtual disk with a work node to create a disk mapping to the distributed storage system, and waits for the disk mapping to be created. In this step, the virtual disk is bound to the work node to create a mapping disk associated with the iSCSI client in the distributed storage system 30, that is, the virtual disk is bound to the work node, thereby creating a disk mapping to improve the access efficiency between the temporary volume and the block device subsequently.

[0075] S245, the disk mapping is created, the node publishes a volume interface to initiate a request of configuring the disk mapping to the work node to the distributed storage system, and after the configuration is completed, a request of creating a block device is completed. In this embodiment, the discovery, packaging and login functions of the iscsiadm tool are used to configure the disk mapping to the work node of the scheduling Pod, and the block device creation process is completed.

[0076] Referring to FIG. 6, the step S3 includes steps S31-S32: Figure 2 Figure 3 As shown in FIG. 6, the step S3 includes steps S31-S32:

[0077] S31, the temporary volume is mounted to the Pod.

[0078] S32, a file system is provided for the Pod to provide a storage service.

[0079] Through the above steps, when the temporary volume is written with data, the mounting point of the temporary volume in the prior art is transferred to the distributed storage system 30, the virtual disk and the disk mapping are created along with the creation of the Pod, and the data written in the temporary volume is also stored in the distributed storage system 30, thereby effectively avoiding the problem that the path is too long and the local disk is occupied too much due to the same mounting point of the temporary volume and the daemon component 21 in the prior art, and further affecting the stability of the cluster.

[0080] ​It should be noted that iSCSI provides block device storage, encapsulates block-level SCSI commands, and then sends them over an IP network. It has built-in multi-path capabilities and can provide more advanced load balancing algorithms to intelligently balance storage traffic across multiple server and array end storage paths. Block devices are a type of i / o device that store information in fixed-size blocks, each of which has a corresponding path address. The information stored in the block device can be read at any location on the device through the path address. In this application, the iSCSI is used to provide block device storage for the temporary volume. In steps S240-S245, the configuration content of the iSCSI shared resource is abstracted into a directory form by creating a target object and using the targetcli command, the worker node information of the scheduling Pod (i.e., the above iqn number) is added to the directory, and the virtual disk is finally bound to the worker node information to form a disk mapping. The path address of the disk mapping is the block device created in this application. By directly accessing the disk mapping address, data can be written and read to the temporary volume. Compared with the NFS file storage, the data write and read need to be performed through the network link in the same server. The application effectively improves the data write and read efficiency, so the application of the iSCSI protocol to store the temporary volume data has better performance.

[0081] Referring to FIG. 1, Figure 4 and Figure 5 As shown in the figure, the temporary volume storage method further includes steps S4-S6 in the embodiment:

[0082] S4, initiate the Pod that declares to use the temporary volume, and delete the attribute information of the Pod.

[0083] S5, the daemon component 21 detects that there are excess mounted temporary volumes in the corresponding worker node, and calls the CSI driver 22 to sequentially initiate the unloading process of the temporary volume mounted in the Pod and the unloading process of the worker node mounting the block device.

[0084] S6, the CSI driver 22 initiates a block device deletion request to the distributed storage system.

[0085] Referring to FIG. 1, Figure 4 and Figure 5 As shown in the figure, step S4 includes steps S41-S43:

[0086] S41, initiate the Pod that declares to use the temporary volume.

[0087] S42, delete the attribute information of the to-be-deleted Pod.

[0088] S43, detect that there is a temporary volume mounted on the to-be-deleted Pod in the corresponding worker node.

[0089] The user initiates to delete the Pod using the temporary volume from the Kubernetes cluster. The attribute information is stored in the ETCD component 13 of the Kubernetes cluster when the Pod is created, and the attribute information stored in the ETCD component 13 is deleted when the Pod is deleted. When the corresponding daemon component 21 of the worker node scheduling the Pod to be deleted detects that the Pod to be deleted corresponds to the bound temporary volume, step S5 is performed.

[0090] Referring to FIG. 6, step S5 includes steps S51-S53. Figure 4 And Figure 5 Referring to FIG. 6, step S5 includes steps S51-S53.

[0091] S51, determine whether the volume type declared by the Pod to be deleted is a temporary volume.

[0092] S52, if not, end, if yes, unload the temporary volume from the Pod to be deleted.

[0093] S53, detach the block device from the worker node scheduling the Pod to be deleted.

[0094] When the corresponding daemon component 21 detects that the Pod to be deleted corresponds to the bound temporary volume, the CSI driver 22 is called to determine whether the volume type declared by the Pod to be deleted is a temporary volume. If not, it means that the Pod should not be deleted, and the process ends. If yes, the CSI driver 22 unloads the temporary volume from the Pod, detaches the block device configured on the worker node, i.e. the disk mapping created in step S245, and then performs step S6.

[0095] Referring to FIG. 6, step S5 includes steps S51-S53. Figure 4 And Figure 5 Referring to FIG. 6, step S5 includes steps S51-S53.

[0096] S61, the daemon component 21 calls the node cancel publish volume interface of the CSI driver 22 to request the distributed storage system to unbind the virtual disk and the worker node;

[0097] S62, the virtual disk and the worker node are unbound, the node cancel publish volume interface initiates a request to the distributed storage system to delete the virtual disk, the virtual disk is deleted, and the block device deletion request is completed.

[0098] The deletion of the disk mapping is completed by unbinding the virtual disk from the worker node, and then deleting the virtual disk. As can be known from the above process, when a Pod that declares to use a temporary volume is deleted, the daemon component 21 detects that the temporary volume bound to the Pod to be deleted in the worker node, and calls the node unpublish volume interface (not shown) of the CSI driver 22 to initiate a block device deletion request to the distributed storage system, so that the block device is deleted in real time with the Pod. The node unpublish volume interface is logically deployed in the CSI driver 22.

[0099] When the Pod that declares to use a temporary volume is migrated across nodes, the disk mapping configured in the worker node before the migration of the Pod is unbound, the working information in the target object is modified to the worker node after the migration of the Pod, and the virtual disk is bound to the worker node after the migration of the Pod again to form a new disk mapping, and the disk mapping is configured to the worker node after the migration of the Pod, so that data is not lost when the Pod is migrated across nodes.

[0100] It should be noted that in the present embodiment, the volume management program in the daemon component 21 detects that there is a temporary volume that needs to be mounted or deleted in the corresponding worker node. The daemon component 21 initiates a node publish volume interface call or a node unpublish volume interface call to the CSI driver 22 in the form of RPC or GRPC. In the present embodiment, the node publish volume interface call or the node unpublish volume interface call is initiated to the CSI driver 22 in the form of GRPC.

[0101] Based on the same inventive idea, the present application also discloses a containerized cloud platform, comprising: a master node 10, at least one worker node managed by the master node 10, and a distributed storage system 30;

[0102] The master node 10 deploys a resource access component 11, a resource controller 12, and a scheduler 14, and the resource controller 12 monitors the resource access component 11;

[0103] The worker node deploys a CSI temporary volume plugin;

[0104] A user initiates a Pod that declares to use a temporary volume to the resource access component 11, and the resource access component 11 saves the attribute information of the created Pod to the ETCD component 13; the Pod is scheduled and deployed to any worker node, the CSI temporary volume plugin is called to create a temporary volume for the Pod, and the CSI temporary volume plugin is called to initiate a block device creation request to the distributed storage system 30; the distributed storage system 30 responds to the block device creation request to create a block device, mounts the block device to the worker node where the Pod is scheduled and deployed, and provides a file system for the Pod as a storage service, and mounts the temporary volume to the Pod.

[0105] The CSI temporary volume plug-in includes a node driver registration program 23 and a CSI driver 22, and the node driver registration program 23 registers information of the CSI driver 22 to a daemon component 21 of a worker node to which the CSI driver 22 belongs;

[0106] The Pod is deployed to any worker node by the scheduler 14, a CSI driver 22 is called for creating a temporary volume for the Pod, and the daemon component 21 detects that the corresponding worker node has a temporary volume to be mounted to the Pod, and then the CSI driver 22 is called again to initiate a block device creation request to the distributed storage system 30, as shown in Figure 2 and Figure 3 The specific block device creation request process has been described above and will not be repeated here.

[0107] The user initiates a deletion declaration of the Pod using the temporary volume to the resource access component 11, and the resource access component 11 removes the Pod information from the ETCD component 13;

[0108] The daemon component 21 detects that there is a temporary volume mounted to the Pod to be deleted in the corresponding worker node, and the CSI driver 22 is called to sequentially initiate the unloading process of the temporary volume mounted in the Pod (step S4 described above), the unloading process of the worker node mounting the block device (step S5 described above), and the block device deletion request to the distributed storage system 30 (step S6 described above).

[0109] It should be noted that although the ETCD component 13 is deployed outside the master node 10 as shown in Figure 5 In actual application, the ETCD component 13 can also be deployed inside the master node 10.

[0110] The application further discloses a computer readable medium, and the computer readable medium 900 stores computer program instructions 901, and the computer program instructions 901 are read and run by a processor 902 to execute the steps in the temporary volume storage method.

[0111] The series of detailed descriptions listed above are only specific descriptions of the feasible implementation modes of the application, and are not used to limit the protection scope of the application, and equivalent implementation modes or changes made without departing from the spirit of the application should be included in the protection scope of the application.

[0112] It will be obvious to a person skilled in the art that the application is not limited to the details of the foregoing exemplary embodiments and can be implemented in other concrete forms without departing from the spirit or essential characteristics of the application. The embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the application being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. No reference signs in the claims should be considered as limiting the scope of the claims to the identity of the reference signs therein.

[0113] Furthermore, it should be understood that although the description is made on the basis of the embodiments, not every embodiment contains only one independent technical solution, and the description of the specification is only for the sake of clarity, and those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that those skilled in the art can understand.

Claims

1. A temporary volume storage method characterized by, The application relates to a method for creating and deleting a temporary volume of a pod in a distributed storage system. The method comprises the following steps: initiating creation of a pod using a temporary volume, saving attribute information of the created pod; scheduling the pod to an arbitrary worker node, calling a CSI temporary volume plug-in to create a temporary volume for the pod, and calling the CSI temporary volume plug-in to initiate creation of a block device in the distributed storage system; the distributed storage system responds to the creation of the block device to create a block device, mounts the block device to the worker node where the pod is deployed, and mounts the temporary volume to the pod; the CSI temporary volume plug-in comprises a node driver registration program and a CSI driver, and the node driver registration program registers CSI driver information to a daemon process component of the worker node; 2. The temporary volume storage method of claim 1, wherein, scheduling deployment of the pod to an arbitrary worker node, calling the CSI driver to create a temporary volume for the pod in response to a declaration of the temporary volume of the pod, and calling the CSI driver to initiate creation of a block device in the distributed storage system when the daemon process component detects that the temporary volume needs to be mounted to the pod in the corresponding worker node. The creation of the block device request comprises the following steps: the daemon process component calls a node published volume interface of the CSI driver to initiate creation of a resource pool in the distributed storage system; after the resource pool is created, the node published volume interface initiates a target object request of an iSCSI service end in the distributed storage system; after the target object of the iSCSI service end is created, the node published volume interface initiates a virtual disk creation request in the distributed storage system; after the virtual disk is created, the node published volume interface initiates a request of adding worker node information to the target object of the iSCSI service end in the distributed storage system; after the worker node information is added to the target object of the iSCSI service end, the node published volume interface initiates a request of binding the virtual disk and the worker node to create a disk mapping in the distributed storage system; 3. The temporary volume storage method according to claim 2, wherein, after the disk mapping is created, the node published volume interface initiates a request of configuring the disk mapping to the worker node in the distributed storage system, and the creation of the block device request is completed after the configuration is completed. The node published volume interface judges whether the pod declares the use of the temporary volume; if yes, the temporary volume is created; 4. The temporary volume storage method according to claim 2, wherein if no, the mounting process of the pod and the persistent volume is performed. The method further comprises the following steps: initiating deletion of a pod declaring the use of a temporary volume, and deleting attribute information of the pod; 5. The temporary volume storage method of claim 4, wherein, the daemon process component detects that there is a temporary volume mounted in the corresponding worker node of the to-be-deleted pod, and calls the CSI driver to successively initiate an unloading process of the temporary volume mounted in the pod, an unloading process of the block device mounted in the worker node, and a block device deletion request to the distributed storage system. The block device deletion request comprises the following steps: the daemon process component calls a node cancel published volume interface of the CSI driver to initiate a request of unbinding the virtual disk and the worker node in the distributed storage system; after the virtual disk and the worker node are unbound, the node cancel published volume interface initiates a request of deleting the virtual disk in the distributed storage system.

6. The temporary volume storage method according to claim 5, wherein, Detecting, by a volume manager in the daemon component, that there is a temporary volume in the corresponding worker node that needs to be mounted or deleted.

7. The temporary volume storage method according to claim 4, wherein, The daemon component initiates a node publish volume interface call or a node cancel publish volume interface call to the CSI driver in an RPC or GRPC manner.

8. A containerized cloud platform, characterized by, The method comprises the following steps: A master node, at least one worker node managed by the master node, and a distributed storage system; The master node deploys a resource access component; The worker node deploys a CSI temporary volume plugin; A user initiates a Pod that declares to use a temporary volume to the resource access component, and the resource access component saves the attribute information of the created Pod to the ETCD component; the Pod is scheduled to any worker node, the CSI temporary volume plugin is called to create a temporary volume for the Pod, and the CSI temporary volume plugin is called to initiate a block device creation request to the distributed storage system; the distributed storage system responds to the block device creation request to create a block device, mounts the block device to the worker node where the Pod is scheduled and deploys the storage service file system to the Pod, and mounts the temporary volume to the Pod. The CSI temporary volume plugin comprises a node driver registration program and a CSI driver, and the node driver registration program registers the information of the CSI driver to the daemon component of the worker node; The Pod is scheduled to any worker node, the CSI driver is called to create a temporary volume for the Pod, and the daemon component detects that there is a temporary volume in the corresponding worker node that needs to be mounted to the Pod, and then the CSI driver is called again to initiate a block device creation request to the distributed storage system.

9. The containerized cloud platform of claim 8, wherein: A user initiates a Pod that declares to use a temporary volume to the resource access component, and the resource access component clears the Pod information from the ETCD component; The daemon component detects that there is a temporary volume mounted in the to-be-deleted Pod in the corresponding worker node, and calls the CSI driver to sequentially initiate an unloading process of the temporary volume mounted in the Pod, an unloading process of the block device mounted in the worker node, and a block device deletion request to the distributed storage system.

10. A computer readable medium characterized by The computer readable medium stores computer program instructions, and when the computer program instructions are read and run by a processor, the steps in the temporary volume storage method of any one of claims 1-7 are executed.

Images