Persistent Volumes (PV) & Persistent Volume Claims (PVC) Explained in Kubernetes

Introduction

Containers are designed to be temporary. When a Pod is deleted, all data stored inside the container can be lost. This creates a major challenge for applications that need persistent storage, such as databases, file uploads, logs, and backups.

Kubernetes solves this problem using:

Persistent Volumes (PV)
Persistent Volume Claims (PVC)

These resources provide storage that remains available even when Pods are restarted, deleted, or moved to another node.

In this guide, we will learn Persistent Volumes, Persistent Volume Claims, architecture, workflow, real-world examples, and interview questions.

Why Do We Need Persistent Storage?

Consider a MySQL Pod:

MySQL Pod
     │
     ▼
Database Files

If the Pod crashes:

Pod Deleted ❌
Database Lost ❌

This is unacceptable in production environments.

Kubernetes uses Persistent Volumes to solve this issue.

What is a Persistent Volume (PV)?

A Persistent Volume (PV) is a storage resource in Kubernetes that exists independently of Pods.

A PV can be backed by:

AWS EBS
Azure Disk
Google Persistent Disk
NFS
Ceph
Local Storage

A PV is created by an administrator or dynamically provisioned by Kubernetes.

Persistent Volume Architecture

Storage
   │
   ▼
Persistent Volume (PV)
   │
   ▼
Persistent Volume Claim (PVC)
   │
   ▼
Pod

The Pod never directly uses storage.

Instead:

Pod → PVC → PV → Storage

What is a Persistent Volume Claim (PVC)?

A PVC is a request for storage made by a user or application.

Think of it as:

PV = Actual Storage
PVC = Storage Request

Applications request storage through PVCs.

Real-World Analogy

Imagine a hotel.

Hotel Rooms

Persistent Volumes

Guest Reservation

Persistent Volume Claim

Guest

Pod

A guest does not directly choose a room.

The reservation system allocates an available room.

Similarly:

Pod → PVC → PV

Creating a Persistent Volume

Example:

apiVersion: v1
kind: PersistentVolume

metadata:
  name: my-pv

spec:
  capacity:
    storage: 5Gi

  accessModes:
    - ReadWriteOnce

  hostPath:
    path: /data

Apply:

kubectl apply -f pv.yaml

PV Components

Capacity

Defines storage size.

Example:

capacity:
  storage: 5Gi

Access Modes

Defines how storage can be accessed.

ReadWriteOnce (RWO)

One node can read/write.

ReadOnlyMany (ROX)

Multiple nodes can read only.

ReadWriteMany (RWX)

Multiple nodes can read/write.

Storage Class

Defines storage provisioning behavior.

Examples:

gp3 (AWS EBS)
standard (GKE)
managed-premium (Azure)

Creating a Persistent Volume Claim

Example:

apiVersion: v1
kind: PersistentVolumeClaim

metadata:
  name: my-pvc

spec:

  accessModes:
    - ReadWriteOnce

  resources:
    requests:
      storage: 2Gi

Apply:

kubectl apply -f pvc.yaml

PVC Binding Process

PVC Request
     │
     ▼
Matching PV Found
     │
     ▼
PVC Bound to PV

Kubernetes automatically binds the PVC to a suitable PV.

Using PVC in a Pod

Example:

apiVersion: v1
kind: Pod

metadata:
  name: nginx-pod

spec:

  containers:
  - name: nginx
    image: nginx

    volumeMounts:
    - mountPath: "/usr/share/nginx/html"
      name: web-storage

  volumes:
  - name: web-storage

    persistentVolumeClaim:
      claimName: my-pvc

Complete Workflow

Storage
   │
   ▼
Persistent Volume
   │
   ▼
Persistent Volume Claim
   │
   ▼
Pod
   │
   ▼
Application

This is the standard Kubernetes storage workflow.

Static Provisioning

In static provisioning:

Administrator creates PV.
User creates PVC.
PVC binds to PV.

Example:

Admin → PV
User → PVC

Dynamic Provisioning

In dynamic provisioning:

User creates PVC.
Kubernetes automatically creates PV.

Requires a StorageClass.

StorageClass Example

apiVersion: storage.k8s.io/v1
kind: StorageClass

metadata:
  name: fast-storage

provisioner: kubernetes.io/aws-ebs

parameters:
  type: gp3

Real-World Example

Suppose an E-Commerce application uses:

Frontend

Stateless application.

No persistent storage needed.

MySQL Database

Stores:

Orders
Customers
Products

Requires persistent storage.

Architecture:

MySQL Pod
     │
     ▼
PVC
     │
     ▼
PV
     │
     ▼
AWS EBS Volume

Even if the Pod is deleted:

Pod Deleted ❌
Data Remains ✅

Reclaim Policies

Defines what happens when a PVC is deleted.

Retain

Storage remains available.

Delete

Storage is automatically removed.

Recycle

Deprecated in modern Kubernetes.

PV vs PVC

Feature	PV	PVC
Purpose	Actual Storage	Storage Request
Created By	Admin/Kubernetes	User/Application
Represents	Physical Storage	Logical Request
Used By Pod	Indirectly	Directly

Useful Commands

View PVs

kubectl get pv

View PVCs

kubectl get pvc

Describe PV

kubectl describe pv my-pv

Describe PVC

kubectl describe pvc my-pvc

Delete PVC

kubectl delete pvc my-pvc

Best Practices

Use Dynamic Provisioning

Reduces manual storage management.

Use Appropriate Storage Classes

Choose storage based on workload requirements.

Backup Critical Data

Especially for databases.

Monitor Storage Usage

Avoid running out of storage.

Use Retain Policy for Important Data

Prevents accidental deletion.

Common Mistakes

❌ Storing databases without PV/PVC

❌ Using incorrect access modes

❌ Not monitoring storage consumption

❌ Deleting PVC without understanding reclaim policy

❌ Using local storage for critical workloads

Kubernetes Interview Questions

What is a Persistent Volume?

A Persistent Volume is a storage resource in Kubernetes that exists independently of Pods.

What is a Persistent Volume Claim?

A Persistent Volume Claim is a request for storage made by a user or application.

What is the relationship between PV and PVC?

PVC requests storage and binds to a matching PV.

Why are PVs needed?

They provide persistent storage that survives Pod restarts and deletions.

What is Dynamic Provisioning?

Dynamic Provisioning automatically creates Persistent Volumes when a PVC is created.

What are the access modes of a PV?

ReadWriteOnce (RWO)
ReadOnlyMany (ROX)
ReadWriteMany (RWX)

Can a Pod directly use a PV?

No. A Pod accesses storage through a PVC.

Conclusion

Persistent Volumes and Persistent Volume Claims are fundamental Kubernetes storage concepts. They provide reliable and persistent storage for stateful applications such as databases, file systems, and enterprise workloads.

PV represents actual storage.
PVC represents a storage request.
StorageClasses enable dynamic provisioning.
Pods consume storage through PVCs.

Understanding PVs and PVCs is essential before moving to StatefulSets, Helm, RBAC, and advanced Kubernetes production architectures.