Understanding Kubernetes Volumes: Persistent Volume and Persistent Volume Claim

Consider a case where data gets added or updated on PostgreSQL, when pod restart all changes will be gone.

Why?

Kubernetes doesn’t automatically persist data when a pod restarts. By default, when a pod dies, its storage disappears with it. This is because Kubernetes treats pods as ephemeral, they come and go, and their associated storage doesn’t stick around unless you explicitly configure it to.

For databases, logs, and any application that needs to retain state, this is a huge problem. That’s where Persistent Volumes (PV) and Persistent Volume Claims (PVC) come in. They allow Kubernetes to handle storage separately from pods, ensuring your data doesn’t vanish every time a pod is replaced.

If you’re coming from Docker, you might wonder how this compares to Docker volumes,
"Doesn’t Docker have volumes for persistent storage?"

Yes, it does. But Kubernetes handles storage in a more decentralized, scalable way. Unlike Docker, where volumes are tied to a single host, Kubernetes volumes are designed to be cluster-wide and can be provisioned dynamically.

In this guide, we’ll break down:
✅ What Persistent Volumes (PV) are and how they’re managed by administrators.
✅ How developers request storage using Persistent Volume Claims (PVC).

By the end, you’ll not only understand how Kubernetes storage works but also be able to set up persistent storage for your own applications. Let’s get started 🚀

---

How Does Kubernetes Handle Storage?

Kubernetes uses Volumes to provide persistent storage, but here’s the thing:

➡️ A Kubernetes Volume is just an abstraction—it doesn’t store data itself. It needs to be backed by actual physical storage.

So, where does this storage come from?

Types of Storage in Kubernetes

1️⃣ Local Storage (Node-Specific)

• Tied to a single node.
• If a pod moves to another node, the data doesn’t follow.
• Examples:
  • emptyDir (temporary storage that lasts as long as the pod exists).
  • hostPath (uses a directory on the host machine).

2️⃣ Remote Storage (Cluster-Wide)

• Decoupled from any single node, so pods can move freely without losing data.
• Provided by external storage systems.
• Examples:
  • Cloud storage: AWS EBS, Google Persistent Disks, Azure Disk.
  • Network storage: NFS, Ceph, GlusterFS.

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

To make storage management easier, Kubernetes introduces:

✔ Persistent Volumes (PV): The actual storage backend.

✔ Persistent Volume Claims (PVC): A way for pods to request storage dynamically.

Think of it like a hotel:

• A PV is a hotel room.
• A PVC is a reservation.
• When a pod needs storage, it "books" a room (PV) through a PVC.

📌 Kubernetes Volumes are not actual storage—they just connect your pod to a real storage system.

---

Persistent Volume (PV) – The Admin’s Role

We now know that Kubernetes doesn’t provide storage by itself, so who sets it up?

A PV is a pre-configured storage unit set up by the cluster administrator. Once it's available, developers can claim it using a Persistent Volume Claim (PVC) (which we’ll cover next). But first, let’s see how admins actually set up storage in Kubernetes.

How Do Admins Provision Storage?

Admins set up storage by:

1️⃣ Setting up the storage backend (Local disk, NFS, AWS EBS, etc.).

2️⃣ Defining a Persistent Volume (PV) that connects to this storage.

3️⃣ Making the PV available for developers to claim via PVCs.

Example: Creating a Persistent Volume (PV)

Here’s a simple YAML configuration for a local storage PV:

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

Breaking It Down

🔹 capacity.storage: 5Gi → Provides 5GB of storage.

🔹 accessModes: ReadWriteOnce → Can be mounted by only one node at a time.

🔹 persistentVolumeReclaimPolicy: Retain → Storage remains even after the pod using it is deleted.

🔹 storageClassName: local-storage → Specifies which storage class to use.

🔹 hostPath: /mnt/data → Uses a local directory as storage.

Of course, admins can also configure networked storage like NFS, AWS EBS, or Google Persistent Disk instead of using a local directory.

📌 PVs exist independently of pods, ensuring data persists even if a pod is deleted or rescheduled.

---

Persistent Volume Claim (PVC) – The Developer’s Role

The admin has set up a Persistent Volume (PV)—now how do developers actually use it?

That’s where Persistent Volume Claims (PVCs) come in.

A PVC is a storage request from a developer. It’s like saying:

🗣️ “Hey Kubernetes, I need 5GB of storage with read/write access. Find me a PV that matches!”

If a suitable PV is available, Kubernetes automatically binds the PVC to it, making storage available for the pod.

How Developers Request Storage Using PVC

1️⃣ Create a PVC specifying storage requirements.

2️⃣ Kubernetes finds a matching PV and binds the PVC to it.

3️⃣ Mount the PVC inside a pod to store data persistently.

Example: Creating a PVC

Here’s a simple YAML configuration for a PVC requesting 5GB of storage:

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

Breaking It Down

🔹 accessModes: ReadWriteOnce → Storage can be mounted by only one node at a time.

🔹 resources.requests.storage: 5Gi → Requests 5GB of storage.

🔹 storageClassName: local-storage → Uses a PV with the matching storage class.

How the PVC Gets Bound to a PV

✅ If a PV with the right storage size, access mode, and storage class exists, Kubernetes automatically binds the PVC to it.

✅ Once bound, the PVC can be used inside a pod for persistent data storage.

Mounting the PVC in a Pod

Now that we have a PVC, let’s use it inside a pod:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: my-container
      image: postgres
      volumeMounts:
        - mountPath: "/var/lib/postgresql/data"
          name: my-storage
  volumes:
    - name: my-storage
      persistentVolumeClaim:
        claimName: my-pvc

📌 Now, even if the pod restarts, the PostgreSQL database will still have its data

Thanks for reading! Be sure to follow for more DevOps content, and feel free to comment with the DevOps concepts you'd like to see covered next.