Kubernetes Persistent Volumes (PV), Persistent Volume Claims (PVC), Storage Classes, and Provisioning Explained

In Kubernetes, managing storage for your applications is crucial, especially when dealing with data persistence. Kubernetes provides Persistent Volumes (PVs) and Persistent Volume Claims (PVCs) to handle this seamlessly. Alongside these, Storage Classes enable flexible provisioning, whether static or dynamic. This article explores these concepts in detail with practical examples and hands-on implementation.

Persistent Volumes (PVs) and Persistent Volume Claims (PVCs)

Persistent Volume (PV)

A Persistent Volume is a storage resource in a Kubernetes cluster that abstracts underlying storage systems. It is provisioned by administrators and can be backed by various storage backends such as NFS, AWS EBS, Azure Disk, or GCP Persistent Disk.

Key Features:

• Cluster-level resource, not bound to any specific pod.
• Retains data even if the pod accessing it is deleted.

Persistent Volume Claim (PVC)

A Persistent Volume Claim is a request for storage by a user. Pods use PVCs to access PVs, and Kubernetes matches the PVC request to a suitable PV.

Key Features:

• Specifies size, access mode (ReadWriteOnce, ReadOnlyMany, or ReadWriteMany).
• Abstracts storage details for developers, focusing only on their application needs.

Storage Class (SC)

A Storage Class defines how storage is dynamically provisioned in Kubernetes. Instead of statically provisioning storage upfront, Storage Classes enable Kubernetes to automatically provision storage when a PVC is created.

Key Features:

• Facilitates dynamic provisioning of PVs.
• Configurable parameters such as storage type, size, and reclaim policies.
• Can be customized for specific use cases like high IOPS or durable storage.

Provisioning: Static vs. Dynamic

Static Provisioning

In static provisioning, administrators manually create PVs that users can claim via PVCs. This approach works well for pre-configured storage resources.

Example of Static Provisioning

Step 1: Create a PV YAML file.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: static-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /mnt/static-pv

Step 2: Create a PVC YAML file.

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

Step 3: Deploy the PV and PVC.

kubectl apply -f static-pv.yaml
kubectl apply -f static-pvc.yaml

Step 4: Verify the binding.

kubectl get pv
kubectl get pvc

The PVC binds to the PV if the specifications match.

Dynamic Provisioning

Dynamic provisioning automates PV creation when a PVC is made, using Storage Classes to define the configuration.

Example of Dynamic Provisioning

Step 1: Create a Storage Class YAML file.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: dynamic-sc
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  fsType: ext4
  zone: us-west-1a

Step 2: Create a PVC YAML file using the Storage Class.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: dynamic-sc

Step 3: Apply the configurations.

kubectl apply -f storage-class.yaml
kubectl apply -f dynamic-pvc.yaml

Step 4: Verify the creation of the PV and PVC.

kubectl get sc
kubectl get pv
kubectl get pvc

You’ll notice that the PV is automatically provisioned and bound to the PVC.

Hands-On: Using PV, PVC, and Storage Classes in a Pod

Here’s a complete example to demonstrate using a dynamically provisioned PV with a pod.

Step 1: Create the Storage Class and PVC as shown in the dynamic provisioning example above.

Step 2: Create a Pod YAML file to use the PVC.

apiVersion: v1
kind: Pod
metadata:
  name: storage-pod
spec:
  containers:
  - name: app-container
    image: nginx
    volumeMounts:
    - mountPath: "/usr/share/nginx/html"
      name: storage-volume
  volumes:
  - name: storage-volume
    persistentVolumeClaim:
      claimName: dynamic-pvc

Step 3: Deploy the pod.

kubectl apply -f pod.yaml

Step 4: Verify the storage is mounted.

kubectl exec -it storage-pod -- df -h

The storage should be mounted at /usr/share/nginx/html.

Reclaim Policies in PVs

Reclaim policies determine what happens to the PV when its associated PVC is deleted. Common policies include:

• Retain: Keeps the PV and its data intact.
• Recycle: Clears the data and makes the PV available for new claims.
• Delete: Deletes the PV and its associated storage.

Reclaim policies are set in the PV specification:

persistentVolumeReclaimPolicy: Delete

Best Practices

1. Choose Appropriate Access Modes: Use the right access mode based on your application’s requirements.
2. Dynamic Provisioning: Prefer dynamic provisioning for better scalability and reduced administrative overhead.
3. Storage Class Selection: Use storage classes tailored for your workload (e.g., high IOPS for databases).
4. Reclaim Policies: Set appropriate reclaim policies to avoid accidental data loss.

Conclusion

Kubernetes Persistent Volumes, Persistent Volume Claims, Storage Classes, and provisioning techniques offer a powerful abstraction for managing stateful workloads. Static provisioning works well for pre-configured environments, while dynamic provisioning simplifies storage management. By combining these features, Kubernetes provides a robust, flexible, and scalable storage system for your applications.