The CSI driver and the default StorageClass

A bare NFS export is static — you'd have to hand-create a PersistentVolume for every claim. The CSI driver for NFS automates that: when a pod asks for storage, the driver creates a subdirectory on the export and wires up the volume on the fly. That's dynamic provisioning.

Installed with Helm into its own namespace, it adds:

csi-nfs-controller   (Deployment)  - watches for PersistentVolumeClaims
csi-nfs-node         (DaemonSet)   - runs on every node, does the mounting

Then a StorageClass ties claims to the NFS server and is marked as the cluster default:

provisioner: nfs.csi.k8s.io
parameters:
  server: 10.100.100.12
  share:  /srv/nfs/k8s
mountOptions: [ nfsvers=4.1 ]
reclaimPolicy: Delete
+ annotation: storageclass.kubernetes.io/is-default-class = true

"Default" means any PVC that doesn't name a class gets this one. So an app author writes a five-line PVC, mentions no storage details at all, and gets a working ReadWriteMany volume. reclaimPolicy: Delete means deleting the claim also removes its subdirectory on the server — tidy for a lab.

Why we use this: the StorageClass is the contract between "I need storage" and "here's how this cluster provides it." Making one the default means application manifests stay portable — they ask for storage generically, and the cluster decides how to satisfy it. That separation is the whole point of the CSI abstraction.

Diagram