In Kubernetes, a Persistent Volume (PV) represents a piece of storage within the cluster, while a Persistent Volume Claim (PVC) serves as a request for storage resources.
There are two primary methods for using persistent storage in Kubernetes:
- Using an Existing Persistent Volume: In this approach, your application utilizes a PVC that is bound to an existing PV. The PV should have at least the minimum resources required by the PVC.
- Dynamically Provisioning New Persistent Volumes: Here, your application relies on a PVC that is bound to a StorageClass. The StorageClass contains the authorization to dynamically create new persistent volumes when needed.
About Persistent Volume Claims:
PVCs act as requests for storage resources within your Kubernetes cluster. Think of them as vouchers that your deployments can redeem to gain access to storage. A PVC is mounted into workloads as a volume, allowing the workload to claim a specified portion of persistent storage.
To enable a pod to access persistent storage, it must have a PVC mounted as a volume. This allows your application to store its data externally, ensuring that even if a pod fails, a replacement pod can seamlessly access its data stored externally, effectively masking the outage.
PVCs are essential for both scenarios involving new and existing persistent storage. If your workload requires existing storage, it mounts a PVC that references a PV, which, in turn, corresponds to pre-existing storage infrastructure. In the case of workloads needing new storage, the PVC mounts a StorageClass, which has the capability to create a new PV along with the underlying storage infrastructure.
Rancher allows you to create multiple PVCs within a project. You can either mount PVCs to a deployment during its creation or do so at a later stage while the deployment is running.
Setting up Existing Storage with a PVC and PV:
Pods can store data in volumes, but data loss can occur if a pod fails. Kubernetes addresses this by offering Persistent Volumes (PVs), which are resources representing external storage disks or file systems accessible to pods. Replacement pods can access the data in persistent storage without losing any data in case of a pod crash.
PVs can correspond to physical disks or file systems hosted on-premises or to vendor-hosted storage resources like Amazon EBS or Azure Disk. Creating a persistent volume in Rancher does not create a storage volume but rather creates a Kubernetes resource mapping to an existing volume. Therefore, provisioning storage is a prerequisite before creating a PV as a Kubernetes resource.
Binding PVs to PVCs:
When pods are configured to use persistent storage, they mount a PVC, just like any other Kubernetes volume. Each PVC is treated as a request for storage and is bound to a PV that meets or exceeds the minimum resource requirements specified in the PVC. Not every PVC is guaranteed to be bound to a PV; Kubernetes will bind them as suitable PVs become available.
To dynamically provision new storage, the PVC mounted in the pod must correspond to a StorageClass, rather than a Persistent Volume.
Provisioning New Storage with a PVC and Storage Class:
Storage Classes facilitate the dynamic creation of PVs without the need to pre-provision storage in an infrastructure provider. For instance, if a workload is bound to a PVC referencing an Amazon EBS Storage Class, the Storage Class can dynamically create an EBS volume and a corresponding PV. The Kubernetes master will then bind the newly created PV to your workload’s PVC, allowing your workload to utilize the persistent storage.
The Storage Classes in Kubernetes eliminate the need for manual intervention to create PVs. When you use a Storage Class, it defines the storage properties and provisioning mechanisms. When a Persistent Volume Claim (PVC) is created and references a specific Storage Class, the Kubernetes cluster can automatically provision a new PV that matches the requirements specified in the PVC. This automation streamlines the process and ensures that the required storage resources are dynamically created as needed, without manual intervention.