How Persistent Volume Claims Work

  1. Requesting Storage:
    • A PVC defines how much storage is required and the desired access mode. The access modes can be:
      • ReadWriteOnce (RWO): The volume can be mounted as read-write by a single node.
      • ReadOnlyMany (ROX): The volume can be mounted as read-only by multiple nodes.
      • ReadWriteMany (RWX): The volume can be mounted as read-write by multiple nodes.
  2. Binding to a Persistent Volume (PV):
    • When a PVC is created, Kubernetes searches for an available PV that matches the requirements of the PVC (e.g., size, access mode). If a match is found, the PV and PVC are bound together, making the storage accessible to the pod that uses the PVC.
    • This binding is exclusive, meaning a PV can only be bound to one PVC at a time, but the PVC can be used by multiple pods if the PV supports it.
  3. Dynamic Provisioning:
    • With dynamic provisioning, if there are no existing PVs that match the PVC’s request, Kubernetes can automatically create a new PV based on a StorageClass. This allows for on-demand provisioning of storage resources, simplifying the management of storage in large-scale deployments.

Example of a PVC Configuration

Here is an example of a PVC requesting 5Gi of storage with ReadWriteOnce access mode:


  apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Example Use Case

Imagine you are deploying a WordPress application in Kubernetes. The WordPress pod needs to store user-uploaded content (e.g., images, videos) in a way that persists across restarts. You can create a PVC to request persistent storage, and Kubernetes will ensure the pod has access to a PV that meets the requirements. This way, the user-generated content remains intact even if the WordPress pod is restarted or rescheduled.

PVC and Storage Classes

Storage Classes provide a way to define different types of storage in the Kubernetes cluster (e.g., SSD, HDD). When dynamic provisioning is enabled, a PVC can specify a StorageClass to indicate which type of storage it requires. Kubernetes will use this information to automatically provision a new PV that meets the PVC’s specifications.


  apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: fast-storage-pvc
spec:
  storageClassName: fast
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi

How to expand a Persistent Volume Claim?

To expand a PVC, make sure the following conditions are met:
The StorageClass used by the PVC must have allowVolumeExpansion set to true.
The volume plugin must support resizing (e.g., AWS EBS, GCE PD, Azure Disk).

Steps to Expand a PVC:

  1. Edit the PVC and increase the storage value:

  apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi  # Increased from the original size



2. Apply the changes with kubectl apply -f <pvc-file.yaml>.
3. Verify the expansion by checking the status of the PVC using kubectl get pvc <pvc-name>.

Note: If the PVC is in use by a running pod, the volume expansion may only take effect after the pod is restarted or recreated, depending on the underlying storage provider.

FAQ: Persistent Volume Claims in Kubernetes

1. How to dynamically create a Persistent Volume Claim?

To dynamically create a PVC, you need to specify a StorageClass in the PVC definition. Kubernetes will automatically create a matching PV when the PVC is created. Here is an example:

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: dynamic-pvc spec: storageClassName: standard accessModes: – ReadWriteOnce resources: requests: storage: 20Gi

In this example, the storageClassName is set to standard. Kubernetes will use this StorageClass to dynamically provision a new PV that meets the specified requirements.

2. Why is a Persistent Volume Claim pending and how to fix it?

A PVC may be pending if Kubernetes is unable to find or create a PV that meets the PVC’s requirements. Common reasons include:

No existing PVs match the requested storage size, access mode, or StorageClass.

Dynamic provisioning is not enabled, and no suitable PVs are available.

How to Fix:

Ensure that a suitable PV exists that matches the PVC’s specifications, or enable dynamic provisioning by configuring a StorageClass.

Check the PVC and PV specifications to verify that their requirements align.

Use the kubectl describe pvc command to check for error messages and adjust the configuration as needed.

3. What happens if I delete a Persistent Volume Claim?

When a PVC is deleted, the bound PV will be released. The fate of the PV and its data depends on the reclaim policy of the PV:

Retain: The PV will keep its data and will not be available for new PVCs until manually released by an administrator.

Delete: The PV and all its data will be deleted automatically.

Recycle (deprecated): The PV’s data will be cleared, and the volume will be made available for new claims.

Make sure to understand the reclaim policy of your PVs before deleting PVCs to avoid accidental data loss.

4. What are Finalizers used for in Persistent Volume Claims?

Finalizers are used to prevent a PVC from being deleted until specific cleanup tasks are completed. When a PVC has a finalizer, Kubernetes ensures that the finalizer’s instructions are executed before the PVC can be removed. This can be useful to ensure that any external dependencies or services (e.g., backing up data, unmounting volumes) are properly handled before the PVC is deleted.

For example, the kubernetes.io/pvc-protection finalizer ensures that the PVC cannot be deleted if it is still in use by a pod, preventing accidental data loss.

References

  1. Kubernetes Official Documentation: Persistent Volume Claims