Storage & State Knowledge

A PersistentVolume, or PV, is a cluster-wide storage resource. It can be created manually by an administrator or dynamically by a StorageClass and provisioner. A PV represents actual storage that can be bound to a claim.

A PersistentVolumeClaim, or PVC, is a request for storage by a workload. It specifies storage size, access mode, and optionally a StorageClass. Kubernetes binds the claim to a matching PV or dynamically provisions one.

A PersistentVolume is storage available to the cluster. A PersistentVolumeClaim is the workload request for storage. The control plane binds a matching PV to a PVC, or a StorageClass dynamically creates a PV for the claim.

ReadWriteOnce allows read-write mounting by a single node. ReadOnlyMany allows read-only mounting by multiple nodes. ReadWriteMany allows read-write mounting by multiple nodes if the backend supports it. Newer clusters may also support ReadWriteOncePod for single-Pod access.

A StorageClass defines how dynamic storage provisioning occurs. It includes the provisioner, parameters, reclaim policy, volume binding mode, mount options, and expansion settings. It maps Kubernetes claims to a storage backend.

The common default is Delete, meaning the backing storage is deleted when the PVC is removed and the PV is reclaimed. Always verify the StorageClass, because reclaim policy controls data survival.

Static provisioning means an administrator creates PVs ahead of time. Dynamic provisioning means a PVC triggers a StorageClass provisioner to create storage automatically. Dynamic provisioning is the common cloud and CSI pattern.

It delays PV binding or dynamic provisioning until a Pod using the PVC is scheduled. This helps choose storage in the same zone or topology as the selected node and avoids binding a volume in the wrong location.

A Container Storage Interface driver lets external storage systems integrate with Kubernetes. CSI drivers handle provisioning, attaching, mounting, expanding, and snapshotting storage depending on the driver capabilities.

A VolumeSnapshot is a point-in-time snapshot of a PVC, usually provided by a CSI snapshot driver. It can support backup, restore, cloning, and data protection workflows, but application consistency still matters.

Reference the claim under Pod volumes and mount that volume into the container. The volume looks like volumes: [{name: data, persistentVolumeClaim: {claimName: mypvc}}], and the container uses volumeMounts with the same volume name and a mountPath.

volumeMounts define where a declared volume appears inside a container. A Pod-level volume makes storage available; a container-level volumeMount chooses the mount path and optional settings such as readOnly or subPath.

emptyDir is ephemeral storage tied to the Pod lifecycle on a node. It survives container restarts but disappears when the Pod is removed. hostPath mounts a path from the node filesystem into the Pod.

hostPath breaks portability because the Pod depends on a specific node filesystem path. It can also expose sensitive host files or allow node-level compromise if misused. Prefer PVCs or tightly controlled purpose-built node agents.

A StatefulSet manages stateful applications that need stable identities, stable network names, ordered rollout or termination, and persistent storage tied to each Pod ordinal.

Each replica gets its own PVC created from the template. The claim sticks to the Pod identity, such as data-db-0, so replacement Pods reuse the same storage for that ordinal.

Bound means the PV is attached to a PVC. Released means the PVC was deleted, but the PV has not yet been reclaimed or made available again. With Retain, manual cleanup is usually required before reuse.

Retain preserves the underlying storage after PVC deletion. It is useful for manual recovery, forensic inspection, or cautious data handling, but it also requires operational cleanup before the volume can be reused safely.

A projected volume combines multiple sources into one mounted directory. Common sources include ConfigMaps, Secrets, Downward API data, and ServiceAccount tokens. It keeps related runtime metadata in one volume path.

The Downward API exposes Pod and container metadata to containers through environment variables or files. Examples include Pod name, namespace, labels, annotations, node name, and resource requests or limits.

subPath mounts a static file or directory from a volume into a container. subPathExpr supports environment variable expansion, which allows paths based on runtime values such as Pod name. subPath mounts do not receive projected volume updates the same way normal mounts do.

Use kubectl get pvc mypvc -o wide and look at the VOLUME column. You can then inspect the PV with kubectl describe pv <pv-name> to see reclaim policy, capacity, access modes, StorageClass, and backend details.

The PVC may be unbound, the StorageClass may not exist, the provisioner may be failing, requested size or access mode may be unavailable, or volume binding may wait for a selected node. Describe both Pod and PVC.

The storage backend may still think the volume is attached to the old node, the detach operation may be delayed, or the volume supports only single-node attachment. Check events, VolumeAttachment objects, CSI controller logs, CSI node logs, and provider volume state.