CN116243860A

CN116243860A - Storage persistent volume creation method, computing device and computer cluster

Info

Publication number: CN116243860A
Application number: CN202310081073.7A
Authority: CN
Inventors: 阮超
Original assignee: XFusion Digital Technologies Co Ltd
Current assignee: XFusion Digital Technologies Co Ltd
Priority date: 2023-01-29
Filing date: 2023-01-29
Publication date: 2023-06-09

Abstract

The embodiment of the application discloses a storage persistent volume creation method, a computing device and a computer cluster, wherein the method comprises the following steps: configuring available storage attributes for a plurality of storage classes respectively; receiving a storage persistent volume statement of a storage persistent volume to be created, wherein the storage persistent volume statement comprises storage attributes required by the storage persistent volume to be created; determining a target storage class meeting the condition from the plurality of storage classes according to the storage attribute required by the to-be-created storage persistent volume; and creating a storage persistent volume through a storage drive corresponding to the target storage class. According to the embodiment of the application, the proper storage class can be automatically matched according to the storage attribute carried in the storage persistent volume statement, and the creation efficiency of the storage persistent volume can be improved.

Description

Storage persistent volume creation method, computing device and computer cluster

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a storage persistent volume creation method, a computing device, and a computer cluster.

Background

Kubernetes is an open source platform for automated deployment, expansion, and operation of container clusters. The system has the functions of disaster recovery, horizontal expansion (elastic expansion), service discovery, load balancing, version rollback, storage arrangement and the like, and is widely applied to the construction and management of computer clusters.

Pod (container group) is the smallest unit of deployment in k8s (minimizing the resource object running the containerized application). One or more containers (a set of containers) may be included in each Pod, which may be used to run user business programs. Also, containers in one Pod may share networks, namespaces, and the like.

In order to realize the persistent storage of data, ensure that the business data generated by a container in the Pod is not lost when the Pod exits, k8s provides a Persistent Volume (PV) mechanism to support the Pod to perform the persistent storage on the data. At the same time, how to simplify the process of creating PV, and to improve the efficiency of PV creation is a matter of concern to the skilled person.

Disclosure of Invention

The embodiment of the application discloses a storage persistent volume creation method, a computing device and a computer cluster, which can improve the creation efficiency of the storage persistent volume.

The first aspect discloses a storage persistent volume creation method, which can be applied to a management node in a Kubernetes cluster, a module (e.g., a chip) in the management node, and a logic module or software capable of implementing all or part of the functions of the management node. The following description is given by taking an example of application to a management node. The storage persistent volume creation method may include: configuring available storage attributes for a plurality of storage classes respectively; receiving a storage persistent volume statement of a storage persistent volume to be created, wherein the storage persistent volume statement comprises storage attributes required by the storage persistent volume to be created; determining a target storage class meeting the condition from the plurality of storage classes according to the storage attribute required by the to-be-created storage persistent volume; and creating a storage persistent volume through a storage drive corresponding to the target storage class.

In this embodiment, for each storage class, the available storage attribute may be configured, for each storage persistent volume, it may include the storage attribute required by the storage persistent volume to be created, so the management node may match the storage attribute required by the storage persistent volume to be created with the appropriate storage class, and then create the storage persistent volume through the storage class. In this way, a specific storage class may not be specified in the storage persistent volume declaration, the creation process of the storage persistent volume declaration may be simplified, and the creation efficiency of the storage persistent volume may be improved.

As one possible implementation manner, the determining, according to the storage attribute required by the to-be-created storage persistent volume, a target storage class that satisfies a condition from the plurality of storage classes includes: determining one or more storage classes meeting the conditions according to the storage attributes required by the to-be-created storage persistent volume; a target storage class is determined from the one or more storage classes.

In the embodiment of the present application, the management and control node may determine, from the plurality of storage classes, one or more storage classes that satisfy the condition according to the storage attribute required for the storage persistent volume to be created, and then determine the target storage class according to the one or more storage classes. In this way, it may be ensured that the target storage class is a more appropriate storage class and that the storage attributes required for the storage durable volume to be created may be provided.

As a possible implementation manner, the method may further include: judging whether the storage class is appointed in the storage persistent volume statement; the determining one or more storage classes that satisfy the condition according to the storage attributes required to create the storage durable volume includes: in the case that no storage class is specified in the storage persistent volume declaration, determining one or more storage classes meeting a condition according to the storage attribute required by the storage persistent volume to be created; in the case where a storage class is specified in the storage persistent volume declaration, the storage class specified in the storage persistent volume declaration is determined to be the target storage class.

In the embodiment of the application, the storage class can be designated or not designated in the storage persistent volume statement so that a user can flexibly select, and thus, the flexibility of creating the storage persistent volume statement can be improved.

As one possible implementation, the storage attributes required by the storage persistent volume to be created are defined in the storage attribute tags of the storage persistent volume declaration, the storage attributes of the plurality of storage classes are defined in the storage attribute tags of the respective storage classes, and the determining one or more storage classes that satisfy the condition according to the storage attributes required by the storage persistent volume to be created includes: matching the storage attribute labels of the storage persistent volume statement with the storage attribute labels of the plurality of storage classes respectively; one or more storage classes of the plurality of storage classes that match successfully are determined to be one or more storage classes that satisfy the condition.

In this embodiment of the present application, a storage attribute required for creating a storage persistent volume may be defined in a storage attribute tag of the storage persistent volume declaration, and a storage attribute of a plurality of storage classes may be defined in a storage attribute tag of each storage class, and a management node may determine one or more storage classes that satisfy a condition by matching the storage attribute tag of the storage persistent volume declaration and the storage attribute tag of the plurality of storage classes. Such an implementation may facilitate configuration of storage attributes of storage persistent volume statements and storage classes, as well as facilitating determination of storage classes that satisfy a condition.

As one possible implementation, the storage attributes required by the storage persistent volume to be created are defined in a storage persistent volume declaration storage attribute request table, the storage attributes of the plurality of storage classes are defined in a storage class storage attribute table, and the determining one or more storage classes that satisfy the condition according to the storage attributes required by the storage persistent volume to be created includes: determining storage attributes required by the to-be-created storage persistent volume according to the storage persistent volume statement storage attribute table; matching the storage attributes required by the to-be-created storage persistent volume with the storage attributes of a plurality of storage classes in the storage class storage attribute table respectively; one or more storage classes of the plurality of storage classes that match successfully are determined to be one or more storage classes that satisfy the condition.

In the embodiment of the application, the storage attributes required by the storage persistent volume to be created can be uniformly defined in the storage persistent volume statement storage attribute request table, and the storage attributes of a plurality of storage classes are defined in the storage class storage attribute table, so that the management of the storage attributes of the storage persistent volume and the storage classes is facilitated.

As one possible implementation, the determining the target storage class according to the one or more storage classes includes: acquiring the idle capacity corresponding to the one or more storage classes according to the capacity detection interfaces of the one or more storage classes; determining one or more storage classes in the one or more storage classes which meet the capacity requirement of the storage persistent volume according to the free capacity corresponding to the one or more storage classes; a target storage class is determined from the one or more storage classes that satisfy the capacity requirements of the storage durable volume declaration.

In this embodiment of the present application, the management and control node may obtain, according to the capacity detection interfaces of the one or more storage classes, the free capacity corresponding to the one or more storage classes, and then may determine which storage classes may satisfy the capacity requirement of the storage persistent volume declaration, and may determine the target storage class from the storage classes that satisfy the capacity requirement of the storage persistent volume declaration. In this way, the problem of storage persistent volume creation failure due to insufficient capacity can be avoided.

As one possible implementation, the plurality of storage classes each include a priority, and determining the target storage class from the one or more storage classes that meet the capacity requirement declared by the storage persistent volume includes: the highest priority storage class of the one or more storage classes meeting the capacity requirements declared by the storage durable volumes is determined as the target storage class.

In the embodiment of the present application, the higher the priority, the higher the storage performance of the corresponding storage class may be. Therefore, when there are a plurality of storage classes satisfying the capacity requirement of storing persistent volume declarations, the management node can determine the storage class in which the priority is highest as the target storage class, and thus, the utilization efficiency of the storage resources can be improved.

As one possible implementation, the plurality of storage classes each include a priority, and the determining the target storage class from the one or more storage classes includes: and determining the storage class with the highest priority among the one or more storage classes as a target storage class.

As one possible implementation, the storage attributes include underlying storage system, storage media, data redundancy scheme, file system.

In the embodiment of the present application, the storage attribute may include an underlying storage system, a storage medium, a data redundancy manner, a file system, and the like, so that a user may flexibly select a required storage attribute.

A second aspect discloses a computing device comprising a processor, a memory and a communication interface for receiving information from and outputting information to other electronic devices than the computing device, the processor invoking a computer program stored in the memory to implement a storage durable volume creation method as provided in the first aspect and any of the possible implementations of the first aspect.

A third aspect discloses a computer cluster comprising a management node for performing the storage durable volume creation method provided in the first aspect and any possible implementation manner of the first aspect.

A fourth aspect discloses a computer-readable storage medium having stored thereon a computer program or computer instructions which, when run, implement the storage durable volume creation method as disclosed in the above aspects.

A fifth aspect discloses a chip comprising a processor for executing a program stored in a memory, which when executed causes the chip to perform the storage durable volume creating method disclosed in the above aspects.

As a possible implementation, the memory is located off-chip.

A sixth aspect discloses a computer program product comprising computer program code which, when run, causes the storage durable volume creation method disclosed in the above aspects to be performed.

It will be appreciated that the computing device provided in the second aspect, the computer cluster provided in the third aspect, the computer readable storage medium provided in the fourth aspect, the chip provided in the fifth aspect, and the computer program product provided in the sixth aspect described above may be used to perform the storage durable volume creation method provided in the first aspect of the present application and any possible implementation manner of the first aspect. Therefore, the advantages achieved by the method can be referred to as the advantages of the corresponding method, and will not be described herein.

Drawings

The drawings in the following description will be presented to more clearly illustrate the embodiments of the present application and to provide a brief description of the drawings, it being apparent that the drawings in the following description are only some of the embodiments of the present application and that other drawings may be obtained from these drawings by those skilled in the art without inventive faculty.

FIG. 1 is a schematic diagram of persistent volume mount as disclosed in an embodiment of the present application;

FIG. 2 is a schematic diagram of a scenario in which a user Pod mounts a storage volume according to an embodiment of the present disclosure;

FIG. 3 is a schematic diagram of a scenario in which another user Pod mounts a storage volume disclosed in an embodiment of the present application;

FIG. 4 is a schematic diagram of a system architecture disclosed in an embodiment of the present application;

FIG. 5 is a schematic diagram of a scenario in which a user Pod mounts a storage volume according to an embodiment of the present disclosure;

FIG. 6 is a flow diagram of a method of PV creation as disclosed in an embodiment of the present application;

FIG. 7 is a flow diagram of another PV creation method disclosed in an embodiment of the present application;

FIG. 8 is a flow diagram of yet another PV creation method disclosed in an embodiment of the present application;

fig. 9 is a schematic structural diagram of a computing device disclosed in an embodiment of the present application.

Detailed Description

The embodiment of the application discloses a storage persistent volume creation method, a computing device and a computer cluster, which can improve the creation efficiency and flexibility of PV. The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application.

For a better understanding of the embodiments of the present application, the related art of the embodiments of the present application will be described first.

Container (container): a virtualization technique in a computer operating system. The technology enables the process to run in a relatively independent and isolated environment (comprising independent file systems, namespaces, resource views and the like), so that the deployment flow of the software can be simplified, the portability and the safety of the software are enhanced, and the utilization rate of system resources is improved. The container technology is widely applied to the service scene in the cloud computing field, and container development is also gradually becoming the mainstream application development technology.

Kubernetes (i.e., k8 s) is an open source platform for automated deployment, expansion, and operation of container clusters. The system has the functions of disaster recovery, horizontal expansion (elastic expansion), service discovery, load balancing, version rollback, storage arrangement and the like, and is widely applied to the construction and management of computer clusters.

It should be noted that, data generated by the Pod during the operation (such as service data generated by a container in the Pod) is generally stored in a Volume (Volume) of the Pod, and the Volume of the Pod generally disappears when the Pod exits, so that the data generated by the Pod during the operation is lost, and the data cannot be persisted. In order to realize the persistent storage of data, ensure that the business data generated by a container in the Pod is not lost when the Pod exits, k8s provides a Persistent Volume (PV) mechanism to support the Pod to perform the persistent storage on the data.

The persistent volume mechanism of k8s is roughly implemented as: volumes of Pod are mapped to underlying storage Persistent Volumes (PVs), which are typically created in remote storage (e.g., a distributed storage cluster). In this way, the business data generated by the container in the Pod can be actually stored in the bottom layer PV, and the bottom layer PV cannot disappear when the Pod exits, so that the persistent storage of the data in the Pod can be realized. It should be noted that the PV may be a storage resource of the k8s cluster, which has a life cycle independent of the Pod, and the PV will not be deleted by Pod deletion when the PV is mounted on a Pod.

Referring to fig. 1, fig. 1 is a schematic diagram of persistent volume mounting according to an embodiment of the present application. As shown in FIG. 1, an administrator is generally responsible for managing remote storage (e.g., a distributed storage cluster), and may specifically manage servers, hard disks, storage pools, etc. corresponding to the remote storage, and may allocate storage volumes from the remote storage via corresponding storage drivers of the remote storage. When a user creates and starts a Pod, the storage Volume in the remote storage may be mounted for use by the Pod created by the user, and the Volume of the Pod may be mapped to the storage Volume in the remote storage.

At present, three modes of mounting storage volumes for Pod are mainly described below.

The first way is: the storage volumes in the remote storage are specified in the Pod description file. In this manner, an administrator may prepare a remote storage system (e.g., a Ceph storage cluster) in advance, and may create a storage Volume (Volume) in advance in the remote storage system. After that, when the Pod is created, the user can designate the created storage volume in the remote storage system to be used, and the k8s persistent volume management module can mount the corresponding storage volume to the Pod, so that the Pod can be supported to perform persistent storage on data (such as service data corresponding to the user service container).

The following exemplifies a Pod description file:

in the Pod description file, the portion corresponding to volumes designates a storage volume in a remote storage, and the storage volume can be mounted to a/data directory for use. Specifically, monitoring node/monitor (monitors), storage pool (pool), image (image) fields specify storage volumes in one remote storage. For example, the monitor field in the Pod description file may include three IP addresses, i.e., 172.16.143.121:6789, 172.16.143.122:6789, and 172.16.143.121:6789, which may be IP addresses of three servers, and corresponding port numbers, which may be port numbers corresponding to processes that provide services such as storage for the corresponding servers. It should be appreciated that the three servers may be monitoring nodes of a Ceph storage cluster. kubernetes may be the name of a storage pool in the server cluster. The ceph-image may be the name of one storage volume (mirror) in the kubernetes storage pool. In this way, the storage volume ceph-image can be mounted for use by the pod-with-ceph. It should be appreciated that rbd (RADOS Block Devcie) in the Pod description file is a protocol, namely, an externally provided block storage protocol based on RADOS (reliable autonomic distributed object store, reliable, self-repairing distributed object storage), which is generally applied to a Ceph distributed storage system (Ceph storage cluster).

It should be appreciated that the kined field in the above description file is used to indicate a resource (resource object) type, such as the Pod resource described above, and the resource type may be persistent volume, persistent volume claim, storage class, depoyment, or the like. The metadata field in the above description file is used to indicate metadata information of a resource, such as name, namespace, labels, and the like. The spec field in the above description file may be used to indicate parameters that the containers, storage, volumes, other k8s clusters need to know, etc.

The second mode is as follows: the persistent volume declaration (persistent volume claim, PVC) can be used in the Pod description file after the storage Persistent Volume (PV) is created in advance, and the PV meeting the requirements is automatically matched for Pod use by the PVC. Specifically, referring to fig. 2, fig. 2 is a schematic view of a scenario in which a user Pod mounts a storage volume according to an embodiment of the present application. As shown in fig. 2, this may include, but is not limited to, the following steps:

201. an administrator prepares in advance a storage system (e.g., ceph storage cluster, curve storage cluster, etc.) for use and may create in advance one or more storage pools based on the storage system and create a storage Volume (Volume) based on the one or more storage pools, respectively.

202. The administrator pre-allocates a plurality of storage durable volumes according to the actual situation of the storage system.

Specifically, an administrator may pre-allocate a plurality of storage Persistent Volumes (PVs) according to the actual situation of the storage system (e.g., the number of storage pools in the storage system, the size of each storage pool, one or more storage volumes to which the storage pools correspond, etc.).

The following exemplifies a PV profile:

the name field in the PV description file indicates that the name corresponding to the PV resource object is PV-with-ceph, and the storage field in the PV description file has a value of 10Gi, which indicates that the storage size (storage capacity) of the PV is 10GB (gigabytes). The accessModes field has a value of ReadWriteOnce (RWO), which indicates that it has read and write rights and can only be mounted by a single Node. monitors, pool, image, etc., specifies a storage volume in a remote storage. It is understood that the storage space corresponding to pv-with-ceph may be the storage space of ceph-image. The fsType field indicates that the corresponding file system is an xfs (x file system) file system. It should be noted that, in the PV description file, an administrator may describe information such as deployment details, volume (i.e. image) size and the like of the underlying storage, and then may submit the PV description file to the k8s cluster, and the k8s cluster may create a corresponding PV according to the PV description file.

It should be appreciated that in addition to ReadWriteOnce, the value of the accessModes field may also be ReadOnlyMany (ROX), indicating that it has read-only rights and is allowed to be mounted by multiple nodes; readWriteMany (RWX), which shows that the system has read-write authority and is allowed to be mounted by a plurality of nodes; readWriteOncePod (RWOP), which shows that it has read-write rights and is allowed to be mounted by a single Pod. It should also be appreciated that the value of the fsType field may also be ext4 (fourth extended filesystem, fourth generation extended file system).

203. The user creates a storage persistent volume statement according to the actual situation of the business system.

Because there is an administrator in the k8s cluster that created a good PV in advance, a user can create a storage persistent volume declaration (PVC) first when it is required to mount a PV for a Pod. PVC is primarily used by users to describe what storage volumes are needed, e.g., in PVC profiles, users can specify the required PV size, supported access patterns, etc. At this time, the user does not need to care about the details of the bottom layer storage, and the decoupling of the service and the bottom layer storage is realized.

The following exemplifies a PVC description file:

the name field in the PVC description file indicates that the name corresponding to the PVC resource object is PVC-with-ceph, the accessModes field in the PVC description file specifies that the access mode that needs to be supported by the PV is ReadWriteOnce, and the storage field below the requests field indicates that the storage space that needs to be supported by the PV is 10Gi. The user submits the PVC description file to the k8s cluster, and the k8s cluster can create corresponding PVC according to the PVC description file.

The ks system selects an appropriate storage persistent volume binding for the storage persistent volume declaration.

After the k8s system creates the PVC, the relevant modules (persistent volume management modules) in the k8s system can automatically match the qualified PV according to the information such as the size of the PV and the access mode specified in the PVC, and then can associate (bind) the qualified PV with the PVC. For example, for the PVC described above, i.e., PVC-with-ceph, it may be matched to the PV created above, i.e., PV-with-ceph, and then the k8s cluster may bind PVC-with-ceph and PV-with-ceph.

205. The user creates a Pod and selects the storage persistent volume declarations that need to be used.

Since the user can create the PVC in advance, and can declare the corresponding storage requirement in the PVC. Therefore, after creating the PVC, the user may directly use the already created PVC when creating the Pod, and the created Pod may be stored based on the PV corresponding to the PVC based on the binding relationship between the PVC and the PV.

Another Pod description file is exemplified below:

the name field in the Pod description file indicates that the name corresponding to the Pod resource object is Pod-with-ceph, and the claimName field under the persistence volume class field in the Pod description file designates the PVC to be used as PVC-with-ceph. Based on the binding relationship between the pvc-with-ceph and the pv-with-ceph, the pod-with-ceph can perform persistent storage of data based on the pv-with-ceph.

The third way is: a Storage Class (SC) is created in advance, then the storage class can be bound in PVC, then the storage drive corresponding to the storage class can dynamically create the PV meeting the requirements, then PVC can be used in the Pod description file, and the PV is mounted to the Pod for use through the PVC. Specifically, referring to fig. 3, fig. 3 is a schematic view of another scenario in which a user Pod mounts a storage volume according to an embodiment of the present application. As shown in fig. 3, this may include, but is not limited to, the following steps:

301. the administrator prepares a corresponding storage drive (provider) according to the actual situation of the storage system.

Because the PV meeting the PVC requirement needs to be dynamically created later, the administrator can prepare the corresponding provisioner according to the actual situation of the storage system, that is, deploy the corresponding provisioner in the k8s cluster. provisioner may be a storage drive with the capability to create PV.

302. An administrator configures one or more storage classes according to the storage system.

Storage class (StorageClass, SC) resources are defined in the k8s cluster. Each storage class needs to bind one provisioner so that the PVC can then create a satisfactory PV through the corresponding storage class.

In particular, an administrator may configure one or more storage classes based on the storage system (e.g., the number of storage pools in the storage system, the supported file systems, the mirroring format, the mirroring characteristics, etc.).

The following exemplifies an SC description file:

the name field in the SC description file indicates that the name corresponding to the SC resource object is storageclass-with-ceph, and the provider field in the SC description file indicates that the provider corresponding to the SC is kubernetes. The pos 1 field indicates that the corresponding storage pool is kubernetes, the fsType specifies the corresponding file system as ext4, the imageFormat field specifies the image format as "2", and the imageFeatures field specifies the image feature as "layring". It should be noted that, in the SC description file, an administrator may describe information such as deployment details of the underlying storage (detailed information of the underlying storage and corresponding storage driver provider), and then may submit the SC description file to the k8s cluster, where the k8s cluster may create a corresponding SC according to the SC description file.

It will be appreciated that a plurality of attribute fields (tags), such as pos 1, fsType, imageFormat, imageFeatures, etc., may be included in the SC description file, and that these attributes may have different values and may correspond to different storage classes, so that a k8s cluster may typically include multiple storage classes for user selection.

303. The user creates a storage persistent volume declaration according to the actual situation of the business system and indicates which storage class is processed in the storage persistent volume declaration.

Since there is an SC created by the administrator in the k8s cluster in advance, when creating a storage persistent volume declaration (PVC), a user can designate (bind) one SC therein, and then a corresponding PV can be dynamically created by that SC, binding with that PVC.

Another PVC description file is exemplified below:

the name field in the PVC description file indicates that the name corresponding to the PVC resource object is PVC-with-ceph, and the storageClassName field in the PVC description file indicates that the storage class corresponding to the PVC is storageclass-with-ceph. In addition, the storage field in the PVC description file specifies a storage space size of 10Gi. It should be noted that, in the PVC description file, the user may specify a storage class, and then may submit the PVC description file to the k8s cluster, and the k8s cluster may create a corresponding PVC according to the PVC description file.

304. And the storage class generates corresponding storage persistent volume description information according to the storage persistent volume statement and sends the storage persistent volume description information to a provisioner for processing.

Specifically, after the user submits the PVC description file to the k8s cluster, the k8s cluster (persistent volume management module) may determine a Storage Class (SC) corresponding to the PVC, and then may generate corresponding storage persistent volume description information through the storage class, and send the storage persistent volume description information to a provider process corresponding to the storage class. For example, the storage class specified in the PVC description file is storage class-with-ceph, and the provider corresponding to storage class-with-ceph is kubernetes. The storage class-with-ceph can generate corresponding storage persistent volume description information according to the related information (namely the related information in the SC description file) and the related information of the pvc-with-ceph. For example, the storage space corresponding to the PV may be 10Gi, the corresponding storage pool may be kubernetes, the corresponding file system may be ext4, and so on.

Provisioner creates a corresponding storage persistent volume from the storage persistent volume description information and binds with the storage persistent volume declaration.

After the provisioner corresponding to the storage class receives the storage persistent volume description information, a corresponding storage persistent volume can be created according to the storage persistent volume description information and bound with the storage persistent volume statement. For example, suppose that storing persistent volume description information includes: the storage space corresponding to the PV may be 10Gi, and the corresponding storage pool may be kubernetes or the like. provisioner can create an image (storage volume) of 10Gi size based on the storage pool kubernetes as the actual underlying storage of PV. After the provisioner creates the PV, the PV may be bound to the corresponding PVC (i.e., PVC-with-ceph).

It can be seen that, by designating a storage class for PVC, the k8s cluster (persistent volume management module) can obtain a corresponding Storage Class (SC) from PVC based on the relationship between PVC and storage class and the relationship between storage class and provider, and then obtain a corresponding provider from the storage class, and then can automatically create PV with a size meeting the requirement by calling the provider. In this case, the user can dynamically create any number of PVs with any size based on the actual needs of the service, without concern about the implementation details of the underlying storage, and without requiring an administrator to create the PVs in advance. It should be appreciated that the PVC/Pod and storage class have a strong association (coupling) relationship because of the need to specify the storage class when creating the PVC.

306. The user creates a Pod and selects the storage persistent volume declarations that need to be used.

The following exemplifies yet another Pod description file:

the name field in the Pod description file indicates that the name corresponding to the Pod resource object is Pod-with-ceph, and the claimName field under the persistence volume class field in the Pod description file designates the PVC to be used as PVC-with-ceph. Based on the binding relationship between the pvc-with-ceph and the corresponding PV, the pod-with-ceph can perform persistent storage of data based on the PV to which the pvc-with-ceph is bound.

It should be noted that the above three ways of mounting storage volumes for Pod have certain drawbacks, in which, for the first way, the user needs to know too many details of the underlying storage, and the service Pod and the underlying storage are strongly coupled. For the second way, the administrator needs to create a large number of PVs in advance, the administrator is heavy in burden and low in efficiency, and if the PVs meeting the requirements (such as capacity requirements) of the user Pod are not available, the user Pod may not be able to perform persistent storage of data, and even the Pod may not be successfully created, which may affect deployment of the user service Pod, where it is generally necessary to find the PVs needed by the administrator to create the user. Furthermore, in this manner, an administrator typically needs to create many different sizes of PVs in advance in order to support different user storage needs, which can result in a lot of space being wasted if some of the PVs are not used at all times.

For the third approach, in a system with a larger scale and more complex service, the number of storage classes may be large, for example, for different storage clusters (such as a distributed storage Ceph cluster, a distributed storage Curve cluster, etc.), which correspond to different provisioners. Also, for the same storage cluster, an administrator may partition many different storage pools, such as: different media (such as solid state disk, mechanical hard disk, etc.), different redundancy modes (2 copies, 3 copies, etc.), different file formats (ext 4, xfs, etc.), and other storage related various parameters. For various different storage classes, the user may not select correctly, and even if the user may select the required storage class correctly, the PV creation may fail due to insufficient capacity because it cannot be determined which storage class currently corresponds to the storage pool having free capacity.

In order to solve the above-mentioned problem, in the embodiment of the present application, based on the above-mentioned third mode, a storage class selector (storage class selection module) is newly added in the k8s cluster. Storage attributes may be defined in the PVC description file submitted by the user, which may include specifically storage capacity, priority, etc., and then a specific storage class may not be specified. Then, a storage class selector in the k8s cluster can automatically select a storage class meeting requirements for the PVC according to the storage attribute in the PVC, and then the PV meeting requirements can be dynamically created based on the storage class. By the method, the problem of failure in PV creation caused by insufficient capacity can be avoided, in addition, the PVC/POD and the storage class are loosely coupled, a user does not need to specify an SC, the creation process of the PVC can be simplified, and the Pod deployment efficiency of the user can be improved.

For a better understanding of the embodiments of the present application, the system architecture used by the embodiments of the present application is described below.

Referring to fig. 4, fig. 4 is a schematic diagram of a system architecture according to an embodiment of the present application. As shown in fig. 4, the system architecture may include a k8s cluster 401, a storage cluster 402, a network 403, and an electronic device 404.

Wherein the k8s cluster 401, the storage cluster 402 and the electronic device 404 may be respectively connected to the network 403, and communication (i.e. data interaction) between each other is implemented through the network 403. It should be appreciated that communication between the k8s cluster 401 and the various nodes in the storage cluster 402 may also be via a network.

The k8s cluster 401 may include a plurality of nodes, four of which are illustrated in fig. 4 as node a 4011, node b 4012, node c 4013, and node d 4014. Each node in the k8s cluster 401 may be one or more servers, and specifically may be a server such as a blade server, a high-density server, a rack server, or a rack server.

It should be appreciated that the nodes in the k8s cluster 401 may include two classes, namely control nodes (control nodes) and work nodes (workernodes). The control nodes in k8s cluster 401 may constitute a Control Plane (CP), and in some embodiments, the control nodes in the CP may be divided into one or more master nodes (masters) and one or more slave nodes (slaves). The management and control node is mainly responsible for managing and maintaining the whole k8s cluster, so that each node works in cooperation with each other. For example, the management node needs to schedule resources, detect and respond to cluster events so that services running on the cluster can function properly. The working nodes, which may also be simply referred to as nodes, are carriers in the cluster that are responsible for running Pod, user containers (i.e., various service processes). It should be noted that, the PV creation method provided in the embodiment of the present application may be applied to a management node in a k8s cluster, and may be a master node in the management node, or may be a slave node in the management node.

The management and control node can comprise a persistent volume management module which is mainly responsible for the related management of the storage Persistent Volume (PV), and concretely can comprise mounting the PV for Pod, binding the PV for PVC based on a PVC description file, dynamically creating the PV meeting requirements based on the storage class appointed by PVC, and the like. In this embodiment of the present application, a sub-module, that is, a storage class selection module, may be newly added to the persistent volume management module, where the storage class selection module may match a storage class meeting requirements for the storage class according to related description information of the PVC, and then may bind the storage class with the PVC, so that a corresponding provider may be invoked to dynamically create a PV meeting requirements for the PVC. It should be appreciated that in some embodiments, the storage class selection module may also be implemented as a module that is independent of the persistent volume management module. It should be noted that the persistent volume management module may include controllers and services related to the persistent volume in the k8s cluster.

Storage cluster 402 may include a plurality of nodes, four of which are illustrated in FIG. 4 as node e 4021, node f 4022, node g 4023, and node h 4024. Each node in the storage cluster 402 may be one or more servers, and specifically may be a server such as a blade server, a high-density server, a rack server, or a rack server. In embodiments of the present application, the underlying storage of PV resource objects in a k8s cluster may be based on the storage cluster 402.

It should be appreciated that different nodes may be partitioned according to functionality in different storage clusters. For example, in some embodiments, the nodes in the storage cluster 402 may include two types, namely a Coordinator Node (CN) and a Data Node (DN). The data node is mainly used for storing data, executing data operation instructions (such as data inquiry, data modification and the like) issued by the coordination node and returning an execution result to the coordination node. The coordination node is mainly used for managing and monitoring each data node, can issue data operation instructions to each data node, can monitor the resource use condition (such as processor resource, disk IO resource and disk residual storage capacity) of each data node, and can maintain the whole database cluster to be in a healthy state. In some embodiments, the coordinating node may act as a communication portal for the entire storage cluster, and all operations on the data (e.g., addition, deletion, modification, querying, etc. of the data) may be performed by the coordinating node.

It should be noted that, in the embodiment of the present application, a plurality of storage pools may be created for the storage cluster 402. For example, assume that a storage cluster has 20 data nodes, namely node 1-node 20, each of which includes 4 hard disks, where two hard disks may be mechanical hard disks (HDDs) and the other two hard disks may be Solid State Disks (SSDs). At this time, 4 storage pools may be configured, and the storage pool 1 may include storage spaces corresponding to the mechanical hard disks of the nodes 1 to 10. Storage pool 2 may include storage space corresponding to the mechanical hard disk of node 11-node 20. The storage pool 3 may include storage spaces corresponding to the solid state drives of the nodes 1-10. Storage pool 4 may include storage space corresponding to the solid state drives of nodes 11-20. In addition, in order to improve the reliability of data storage, a corresponding redundancy protection mode may be configured for each storage pool. Storage pool 1 may be configured as a 2-copy, storage pool 2 may be configured as a 3-copy, storage pool 3 may be configured with an Erasure Coding (EC) redundancy ratio of 4+2, and storage pool 4 may be configured as a 2-copy.

Further, for each storage pool, a plurality of storage volumes may be configured for it, for example, 4 storage volumes may be configured for storage pool 1, and the sizes of the 4 storage volumes may be different, and may be 2GB, 10GB, 15GB, and 20GB, respectively. For each storage volume, the storage volume can be used as the bottom storage of the PV in the k8s cluster, so that the persistent storage of Pod data can be realized.

It should be understood that the above description of the storage pools is illustrative only and not limiting. For example, in some embodiments, a hard disk may be partitioned into multiple logical storage spaces, and then the storage pools may be configured based on the logical storage spaces.

In the embodiment of the present application, the electronic device 404 may send the PVC description file, the Pod description file, etc. to the k8s cluster 401, so that a corresponding resource object may be created in the k8s cluster.

It should be noted that, in fig. 4, one storage cluster (i.e. storage cluster 402) is illustrated, but in a practical scenario, different storage clusters may be set up for the k8s system, such as a Ceph storage cluster, a Curve storage cluster, and so on. And, the storage cluster may be a cloud storage cluster.

It should be noted that the system architecture shown in fig. 4 is only exemplary, and is not limited to the configuration thereof. In other embodiments of the present application, the system architecture shown in fig. 4 may include more or fewer devices or modules than illustrated, and is not limited to only including the k8s cluster 401, storage cluster 402, network 403, and electronic device 404 shown in fig. 4.

Referring to fig. 5, fig. 5 is a schematic view of a scenario of another user Pod mounted storage volume disclosed in an embodiment of the present application. As shown in fig. 5, this may include, but is not limited to, the following steps:

501. and the administrator prepares the corresponding provisioner according to the actual condition of the storage system through the operation management end.

Step 501 is substantially the same as the principle of step 301 described above, and reference is made to the above description.

502. An administrator configures one or more storage classes according to the storage system by operating the management side and defines available storage attributes for each storage class.

Unlike step 302 described above, when the administrator configures one or more storage classes according to the storage system by operating the management end, in addition to binding a provisioner for each storage class, each storage class may define a provisionable storage attribute, where the storage attribute may be a storage attribute that may be provided by a storage pool corresponding to the storage class.

In particular, the storage attributes may include attributes such as storage capacity, and priority. The storage capability attributes may include underlying storage system/software vendors (e.g., ceph, curve, etc.), media (e.g., HDD, SSD, etc.), data redundancy (e.g., 2-copy, 3-copy, 4+2EC redundancy, etc.), file system/file formats (e.g., ext4, xfs, etc.). The storage capacity attributes may include a representational state transfer (representational state transfer, REST) interface that queries the total capacity and free capacity of the underlying storage (e.g., storage pool) to which the storage class corresponds. The priority attributes may include High (High), low (Low), etc. priorities.

503. And the user creates a storage persistent volume statement according to the actual condition of the service system by operating the user terminal, and defines the required storage attribute in the storage persistent volume statement.

Unlike step 303 described above, the administrator creates a well defined SC in the k8s cluster with available storage attributes, so when the user creates a storage persistent volume declaration (PVC) by operating the user side, it is not necessary to specify (bind) an SC in the PVC, and it is possible to specify/define a required storage attribute, storage space size (storage capacity), etc. in the PVC.

504. The storage class selection module selects a storage class according to the storage attribute in the storage persistent volume declaration.

After the k8s persistent volume management module receives the PVC creation request of the user, a storage class meeting the requirements can be selected for the PVC according to the storage attribute of the PVC and the storage attribute of each storage class in the k8s cluster.

Specifically, the storage class selection module may automatically select a storage class meeting the requirements for the PVC based on the principle of "capability attribute matching+enough free capacity". The selected storage class may then be bound to the PVC, and then the provisioner corresponding to the storage class may be called to create the PV.

505. And the storage class generates corresponding storage persistent volume description information according to the storage persistent volume statement and sends the corresponding storage persistent volume description information to corresponding provisioner processing.

506. And the provisioner corresponding to the storage class creates a corresponding storage persistent volume according to the storage persistent volume description information and binds with the storage persistent volume statement.

507. The user creates a Pod and selects the storage persistent volume declarations that need to be used.

Steps 505-507 are substantially the same as the principles of steps 304-306 described above, and reference may be made to the relevant descriptions in steps 304-306 described above.

The scenario in which the user Pod mounts the storage volume shown in fig. 5 is merely illustrative, and is not limited to this configuration.

Based on the above system architecture, please refer to fig. 6, fig. 6 is a flowchart of a PV creating method disclosed in an embodiment of the present application. As shown in fig. 6, the PV creation method may include, but is not limited to, the following steps:

601. and the administrator configures the available storage attributes for the storage classes respectively through the operation management end.

In particular, to facilitate later management and control nodes may automatically match appropriate storage classes based on storage attributes carried in the storage persistent volume declaration. When an administrator creates a plurality of storage classes through the operation management end, the storage attributes which can be provided can be respectively configured for the plurality of storage classes. For example, the plurality of storage classes include storage class 1 and storage class 2, and when the administrator creates storage class 1 by operating the management end, the storage class 1 may be defined as a disk type for the available storage attributes, and the storage class 2 may be defined as a disk type for the available storage attributes: HDD, redundancy scheme: EC redundancy.

602. The management node receives a storage persistent volume declaration of the storage persistent volume to be created, wherein the storage persistent volume declaration contains storage attributes required by the storage persistent volume to be created.

Specifically, to bind PV usage to Pod, a user may send a storage persistent volume statement to the management node that a storage persistent volume is to be created through the electronic device. Accordingly, the management node may receive a storage persistent volume declaration from the electronic device for which the storage persistent volume is to be created.

And, in order for the management node to automatically match the appropriate storage class according to the storage persistent volume declaration, the storage persistent volume declaration may carry storage attributes required for the storage persistent volume to be created. For example, when the type of the required storage attribute disk is SSD and the redundancy mode is copy redundancy, at this time, the storage attribute carried in the storage persistent volume statement may be: disk type: SSD, redundancy mode: duplicate redundancy.

603. And the management and control node determines a target storage class meeting the condition from the plurality of storage classes according to the storage attribute required by the to-be-created storage persistent volume.

Specifically, after receiving the storage persistent volume statement of the storage persistent volume to be created, the management node may determine, from the plurality of storage classes, a target storage class that satisfies the condition according to the storage attribute required by the storage persistent volume to be created carried therein. For example, the storage attributes required for the storage persistent volume to be created, carried in the storage persistent volume declaration, may be: disk type: SSD, redundancy mode: duplicate redundancy, while storage class 1 may provide storage attributes of: SSD, redundant mode copy redundancy, therefore, the management node may determine that storage class 1 of the plurality of storage classes satisfies a condition, may determine storage class 1 as the target storage class.

604. And the management and control node creates a storage persistent volume through a storage drive corresponding to the target storage class.

After the management and control node determines a target storage class meeting the condition from the plurality of storage classes, a storage persistent volume can be created through a storage drive corresponding to the target storage class so as to be mounted for Pod use.

Based on the above system architecture, please refer to fig. 7, fig. 7 is a flow chart of another PV creating method disclosed in an embodiment of the present application. As shown in fig. 7, the PV creation method may include, but is not limited to, the following steps:

701. the management node receives a storage persistent volume declaration.

Specifically, to bind PV usage to Pod, a user may send a storage persistent volume declaration (PVC) to a management node in the k8s cluster through an electronic device (e.g., the electronic device shown in fig. 4). Accordingly, a management node in the k8s cluster may receive a storage persistent volume declaration from the electronic device.

In PVC, a user can declare the required storage space size (e.g., 10 Gi). Also, in order to be able to dynamically create a PV that meets the PVC requirements, the user may also specify a storage class in the PVC.

In addition to specifying a storage class in the PVC, in the embodiment of the present application, considering that there may be a large number of storage classes in the k8s cluster, the user may have difficulty in selecting, so the user may set the value of the storage class attribute in the PVC description file to be null, may indicate the required storage capability attribute in the PVC (i.e. define the storage capability attribute request), and then, the management node in the k8s cluster selects a storage class according to the storage capability attribute, the storage capacity and so on required by the PVC, and binds to the PVC. The storage capability attributes may include underlying storage system/software vendors (e.g., ceph, curve, etc.), media (e.g., HDD, SSD, etc.), data redundancy (e.g., copy redundancy, EC redundancy, etc., or 2-copy, 3-copy, 4+2EC redundancy, etc.), file system/file formats (e.g., ext4, xfs, etc.), and the like.

In one possible implementation, the required storage capability attributes of the PVC may be defined in tags (labels) of the PVC, i.e. one or more required storage capability attributes may be indicated in the tag (labels) field of the PVC, which may accordingly be referred to as storage capability attribute tags.

The following exemplifies a PVC description file including a storage attribute tag:

as can be seen from the PVC description file above, when a user creates a PVC, the PVC may be labeled, with the required storage capability attributes defined in the label. Specifically, two attributes (storage capability attribute tag) including a DiskType (disk type) and a Redundancy (Redundancy type) are included under the labels attribute of PVC, the DiskType attribute has a value of SSD, and the Redundancy attribute has a value of Redundancy. The values of the two attributes can be used to indicate that the bottom storage medium of the storage pool corresponding to the storage class required by the user is an SSD, and the redundancy mode adopted by the storage pool is copy redundancy (e.g. 2-copy, 3-copy redundancy, etc.). It should be appreciated that the user may also indicate the underlying storage system in the PVC, such as a storage system attribute under the labels attribute, which may have a value of "Ceph" to indicate that the underlying storage system is a Ceph storage system.

It will be appreciated that in order to automatically bind the appropriate storage class for a PVC based on the storage capability attributes included in the PVC, an administrator may define storage attributes that may be provided for each storage class when configuring one or more storage classes based on the storage system (e.g., the number of storage pools in the storage system, the file systems supported, the mirroring formats, the mirroring features, etc.). The storage attributes may include attributes such as storage capacity, and priority. The storage capacity attribute may refer to the related description above, and the storage capacity attribute may include a representational state transfer (representational state transfer, REST) interface that queries the total capacity and free capacity of the underlying storage (e.g., storage pool) corresponding to the storage class. The priority attributes may include High (High), low (Low), etc. priorities.

In one possible implementation, storage capability attributes, etc., that a storage class may provide may be defined in tags (labels) of the storage class.

The following exemplifies a storage class description file that includes a storage attribute tag:

as can be seen from the SC description file, the storage class bottom layer is based on the storage pool kubernetes, the bottom layer storage medium of the storage pool kubernetes may be an SSD, and the configured redundancy manner may be a 2-copy, as in the storage pool 4. Accordingly, storage capability attributes that may be provided by the storage class-with-ceph include SSD and 2 copies, and accordingly, may include two attributes, diskType and Reducance, under the labels attribute of the SC, the DiskType attribute may have a value of SSD, and the Reducance attribute may have a value of repetition. In addition, since the capacity of the storage pool kubernetes may be gradually reduced due to the dynamic creation of the PV, in order to avoid the failure of the PV creation, a storage capacity attribute capacity probe (capacity detection interface) may be further included under the labes attribute of the SC, and the storage capacity attribute capacity probe corresponding to the storage class-with-ceph may be 72.16.143.121:8080/capacity. It should be appreciated that the free capacity of the storage pool kubernetes can be queried by 72.16.143.121:8080/cspace.

It should be appreciated that in some embodiments there may be multiple storage classes that meet the PVC requirements (storage capability attribute requirements), and thus, a priority may be defined for each storage class, and a storage class with a higher priority may be preferentially selected. In one possible implementation, the classification may be high priority and low priority. In another possible implementation, the plurality of levels may be divided into five levels, such as 1, 2, 3, 4, 5. Embodiments of the present application are not limited in this regard as to the manner in which the priorities are assigned.

It should be noted that the storage capability attribute may also include other storage related attributes, such as a read/write rate, and the like, which are not limited herein. It will be appreciated that in some embodiments, each storage capability attribute may have a different level of detail, for example, assuming that the storage pool for a storage class is based on a dual-arm mechanical hard disk, the storage capability attribute of the storage class may be defined as an HDD, or may be defined as a more detailed dual-arm HDD.

702. The control node determines whether or not a storage class is specified in the storage persistent volume declaration, and if the storage class is not specified, it executes step 703, and if the storage class is specified, it executes step 706.

Because in the embodiment of the application, the user can specify a storage class in the PVC, or set the value of the storageClassName attribute to be null, and wait for the management and control node to match a storage class meeting the requirement for the management and control node. Therefore, after the control node receives the PVC (PVC description file) from the electronic device, it may determine whether a storage class is specified in the PVC, if no storage class is specified in the PVC, it may match a storage class that meets the requirements, step 703 may be executed, and if a storage class is specified in the PVC, a PV that meets the requirements may be dynamically created by the specified storage class, and step 706 may be executed.

703. The management and control node determines one or more storage classes meeting the condition according to the storage capability attribute tags in the storage persistent volume declaration.

In the event that a storage class is not specified in the PVC, the management node may determine one or more storage classes that satisfy the condition from the storage capability attribute tag in the PVC.

Specifically, since the PVC may include the required storage capability attribute declared by the user, and the storage class may include the storage capability attribute that the storage class may provide, the management node may determine, according to the storage capability attribute tag in the PVC, the storage class that may provide the corresponding storage capability attribute in all the storage classes of the k8s cluster. In one possible implementation, the management node may match the storage capability attribute tags of all the storage classes in the k8s system according to the storage capability attribute tags in the PVC, and may determine one or more storage classes that match the storage capability attribute tags in the PVC.

For example, suppose that the k8s system includes 4 storage classes, namely, storage class 1, storage class 2, storage class 3, and storage class 4, and the storage capability attribute tags of storage class 1, storage class 2, storage class 3, and storage class 4 each include DiskType and Redundancy. Wherein, the DiskType tag of the storage class 1 has a value of SSD and the Reductance tag has a value of reply. The DiskType tag of storage class 2 has a value of SSD and the Redundancy tag has a value of EC. The DiskType tag of storage class 3 has a value of HDD and the Redundancy tag has a value of reply. The DiskType tag of storage class 4 has a value of HDD and the Redundancy tag has a value of EC. Storage capability attribute tags in PVC also include DiskType and Redundancy. Wherein, the DiskType tag has a value of SSD and the Redundancy tag has a value of EC. Thus, the policing node may determine that storage class 2 matches a PVC, i.e., storage class 2 may provide the storage capability attributes required by the PVC. For another example, for the pvc-with-ceph, the management node may determine that the storage class-with-ceph may meet its storage capability attribute requirements, matching it.

It should be appreciated that the number of storage capability attribute tags in a storage class may be greater than the number of storage capability attribute tags in a PVC, e.g., for storage class a, storage class a may include three tags, diskType, redundancy, fileSystem (file system), and a PVC may include two tags, diskType, redundancy. The value of the DiskType tag of the storage class a may be HDD, the value of the Redundancy tag may be reply, the value of the file system tag may be ext4, the value of the DiskType tag of PVC may be HDD, and the value of the Redundancy tag may be reply. At this time, the management and control node can determine that the storage class a can meet the requirement of the PVC on the storage capability attribute, and can determine that the storage class a is matched with the storage capability attribute of the PVC. It can be seen that, when defining the storage capability attribute tags of the PVC, the user may define only some storage capability attribute tags that pay attention to themselves, or storage capability attribute tags that have a greater influence on the service. While for an administrator, when defining storage capability attribute tags for a storage class, it may define all storage capability attribute tags for later matching with a PVC. For example, it is assumed that the user service program needs to write data frequently, at this time, when defining the storage capability attribute tag of the PVC, the user may define the value of the DiskType tag as SSD, where SSD has a faster writing rate than HDD, and may improve the data writing efficiency.

It will be appreciated that when the PVC and the storage class further include storage capability attributes such as a read/write rate, the read/write rate in the PVC may indicate a minimum read/write rate that is required, the read/write rate in the storage class may indicate a minimum read/write rate that may be provided, or may indicate a range of read/write rates that may be provided, at which time, when the read/write rate that may be provided by the storage class meets the requirements of the PVC, it may be determined that the storage class and the PVC match. It will also be appreciated that in some embodiments, for storage capability attributes having different levels of detail, a higher level of matching may be more detailed, e.g., assuming a storage class with medium storage capability attributes of a dual magnetic arm HDD and a PVC with medium storage capability attributes of a HDD, it may be determined that the PVC matches the storage class. Conversely, when the media storage capability attribute of a storage class is HDD and the media storage capability attribute of a PVC is dual magnetic arm HDD, it cannot be determined that the PVC matches the storage class.

704. The management and control node determines one or more storage classes which meet the capacity requirement according to the capacity detection interfaces of the one or more storage classes.

After the management and control node determines one or more storage classes meeting the condition according to the storage capability attribute tag in the storage persistent volume declaration, the management and control node may determine one or more storage classes meeting the capacity requirement according to the capacity detection interface of the one or more storage classes.

Specifically, since some of the underlying storage space corresponding to the storage class (e.g., the storage pool corresponding to the storage class) that conforms to the storage capability attribute may be insufficient, the free capacity may be smaller than the storage capacity size declared in the PVC (i.e., the value of the storage attribute). Thus, to avoid a subsequent PV creation failure, the management node may determine one or more storage classes in which the capacity requirements are met based on the capacity probe interface of each storage class. In the SC description file, the capacity detection interface of the storage class-with-ceph is 72.16.143.121:8080/cspace, and the management node can determine the free capacity of the storage pool kubernetes by accessing 72.16.143.121:8080/cspace.

For example, suppose that 4 storage classes in the k8s cluster meet the storage capability attribute requirement of the PVC, the four storage classes are storage class 5, storage class 6, storage class 7, and storage class 8, respectively. Wherein storage class 5 corresponds to storage pool 5, storage class 6 corresponds to storage pool 6, storage class 7 corresponds to storage pool 7, and storage class 8 corresponds to storage pool 8. The free capacity of the storage pool 5 can be inquired to be 20GB according to the capacity detection interface of the storage class 5 by the control node, the free capacity of the storage pool 6 can be inquired to be 15GB according to the capacity detection interface of the storage class 6 by the control node, the free capacity of the storage pool 7 can be inquired to be 5GB according to the capacity detection interface of the storage class 7 by the control node, and the free capacity of the storage pool 8 can be inquired to be 12GB according to the capacity detection interface of the storage class 8 by the control node. The storage capacity stated in the PVC is 10GB, so the management and control node can determine that storage class 7 of the four storage classes does not satisfy the capacity requirement of the PVC, and storage class 5, storage class 6, and storage class 8 satisfy the capacity requirement of the PVC.

705. The management and control node determines a target storage class (a first storage class) according to the priority of one or more storage classes meeting the capacity requirement, and refreshes the target storage class into the storage persistent volume declaration.

After determining one or more storage classes meeting the capacity requirement according to the capacity detection interfaces of the storage classes, the management and control node can determine a target storage class according to the priority of the one or more storage classes, and can refresh the target storage class into the storage persistent volume declaration and bind the storage persistent volume declaration with the target storage class. The target storage class may be the highest priority storage class of the one or more storage classes.

In particular, each storage class may have a corresponding priority, and thus, for one or more storage classes meeting capacity requirements, the management node may determine the storage class with the highest priority as the target storage class. It should be appreciated that in some embodiments, for one or more storage classes meeting capacity requirements, there may be multiple storage classes with highest priority, at which point the management node may determine any of these storage classes as the target storage class.

It should be noted that in some embodiments, priorities may not be defined for storage classes. At this time, in a case where there are a plurality of storage classes satisfying the capacity demand, in one possible implementation, one storage class may be randomly selected from the plurality of storage classes as the target storage class, and bound to the PVC. In another possible implementation, a storage class may be selected in which the free capacity (i.e., the free capacity corresponding to the storage pool) is the largest, so that load balancing may be achieved. In still another possible implementation manner, a storage class in which the corresponding storage medium is an SDD may be selected, so that the read-write efficiency of data may be improved. The embodiment of the present application is not limited to a manner of selecting the storage class.

It should also be noted that in some embodiments, a capacity detection interface may not be defined for a storage class. At this time, for one or more storage classes satisfying the condition, the storage class of which the priority is highest may be directly determined as the target storage class. It should also be noted that, in other embodiments, the above steps 704 and 705 may not be performed, and one storage class may be selected directly from one or more storage classes that satisfy the condition, as the target storage class.

It will be appreciated that in some embodiments, the management node may first determine one or more storage classes of all storage classes of the k8s cluster that satisfy the PVC capacity requirement, then may match the storage capability attribute of the PVC with the storage capability attribute of the one or more storage classes that satisfy the PVC capacity requirement, so that one or more storage classes that match the PVC storage capability attribute may be obtained, and then may select a storage class (e.g., a storage class with the highest priority) from the one or more matched storage classes as the target storage class.

It should be understood that the operations performed by the management node in steps 701-705 may be operations performed by a storage class selection module in the management node.

706. And the management and control node creates the storage persistent volume through the storage drive corresponding to the storage class corresponding to the storage persistent volume statement.

In the case where a storage persistent volume claim includes a storage class (e.g., a target storage class for which it matches as described above), the management node may create the storage persistent volume through a storage driver corresponding to the storage class to which the storage persistent volume claim corresponds.

Specifically, the management and control node can generate corresponding storage persistent volume description information through a storage class corresponding to the PVC, and send the storage persistent volume description information to a storage driver (provisioner) corresponding to the storage class for processing. For example, the PVC-with-ceph matching target storage class corresponding to the PVC description file is the storageclass-with-ceph corresponding to the SC description file. The provisioner corresponding to the storageclass-with-ceph is kubernetes. The management and control node can generate corresponding storage persistent volume description information according to the related information of the storage class-with-ceph (namely, the related information in the SC description file) and the related information of the PVC-with-ceph (namely, the related information in the PVC description file). For example, the storage space corresponding to the PV may be 10Gi, the corresponding storage pool may be kubernetes, the corresponding file system may be ext4, and so on.

And then, when the user creates the Pod, the created Pod can be directly used by the created PVC, and the created Pod can be stored based on the PV corresponding to the PVC based on the binding relation between the PVC and the PV.

It should be noted that in some embodiments, the free capacity corresponding to the storage class specified by the user in the PVC may be insufficient, at which time the capacity requirement of the PVC may not be satisfied, so in order to avoid a subsequent PV creation failure, the user may specify a storage class in the PVC, and may define one or more storage capability attributes in the PVC. After the control node receives the PVC, the control node may query the free capacity corresponding to the storage class through the capacity detection interface of the storage class specified in the PVC, and if the free capacity is greater than or equal to the capacity declared in the PVC, the control node may perform related processing through the provider corresponding to the specified storage class. If the free capacity is less than the capacity declared in the PVC, the policing node may perform steps 703-705 described above, matching an appropriate storage class for the PVC.

It will be appreciated that in the case where a plurality of policing nodes are included in the k8s cluster, steps 701-706 described above may be performed by any of the policing nodes in the k8s cluster, or may be performed cooperatively by a plurality of the policing nodes in the k8s cluster.

In the above method flow, the storage attribute that can be provided by the storage class can be defined when the storage class is created, and the storage attribute required by the storage persistent volume declaration can be defined when the storage persistent volume declaration is created, so that the management node can automatically match the appropriate storage class according to the storage attribute required by the storage persistent volume declaration, thereby helping the user to select. In addition, when the storage class is selected, the residual capacity (free capacity) corresponding to the storage class can be queried through the capacity detection interface corresponding to the storage class, so that the problem that the PV fails to create due to insufficient free capacity can be avoided, and the capacity requirement for storing persistent volume declarations can be met. In addition, since a specific storage class (storage class name) does not need to be specified in advance in the storage persistent volume declaration, it is possible to support the user to automatically create Pod and the storage persistent volume declaration in the program.

Based on the above system architecture, please refer to fig. 8, fig. 8 is a flowchart of another PV creating method disclosed in an embodiment of the present application. As shown in fig. 8, the PV creation method may include, but is not limited to, the following steps:

801. The management node receives a storage persistent volume declaration.

Unlike step 701 described above, the storage attributes that can be provided by the storage class can be defined in a separate SC storage attribute table, and the storage attributes required by the PVC can be defined in a separate PVC storage attribute request table.

Specifically, when creating a storage class, an administrator may define storage attributes that may be provided for each storage class and may save it into the SC storage attribute table. For example, suppose that 4 storage classes are included, namely, storage class a, storage class b, storage class c, and storage class d, and the corresponding storage attributes are shown in the following table 1:

TABLE 1

Name of the name

Disk type

Redundancy scheme

……

File system

Capacity detection interface

Priority level

Storage class a

HDD

replication

……

ext4

72.16.143.121:8080/cpacity

Low and low

Storage class b

HDD

replication

……

ext4

72.16.143.121:8080/cpacity

Low and low

Storage class c

SSD

EC

……

xfs

72.16.143.122:8080/cpacity

High height

Storage class d

SSD

EC

……

xfs

72.16.143.122:8080/cpacity

High height

As can be seen from table 1 above, the SC storage attribute table may include a plurality of columns, and the first column may be the name of the storage class, or may be information that may uniquely identify one storage class, such as the identification of the storage class, and may be used as an index of the SC storage attribute table. The next-to-last column may be a storage capability attribute of the storage class, indicating the storage capability attribute that the storage class may provide, and the next-to-last column may be a storage capacity attribute (capacity probe interface) of the storage class, and the next-to-last column may be a priority of the storage class. For example, the disk type (DiskType) corresponding to the storage class a is HDD, the Redundancy mode (Redundancy) is Redundancy, the file system (File System) is ext4, the capacity detection interface is 72.16.143.121:8080/cParty, and the priority is low.

When creating the PVC, the user can write the storage attribute required by the PVC into the PVC storage attribute request table. For example, suppose that 4 PVC's are included, PVC-1, PVC-2, PVC-3 and PVC-4, respectively, with corresponding storage attributes as shown in Table 2 below:

TABLE 2

As can be seen from table 2 above, the PVC storage attribute table may include a plurality of columns, and the first column may be a name of PVC, or may be information that can uniquely identify one PVC, such as an identification of PVC, which may be used as an index of the PVC storage attribute table. The columns following the second column may be the storage capability attributes of the PVC indicating the storage capability attributes required by the PVC. For example, the redundancy mode corresponding to PVC-1 is replying, and the file system is ext4. Wherein, the NULL of the disk type corresponding to the PVC-1 indicates that the PVC-1 has no requirement on the disk type, and the HDD and the SSD can both be used.

802. The control node determines whether or not a storage class is specified in the storage persistent volume declaration, and if the storage class is not specified, it executes step 803, and if the storage class is specified, it executes step 806.

The principle of step 802 and step 702 is substantially the same, and reference is made to the description of step 702.

803. The control node determines one or more storage classes meeting the condition according to the SC storage attribute table and the PVC storage attribute table.

In the event that the management node receives the storage persistent volume declaration and determines that no storage class is specified in the storage persistent volume declaration, the PVC storage attribute table and the SC storage attribute table may be queried and one or more storage classes that satisfy the condition may be determined.

For example, for PVC-1, the management node can determine the storage capability attribute required by PVC-1 by querying the PVC storage attribute table, wherein the redundancy mode is replication, and the file system is ext4. Further, the management and control node can determine that the redundancy mode provided by the storage class a and the storage class b is replying and the file system is ext4 by querying the SC storage attribute table, and further can determine that the PVC-1 is matched with the storage class a and the storage class b.

804. The management and control node determines one or more storage classes which meet the capacity requirement according to the capacity detection interfaces of the one or more storage classes.

805. And the management and control node determines a target storage class according to the priority of one or more storage classes meeting the capacity requirement, and refreshes the target storage class into the storage persistent volume statement.

806. And the management and control node creates the storage persistent volume through the storage drive corresponding to the storage class corresponding to the storage persistent volume statement.

Steps 804-806 are substantially the same as steps 704-706 in principle, and reference may be made to the relevant descriptions in steps 704-706 above.

It will be appreciated that in some embodiments, the storage capability attributes required by a PVC may be defined in a label (labes) of the PVC, and the storage attributes that an SC may provide may be defined in an SC storage attribute table. In other embodiments, the storage capability attributes required by the PVC may be defined in a PVC storage attribute table, and the storage attributes that the SC may provide may be defined in the label of the SC, which is not limited herein.

It should be noted that, the related information (i.e., the same information or similar information) and the related description in the above different embodiments may refer to each other.

It should be understood that the above-mentioned processing flows are illustrated in fig. 6, fig. 7, and fig. 8 by taking the management node as an execution body of the interaction schematic, but the application is not limited to the execution body of the interaction schematic. For example, the control node in fig. 6, 7 and 8 may also be a chip, a system on a chip, or a processor that supports the control node to implement the method, or may be a logic module or software that can implement all or part of the control node functionality.

Based on the above system architecture, please refer to fig. 9, fig. 9 is a schematic structural diagram of a computing device according to an embodiment of the present application. Wherein the computing device 900 may include: a processor 901, a communication interface 902, and a memory 903. The processor 901, the communication interface 902 and the memory 903 may be connected to each other or to each other via a bus 904.

By way of example, memory 903 is used to store computer programs and data for computing device 900, and memory 903 may include, but is not limited to, random access memory (random access memory, RAM), read-only memory (ROM), erasable programmable read-only memory (erasable programmable read only memory, EPROM), or portable read-only memory (compact disc read-only memory, CD-ROM), etc. The communication interface 902 is used to support communication by the computing device 900, such as receiving or transmitting data.

By way of example, the processor 901 may be a CPU, complex programmable logic device, general purpose processor, digital signal processor, application specific integrated circuit, field programmable gate array or other programmable logic device, transistor logic device, hardware component, or any combination thereof. A processor may also be a combination that performs a computational function, such as a combination comprising one or more microprocessors, a combination of a digital signal processor and a microprocessor, and so forth.

In one embodiment, the computing device 900 may be a management node, and the processor 901 may be configured to read the program stored in the memory 903, and perform the operations performed by the management node in the method embodiments shown in fig. 6, fig. 7, or fig. 8, which are described above and will not be described in detail herein.

It should be noted that the computing device 900 shown in fig. 9 is merely an implementation of an embodiment of the present application, and in practical applications, the computing device 900 may further include more or fewer components, which is not limited herein.

The present application also discloses a computer-readable storage medium having stored thereon instructions that, when executed, perform the method of the above-described method embodiments.

The present application also discloses a computer program product comprising instructions which, when executed, perform the method of the above-described method embodiments.

It will be apparent that the embodiments described above are only some, but not all, of the embodiments of the present application. Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the application for the embodiment. The appearances of such phrases in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those of skill in the art will explicitly and implicitly understand that the embodiments described herein may be combined with other embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure. The terms "first," second, "" third and the like in the description and in the claims and drawings are used for distinguishing between different objects and not for describing a particular sequential order. Furthermore, the terms "comprising," "including," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion. For example, a series of steps or elements may be included, or alternatively, steps or elements not listed or, alternatively, other steps or elements inherent to such process, method, article, or apparatus may be included. It should be understood that the equal sign of the above condition judgment may be larger than one end or smaller than one end, for example, the above condition judgment for a threshold value being larger than, smaller than or equal to one end may be changed to the condition judgment for the threshold value being larger than or equal to one end or smaller than one end, which is not limited herein. It should be understood that the above communication manner may be indirect communication and direct communication, where direct communication may be understood as communication between two devices without other devices, and indirect communication may be understood as communication between two devices with other devices.

It is to be understood that only some, but not all, of the details relating to the present application are shown in the accompanying drawings. It should be appreciated that some example embodiments are described as processes or methods depicted as flowcharts. Although a flowchart depicts operations (or steps) as a sequential process, many of the operations can be performed in parallel, concurrently, or at the same time. Furthermore, the order of the operations may be rearranged. The process may be terminated when its operations are completed, but may have additional steps not included in the figures. The processes may correspond to methods, functions, procedures, subroutines, and the like.

As used in this specification, the terms "component," "module," "system," "unit," and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, or software in execution. For example, a unit may be, but is not limited to being, a process running on a processor, an object, an executable, a thread of execution, a program, and/or being distributed between two or more computers. Furthermore, these units may be implemented from a variety of computer-readable media having various data structures stored thereon. The units may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., second unit data from another unit interacting with a local system, distributed system, and/or across a network).

The foregoing embodiments have been provided for the purpose of illustrating the technical solution and advantageous effects of the present application in further detail, and it should be understood that the foregoing embodiments are merely illustrative of the present application and are not intended to limit the scope of the present application, and any modifications, equivalents, improvements, etc. made on the basis of the technical solution of the present application should be included in the scope of the present application.

Claims

1. A method of creating a storage durable volume, the method comprising:

configuring available storage attributes for a plurality of storage classes respectively;

receiving a storage persistent volume statement of a storage persistent volume to be created, wherein the storage persistent volume statement comprises storage attributes required by the storage persistent volume to be created;

determining a target storage class meeting the condition from the plurality of storage classes according to the storage attribute required by the to-be-created storage persistent volume;

and creating a storage persistent volume through a storage drive corresponding to the target storage class.

2. The method of claim 1, wherein the determining, from the plurality of storage classes, a target storage class that satisfies a condition according to the storage attributes required for the storage durable volume to be created, comprises:

Determining one or more storage classes meeting a condition according to the storage attribute required by the to-be-created storage persistent volume;

and determining a target storage class according to the one or more storage classes.

3. The method according to claim 2, wherein the method further comprises:

judging whether the storage class is designated in the storage persistent volume statement;

the determining one or more storage classes that satisfy a condition according to storage attributes required for a storage durable volume to be created includes:

determining one or more storage classes meeting a condition according to the storage attribute required by the storage persistent volume to be created under the condition that the storage class is not specified in the storage persistent volume statement;

in the case where a storage class is specified in the storage persistent volume declaration, determining the storage class specified in the storage persistent volume declaration as a target storage class.

4. The method of claim 3, wherein the storage attributes required for the storage durable volume to be created are defined in storage attribute tags of the storage durable volume declaration, wherein the storage attributes of the plurality of storage classes are defined in storage attribute tags of the respective storage classes, and wherein determining one or more storage classes that satisfy a condition based on the storage attributes required for the storage durable volume to be created comprises:

Matching the storage attribute labels of the storage persistent volume statement with the storage attribute labels of the storage classes respectively;

and determining one or more storage classes which are successfully matched from the plurality of storage classes as one or more storage classes which meet the condition.

5. The method of claim 3, wherein the storage attributes required for the storage persistent volume to be created are defined in a storage persistent volume declaration storage attribute request table, wherein the storage attributes of the plurality of storage classes are defined in a storage class storage attribute table, wherein determining one or more storage classes that satisfy a condition based on the storage attributes required for the storage persistent volume to be created comprises:

determining storage attributes required by the to-be-created storage persistent volume according to the storage persistent volume statement storage attribute table;

matching the storage attributes required by the to-be-created storage persistent volume with the storage attributes of a plurality of storage classes in the storage class storage attribute table respectively;

6. The method of any of claims 2-5, wherein the determining a target storage class from the one or more storage classes comprises:

Acquiring the idle capacity corresponding to the one or more storage classes according to the capacity detection interfaces of the one or more storage classes;

determining one or more storage classes meeting the capacity requirement of the storage persistent volume statement in the one or more storage classes according to the free capacity corresponding to the one or more storage classes;

and determining a target storage class according to the one or more storage classes meeting the capacity requirement of the storage persistent volume statement.

7. The method of claim 6, wherein each of the plurality of storage classes includes a priority, wherein determining a target storage class from the one or more storage classes that meet the capacity requirement of the storage persistent volume claim comprises:

and determining the storage class with the highest priority in the one or more storage classes meeting the capacity requirement of the storage persistent volume statement as a target storage class.

8. The method of any of claims 2-5, wherein each of the plurality of storage classes includes a priority, wherein determining a target storage class from the one or more storage classes includes:

and determining the storage class with the highest priority among the one or more storage classes as a target storage class.

9. The method of any of claims 1-8, wherein the storage attributes comprise underlying storage system, storage media, data redundancy scheme, file system.

10. A computing device comprising a processor, a memory, and a communication interface for receiving information from and outputting information to other electronic devices than the computing device, the processor invoking a computer program stored in the memory to implement the method of any of claims 1-9.

11. A computer cluster comprising a management node for performing the method of any of claims 1-9.