Overview

PersistentVolume (PV) is a Kubernetes API resource that represents the mapping relationship between backend storage volumes and the cluster. It is a cluster-related resource that abstracts actual storage resources into the storage infrastructure of the cluster. PV has an independent lifecycle from Pods and can achieve persistent storage of Pod data.

Administrators can manually create static PersistentVolumes or generate dynamic PersistentVolumes based on storage classes. Developers can request suitable PersistentVolumes by matching and binding with PersistentVolumeClaims (PVCs) when they need to obtain storage resources for applications.

Dynamic persistent volumes vs. static persistent volumes

The platform supports administrators to manage two types of PersistentVolumes, dynamic and static.

• Dynamic PersistentVolumes: Implemented based on storage classes. Storage classes are Kubernetes resources created by administrators that define the “description” of storage resource categories and are cluster-related resources. After developers create PersistentVolumeClaims associated with storage classes, the platform dynamically creates suitable PersistentVolumes based on the parameters configured in the PersistentVolumeClaims and storage classes, binds them with the PersistentVolumeClaims, and achieves dynamic allocation of storage resources.

• Static PersistentVolumes: Manually created by administrators, currently supporting the creation of HostPath or NFS CSI types of static PersistentVolumes. After developers create PersistentVolumeClaims that do not use storage classes, the platform matches and binds suitable static PersistentVolumes based on the parameters configured in the PersistentVolumeClaims.

  • HostPath: Uses the file directory on the node host (local storage not supported) as the backend storage, for example: /etc/kubernetes. Generally only suitable for testing scenarios in single compute node clusters.

  • NFS CSI: Network File System is a common backend storage for persistent volumes. Users and programs can access files on remote systems as if they were accessing local files.

Lifecycle of persistent volumes

1. Provision: The administrator manually creates a static persistent volume, which enters the Available state after creation; or the platform dynamically creates a suitable persistent volume based on the persistent volume claim associated with the storage class.

2. Bound: After the static persistent volume is matched and bound to the persistent volume claim, it enters the Bound state; the dynamic persistent volume is created dynamically based on the request that matches the persistent volume claim, and enters the Bound state after successful creation.

3. Use: Developers associate the persistent volume claim with the container instance of the computing component and use the backend storage resources mapped by the persistent volume.

4. Release: After the developer deletes the persistent volume claim, the persistent volume is released.

5. Reclaim: After the persistent volume is released, the persistent volume is reclaimed based on the recycling policy parameters of the persistent volume or storage class.