How Kubernetes Storage Works: Volumes, PVs & PVCs with Real-World Use Cases

Byjaganrajagopalme

One of the first challenges beginners face in Kubernetes is data persistence.
By default, containers are ephemeral—when a pod restarts, all local data is lost.
Kubernetes solves this problem using Volumes, PersistentVolumes (PV), and PersistentVolumeClaims (PVC).

This article explains these concepts in a simple way, shows how to implement them, and maps them to real business use cases.

1. Why Storage Is Important in Kubernetes

Kubernetes is designed for stateless applications, but real-world systems often need to store:

  • Database data
  • Uploaded files
  • Logs and audit records
  • Application state

Without persistent storage, restarting or rescheduling a pod can cause data loss, which is unacceptable in production.

2. What Is a Volume?

A Volume is storage that is mounted inside a Pod and shared by its containers.

Key Characteristics

  • Exists only as long as the Pod runs
  • Tied directly to the Pod lifecycle
  • Data is lost when the Pod is deleted (unless backed by PV)

When to Use

  • Temporary files
  • Cache data
  • Shared files between containers in the same Pod

3. What Is a PersistentVolume (PV)?

A PersistentVolume (PV) is a cluster-level storage resource that exists independently of Pods.

Key Characteristics

  • Provisioned by a storage admin or dynamically via a StorageClass
  • Backed by actual storage like:
    • AWS EBS / EFS
    • Azure Disk / File
    • Google Persistent Disk
    • NFS / SAN
  • Remains available even if Pods are deleted

4. What Is a PersistentVolumeClaim (PVC)?

A PersistentVolumeClaim (PVC) is a request for storage made by an application.

Key Characteristics

  • Developers request storage using PVCs
  • PVC defines:
    • Size (e.g., 20Gi)
    • Access mode (ReadWriteOnce, ReadOnlyMany, etc.)
  • Kubernetes automatically binds the PVC to a suitable PV

PVCs abstract storage details from applications.

5. How PV, PVC & Volume Work Together

The relationship is simple:

Pod → Volume → PVC → PV → Storage Backend

  • Pod mounts a volume
  • Volume is backed by a PVC
  • PVC is bound to a PV
  • PV maps to real storage

6. Implementation Example (Step-by-Step)

Step 1: Create a PersistentVolume (PV)

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


Step 2: Create a PersistentVolumeClaim (PVC)

Step 2: Create a PersistentVolumeClaim (PVC)

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

Step 3: Mount PVC in a Pod

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

I’ll explain the architecture shown in that diagram in a beginner-friendly, step-by-step way, mapping each block to Kubernetes storage concepts (Volume, PV, PVC) and why it exists. This is a very common and correct reference diagram used in blogs and training.

What This Diagram Represents (Big Picture)

The diagram explains how Kubernetes decouples applications from physical storage using:

  • Pod & Volume (application side)
  • PersistentVolumeClaim (PVC) (request layer)
  • PersistentVolume (PV) (storage layer)
  • Storage Backend (actual disk/network storage)

This separation allows data to survive pod restarts, rescheduling, and scaling.

Step-by-Step Explanation of the Diagram

Pod (Application Layer)

  • The Pod runs your application (e.g., MySQL, Nginx, backend API).
  • Pods are ephemeral:
    • They can restart
    • They can move to another node
    • They can be deleted and recreated

By default, pods do not retain data.

Volume (Mounted into the Pod)

  • The Volume is mounted inside the Pod’s filesystem.
  • The application reads/writes data to this mount path.

Important:

  • The pod does not talk directly to the storage backend.
  • The pod only knows about the volume, not the disk type.

PersistentVolumeClaim (PVC) – The Request

  • PVC is a storage request made by the application.
  • Example request:
    • Size: 10Gi
    • Access Mode: ReadWriteOnce

Think of PVC as:

“Dear Kubernetes, I need persistent storage, but I don’t care how it’s implemented.”

✔ Developers work only with PVCs
✔ Storage complexity is hidden

PersistentVolume (PV) – The Resource

  • PV is the actual storage resource in the cluster.
  • It is provisioned by:
    • Storage admin (static provisioning)
    • StorageClass + CSI driver (dynamic provisioning)

PV maps to real storage like:

  • AWS EBS / EFS
  • Azure Disk / File
  • GCP Persistent Disk
  • NFS / SAN

PV exists independently of pods.

Binding Between PVC and PV

  • Kubernetes matches PVC → PV based on:
    • Size
    • Access mode
    • Storage class

Once matched:

  • PVC is bound to a PV
  • Pod can safely use the storage

This binding is shown clearly in the diagram.

Storage Backend (Actual Disk / Network Storage)

  • This is where the real data lives
  • Kubernetes does not store data itself
  • Kubernetes only orchestrates access

Even if:

  • Pod crashes
  • Pod is deleted
  • Pod moves to another node

Data remains safe

Data Flow Explained (Simple)

Application (Pod)
   ↓
Volume (Mount)
   ↓
PVC (Request)
   ↓
PV (Actual Storage)
   ↓
Cloud / Storage System

7. Real Business Use Cases

Databases on Kubernetes

Example: MySQL, PostgreSQL, MongoDB

  • PVC ensures data survives Pod restarts
  • Enables rolling updates without data loss

File Upload Systems

Example: Document management systems

  • Files uploaded by users stored in PV
  • Accessible even after scaling or redeployment

Logging & Auditing

Example: Compliance systems

  • Logs stored persistently for audits
  • Data retained even during failures

Stateful Applications

Example: ERP or legacy apps

  • Application state maintained safely
  • Reliable production deployments

8. When Should You Use PV & PVC?

✔ When your application requires persistent data
✔ When running databases or stateful services
✔ When data must survive Pod restarts or scaling

Avoid PV/PVC for:

  • Stateless APIs
  • Short-lived batch jobs (unless data retention required)

9. Conclusion

Kubernetes storage architecture using Volumes, PVs, and PVCs allows teams to run stateful, production-grade workloads confidently.
By separating applications from storage, Kubernetes delivers resilience, flexibility, and scalability—critical for modern cloud-native businesses.

Reference to Document :Persistent Volumes | Kubernetes

Storage | Kubernetes

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *