Why NFS for cluster storage

Pods are disposable; their data shouldn't be. Kubernetes solves that with PersistentVolumes — storage that outlives the pod using it. The question is what backs those volumes.

For a lab, NFS is a pragmatic, honest choice:

• It's ReadWriteMany — the same volume can be mounted by several pods at once, on different nodes. A lot of simpler options (hostPath, local disks) are tied to one node; NFS isn't.
• It's dead simple to reason about — it's just a directory on a server, exported over the network. When something looks wrong, you SSH to the NFS box and ls the directory.
• It needs no special hardware — no Ceph cluster, no cloud block-storage driver.

The tradeoff: NFS is not the fastest, and it's a single server (a single point of failure). For databases I deliberately don't use it — those get their own VMs with local disk (see the Data book). But for general application volumes in a learning environment, NFS is exactly enough.

Why we use this: match the storage to the job. NFS for shared, general-purpose volumes; local disk for databases that care about latency and fsync semantics. Reaching for one storage system for everything is a common mistake — different workloads genuinely want different backends.