Persistent storage

Lockers that outlive the pod.

For data that must truly outlive any pod — a database’s files, user uploads — you need storage that exists independently of pods, and Kubernetes provides it through a clean request-and-provide system. Think of it as renting a storage locker: you ask for a locker of a certain size, you get one, and it stays yours even as the people using it (the pods) come and go.

Lockers that outlive the pod

Persistent storage in Kubernetes separates the request from the actual storage. You write a PersistentVolumeClaim (PVC) — "I need 10 gigabytes of storage" — and Kubernetes provides a PersistentVolume (PV), the real storage (a cloud disk, a network share) that satisfies the claim. Your pod then mounts the PVC like any volume. The beauty is the decoupling: your pod definition only names a claim, not a specific disk, so it is portable, and the storage lives independently of the pod. If the pod is deleted and recreated, it reattaches to the same PVC and finds its data intact — the locker stayed put while the pod that used it was replaced. On most clusters this is dynamic: you just create the PVC and the cluster automatically provisions a matching disk for it, no manual setup.

apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: data }
spec:
  accessModes: [ReadWriteOnce]
  resources: { requests: { storage: 10Gi } }   # "I need 10Gi"
---
spec:                              # a pod references the CLAIM (not a disk)
  containers:
    - name: db
      volumeMounts: [{ name: data, mountPath: /var/lib/db }]
  volumes:
    - name: data
      persistentVolumeClaim: { claimName: data }
# Delete + recreate the pod → it reattaches to "data" and finds its files intact.

What this unlocks (and a caution)

Persistent storage is what lets Kubernetes run stateful applications — databases, queues, anything that must remember data — not just stateless web apps. With a PVC, a database pod can be restarted, rescheduled to another node, or updated, and its data survives because the data lives in the persistent volume, not in the pod. For genuinely stateful clustered software, there is a special controller called a StatefulSet (which you will meet in the administration course) that gives each pod its own stable PVC, but the PVC is the foundation underneath. One caution to know early: what happens to the underlying disk when you delete a PVC depends on a setting — some storage is configured to delete the disk (and its data) along with the claim, which means an accidental deletion can permanently lose data. So treat PVCs holding important data with care, just as you would a real disk. For fundamentals, the key idea is complete: container filesystems and emptyDir are temporary, but a PVC gives you durable storage that outlives pods, which is exactly what stateful apps need — you request storage by claim, mount it in your pod, and your data persists through everything the pods go through.