rootnode-academy/content/root/root-08-kubernetes-storage-scheduling/m01-storage-fundamentals/01-lesson-storage-fundamentals.md

Ephemeral vs. Persistent Storage

The default: a container's filesystem is thrown away

By default, anything a container writes to its own filesystem disappears the moment that container is replaced — a crash, a rollout, a reschedule, anything. This is a deliberate design choice (it's part of what makes a Pod safely disposable/replaceable), but it means "just write files to disk" silently loses data unless you use one of Kubernetes' actual storage mechanisms.

emptyDir: shared, but still temporary

An emptyDir volume gives a Pod's containers a shared directory that survives a container restart WITHIN the same Pod, but is deleted the moment the Pod itself is removed. It's the right tool for two containers in one Pod that need to share files with each other (a sidecar writing logs another container reads, for example) — not for anything that needs to outlive the Pod.

volumes:
- name: shared-data
  emptyDir: {}

PersistentVolume & PersistentVolumeClaim: storage that outlives the Pod

A PersistentVolume (PV) represents an actual piece of storage (a cloud disk, an NFS share, whatever the cluster's infrastructure provides) as a Kubernetes object. A PersistentVolumeClaim (PVC) is a Pod's REQUEST for storage matching some criteria (size, access mode) — the Pod references the PVC, not a PV directly, and Kubernetes binds the PVC to a matching PV.

Pod  ──references──>  PVC ("I need 5Gi, ReadWriteOnce")  ──binds to──>  PV (actual storage)

This indirection matters: a Pod's manifest doesn't need to know or care exactly which physical storage backs its PVC — that's resolved separately, and the same PVC keeps working even if the Pod behind it is replaced.

StorageClass & dynamic provisioning

Manually creating a PV for every PVC doesn't scale. A StorageClass describes a category of storage (e.g. "fast SSD" vs. "cheap archival") and, when a PVC requests that class, the cluster can automatically provision a matching PV on demand — this is "dynamic provisioning," and it's the normal way storage works on any real cloud-hosted cluster. A StorageClass also controls the reclaim policy — what happens to the underlying storage after its PVC is deleted (Delete the data, or Retain it for manual recovery).

The decision in one pass

You need...	Use
Temporary scratch space shared between containers in ONE Pod	emptyDir
Storage that survives Pod replacement, manually provisioned	PV + PVC
The above, provisioned automatically on demand	PVC + StorageClass (dynamic provisioning)

Instructor Notes

Approximate timing: 15 minutes read; 10 minutes live with the PV/PVC/StorageClass diagram.

Likely misconceptions to watch for:

• Students often assume emptyDir is "persistent" because the name doesn't obviously say otherwise. Be explicit: it survives a CONTAINER restart, not a POD deletion.
• The PV/PVC indirection can seem like unnecessary ceremony at first — frame it as the same "declare what you want, let the system resolve it" pattern from ROOT 05's desired-state lesson, applied to storage instead of Pod count.

Discussion question: "If a Pod using a PVC is deleted and replaced, what happens to its data?" (Answer: it's preserved — the PVC and its bound PV are separate objects from the Pod, and a new Pod referencing the same PVC picks up right where the data was left, which is the entire point of using persistent storage over emptyDir.)

Optional extension: ask what a Retain reclaim policy is protecting against, compared to Delete (answer: accidental data loss from deleting a PVC by mistake — Retain keeps the underlying storage around for manual recovery instead of immediately destroying it).