Kubernetes persistent storage keeps application data available beyond the lifecycle of an individual Pod. The core model is simple: Pods are replaceable; persistent state should not be tied to one Pod instance.
For most teams, the storage path looks like this:
Pod → PersistentVolumeClaim (PVC) → PersistentVolume (PV) → StorageClass / storage backend
Raff Technologies provides dedicated storage for stateful Kubernetes workloads, but the same production rule applies: a volume that survives Pod replacement is not the same thing as a backup.
This guide owns the Kubernetes storage decision model: PVs, PVCs, StorageClasses, access modes, reclaim policy, binding behavior, StatefulSets, snapshots, and backup boundaries. For implementation steps, the separate persistent-storage tutorial should own the YAML and verification flow rather than duplicating it here.
What is Kubernetes persistent storage?
Kubernetes persistent storage is the set of resources and storage integrations that let workload data survive ordinary Pod replacement.
Without persistent storage, data written only to a container or Pod-local filesystem can disappear when the Pod is recreated.
Persistent storage separates the application lifecycle from the storage lifecycle.
The important objects are:
| Object | Responsibility |
|---|---|
| PersistentVolume (PV) | Represents storage available to the cluster |
| PersistentVolumeClaim (PVC) | Requests storage for a workload |
| StorageClass | Describes how a class of storage is provisioned and managed |
| CSI driver / storage implementation | Connects Kubernetes to the underlying storage system |
For application teams, the PVC is normally the main contract. The workload asks for storage; the cluster decides how the matching storage is provisioned.
PV vs PVC: what is the difference?
A PersistentVolume is the storage resource.
A PersistentVolumeClaim is the workload's request to use storage.
Think of it as:
PVC = "I need 20 GiB of storage with these characteristics."
PV = "Here is the storage resource that satisfies the request."
When dynamic provisioning is available, a team often creates only the PVC. The StorageClass and storage driver provision the underlying PV automatically.
That is usually more portable than making every application define infrastructure-specific PV objects.
A minimal conceptual PVC can look like:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: app-data spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi
The exact StorageClass, access modes, expansion behavior, and provisioning model depend on the cluster.
StorageClass defines how storage is provisioned
A Kubernetes StorageClass describes a category of storage and the rules used to provision it.
Important StorageClass properties can include:
- the storage provisioner;
- provider-specific parameters;
- reclaim policy;
- volume binding mode;
- whether volume expansion is allowed.
Application teams should know which StorageClass they are requesting. "PVC created successfully" is not enough if the team does not understand the lifecycle and failure behavior behind that class.
A useful production review asks:
- Which StorageClass is this PVC using?
- Is the storage dynamically provisioned?
- Can the volume expand?
- What reclaim policy applies?
- Does topology affect where the Pod can run?
- What backup or recovery path protects the data?
Immediate vs WaitForFirstConsumer binding
Storage topology can affect scheduling.
With Immediate binding, Kubernetes may bind or provision storage as soon as the PVC is created.
With WaitForFirstConsumer, binding or provisioning is delayed until Kubernetes knows where the consuming Pod is being scheduled.
That distinction matters when the underlying storage has topology constraints.
Conceptually:
Immediate: PVC → provision storage → later schedule Pod
WaitForFirstConsumer: PVC → schedule Pod context → provision compatible storage
For topology-aware storage, WaitForFirstConsumer can reduce the risk of provisioning a volume in a location that conflicts with the workload's scheduling requirements.
The StorageClass should own that infrastructure policy so application YAML does not need to encode provider-specific topology logic.
Access modes do not mean what many teams assume
Kubernetes supports several PersistentVolume access modes.
Common modes include:
- ReadWriteOnce (RWO)
- ReadOnlyMany (ROX)
- ReadWriteMany (RWX)
- ReadWriteOncePod (RWOP)
A common mistake is reading ReadWriteOnce as "only one Pod can ever mount this volume."
RWO is defined around a single node. Multiple Pods on the same node may still access the volume depending on the storage implementation.
ReadWriteOncePod is the stricter model intended for a single Pod when supported by the CSI stack.
Choose the access mode from the application requirement:
| Requirement | Storage implication |
|---|---|
| One stateful replica writes the filesystem | RWO/RWOP may fit |
| Multiple replicas need one shared writable filesystem | RWX-capable storage is required |
| Replicas can rebuild state | Persistent storage may not be needed |
| Data is a database | Database-aware recovery matters more than generic shared disk |
| Data is user uploads | Object storage may be a cleaner architecture |
Do not select a shared-write access mode merely "for flexibility." Shared writable filesystems add coordination and failure behavior the application must actually need.
StatefulSet helps identity, but it does not replace storage design
StatefulSets are useful for workloads that need stable Pod identity or ordered lifecycle behavior.
They can also create per-Pod PVCs through volumeClaimTemplates.
For example, a three-replica StatefulSet can create separate storage claims for each replica rather than one shared volume.
Conceptually:
stateful-app-0 → PVC 0 → PV 0
stateful-app-1 → PVC 1 → PV 1
stateful-app-2 → PVC 2 → PV 2
But StatefulSet does not make the application data highly available by itself.
If replica 0 owns a volume and that application's replication model is broken, Kubernetes cannot infer how to reconstruct the business data merely because the workload is a StatefulSet.
Application replication, storage durability, backup, and restore remain separate responsibilities.
Reclaim policy controls deletion lifecycle
Reclaim policy determines what happens to the underlying storage after a claim is released.
Two important policies are:
Delete
The backing storage is normally deleted when the dynamically provisioned PV is released.
This can be appropriate for disposable environments, but it creates a sharp deletion boundary for important state.
Retain
The PV and underlying storage are preserved for manual recovery or reuse.
Retain can provide an extra safety boundary around accidental PVC deletion, but it also creates operational cleanup work.
The decision should follow the value of the data.
| Data | Reclaim policy to evaluate |
|---|---|
| Disposable test environment | Delete |
| Rebuildable cache | Delete |
| Business-critical filesystem data | Retain may be safer |
| Database storage | Retain may help, but backups are still required |
Reclaim policy is not a backup policy.
Retaining a corrupted volume preserves corrupted data. Retaining a volume after a destructive migration preserves the destructive result.
Volume expansion needs both platform and filesystem support
Some StorageClasses allow PVC expansion.
When supported, teams can increase requested storage without replacing the workload's entire storage architecture.
But three separate layers may be involved:
- the PVC request;
- the underlying storage capacity;
- the filesystem inside the volume.
A larger volume allocation does not automatically mean every filesystem or application uses the extra capacity immediately.
Before relying on online expansion, verify the behavior of the actual StorageClass and workload.
Capacity planning should also leave headroom. Waiting until a stateful workload is at 99% disk usage before expanding it creates avoidable operational risk.
Persistent storage vs object storage vs managed databases
Not every form of application state belongs on a PVC.
Use the state type to choose the system.
| State | Better starting point |
|---|---|
| Application image/code | Container registry |
| Database records | Managed database or database-specific storage model |
| Shared uploads and media | Object storage in many architectures |
| Durable mounted filesystem | PVC / PV |
| Cache | Rebuildable cache or cache service |
| Logs and metrics | Observability system |
| Backup archives | Separate backup destination |
For small teams, a stateless Kubernetes application connected privately to a managed database and object storage is often easier to operate than a cluster where every workload carries local persistent state.
PersistentVolumes are valuable when the application genuinely requires filesystem semantics.
They should not be the default answer to every data problem.
Snapshots are not the same as backups
Kubernetes VolumeSnapshot resources can provide point-in-time storage snapshots when the cluster and CSI storage implementation support them.
Snapshots are useful, but they do not automatically provide:
- application consistency;
- off-cluster recovery;
- independent credentials;
- long-term retention;
- restore verification.
A snapshot taken while an application is actively writing may capture a storage-consistent or crash-consistent point without guaranteeing application-level consistency.
For databases and other transactional systems, the backup method should understand the application where necessary.
The layers are different:
| Protection layer | Protects mainly against |
|---|---|
| Persistent volume | Pod replacement |
| Storage replication | Loss of a storage component |
| Snapshot | Point-in-time storage state |
| Application/database backup | Logical recovery |
| Tested restore | Proves the recovery path actually works |
Production storage should have a recovery design beyond "the PVC still exists."
Back up the business state, not only the Kubernetes object
A PVC manifest is easy to recreate. The business data inside the volume is what matters.
For every important PVC, document:
- what data the volume contains;
- whether the application can be paused or quiesced for backup;
- backup frequency;
- retention;
- recovery point objective (RPO);
- recovery time objective (RTO);
- restore destination;
- who owns restore testing.
The Kubernetes Backup and Disaster Recovery Strategy covers the broader recovery model.
A strong recovery test restores data into a usable application, not merely into a storage device.
How Raff Kubernetes storage fits this model
Raff Kubernetes provides dedicated storage nodes for stateful workloads.
The current public Kubernetes pricing lists:
- storage nodes from 10 GB to 1,000 GB;
- $0.10/GB-month pricing;
- 100 GB at $10/month;
- replicated storage for stateful workloads;
- free same-region cluster-to-storage traffic.
Use the Raff Kubernetes product page as the live source for platform behavior and pricing.
This is separate from Raff's standalone Block Storage Volumes product for VMs. Do not assume the VM block-storage price is the Kubernetes storage-node price.
The architecture boundary remains:
Kubernetes workload → PVC/PV → cluster storage → backup/recovery
Storage durability reduces infrastructure failure risk. It does not replace application-aware backups or restore testing.
Production persistent-storage checklist
Before shipping a stateful Kubernetes workload, verify:
Workload fit
- The application genuinely needs mounted persistent filesystem state.
- A managed database or object storage is not a better fit.
PVC and StorageClass
- The intended StorageClass is explicit or understood.
- Requested capacity includes growth headroom.
- The access mode matches the workload.
- Expansion behavior is understood.
- Volume binding mode fits topology requirements.
Lifecycle
- Reclaim policy is understood.
- Accidental PVC deletion behavior is known.
- StatefulSet volumeClaimTemplates are understood where used.
Recovery
- Persistent storage is not treated as a backup.
- Snapshot support is verified before relying on it.
- Business-critical data has a backup method.
- Retention and RPO/RTO are documented.
- A restore has been tested.
Final recommendation
Use PersistentVolumes when a Kubernetes workload genuinely needs durable mounted filesystem state.
Let PVCs express application storage requirements and let StorageClasses define the platform provisioning behavior. Choose access modes deliberately, understand reclaim and binding policies, and keep application state outside the cluster when a managed database or object storage is the better system.
Most importantly, design recovery separately from persistence.
A PVC that survives a Pod replacement proves persistence. A tested restore proves recoverability.
Continue with Kubernetes Networking and Storage Architecture for the wider platform model, Kubernetes Cluster Sizing for capacity planning, and Kubernetes Backup and Disaster Recovery Strategy for recovery design.
