🔍 What Happens in the Background When You Create a Persistent Volume (PV) and Persistent Volume Claim (PVC) in Kubernetes?

As we disucssed in the previous article how to Integrate external storage to Kubernetes clusters. Now, Let's understand how it works under the hood.

Storage in Kubernetes is dynamic, persistent, and abstracted from the underlying infrastructure, making it a crucial part of modern cloud-native applications. When you create a Persistent Volume (PV) and a Persistent Volume Claim (PVC), a series of events happen in the background to ensure storage is allocated and mounted correctly.

But what exactly happens behind the scenes? How does Kubernetes handle PV and PVC binding? And in what order do these operations take place?

This article takes a deep dive into the internals of how Kubernetes manages storage dynamically.

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

What is a Persistent Volume (PV)?

A Persistent Volume (PV) is a pre-provisioned storage resource in Kubernetes. It represents physical storage that can be:

✔ A network file system (NFS)

✔ An iSCSI disk

✔ A cloud storage volume (AWS EBS, Azure Disk, GCP Persistent Disk)

✔ A SAN or NAS volume

Kubernetes administrators create PVs to define available storage resources in the cluster.

What is a Persistent Volume Claim (PVC)?

A Persistent Volume Claim (PVC) is a request for storage from an application. Instead of knowing details about physical storage, the application simply asks for a storage resource (e.g., "I need 50Gi of storage with read-write access"), and Kubernetes dynamically provisions it.

🔄 What Happens in the Background? Step-by-Step Breakdown

1️⃣ PV is Created (Pre-Provisioned Storage)

Kubernetes Admin creates the PV before applications request storage.

✅ PV YAML is applied:

📌 What Happens Internally?

• Kubernetes registers this PV in its etcd database.

• The PV remains Available in kubectl get pv output until a PVC binds to it.

• No pod or workload is using this storage yet.

2️⃣ PVC is Created (Storage Requested by an Application)

Where: Application Developer creates a PVC to request storage.

✅ PVC YAML is applied:

📌 What Happens Internally?

• Kubernetes creates an internal object representing the PVC in etcd.

• The kube-controller-manager detects the new PVC and begins binding.

• Kubernetes checks for an existing PV that matches:

• ✅ Requested storage size (50Gi)

• ✅ Access mode (ReadWriteOnce)

3️⃣ Kubernetes Automatically Binds the PVC to an Available PV

📌 What Happens Internally?

• If an exact match PV is found, Kubernetes binds the PVC to the PV.

• The PV's status changes from Available to Bound.

• The PVC is now attached to the PV.

✅ Check the binding status:

🔍 Output will show as below:

The PV is now bound to the PVC! 🎯

4️⃣ A Pod Requests the PVC (Storage is Attached to a Workload)

Where: Application Developer defines a Pod that uses the PVC.

✅ Pod YAML is applied:

📌 What Happens Internally?

• kube-scheduler assigns the Pod to a node.

• kubelet on that node sees the PVC request and attaches the corresponding PV.

• If it’s NFS/iSCSI, the node mounts the storage before starting the container.

• If it’s a cloud-based volume, Kubernetes uses the corresponding Cloud Provider API (e.g., AWS EBS attach, GCP Persistent Disk mount).

✅ Check storage inside the running pod:

You should see /data mounted inside the container!

🔄 PV and PVC Lifecycle & Reclaim Policies

Once a PVC is deleted, Kubernetes follows the reclaim policy set in the PV.

🔹 Types of Reclaim Policies:

✅ Retain – Keeps the PV after PVC is deleted (Manual cleanup required).

✅ Delete – Automatically deletes the underlying storage when PVC is deleted.

✅ Recycle – Wipes the data and makes the PV available again (deprecated).

Check the reclaim policy:

🚀 Key Differences Between PV and PVC

1️⃣ Who creates it?

• A Persistent Volume (PV) is created by the Kubernetes administrator in advance as a storage resource.

• A Persistent Volume Claim (PVC) is created by the application developer when a pod requests storage.

2️⃣ Purpose

• A PV defines an available storage resource within the cluster.

• A PVC is a request for a specific amount of storage by an application.

3️⃣ Status Lifecycle

• A PV transitions through the following states: Available → Bound → Released (if the PVC is deleted).

• A PVC transitions through: Pending → Bound → Deleted (when the claim is no longer needed).

4️⃣ Storage Type

• A PV can be backed by NFS, iSCSI, AWS EBS, Azure Disks, GCP Persistent Disk, or other storage solutions.

• A PVC does not specify the exact storage type; instead, it requests a storage volume based on the available PVs or a StorageClass.

5️⃣ Binding Process

• A PV is passive—it sits in an Available state until a PVC binds to it.

• A PVC actively looks for a matching PV and binds to it automatically if one exists.

By understanding these differences, you can efficiently manage persistent storage in your Kubernetes cluster!

💡 Summary: The Order of Operations

1️⃣ Admin creates a PV → Available for use.

2️⃣ Application requests a PVC → Kubernetes searches for a matching PV.

3️⃣ PVC binds to an available PV → Storage is now reserved.

4️⃣ Pod requests the PVC → Kubernetes mounts the storage inside the Pod.

5️⃣ Storage is dynamically attached to the running application.

🔎 Deep Dive Conclusion

Kubernetes storage is designed to be flexible, scalable, and automated. Understanding the internals of PV and PVC binding helps you troubleshoot issues, optimize storage, and build robust cloud-native applications.

🚀 Did you find this deep dive helpful? Share your thoughts in the comments! Let’s discuss real-world Kubernetes storage challenges.

#Kubernetes #Storage #DevOps #CloudNative #PersistentVolume #K8s