eSurfing Cloud CCSE uses the Kubernetes orchestration system as a management platform for clusters, applications, storage, networks, and other modules. This section introduces the basic knowledge related to CCSE container storage, helping you understand the fundamental principles and usage guidelines when using the storage capabilities of container service.
Volume
To prevent the loss of container files due to container restarts, Kubernetes introduces Volumes to provide a solution for the temporary nature of file storage within a container. A Volume acts as a channel for data transfer between a Pod and an external storage device. It also facilitates data sharing between containers within a Pod, between Pods, and between a Pod and the external environment.
A Volume defines the details of external storage and is embedded within a Pod as part of the Pod. Fundamentally, a Volume is a resource mapping of external storage in the Kubernetes system. When a workload needs to use external storage, it can retrieve relevant information from the Volume and execute the storage mounting operation.
Volume Classification | Description |
Local Storage | Volumes suitable for local storage, such as HostPath, emptyDir, etc. The characteristics of local PV are that data is stored on specific nodes in the cluster and cannot follow the migration of applications. When the node shuts down, the data is no longer available. |
Network Storage | Volumes suitable for network storage, such as Ceph, GlusterFS, NFS, iSCSI, etc. The characteristics of network PV are that data is not on a specific node in the cluster, but on a remote storage service. When using PV, you need to mount the storage service locally. |
Secret and ConfigMap | Secret and ConfigMap are special volumes. Their data is some object information from the cluster. This object data is mounted on the node in the form of a volume for application use. |
PVC | One way to define a volume is to abstract the volume into an object independent of the Pod. This object defines (associates) the actual storage information corresponding to the PV for Kubernetes load mounting. |
Principles of Using Volumes:
l A Pod can mount multiple Volumes.
l A Pod can mount multiple types of Volumes.
l Each volume mounted by the Pod can be shared among different containers.
l It is recommended to use the PVC and PV methods to mount Volumes in the Kubernetes environment.
l Although a single Pod can mount multiple Volumes, it is not recommended to mount too many Volumes on a single Pod.
PV and PVC
Not all Kubernetes Volumes have persistent characteristics. To achieve persistence, container storage needs to rely on a remote storage service. For this, Kubernetes introduces two resource objects, PV and PVC, to abstract the details of storage implementation from how it is used, and to decouple the responsibilities of storage users and system administrators. The concepts of PV and PVC are as follows:
PV: PV is an abbreviation for "Persistent Volume". In Kubernetes, PV represents a volume of a specific storage class, and its object defines the specific storage classes and volume parameters. That is, all relevant information of the target storage service is saved in PV, and Kubernetes refers to the storage information in PV to perform mounting operations.
PVC: PVC is an abbreviation for "Persistent Volume Claim". In Kubernetes, PVC is an abstract PV type, representing the volume expression of a specific type of storage. Its design intention is to separate storage from application orchestration, abstract storage details, and implement storage orchestration. In this way, the PV object in Kubernetes exists independently of application orchestration, decoupling applications and storage at the orchestration level.
Instructions for PV and PVC
l Binding PVC and PV
A PV and a PVC maintain a one-to-one connection. Each PVC can only mount a single PV, and each PV can only be mounted by a single PVC. When configuring storage for an application, we need to declare a PVC. Kubernetes will select a PV that best matches the requirements of the PVC and bind them together. Therefore, in terms of responsibility, PVC is the storage object that the application requires and falls within the application scope. PV represents the storage object in the storage plane and belongs to the entire storage domain.
A PVC can be used by a Pod only after it has been bound to a PV. The process of binding a PVC to a PV, which is essentially consuming the PV, follows certain rules. A PV can only be bound to a PVC if all of the following rules are satisfied.
n VolumeMode: The VolumeMode of the PV consumed must match that of the PVC.
n AccessMode: The AccessMode of the PV consumed must match that of the PVC.
n StorageClassName: If this parameter is defined in the PVC, the PV must have the corresponding parameters defined to be eligible for binding.
n LabelSelector: The PV is selected for binding from the list of available PVs by label matching.
n Size: The capacity of the PV consumed must be greater than or equal to the storage capacity requested by the PVC.
l Size Fields in PV and PVC Definitions
The functions of size fields in PVC and PV are as follows:
n When binding PVC and PV, the sizes of each are considered for filtering.
n When dynamically creating PV through PVC and StorageClass, some storage classes will refer to the size of PVC to create PV and back-end storage of corresponding sizes.
n For storage classes that support Resize operation, the size of the PVC will be used as the capacity value for the expanded PV and back-end storage.
The size values of a PVC and PV are used as configuration parameters during certain PVC and PV management operations.
When the PV data flow actually writes data, it does not refer to the size fields of the PVC or PV. Instead, it relies on the actual capacity of the underlying storage medium.
Usage of Volumes
Common ways to use the container storage PV are as follows:
l Static PV
Static PV generally refers to the PV created by the administrator. All volumes support the creation of static PV.
Storage mediums (such as cloud disks, NAS disks, etc.) are pre-allocated to the static PV by the cluster administrator based on the storage demand within the cluster, and corresponding PV objects are created. Created PV objects await consumption by PVC. If a PVC requirement is defined in the workload, Kubernetes will bind the PVC to a matching PV based on relevant rules, thus achieving the access of the application to storage services.
l Dynamic PV
Dynamic PV generally refers to the PV automatically created by storage plug-ins.
In dynamic volumes, the back-end storage pools are usually configured by the cluster administrator, who creates corresponding StorageClass. When a PVC needs to consume a PV, a storage plug-in dynamically creates a PV based on the requirements defined by the PVC and the storage details of the StorageClass. Definition of StorageClass is as follows:
n StorageClass
If the StorageClassName field is added to the PVC when you declare a PVC, it means that when the PVC cannot find a matching PV within the cluster, an appropriate Provisioner plug-in will be triggered to create a suitable PV for binding based on the definition of StorageClassName. This is the creation of a dynamic volume.
Dynamic volumes are created by the Provisioner plug-in and associated with a PVC through the StorageClassName.
StorageClass (literally storage class) represents a template for creating PV. During the process in which PVC triggers the automatic creation of PV, the content within the StorageClass object is used for the creation. Its content is as follows:
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: alicloud-disk-topology parameters: type: cloud_ssd provisioner: diskplugin.csi.ctyun.com reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer |
Parameter | Description |
reclaimPolicy | It is used to specify the persistentVolumeReclaimPolicy field value of the created PV, and supports Delete and Retain. l "Delete" indicates that the dynamically created PV will be automatically deleted upon destruction. l "Retain" indicates that the dynamically created PV will not be automatically deleted, instead requiring manual processing by the administrator. |
allowVolumeExpansion | Define whether the PV created by this storage class supports dynamic scaling up. The default setting is false. The dynamic scaling up is implemented by the underlying storage plug-in. The setting here merely enables or disables that functionality. |
volumeBindingMode | Refer to the time of the dynamic PV creation. It supports Immediate and WaitForFirstConsumer, representing instant creation and delayed creation respectively. |
n Delayed Binding
Certain types of storage (such as eSurfing Cloud Disk) have mounting restrictions. Specifically, only volumes and nodes in the same availability zone as can be mounted to certain types of storage. This type of PV often encounters the following problems:
l A volume is created in availability zone A, but all node resources in zone A are exhausted, leading to a failure in mounting the Pod start-up.
l When planning PVCs and PVs, cluster administrators are uncertain about which availability zones to create multiple PVs for standby.
The volumeBindingMode field in the StorageClass provides a solution to this problem. By setting volumeBindingMode to WaitForFirstConsumer, the storage plug-in does not immediately create the volume upon receiving the PVC Pending. Instead, it initiates the creation process when the PVC is consumed by the Pod.
Advantages of Dynamic PV
n Dynamic PV enables Kubernetes to automatically manage the lifecycle of PVs, with creation and deletion of PVs processed by the Provisioner.
n Automated creation of PV objects reduces configuration complexity and the system administrator's workload.
n Dynamic volumes ensure that the storage capacity of the PVC matches the PV capacity managed by the Provisioner, optimizing storage capacity planning.
l Mounting SubPath Volume
Kubernetes provides configuration of the property volumeMounts.subPath. This allows you to designate a subpath within the referenced volume, rather than using its root path.
PV Quota Description
l The number of volumes that can be mounted on each node is limited for some storage classes.