The first article:

[Kubernetes] Detailed Explanation of the Relationship Between PV, PVC, and StorageClass—-|_Rise of Code Farmers-Programmer Homestead

The third article: [Kubernetes]PV,PVC,StorageClass Actual Combat—-|||_Rise of Code Farmers-Programmer Homestead

Official website

Storage Classes | Kubernetes

1. Know PV/PVC/StorageClass

1.1 Introduction

Purpose: In order to shield the details of the underlying storage implementation, making it easy for users to use and easy for administrators to manage, two resource objects, pv and pvc, are introduced to implement the storage management subsystem
pv: An abstraction of the underlying network shared storage, defining shared storage as a resource

pvc: A magic for users to store resources, just like pod consumes node’s cpu, memory and other resources, pvc can consume pv resources, pvc can apply for specific storage space and access mode

StorageClass: Mark the characteristics and performance of storage resources. In version 1.6, the mechanism of StorageClass and dynamic resource supply has been improved, and the on-demand creation of storage volumes has been realized

Managing storage is an obvious problem with managing computing. The PersistentVolume subsystem provides users and administrators with an API that abstracts the details of how storage is made available based on how it is consumed. To this end, we introduced two new API resources: PersistentVolume and PersistentVolumeClaim

PersistentVolume (PV) is a segment of network storage configured by the administrator in the cluster. It is a resource in the cluster, just like a node is a cluster resource. PVs are capacity plugins, like Volumes, but have a lifecycle independent of any individual pod using the PV. This API object captures storage implementation details, including NFS, iSCSI, or cloud provider-specific storage systems.

A PersistentVolumeClaim (PVC) is a storage request by a user. It is similar to pod. Pod consumes node resources, and PVC consumes PV resources. Pods can request specific levels of resources (CPU and memory). Claims can request a specific size and access mode (for example, can be read/write once or read-only many times).

Although PersistentVolumeClaims allow users to use abstract storage resources, PersistentVolumes usually require different attributes (such as performance) for different problems. Cluster administrators need to be able to provide various PersistentVolumes in different ways, not just size and access mode, without making users aware of how these volumes are implemented. For these needs, there is the StorageClass resource.

StorageClass provides a way for administrators to describe the “class” of storage they provide. Different classes may map to quality of service levels, or backup policies, or any policy determined by the cluster administrator. Kubernetes itself is pretty self-explanatory as to what classes represent. This concept is sometimes called a “profile” in other storage systems.

PVC and PV are in one-to-one correspondence.

PV and StorageClass are not limited to Namespace, PVC is limited to Namespace, Pod is also limited by Namespace when referencing PVC, only PVCs in the same Namespace can be mounted into the Pod.

StorageClass:

[root@jettoloader nfs]# k3s kubectl describe storageclass.storage.k8s.io/jettech-nfs-storage
 Name: jettech-nfs-storage
 IsDefaultClass: Yes
 Annotations: kubectl.kubernetes.io/last-applied-configuration={"allowVolumeExpansion":true,"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations  ":{"storageclass.kubernetes.io/is-default-class":"true"},"name":"jettech-nfs-storage"},"mountOptions":["hard","nfsvers=4"]  ,"parameters":{"archiveOnDelete":"true"},"provisioner":"jettech.com/nfs-jettech-external-provisioner","reclaimPolicy":"Retain","volumeBindingMode":"Immediate"}
 ,storageclass.kubernetes.io/is-default-class=true
 Provisioner: jettech.com/nfs-jettech-external-provisioner
 Parameters: archiveOnDelete=true
 AllowVolumeExpansion: True
 MountOptions:
   hard
   nfsvers=4
 ReclaimPolicy: Retain
 VolumeBindingMode: Immediate
 Events: 

PV:

[root@localhost pv]# k3s kubectl describe -n wubo persistentvolume/pv1
 Name: pv1
 Labels: name=wubo-pv1
 Annotations: 
 Finalizers: [kubernetes.io/pv-protection]
 StorageClass:
 Status: Available
 Claim:
 Reclaim Policy: Retain
 Access Modes: RWX
 VolumeMode: Filesystem
 Capacity: 5Gi
 Node Affinity: 
 messageQuery mode) Select a PV that meets the PVC requirements from the existing PVs. Once found, bind the PV to the defined PVC, and the application can use this PVC.  If there is no such PV in the system, the PVC will always process the Pending state until there is a qualified PV in the system.  Once a PV is bound to a PVC, it will be exclusively occupied by the PVC and cannot be bound to other PVCs.  When the storage space requested by the PVC is less than that of the PV, the entire PV space can be used by the PVC, which may cause a waste of resources.  If the resource provisioning mode is dynamic, after the system finds a suitable StorageClass for the PVC, it will automatically create a PV and complete the binding with the PVC.  

 
(3) Resource usage
 
Pod uses Volume definition to mount PVC to a certain path in the container for use.  The type of Volume is Persistent VolumeClaim. After a PVC is mounted on the container, it can be continuously used exclusively.  Multiple Pods can be mounted on the same PVC.  
 
volumes:
   - name: pv
     persistentVolumeClaim:
       claimName: pvc

（4）Resource release
When the storage resources are used up, the PVC can be deleted, and the PV bound to the PVC will be marked as "released", but it cannot be bound to other PVCs immediately.  Data written through a previous PVC may also be retained on the storage device, and the PV can only be used again after being cleared.  
(5) Resource recovery
For PV, the administrator can set the recovery policy, which is used to set how to deal with the remaining data after the PVC bound to it releases resources.  Only when the PV storage space is reclaimed can it be bound and used by new PVCs.  
Through two diagrams, the principle of using PVC for PV, PVC, StorageClass and Pod in static resource supply mode and dynamic resource supply mode is explained respectively.  
In the static resource supply mode, the binding is completed through PV and PVC, and the storage management mechanism used by Pod


 In the dynamic resource supply mode, resource dynamic binding is completed through StorageClass and PVC (the system automatically generates PV), and the storage management mechanism used by Pod



3. Dynamic supply of PV
[Kubernetes]PV,PVC,StorageClass actual combat----|||_Rise of code farmers-programmer's homestead