The Ephemeral Paradox

Containers are designed to be stateless and disposable. This is their greatest strength (scalability) and their greatest weakness (amnesia). When a Pod dies, its filesystem is wiped clean. To build databases, message queues, and stateful apps, we need a way to cheat death.

1. First Principles: Why is Storage Hard?

In a traditional server model, storage is easy: the hard drive is physically inside the server. The application writes to /var/lib/mysql, and the data stays there.

In a distributed cluster, this model breaks:

Scheduling is Random: Your Pod might restart on Node A today, but Node B tomorrow.
Storage is Local: Node B cannot physically access the hard drive of Node A.
Lifecycle Mismatch: Pods live for minutes; Data must live for years.

To solve this, Kubernetes decouples Compute (Pod) from Storage (Volume).

2. The Solution: Persistent Volume (PV)

A Persistent Volume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes. It is a resource in the cluster just like a Node is a cluster resource.

Independent Lifecycle: PVs exist independently of any individual Pod.
Network Attached: Typically backed by network storage (EBS, NFS, iSCSI) so it can “follow” the Pod to any node.

3. Interactive: Data Survival Lab

Visualize the difference between Local Storage (Ephemeral) and Persistent Volumes (Durable).

Node 1 (10.0.0.1)

ACTIVE

Pod-A

Local Disk

Node 2 (10.0.0.2)

WAITING

Pod-A

Local Disk

Persistent Volume (Network Storage)

$ System ready. Waiting for failure simulation...

4. Volume Types Deep Dive

Not all PVs are created equal. The implementation depends on your infrastructure.

1. HostPath (The Danger Zone)

Maps a file or directory on the Node’s filesystem to the Pod.

UseCase: Single-node clusters (Minikube), DaemonSets (accessing /var/log).
Risk: If the Pod moves to another node, the data is left behind.

2. NFS (Network File System)

A file-based storage protocol shared across the network.

UseCase: Sharing data between multiple Pods (ReadWriteMany).
Trade-off: High latency, poor performance for databases.

3. Block Storage (EBS, PD, Longhorn)

Raw block devices attached over the network (like a virtual hard drive).

UseCase: Databases (PostgreSQL, MySQL).
Constraint: Usually ReadWriteOnce (can only attach to one node at a time).

5. Configuration: The PV Object

Here is how we define a Persistent Volume in YAML. This is usually done by the Cluster Administrator.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-app-pv
  labels:
    type: local
spec:
  # 1. Capacity: How much space?
  capacity:
    storage: 10Gi

  # 2. Access Modes: Who can read/write?
  accessModes:
  - ReadWriteOnce  # Only one node can mount this R/W

  # 3. Reclaim Policy: What happens when released?
  persistentVolumeReclaimPolicy: Retain

  # 4. The Backend Implementation
  # In production, this would be awsElasticBlockStore or csi
  hostPath:
    path: "/mnt/data"

[!IMPORTANT] Access Modes Explained:

RWO (ReadWriteOnce): Mounted by a single node (e.g., Block Storage).

RWX (ReadWriteMany): Mounted by many nodes (e.g., NFS).

ROX (ReadOnlyMany): Mounted by many nodes, but read-only.

6. Next Steps

Now that we have a PV (the pile of storage), how does a developer ask for a piece of it? Enter the Persistent Volume Claim (PVC).

Persistent Volumes (PV)