Volumes, PersistentVolumes, and PersistentVolumeClaims Explained for CKAD

Storage is often where Kubernetes starts to feel abstract. Volumes, PersistentVolumes (PV), and PersistentVolumeClaims (PVC) introduce new concepts, new objects, and new YAML — and many people try to memorize them instead of understanding them.

This article uses one real-world analogy you can easily remember during the CKAD exam.

Think of Kubernetes as an Apartment Building

Imagine an apartment building where people live and move in and out.

• Pods are people
• Nodes are apartment buildings
• Data is personal belongings

Here is the problem Kubernetes needs to solve:

People may move out, but they don't want to lose their belongings.

Pods are temporary. Data should not be.

Why Kubernetes Separates Compute From Storage

Pods can:

• restart
• be rescheduled
• move to another node

If data were tied directly to Pods, it would disappear constantly.

So Kubernetes separates:

• Pod lifecycle
• storage lifecycle

This is the foundation of Kubernetes storage.

Volumes — "A Closet Inside the Apartment"

A Volume is storage that exists inside the Pod.

Example:

volumes:
- name: data
  emptyDir: {}

Analogy:

A closet inside the apartment.

Important to remember:

• When the Pod stops, the data disappears
• Volumes are useful for: caches, temporary files, sharing data between containers in the same Pod.

Volumes are not persistent.

PersistentVolume (PV) — "A Storage Room Owned by the Building"

A PersistentVolume is storage managed by the cluster.

Example:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-data
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /data

Analogy:

A storage room owned by the apartment building, not by the tenant.

Key ideas:

• A PV exists independently of Pods
• It describes: size, access rules, how data is handled when released.
• It is usually created by: a cluster admin, or dynamically via a StorageClass.

Pods do not use PVs directly.

PersistentVolumeClaim (PVC) — "The Rental Contract"

Pods never ask for a specific storage room.

Instead, they make a claim.

Example:

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

Analogy:

A tenant requesting a storage room of a certain size.

The PVC says:

• how much storage is needed
• what access is required

Kubernetes finds a matching PV and binds it automatically.

Pods Use PVCs, Not PVs (Very Important)

A Pod references a PVC like this:

volumes:
- name: data
  persistentVolumeClaim:
    claimName: pvc-data

Analogy:

The tenant accesses the storage room through the rental contract.

This indirection is intentional:

• Pods stay simple
• Storage can be replaced or resized independently

This is a core CKAD rule.

Access Modes — Who Can Use the Storage

Every PV defines how it can be accessed.

Some storage:

• can be mounted by only one node
• some can be shared
• some are read-only

Always read access modes as:

"Who is allowed to open the storage room, and how?"

Reclaim Policy — What Happens When the Claim Is Deleted

When a PVC is deleted, Kubernetes checks the PV reclaim policy.

The most important one to remember:

• Retain → data stays even after claim deletion

Analogy:

The tenant leaves, but the belongings stay in the storage room.

This is commonly tested in CKAD scenarios.

Dynamic Provisioning — Storage On Demand

With a StorageClass:

• you don't create PVs manually
• Kubernetes creates them automatically when a PVC appears

Analogy:

The building creates a storage room as soon as someone signs a contract.

This is how most cloud clusters work.

Imperative Commands You Must Know (CKAD)

These commands help you understand storage state quickly:

kubectl get pv
kubectl get pvc
kubectl describe pv
kubectl describe pvc
kubectl delete pvc

They tell you:

• whether a claim is bound
• why it is pending
• what storage is in use

Troubleshooting Checklist (Exam Gold)

If a PVC is Pending, always ask:

• Is there enough storage?
• Do access modes match?
• Is the StorageClass correct?
• Is a PV available?

kubectl describe pvc <pvc-name>

The reason is almost always there.

Final Mental Shortcut (Remember This)

• Volume → closet inside the apartment
• PersistentVolume → building storage room
• PersistentVolumeClaim → rental contract
• Pod → tenant

If you remember this story, the YAML becomes obvious.

One-Sentence Summary

Kubernetes storage works like apartment storage: Pods request space via claims, the cluster provides storage independently, and data survives Pod restarts.