Persistent Volumes and Storage

Why Storage Needs Special Handling

Container filesystems are ephemeral. When a pod dies, its data dies with it. For databases, uploads and logs you need persistent storage provided by PersistentVolume (PV) and PersistentVolumeClaim (PVC).

How It Fits Together

• PV - a piece of storage provisioned in the cluster (a disk unit, NFS share, cloud volume).
• PVC - a request for storage by a workload; Kubernetes binds it to a matching PV.
• StorageClass - defines how storage is provisioned dynamically (e.g. fast, standard).

A Claim and a Pod Using It

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

spec:
  volumes:
  - name: app-data
    persistentVolumeClaim:
      claimName: data
  containers:
  - name: app
    image: mydb:2
    volumeMounts:
    - name: app-data
      mountPath: /var/lib/db

kubectl apply -f pvc.yaml
kubectl get pvc
kubectl get pv

Access Modes

• ReadWriteOnce - one node can mount it read-write (most common for databases).
• ReadOnlyMany - many nodes can mount it read-only.
• ReadWriteMany - many nodes can mount it read-write.

Key Points

• By default containers store nothing durable; use PVCs for real data.
• StorageClasses enable automatic provisioning on cloud platforms.
• ReadWriteOnce is the right default for a single-replica database.