A PersistentVolume (PV) is a Kubernetes API object representing storage available to applications. The storage can be attached to a node or accessed over a network. Unlike an emptyDir volume, a conventional PV and its data can outlive the pod that uses it, so deleting and recreating a pod need not erase application data. section 10.6 section 10.2
A pod does not name a PV directly. Create a PersistentVolumeClaim (PVC) describing the storage needed, then reference that claim in the pod’s volumes and mount it in a container. Kubernetes binds the claim to a suitable PV. The claim and PV remain even when no pod uses them. section 10.1.1 section 10.1.2
Keep a database across pod replacements
For a MongoDB container, create a PVC requesting 1Gi with access mode ReadWriteOncePod. In the pod manifest, set a persistentVolumeClaim volume’s claimName to that PVC’s name and mount the volume at /data/db. Run kubectl get pvc and kubectl get pv to check that both objects are Bound. A new PV may be created on demand to satisfy the claim; unlike the earlier emptyDir, its data is not lost merely because the pod is recreated. section 10.2.1 section 10.2.2 section 10.2
Choose and inspect storage with these distinctions in mind:
- Dynamic provisioning creates a PV and its underlying storage when a PVC needs them. A StorageClass selects the provisioner and its settings; if the claim omits storageClassName, the cluster’s default is used when available. A class may bind immediately or wait until a pod first uses the claim. section 10.1.2 section 10.2.5
- Static provisioning starts with storage and a PV created in advance. Kubernetes then matches a PVC to that PV. A node-local PV specifies where its storage resides; scheduling places a pod that uses it on the appropriate node. section 10.3 section 10.3.1
- Access modes constrain sharing: ReadWriteOncePod permits one pod to write; ReadWriteOnce permits pods on one node to write; ReadWriteMany permits writing from multiple nodes; ReadOnlyMany permits reading from multiple nodes. The available choice depends on the storage. section 10.2.1 section 10.2.4
- Deleting a pod leaves its claim and PV intact. Deleting the claim releases the PV: a Delete reclaim policy removes the PV and underlying storage, while Retain leaves reclamation to an administrator. A retained, Released PV is not automatically Available to a new claim. section 10.2.3 section 10.3.3
A CSI driver commonly provisions storage through a controller and attaches or mounts it through a node-level component. If a claim stays Pending, check its StorageClass and events with kubectl describe; a nonexistent class produces ProvisioningFailed events. Where the StorageClass allows expansion, increasing the PVC’s requested size can enlarge an existing volume. PVs can also be snapshotted or initialized from supported data sources. section 10.2.6 section 10.2.1 section 10.4.1 section 10.6
An ephemeral PV is the deliberate exception to the usual independent lifecycle: a pod can create its claim from a volumeClaimTemplate for scratch data. It offers PV features such as snapshots and a requested size, although its data is typically discarded when the pod finishes. section 10.5 section 10.5.2
