Understanding Kubernetes Persistent Volumes (PV) and Persistent Volume Claims (PVC)

Kubernetes Persistent Volumes (PV) and Persistent Volume Claims (PVC)

In Kubernetes, storage is an essential part of many applications. While Pods are ephemeral (short-lived), sometimes applications need to store data that persists even when Pods are terminated or rescheduled. Kubernetes provides a solution for persistent storage using Persistent Volumes (PVs) and Persistent Volume Claims (PVCs).

This article will explain how Persistent Volumes and Persistent Volume Claims work, and how they help manage storage in a Kubernetes environment.

---

What Are Persistent Volumes (PVs)?

A Persistent Volume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically created using a StorageClass. PVs are resources in the cluster that provide durable, persistent storage to Pods. These volumes are independent of Pods and can persist even after the Pods that use them are deleted.

Key Features of PVs:

• Cluster-wide resource: PVs are a resource in the Kubernetes cluster that are independent of individual Pods.
• Provisioned by administrators or dynamically: PVs can either be pre-provisioned by a cluster administrator or dynamically provisioned using StorageClasses.
• Can be backed by different storage types: PVs can be backed by various storage systems such as local storage, network-attached storage (NAS), cloud block storage, etc.

Example of a Persistent Volume (PV) Definition:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: standard
  hostPath:
    path: /mnt/data

In this example:

• The capacity defines the size of the volume (5Gi).
• The accessModes determine how the volume can be accessed by Pods (in this case, ReadWriteOnce).
• The persistentVolumeReclaimPolicy specifies what happens to the PV when the PVC is deleted. In this case, it is set to Retain, which means the volume will not be automatically deleted.

---

What Are Persistent Volume Claims (PVCs)?

A Persistent Volume Claim (PVC) is a request for storage by a user or application. PVCs specify the amount of storage needed, the access mode, and optionally, the storage class. Kubernetes then matches the PVC to an available PV that satisfies the claim’s requirements.

Key Features of PVCs:

• User-initiated: PVCs are created by users or applications to request storage resources.
• Bound to a PV: Once a PVC is created, Kubernetes will bind it to an available PV that meets the requirements of the claim (size, access mode, etc.).
• Dynamic provisioning: If no matching PV is available, and dynamic provisioning is configured, Kubernetes will create a new PV using a StorageClass.

Example of a Persistent Volume Claim (PVC) Definition:

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

In this example:

• The accessModes specify that the volume should be mounted as ReadWriteOnce.
• The resources.requests.storage defines the requested size of the storage (5Gi).
• The storageClassName refers to the type of storage to be used (in this case, it matches a predefined StorageClass called standard).

---

How PVs and PVCs Work Together

The relationship between Persistent Volumes (PVs) and Persistent Volume Claims (PVCs) is central to how Kubernetes handles storage.

1. Binding: When a PVC is created, Kubernetes looks for a PV that matches the size, access mode, and storage class defined in the PVC. If a matching PV is found, Kubernetes binds the PVC to the PV. Once bound, the PV is no longer available for other PVCs.

2. Dynamic Provisioning: If no existing PVs meet the claim's criteria, and dynamic provisioning is enabled through a StorageClass, Kubernetes can automatically provision a new PV that satisfies the PVC’s request.

3. Reclaim Policies: PVs have reclaim policies that determine what happens to the PV when the PVC is deleted:

   • Retain: The PV is not deleted after the PVC is deleted. The administrator must manually reclaim or delete the PV.
   • Recycle: The PV is scrubbed (cleaned) and made available for reuse by a new PVC (this policy is deprecated).
   • Delete: The PV is deleted when the PVC is deleted (this is typically used with dynamically provisioned volumes).

---

Persistent Volume Access Modes

Kubernetes defines the following access modes that determine how a volume can be mounted by Pods:

• 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 many nodes.
• ReadWriteMany (RWX): The volume can be mounted as read-write by many nodes.

The access mode of a PVC must be compatible with the access mode of the PV it is bound to.

Example:

If a PVC requests ReadWriteOnce access mode, Kubernetes will look for a PV that is either ReadWriteOnce or ReadWriteMany. However, if the PVC requests ReadOnlyMany, Kubernetes will only bind it to a PV with the same access mode.

---

Storage Classes

A StorageClass defines the types of storage available in the Kubernetes cluster and allows administrators to define different storage tiers or policies. When a PVC is created, it can specify a storageClassName, which determines how the storage is provisioned (either dynamically or pre-provisioned).

Example of a StorageClass Definition:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  fsType: ext4

In this example:

• The fast-storage StorageClass uses AWS Elastic Block Store (EBS) as the provisioner.
• The type and fsType parameters specify the type of EBS volume to use and the filesystem format.

If a PVC specifies this fast-storage class, Kubernetes will automatically provision an EBS volume of type gp2 with the ext4 filesystem.

---

Using PVs and PVCs with Pods

Once a PV is bound to a PVC, the PVC can be used in Pods to request persistent storage. The PVC is mounted into the Pod as a volume.

Example of Using PVC in a Pod Definition:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: my-app-image
      volumeMounts:
        - mountPath: /data
          name: my-pvc-volume
  volumes:
    - name: my-pvc-volume
      persistentVolumeClaim:
        claimName: my-pvc

In this example:

• The Pod uses the my-pvc PVC to request storage.
• The PVC is mounted into the container at /data.

---

Best Practices for PVs and PVCs

1. Define appropriate access modes: Choose the correct access mode based on your application’s needs. For example, if your application is multi-node and requires shared storage, ReadWriteMany should be considered.
2. Use dynamic provisioning: For ease of management, use dynamic provisioning with StorageClasses to avoid manually managing PVs.
3. Clean up unused resources: Set appropriate reclaim policies (like Delete) for dynamically provisioned volumes to ensure that unused resources are cleaned up automatically.
4. Monitor storage usage: Keep track of your storage resources to prevent your Pods from running out of space.

---

Conclusion

Kubernetes provides a robust mechanism for managing persistent storage using Persistent Volumes (PVs) and Persistent Volume Claims (PVCs). This separation of storage provisioning and consumption allows for flexible and scalable storage management in Kubernetes clusters. Whether you are using local storage or cloud-based storage, understanding how to use PVs and PVCs is crucial for managing the storage needs of your applications in Kubernetes.

---