Kubernetes Persistent Volumes provide a reliable way to store application data beyond the lifetime of individual Kubernetes Pods. If you are running PostgreSQL, MySQL, MongoDB, WordPress, Jenkins, Kafka, Redis, or another stateful application, understanding persistent storage is essential.
Kubernetes is designed to continuously manage and replace workloads. Pods can be deleted, recreated, restarted, rescheduled to another node, or replaced during deployments. Temporary container storage is therefore not suitable for important application data.
Persistent storage solves this problem by separating the application lifecycle from the storage lifecycle.
In this guide, you will learn how PersistentVolumes (PV), PersistentVolumeClaims (PVC), StorageClasses, and CSI drivers work together. We will also cover practical YAML examples, dynamic provisioning, access modes, StatefulSets, volume expansion, snapshots, troubleshooting, backups, and production best practices.
The goal is to make Kubernetes storage easy to understand using practical examples rather than complicated terminology.
What Are Kubernetes Persistent Volumes?
Kubernetes Persistent Volumes are storage resources that provide persistent storage to applications running inside a Kubernetes cluster.
A normal container filesystem is closely associated with the container and Pod lifecycle. A PersistentVolume, on the other hand, is designed to have a lifecycle that is independent from an individual Pod.
This means an application can lose its Pod while retaining its data on persistent storage.
The basic Kubernetes storage relationship is:
Application
|
v
Pod
|
v
PVC
|
v
PV
|
v
StorageClass
|
v
CSI Driver
|
v
Storage Backend
For example, suppose a PostgreSQL database requires 50Gi of storage.
The application can create a PVC requesting 50Gi. Kubernetes can then dynamically provision a suitable PersistentVolume through a StorageClass and CSI driver.
The PostgreSQL application does not need to know which physical disk was created, where that disk is located, or how the storage provider manages it.
This abstraction is one of the major benefits of Kubernetes storage.
Why Kubernetes Persistent Volumes Are Important
Kubernetes Pods are intentionally disposable. A Pod can disappear because of a deployment, node failure, application failure, scaling operation, or manual deletion.
Consider a database running without persistent storage:
PostgreSQL Pod
|
v
Container Filesystem
|
v
Database Files
If the Pod is deleted and the database files exist only inside temporary container storage, the data may be lost.
With persistent storage, the architecture becomes:
PostgreSQL Pod
|
v
PostgreSQL PVC
|
v
PersistentVolume
|
v
Persistent Storage
Now the Pod can be replaced while the storage remains available.
For example:
Old Pod
|
| deleted
v
New Pod
|
v
Same PVC
|
v
Same Persistent Storage
This is particularly important for stateful workloads where losing application data can cause significant business impact.
Kubernetes Persistent Volumes vs Temporary Storage
Not every Kubernetes volume is a PersistentVolume.
Kubernetes provides temporary storage options such as emptyDir.
Example of emptyDir
apiVersion: v1
kind: Pod
metadata:
name: temporary-storage
spec:
containers:
- name: app
image: nginx
volumeMounts:
- name: cache
mountPath: /cache
volumes:
- name: cache
emptyDir: {}
This is useful for temporary data, caching, scratch space, and sharing files between containers in the same Pod.
However, when the Pod is removed from the node, the emptyDir data is removed.
For important application data, a PersistentVolume is usually more appropriate.
For more information, see the official Kubernetes Volumes documentation.
Understanding a Kubernetes PersistentVolume
A PersistentVolume, commonly called a PV, represents persistent storage that is available to Kubernetes workloads.
A PV can represent storage provided by a variety of storage systems, including:
- Cloud block storage
- NFS
- Ceph
- Enterprise storage systems
- Local storage
- Cloud file storage
- Other CSI-compatible storage systems
A simplified PV definition looks like this:
apiVersion: v1
kind: PersistentVolume
metadata:
name: example-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: manual
hostPath:
path: /data/example
The hostPath example is useful for learning because it is simple. However, it should not automatically be considered an appropriate production storage solution for a multi-node Kubernetes cluster.
In production, use a storage solution designed for your Kubernetes environment and workload requirements.
Understanding PersistentVolumeClaim in Kubernetes
A PersistentVolumeClaim, or PVC, is a request for storage.
This is an important distinction:
- PV represents storage.
- PVC requests storage.
- StorageClass defines how storage can be provisioned.
For example, an application may request 20Gi:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: application-data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
The application is effectively saying:
I need 20Gi of persistent storage with the requested access characteristics.
Kubernetes then attempts to find or provision storage that satisfies the request.
Kubernetes Persistent Volumes and StorageClass
A StorageClass defines a category or class of storage available to applications.
For example, a cluster might have:
standard
fast-ssd
premium
shared-filesystem
Different StorageClasses can represent different performance, availability, cost, or storage backend characteristics.
A PVC can request a specific class:
storageClassName: fast-ssd
This allows developers to request the appropriate type of storage without manually creating a physical volume.
A StorageClass can define settings such as:
- Provisioner
- Storage parameters
- Reclaim policy
- Volume expansion
- Volume binding behavior
- Topology-related configuration
See the official Kubernetes StorageClasses documentation for the current behavior.
How Kubernetes Persistent Volumes Work
The complete process can be understood in six simple steps.
Step 1: The Application Requests Storage
The application creates a PVC.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: database-data
spec:
accessModes:
- ReadWriteOnce
storageClassName: fast-ssd
resources:
requests:
storage: 50Gi
Step 2: Kubernetes Finds the StorageClass
Kubernetes checks the requested StorageClass:
fast-ssd
Step 3: CSI Driver Provisions Storage
When dynamic provisioning is configured, the CSI driver communicates with the storage platform.
PVC
|
v
StorageClass
|
v
CSI Driver
|
v
Storage Provider
Step 4: Storage Is Created
The storage backend creates the requested volume.
Step 5: Kubernetes Binds the PVC
After successful provisioning, the PVC can become Bound.
kubectl get pvc
Example:
NAME STATUS VOLUME CAPACITY
database-data Bound pvc-12345678-abcd-1234-abcd-123456789abc 50Gi
Step 6: The Pod Mounts the PVC
The application Pod references the PVC and mounts it into the container.
Static and Dynamic Kubernetes Persistent Volumes
Static Provisioning
With static provisioning, an administrator creates the storage and PersistentVolume before the application requests it.
Administrator
|
v
Storage
|
v
PersistentVolume
|
v
PersistentVolumeClaim
|
v
Application
This can be useful when existing storage must be manually controlled.
Dynamic Provisioning
Dynamic provisioning allows Kubernetes to create storage when an application requests it.
Application
|
v
PVC
|
v
StorageClass
|
v
CSI Driver
|
v
Storage Provider
|
v
New Storage
Dynamic provisioning is commonly used in cloud environments because administrators do not have to manually create every PV.
The official Kubernetes PersistentVolume documentation provides additional details.
Kubernetes Persistent Volumes Access Modes
Access modes describe how a volume can be mounted, subject to the capabilities of the storage backend and CSI driver.
ReadWriteOnce
ReadWriteOnce, or RWO, allows read-write mounting from a single node.
accessModes:
- ReadWriteOnce
This is commonly used with block storage and database workloads.
Remember that RWO describes node-level access semantics. It should not automatically be interpreted as “only one Pod can ever use the volume.”
ReadOnlyMany
ReadOnlyMany, or ROX, allows a volume to be mounted read-only from multiple nodes when supported by the storage system.
ReadWriteMany
ReadWriteMany, or RWX, allows read-write mounting from multiple nodes when supported by the storage backend.
This is commonly useful for shared filesystem workloads.
ReadWriteOncePod
ReadWriteOncePod, or RWOP, provides stricter single-Pod read-write access when supported by the storage driver.
| Mode | Meaning | Typical Example |
|---|---|---|
| RWO | Read/write from one node | Database on block storage |
| ROX | Read-only from multiple nodes | Shared read-only content |
| RWX | Read/write from multiple nodes | Shared filesystem |
| RWOP | Read/write from one Pod | Strict single-Pod workload |
Always check whether your chosen CSI driver and storage backend support the requested access mode.
Filesystem and Block Volume Modes
Persistent storage can be consumed as either a filesystem or a raw block device.
Filesystem Mode
Filesystem mode is the most common option for applications.
volumeMode: Filesystem
The application sees a mounted directory such as:
/var/lib/postgresql/data
Block Mode
Block mode exposes a raw block device to the application.
volumeMode: Block
This is useful for applications that need to manage the block device themselves.
Kubernetes Persistent Volumes and CSI Drivers
CSI stands for Container Storage Interface.
CSI provides a standardized way for Kubernetes to communicate with external storage systems.
Instead of Kubernetes having to implement custom integration logic for every storage vendor, a storage provider can supply a CSI driver.
Kubernetes
|
v
CSI Driver
|
+-------------+-------------+
| | |
v v v
Cloud Disk NFS Ceph
Depending on the driver, CSI can provide capabilities such as:
- Volume provisioning
- Volume deletion
- Volume attachment
- Volume mounting
- Volume detachment
- Volume expansion
- Snapshots
- Cloning
Feature availability depends on the specific CSI implementation.
See the official Kubernetes CSI documentation.
Real-World Kubernetes Persistent Volumes Example: PostgreSQL
Consider an online shopping application that uses PostgreSQL.
The architecture could look like this:
Online Store
|
v
PostgreSQL Pod
|
v
postgres-data PVC
|
v
PersistentVolume
|
v
Cloud Block Storage
PostgreSQL commonly stores database files under:
/var/lib/postgresql/data
Create the PVC:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: postgres-data
spec:
accessModes:
- ReadWriteOnce
storageClassName: fast-ssd
resources:
requests:
storage: 20Gi
A simplified Deployment could then mount the claim:
apiVersion: apps/v1
kind: Deployment
metadata:
name: postgres
spec:
replicas: 1
selector:
matchLabels:
app: postgres
template:
metadata:
labels:
app: postgres
spec:
containers:
- name: postgres
image: postgres:17
env:
- name: POSTGRES_PASSWORD
value: "change-me"
volumeMounts:
- name: postgres-storage
mountPath: /var/lib/postgresql/data
volumes:
- name: postgres-storage
persistentVolumeClaim:
claimName: postgres-data
The important part is the PVC reference:
persistentVolumeClaim:
claimName: postgres-data
The Pod does not directly specify the underlying physical storage device.
What Happens When a Pod Using Persistent Storage Is Deleted?
Suppose the PostgreSQL Pod is deleted:
kubectl delete pod <POSTGRES_POD>
The Deployment can create a replacement Pod.
Old PostgreSQL Pod
|
| deleted
v
New PostgreSQL Pod
|
v
Same PVC
|
v
Persistent Storage
The persistent storage can therefore survive the replacement of the Pod.
This is the fundamental reason Kubernetes Persistent Volumes are important for stateful workloads.
Kubernetes Persistent Volumes with StatefulSets
Stateful applications often require more than persistent storage. They may also need stable network identities and individual storage for each replica.
Kubernetes StatefulSets are designed for workloads that need stable identities and ordered management.
Common examples include:
- PostgreSQL clusters
- MySQL clusters
- MongoDB deployments
- Kafka
- RabbitMQ
- Elasticsearch
A StatefulSet can use volumeClaimTemplates to create storage claims for individual Pods.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: postgres
spec:
serviceName: postgres
replicas: 3
selector:
matchLabels:
app: postgres
template:
metadata:
labels:
app: postgres
spec:
containers:
- name: postgres
image: postgres:17
volumeMounts:
- name: postgres-data
mountPath: /var/lib/postgresql/data
volumeClaimTemplates:
- metadata:
name: postgres-data
spec:
accessModes:
- ReadWriteOnce
storageClassName: fast-ssd
resources:
requests:
storage: 50Gi
The resulting claims can look similar to:
postgres-data-postgres-0
postgres-data-postgres-1
postgres-data-postgres-2
The architecture is:
StatefulSet
|
+----------+----------+
| | |
v v v
Pod-0 Pod-1 Pod-2
| | |
v v v
PVC-0 PVC-1 PVC-2
| | |
v v v
PV-0 PV-1 PV-2
This pattern is especially important when each replica requires its own independent data directory.
You can also explore our Kubernetes StatefulSet guides.
Block Storage vs File Storage vs Object Storage
Choosing the correct storage type is critical when designing Kubernetes applications.
| Storage Type | Examples | Typical Use |
|---|---|---|
| Block Storage | AWS EBS, Azure Managed Disk, Google Persistent Disk | Databases and filesystems |
| File Storage | NFS, Amazon EFS, Azure Files | Shared filesystem |
| Object Storage | Amazon S3, Google Cloud Storage, Azure Blob | Backups, media and large objects |
Block Storage
Block storage behaves like a disk attached to a system.
It is commonly used for:
- PostgreSQL
- MySQL
- MongoDB
- Application filesystems
File Storage
File storage provides shared filesystem semantics.
NFS is a common example. Cloud file services can also provide shared filesystem access.
Object Storage
Object storage is designed for objects rather than traditional filesystem access.
It is commonly used for:
- Images
- Videos
- Backups
- Archives
- Logs
- Static assets
Important: AWS EBS is block storage, while Amazon S3 is object storage. They are designed for different workloads.
Kubernetes Persistent Volumes and Storage Topology
Storage topology becomes particularly important in multi-zone cloud environments.
For example, a block volume may be created in one availability zone while a Kubernetes Pod is scheduled to a node in another zone.
This can cause volume attachment or scheduling problems depending on the storage implementation.
A StorageClass can use:
volumeBindingMode: WaitForFirstConsumer
This delays volume provisioning until Kubernetes has information about the Pod’s scheduling requirements.
The general workflow becomes:
PVC
|
v
Wait
|
v
Pod Scheduling
|
v
Node Selected
|
v
Storage Provisioned
|
v
Volume Attached
This can be especially useful for topology-aware storage.
Persistent Volume Reclaim Policies
The reclaim policy controls what happens to a PV after the associated claim is released.
Retain
persistentVolumeReclaimPolicy: Retain
Retain keeps the storage available for manual recovery or cleanup.
This can be useful for important production data where accidental deletion must be handled carefully.
Delete
persistentVolumeReclaimPolicy: Delete
Delete can cause dynamically provisioned storage to be removed when the associated storage resource is released, depending on the storage driver and configuration.
This is useful when automatic lifecycle management is desired.
Recycle
The old Recycle reclaim policy is deprecated and should not be used for new designs.
| Policy | Typical Purpose |
|---|---|
| Retain | Important data and manual recovery |
| Delete | Automatic storage lifecycle |
| Recycle | Deprecated |
What Happens When a PVC Is Deleted?
This is an important question for production Kubernetes administrators.
Consider:
Application
|
v
PVC
|
v
PV
|
v
Storage Backend
When a PVC is deleted, the eventual storage behavior depends on the PV and StorageClass configuration.
If the storage is dynamically provisioned and the relevant reclaim behavior is Delete, the underlying storage can eventually be deleted.
If the reclaim behavior is Retain, the storage can remain available for manual recovery.
Therefore, never delete a production PVC without first checking its storage configuration.
Expanding Kubernetes Persistent Volumes
Application storage often grows over time.
For example:
Initial storage:
20Gi
Later requirement:
50Gi
If the StorageClass and CSI driver support volume expansion, the PVC can be increased.
First inspect the StorageClass:
kubectl get storageclass fast-ssd -o yaml
Look for:
allowVolumeExpansion: true
Then edit the PVC:
kubectl edit pvc postgres-data
Change:
storage: 20Gi
to:
storage: 50Gi
You can also use:
kubectl patch pvc postgres-data \
-p '{"spec":{"resources":{"requests":{"storage":"50Gi"}}}}'
Volume expansion increases the requested storage. It should not be treated as a general-purpose volume shrinking mechanism.
Kubernetes Persistent Volumes and Snapshots
CSI-based storage integrations can support volume snapshots.
A snapshot represents a point-in-time state of a volume.
PersistentVolume
|
v
Snapshot
|
v
New PVC
Snapshots can be useful for:
- Testing
- Development
- Application upgrades
- Recovery workflows
- Storage cloning
However, a snapshot should not automatically be considered a complete database backup.
Database consistency, retention, off-site storage, encryption, and restoration testing are still important.
See the official Kubernetes Volume Snapshots documentation.
Kubernetes Persistent Volumes Are Not Backups
This is one of the most important production lessons.
Persistent storage keeps data available, but it does not automatically protect that data from every failure scenario.
For example:
Database
|
v
Persistent Volume
|
v
Database Files
If the database becomes corrupted, the PersistentVolume can preserve the corrupted data perfectly.
A proper production architecture should therefore include a separate backup strategy.
Database
|
v
Persistent Storage
|
+----------------------+
| |
v v
Normal Operation Backup
|
v
Backup Storage
For databases, backups should be tested by performing actual restoration exercises.
Kubernetes Persistent Volumes for WordPress
WordPress is another common stateful application deployed on Kubernetes.
WordPress can require persistent storage for:
- Uploaded media
- Plugins
- Themes
- Generated files
A simplified architecture is:
WordPress
|
+----------+----------+
| |
v v
WordPress PVC Database PVC
| |
v v
Shared/File Storage Block Storage
If multiple WordPress Pods need to access the same uploads directory from different nodes, the storage system must support an appropriate shared access mode.
For example, an RWX-capable filesystem may be appropriate for shared application files.
However, RWX should not be selected simply because it appears more flexible. Storage must match the actual workload and CSI driver capabilities.
Static PersistentVolume Example
Here is a simple static PV example:
apiVersion: v1
kind: PersistentVolume
metadata:
name: manual-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: manual
hostPath:
path: /mnt/data
The matching PVC can be:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: manual-pvc
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
Kubernetes can bind the PVC to a suitable PV when the requirements match.
Dynamic Kubernetes Persistent Volumes Example
Dynamic provisioning is generally easier to manage in cloud environments.
Assume that the cluster has a StorageClass called:
fast-ssd
Create a PVC:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: application-data
spec:
accessModes:
- ReadWriteOnce
storageClassName: fast-ssd
resources:
requests:
storage: 50Gi
Apply it:
kubectl apply -f pvc.yaml
Check its status:
kubectl get pvc
If the StorageClass and CSI driver are configured correctly, Kubernetes can dynamically create the required storage.
How to Check Kubernetes Persistent Volumes
The following commands are useful when managing Kubernetes storage.
List PersistentVolumes
kubectl get pv
List PersistentVolumeClaims
kubectl get pvc
List PVCs in All Namespaces
kubectl get pvc -A
List StorageClasses
kubectl get storageclass
You can also use the shorter command:
kubectl get sc
How to Inspect a PVC
If a PVC is not working correctly, inspect it with:
kubectl describe pvc <PVC_NAME>
Pay particular attention to:
- Status
- StorageClass
- Capacity
- Access modes
- Events
- Provisioning errors
Events are often the fastest way to identify why a claim is not being provisioned or bound.
Kubernetes Persistent Volumes Troubleshooting
Storage issues can occur during application deployment, cluster upgrades, node failures, or CSI driver configuration changes.
PVC Is Stuck in Pending
Check:
kubectl get pvc
Example:
NAME STATUS
postgres-data Pending
Then inspect the claim:
kubectl describe pvc postgres-data
Common causes include:
- StorageClass does not exist
- CSI driver is unavailable
- Requested capacity cannot be provisioned
- Unsupported access mode
- Storage backend failure
- Topology restrictions
- Provisioning configuration errors
StorageClass Does Not Exist
kubectl get storageclass
Verify that the StorageClass requested by the PVC actually exists.
Unsupported Access Mode
For example, a PVC may request:
ReadWriteMany
while the storage backend supports only:
ReadWriteOnce
The claim may therefore remain pending or fail provisioning.
CSI Driver Problem
If dynamic provisioning fails, inspect the CSI controller and node components according to the documentation for the storage provider.
Volume Mount Failure
A PVC can be successfully bound but still fail to mount into a Pod.
Inspect the Pod:
kubectl describe pod <POD_NAME>
Review the Events section for attachment, mounting, permission, or filesystem errors.
Useful Kubernetes Persistent Volumes Troubleshooting Commands
# List PersistentVolumes
kubectl get pv
# List PersistentVolumeClaims
kubectl get pvc
# List PVCs across all namespaces
kubectl get pvc -A
# List StorageClasses
kubectl get storageclass
# Inspect PVC
kubectl describe pvc <PVC_NAME>
# Inspect PV
kubectl describe pv <PV_NAME>
# Inspect Pod
kubectl describe pod <POD_NAME>
# List recent events
kubectl get events --sort-by=.lastTimestamp
Understanding PersistentVolume Status
Available
An Available PV exists but is not currently bound to a PVC.
PV
|
+-- Available
Bound
A Bound PV is associated with a PVC.
PV
|
+-- Bound
|
+-- PVC
Released
A Released PV has had its claim released but may still require cleanup depending on its reclaim behavior.
15 Powerful Kubernetes Persistent Volumes Best Practices
1. Prefer Dynamic Provisioning
Dynamic provisioning reduces manual storage administration and is commonly appropriate for cloud environments.
2. Use StorageClasses
Create storage classes that represent meaningful workload requirements.
Examples include:
standard
fast-ssd
shared-filesystem
3. Choose the Correct Access Mode
Choose RWO, RWX, ROX, or RWOP according to the application and storage capabilities.
4. Understand the Reclaim Policy
Before deleting a PVC, understand what can happen to the underlying storage.
5. Enable Volume Expansion Where Appropriate
Applications such as databases frequently grow, making storage expansion an important operational feature.
6. Consider Storage Topology
Understand zones, nodes, volume attachment, and topology restrictions.
7. Avoid hostPath for General Production Storage
hostPath directly exposes a node’s filesystem and can create problems when workloads move between nodes.
8. Keep Backups Separate
A PersistentVolume is not a backup system.
9. Monitor Storage Capacity
Monitor filesystem utilization, volume capacity, backend capacity, IOPS, throughput, and latency.
10. Test Restores
A backup that has never been restored successfully should not be considered a proven disaster recovery solution.
11. Use StatefulSets for Appropriate Stateful Applications
StatefulSets can provide stable identities and per-Pod storage for suitable workloads.
12. Document Storage Dependencies
Document the StorageClass, CSI driver, access modes, backup process, and recovery procedure.
13. Monitor CSI Components
CSI failures can affect provisioning, attachment, mounting, expansion, and snapshots.
14. Protect Production PVCs
Use appropriate access controls and operational procedures around production storage resources.
15. Test Failure Scenarios
Test Pod replacement, node failure, storage failure, volume expansion, restore procedures, and application recovery before relying on the architecture in production.
Kubernetes Persistent Volumes Production Architecture
A typical production architecture can look like this:
Kubernetes Cluster
|
v
+-------------+
| Application |
| Pod |
+------+------+
|
v
+-------------+
| PVC |
+------+------+
|
v
+-------------+
| PV |
+------+------+
|
v
+-------------+
| StorageClass|
+------+------+
|
v
+-------------+
| CSI Driver |
+------+------+
|
+------------+------------+
| | |
v v v
Block File Other
Storage Storage Backends
This architecture separates the application from the physical storage infrastructure.
The application requests storage through a PVC. Kubernetes uses the StorageClass and CSI driver to connect that request to the appropriate storage backend.
Kubernetes Persistent Volumes vs PVC vs StorageClass
| Component | Purpose | Easy Explanation |
|---|---|---|
| PersistentVolume | Represents storage | The available storage |
| PersistentVolumeClaim | Requests storage | The application’s storage request |
| StorageClass | Defines provisioning | The storage type/profile |
| CSI Driver | Connects Kubernetes to storage | The storage integration layer |
The easiest way to remember this is:
PVC = "I need storage."
PV = "Here is storage."
StorageClass = "Here is how storage should be provisioned."
CSI Driver = "Here is how Kubernetes talks to the storage system."
Easy Analogy for Kubernetes Persistent Volumes
If Kubernetes storage concepts seem complicated, think about renting an apartment.
- PV = Available apartment
- PVC = Rental request
- StorageClass = Apartment category
- Pod = Person living in the apartment
- Storage backend = Building infrastructure
The person renting the apartment does not need to know how the building was constructed.
Similarly, an application does not normally need to know which physical disk provides its storage.
The application requests storage, Kubernetes provisions or selects suitable storage, and the Pod mounts it.
The Kubernetes Persistent Volumes Architecture to Remember
If you remember only one diagram from this article, remember this:
+-------------+
| Pod |
+------+------+
|
| uses
v
+-------------+
| PVC |
+------+------+
|
| binds to
v
+-------------+
| PV |
+------+------+
|
| provisioned through
v
+-------------+
| StorageClass|
+------+------+
|
v
+-------------+
| CSI Driver |
+------+------+
|
v
+-------------+
| Storage |
| Backend |
+-------------+
Once this relationship becomes familiar, most Kubernetes storage configurations become much easier to understand.
15 Key Kubernetes Persistent Volumes Tips
- Use PVCs instead of directly coupling applications to physical storage.
- Prefer dynamic provisioning where it makes sense.
- Understand the StorageClass used by every production PVC.
- Know which CSI driver provides your storage.
- Choose access modes based on actual application requirements.
- Understand the difference between block, file, and object storage.
- Consider topology when using zonal storage.
- Understand reclaim behavior before deleting storage resources.
- Use volume expansion when supported and required.
- Use StatefulSets for workloads that need stable identities and per-Pod storage.
- Never treat persistent storage as a replacement for backups.
- Monitor capacity and storage performance.
- Test backup restoration regularly.
- Use Kubernetes events to troubleshoot storage failures.
- Document storage architecture and recovery procedures.
Kubernetes Persistent Volumes FAQ
What are Kubernetes Persistent Volumes?
Kubernetes Persistent Volumes are Kubernetes storage resources designed to provide persistent storage to applications. They allow data to survive the replacement of individual Pods.
What is a PersistentVolume?
A PersistentVolume, or PV, represents persistent storage available to Kubernetes workloads.
What is a PersistentVolumeClaim?
A PersistentVolumeClaim, or PVC, is a request for persistent storage made by an application or user.
What is the difference between PV and PVC?
A PV represents storage, while a PVC requests storage. Kubernetes binds a suitable PV to a PVC.
What is a StorageClass?
A StorageClass defines a category of storage and provides the configuration Kubernetes can use for dynamic provisioning.
What is CSI?
CSI stands for Container Storage Interface. CSI drivers allow Kubernetes to communicate with external storage platforms.
Does deleting a Pod delete the PersistentVolume?
Normally, deleting a Pod does not delete its PersistentVolume. The storage lifecycle is separate from the individual Pod lifecycle.
Does deleting a PVC delete the storage?
It depends on the storage configuration and reclaim behavior. A Delete policy can result in dynamically provisioned storage being removed, while Retain can preserve storage for manual recovery.
Can Kubernetes Persistent Volumes be expanded?
Yes. PVC expansion is possible when the StorageClass and underlying CSI driver support volume expansion.
Are PersistentVolumes backups?
No. Persistent storage is not a replacement for backups. Production applications should use a separate backup and disaster recovery strategy.
What is the difference between RWO and RWX?
RWO allows read-write mounting from a single node, while RWX allows read-write mounting from multiple nodes when supported by the storage system.
Why is my PVC stuck in Pending?
Common causes include a missing StorageClass, unsupported access mode, insufficient storage capacity, CSI provisioning problems, or topology constraints. Start with kubectl describe pvc <PVC_NAME>.
Useful Kubernetes Storage Commands
# List PersistentVolumes
kubectl get pv
# List PersistentVolumeClaims
kubectl get pvc
# List PVCs in every namespace
kubectl get pvc -A
# List StorageClasses
kubectl get storageclass
# Inspect a PVC
kubectl describe pvc <PVC_NAME>
# Inspect a PV
kubectl describe pv <PV_NAME>
# Inspect a Pod
kubectl describe pod <POD_NAME>
# List recent events
kubectl get events --sort-by=.lastTimestamp
Related Kubernetes Guides
If you are learning Kubernetes storage, the following topics are closely related:
- Kubernetes StatefulSets
- Kubernetes Pods
- Kubernetes Deployments
- Kubernetes ConfigMaps
- Kubernetes Secrets
- Kubernetes RBAC
- Kubernetes Networking
- Kubernetes Troubleshooting
Official Kubernetes Storage Resources
For production deployments, always verify the behavior of your Kubernetes version and CSI driver against the official documentation.
Conclusion: Kubernetes Persistent Volumes Made Easy
Kubernetes Persistent Volumes provide an abstraction between applications and the underlying storage infrastructure. They are essential for workloads where application data must survive Pod replacement, rescheduling, and other changes in the Kubernetes environment.
The most important relationship to remember is:
Pod
|
v
PVC
|
v
PV
|
v
StorageClass
|
v
CSI Driver
|
v
Storage Backend
The PVC represents what the application needs. The PV represents persistent storage. The StorageClass defines how storage can be provisioned, while the CSI driver provides the integration between Kubernetes and the storage platform.
For production workloads, storage should be designed together with backup, restoration, monitoring, security, capacity planning, performance, topology, availability, and disaster recovery.
Once you understand the Pod → PVC → PV → StorageClass → CSI → Storage Backend relationship, Kubernetes storage becomes significantly easier to design, deploy, and troubleshoot.
Whether you are deploying PostgreSQL, MySQL, MongoDB, WordPress, Jenkins, Kafka, or another stateful application, choosing and managing the correct persistent storage architecture is an important part of running Kubernetes successfully.
Comments
Loading comments…
Leave a Comment