Kubernetes Storage Usage Guidelines

Kubernetes Storage Usage Guidelines describe the practices for provisioning, consuming, and managing durable storage for workloads that need it, spanning the abstraction layers Kubernetes provides — PersistentVolume, PersistentVolumeClaim, StorageClass, and the Container Storage Interface (CSI) drivers that connect those abstractions to real backing storage systems. These guidelines exist because storage, unlike compute, carries state that must survive Pod rescheduling, and mismanaging that layer is one of the more common sources of data loss incidents in a cluster.

The Storage Abstraction Layers

PersistentVolume and PersistentVolumeClaim

A PersistentVolume (PV) represents an actual piece of provisioned storage; a PersistentVolumeClaim (PVC) is a request for storage made by a workload, which the cluster binds to a matching PV. This separation lets application manifests request storage abstractly (size, access mode) without needing to know the underlying storage implementation, while cluster operators or dynamic provisioners handle the concrete backing details.

StorageClass and Dynamic Provisioning

A StorageClass defines a provisioner and parameters for dynamically creating PVs on demand as PVCs are created, rather than requiring PVs to be pre-provisioned manually. Clusters should define StorageClasses that map clearly to distinct performance/durability tiers (e.g., fast-ssd, standard, archival), so that workload authors can select storage characteristics by name without needing to understand the underlying infrastructure.

CSI Drivers

The Container Storage Interface standardizes how Kubernetes talks to storage backends, decoupling the core Kubernetes codebase from vendor-specific storage logic. Storage capabilities available to a cluster — snapshotting, resizing, specific access modes — are entirely determined by which CSI driver is installed and what it implements, making CSI driver choice a foundational decision for what storage guidelines are even achievable.

Access Modes

ReadWriteOnce

ReadWriteOnce (RWO) permits mount by a single node at a time (as of newer Kubernetes versions, ReadWriteOncePod further restricts this to a single Pod), which is the correct and by far most common mode for workloads like databases where concurrent multi-writer access would corrupt data.

ReadWriteMany

ReadWriteMany (RWX) permits mount by multiple nodes simultaneously, needed for workloads that genuinely require shared file access across replicas (shared upload directories, certain ML training data patterns). RWX support depends entirely on the backing storage system — block storage typically only supports RWO, while network file systems (NFS, and cloud-native equivalents) are needed for RWX.

Matching Access Mode to Actual Concurrency Needs

Requesting RWX when RWO would suffice narrows the set of eligible storage backends unnecessarily and can introduce file-locking or consistency behavior differences that a simpler RWO volume wouldn't have; access mode should be chosen based on genuine concurrent-write requirements, not habit.

Reclaim Policy and Data Lifecycle

Retain vs. Delete

A PV's reclaimPolicy determines what happens to the underlying storage when its claim is released: Delete destroys the backing storage, Retain preserves it for manual recovery or inspection. Any workload holding data that would be costly or impossible to regenerate should use Retain, accepting the operational cost of manually cleaning up orphaned storage in exchange for protection against accidental data loss from a mistaken PVC deletion.

PVC Deletion Is Often Irreversible in Practice

Even with Retain protecting the underlying volume, deleting a PVC detaches the workload from its data and requires deliberate manual intervention to reattach — treating PVC deletion with the same caution as a destructive database operation is appropriate given how easily it can be triggered accidentally through manifest changes or namespace deletion.

Snapshots and Backup

Volume Snapshots as a Point-in-Time Mechanism

VolumeSnapshot and VolumeSnapshotClass (where supported by the CSI driver) provide point-in-time copies of a volume's state, useful for fast recovery from a bad deployment or accidental data corruption, but a volume snapshot is not equivalent to an application-consistent backup unless the application's write activity is quiesced or the storage system guarantees crash-consistent snapshots.

Backup Strategy Independent of the Cluster

As with stateful workload guidelines generally, snapshots and PV-level protections are not a substitute for a backup strategy that survives the loss of the cluster itself — backups should be replicated to storage outside the cluster's own failure domain and tested via actual restore drills, not merely assumed to work because a snapshot schedule exists.

Capacity and Resizing

Volume Expansion

Where the StorageClass sets allowVolumeExpansion: true, an existing PVC's requested size can be increased without recreating the volume — planning for this ahead of time (rather than discovering a workload's StorageClass doesn't support expansion during an actual capacity crunch) avoids a much more disruptive migration under pressure.

Monitoring Volume Utilization

Storage utilization should be monitored per-volume with alerting before volumes approach capacity, since many storage backends degrade in behavior or reject writes entirely once full, and recovering from a full volume in a stateful workload is often more disruptive than the equivalent situation for compute resources.

Ephemeral Storage Considerations

emptyDir for Genuinely Transient Data

emptyDir volumes provide Pod-lifetime-scoped scratch space (backed by node disk or, optionally, memory) appropriate for caches, temporary processing files, or scratch space that has no need to survive a Pod restart — using persistent storage for genuinely ephemeral data wastes provisioned capacity and adds unnecessary reclaim-policy considerations to data that was never meant to persist.

Example Configuration

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: csi.example.com
parameters:
  type: ssd
allowVolumeExpansion: true
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: codartium-db-data
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: fast-ssd
  resources:
    requests:
      storage: 200Gi

Practical Consequences

Careful storage configuration produces workloads whose data survives Pod rescheduling and node failure, whose capacity can grow without disruptive migration, and whose accidental deletions are recoverable rather than catastrophic. Neglecting these guidelines is a recurring source of the most severe incident class in a cluster — silent, permanent data loss from a Delete reclaim policy on irreplaceable data, corruption from an access mode that allowed concurrent writers it shouldn't have, or outages from a volume that quietly filled to capacity with no alerting in place to catch it beforehand.