A Persistent Volume Claim (PVC) is how a Kubernetes deployment requests storage for data the needs to persist at least for as long as the Kubernetes pod or node exists. While Kubernetes pods request system CPU and memory, a PVC is how the user requests a certain amount and/or type of storage. As pods are ephemeral and easily replaced - having a durable storage volume for application data to be saved for that eventuality is a critical component. The PVC includes a specific set of characteristics the developer requires for that particular Kubernetes application; notable options may include things like reclamation policy, access mode and amount of storage required. If a PVC that matches those characteristics exists and is available (i.e. not bound to another pod), the application will claim it for its exclusive use. The PVC, in turn, is bound to a Persistent Volume (PV) with that set of needed features.
The Persistent Volume is what is actually created and written to on the underlying storage device. The key difference between a PV and a PVC is that generally the Kubernetes node or pod binds to the Persistent Volume Claim, and the Persistent Volume Claim in turn binds to a Persistent Volume. Both PVs and PVCs can be unbound and re-used with other PVCs or nodes, respectively. Another important differentiator between PVs and PVCs is that the Persistent Volume Reclaim Policy only exists for a Persistent Volume and we will go into more detail on that later within this guide. If there is not a persistent volume that matches the required characteristics of the PVC, a persistent volume (PV) with the required characteristics will be created automatically if dynamic provisioning is enabled via a StorageClass (more on that in the next section). If dynamic provisioning is not an option, the pod or node will not become available and require a storage administrator to statically provision a persistent volume that's compatible with the claim before the node or pod can come online successfully.
The de-facto method for a vCenter/storage administrator to provide their Kubernetes developers with storage options within Tanzu is via a StorageClass. A StorageClass is mapped on a 1:1 basis from an SPBM policy which is defined from within vCenter and then assigned to one or more Namespaces. The StorageClass has a manifest of features that enables a Persistent Volume to be created from dynamically when a corresponding Persistent Volume Claim uses it. From a FlashArray perspective, some of the available policy-driven characteristics encapsulated within a StorageClass could include things like datastore type (VMFS or vVols), performance (e.g. an //X90 or a //X10), if snapshots are enabled, if a replication option such as ActiveCluster (VMFS only) or asynchronous replication (VMFS and vVols) is needed.
Now that we have defined what PVCs, PVs and StorageClasses are and how they are related to one another, the next important concept to dive into is the conditions under which they are provisioned: dynamic or static.