What Does Persistent Volume Claims Mean?
Also known as: Persistent Volume Claims, Kubernetes PVC, CKA storage, Persistent Volume vs PVC, Kubernetes storage exam
On This Page
Quick Definition
A Persistent Volume Claim (PVC) is like a storage request form for Kubernetes. It lets your application ask for a specific amount of storage and access speed, without needing to know where the storage physically comes from. Kubernetes then finds or creates the right storage and connects it to your application.
Must Know for Exams
The CNCF CKA (Certified Kubernetes Administrator) exam includes Persistent Volume Claims directly in its curriculum under the Storage domain. The exam objectives specify that candidates must understand how to configure and manage storage for stateful applications. Specifically, candidates need to demonstrate the ability to create PVCs, understand the lifecycle of PVs and PVCs, configure StorageClasses, and troubleshoot binding issues.
Exam questions often require the candidate to create a PVC that matches a given scenario. For example, the question might state: Create a PVC named web-data that requests 5Gi of storage using the standard StorageClass, with access mode ReadWriteOnce. Then create a pod that mounts this PVC at /var/opt/app. The candidate must write the YAML manifest or use kubectl commands to achieve this.
Another common exam task involves understanding the states of PVCs. The candidate might be given a cluster where a PVC is in Pending state, and they must identify why. Possible reasons include no PV with sufficient size, mismatched access mode, or missing StorageClass. The candidate must resolve the issue by either creating a suitable PV or adjusting the PVC.
The exam also tests knowledge of reclaim policies. For instance, a question might ask: What happens to a PV when its associated PVC is deleted if the reclaim policy is set to Retain? The correct answer is that the PV remains in the Released state and must be manually reclaimed by an administrator.
StorageClass definitions and dynamic provisioning are also tested. Candidates may need to create a StorageClass that points to a specific provisioner with parameters like type=pd-ssd on GKE, then ensure PVCs using that StorageClass automatically provision volumes.
Finally, the exam may present multi-step scenarios where the candidate must fix a failing application due to a PVC binding issue. For example, a pod cannot start because it references a PVC that does not exist. The candidate must create the PVC and verify the pod becomes ready.
Mastering PVCs is therefore essential for CKA success. The Storage domain accounts for a significant portion of the exam, and PVCs are the primary way Kubernetes handles persistent data.
Simple Meaning
Think of a Persistent Volume Claim (PVC) as a library card for a book you want to read. In Kubernetes, applications run inside containers, which are like small, temporary rooms. These rooms need storage to keep data, like a notebook or a file. But containers are short-lived: if a container crashes or restarts, everything inside it is lost. That is why Kubernetes introduces Persistent Volumes (PVs), which are like permanent books on a library shelf. A PVC is not the storage itself, but a request that says: I need a book of a certain type and length, with this much information.
The library (Kubernetes) receives the request. It checks its shelves for a book (PV) that matches the request. If a matching book exists, it assigns that book to the requester. If not, the library may order a new book if the system is set up for dynamic provisioning. The user only needs to know what kind of book they need, not where it is stored or which shelf it comes from.
In technical terms, a PVC is a Kubernetes object that binds to a Persistent Volume. The PVC specifies storage size, access modes such as read and write once or read only many, and optionally a storage class for performance or backup rules. Once bound, the PVC acts as a link between the pod and the PV. The pod sees the PVC as a volume that can be mounted, like plugging in a USB drive. If the pod moves to another node, the PVC and its bound PV follow the pod, ensuring data persists.
This separation of request from actual storage gives cluster administrators flexibility. They can manage the underlying storage hardware, whether it is NFS, cloud disks like AWS EBS, or local SSD, without developers needing to change their application code. Developers simply use the PVC, and the administrator ensures the storage pool meets demand.
Full Technical Definition
A Persistent Volume Claim (PVC) is a Kubernetes API object that represents a request for storage resources of a specific size, access mode, and, optionally, storage class. PVCs are part of the Kubernetes storage ecosystem designed to decouple storage consumption from storage provisioning. Administrators provision Persistent Volumes (PVs), which are cluster resources backed by actual storage implementations such as NFS, iSCSI, cloud provider volumes like AWS EBS or Azure Disk, or local storage. Developers or users then create PVCs to claim portions of that storage.
The lifecycle of a PVC involves several stages: creation, binding, use, and possibly release or deletion. When a PVC is created, Kubernetes examines the cluster’s PVs to find one that satisfies the PVC’s requirements: sufficient capacity, compatible access mode, and matching storage class if specified. If a matching PV exists, the PVC binds to it in a one-to-one relationship. If no PV matches and the cluster is configured with a StorageClass that supports dynamic provisioning, Kubernetes will automatically provision a new PV that meets the claim’s specifications. This dynamic provisioning relies on a provisioner plugin, such as CSI drivers, which interacts with the underlying storage system.
Access modes define how the storage can be mounted. The three primary modes are ReadWriteOnce (RWO), which allows a single node to mount the volume as read-write; ReadOnlyMany (ROX), which allows many nodes to mount the volume as read-only; and ReadWriteMany (RWX), which allows many nodes to mount the volume as read-write. These modes align with common storage backends: for example, many cloud block storage devices support only RWO, while network filesystems like NFS can support RWX.
After binding, the PVC remains associated with the PV until the PVC is deleted. During use, a pod references the PVC by name in its volume definitions. The pod can then mount the volume at a specified mount point inside the container. If a pod is deleted or rescheduled, the PVC and its bound PV persist. This ensures data survives pod restarts.
Reclaim policies determine what happens to a PV after its associated PVC is deleted. The three policies are Retain (administrator must manually reclaim the storage), Recycle (basic scrubbing and available for reuse), and Delete (the underlying storage asset is automatically removed). In cloud environments, Delete is common to avoid orphaned disks that incur costs.
PVCs support status fields such as Pending (waiting to bind), Bound (successfully bound to a PV), and Lost (the bound PV is missing). Understanding these states is critical for troubleshooting storage issues in production Kubernetes clusters.
Real-Life Example
Imagine you work in a large office building with a central storage room. This room contains many lockers of different sizes and types. Some lockers have combination locks, some are keyed, and some are open for anyone to store items. Each locker is like a Persistent Volume (PV) in Kubernetes: it is a physical storage container managed by the building manager (the cluster administrator).
You need a place to store your project files because your desk has only a small drawer. You do not care which exact locker you get, as long as it is large enough, secure, and accessible during working hours. So you fill out a storage request form. On this form, you write: I need a medium-size locker, with a combination lock, for my solo use. This form is your Persistent Volume Claim (PVC).
You submit the form to the building manager. The manager looks at the storage room. They check the inventory of lockers. If there is a medium locker with a combination lock that is not assigned to anyone, the manager assigns it to you. Your claim is now bound to that specific locker. A key or combination code is given to you, analogous to the mount path in the pod.
If there is no matching locker, the building manager might order a new locker from a supplier that provides this service. This is like dynamic provisioning, where Kubernetes asks a storage provider to create a new volume that matches your PVC.
Once you have your locker assigned, you can open it, store files, and retrieve them. Even if you move to a different desk on another floor, your claim remains linked to that locker. You can continue accessing your files as long as you keep the claim active. When you finish the project, you return the locker by deleting the claim. The manager then decides whether to clean the locker for someone else (recycle) or keep it closed for later use (retain).
In this analogy, your desk represents a pod, and the files in the locker represent data that survives pod restarts. The claim form (PVC) separates the need for storage from the actual locker management, making the system flexible and simpler for everyone.
Why This Term Matters
Persistent Volume Claims are fundamental to running stateful applications in Kubernetes. Many real-world applications, such as databases, content management systems, and file servers, require data to persist beyond the lifecycle of a container or pod. Without PVCs, developers would need to hardcode storage paths, manually attach storage disks to nodes, or rebuild data after each deployment. This would be error-prone, time-consuming, and not scalable.
In practice, PVCs allow platform teams to standardize storage offerings. An administrator can define a set of StorageClasses that map to different performance tiers: fast SSD storage for databases, slower HDD for backups, and shared network storage for web assets. Developers then use PVCs to request the tier they need without knowing the underlying vendor specifics. This abstraction reduces coupling between application code and infrastructure.
From a cost management perspective, PVCs enable lifecycling of storage. Dynamic provisioning with delete reclaim policies ensures that unused cloud disks are automatically cleaned up when no longer needed, preventing wasted spending. For example, if a development environment spins up and tears down repeatedly, PVCs can be deleted along with the pods, and the associated cloud disk is removed automatically.
Operationally, PVCs provide portability. A Kubernetes cluster running on Amazon EKS can use the same PVC definitions as one running on Google GKE or on bare metal, as long as the StorageClass names are abstracted. This simplifies hybrid or multi-cloud strategies.
In troubleshooting scenarios, PVCs help isolate storage issues. If a pod cannot start because it cannot mount a volume, the administrator investigates the PVC status: is it Pending because no matching PV exists? Or is it Bound but the underlying storage is unreachable? These signals speed up root cause analysis.
Finally, security is improved because PVCs allow fine-grained access control. Namespace-scoped PVCs prevent teams from accidentally claiming storage allocated to another team. The access modes enforce read or write permissions at the node level, preventing unintended writes from multiple pods when the storage backend does not support concurrent writes.
How It Appears in Exam Questions
In CKA and related Kubernetes exams, Persistent Volume Claims appear in several types of questions:
Creation and configuration questions: These ask you to write YAML or use kubectl to create a PVC with specific parameters. For example: Create a PVC named data-volume of size 2Gi, access mode ReadWriteOnce, using the storage class fast. Then create a pod named app that mounts this volume at /data. The candidate must correctly define the PVC, pod volumes, and volumeMounts.
Troubleshooting questions: A cluster has a PVC that remains in Pending state. The question presents the PVC definition and maybe the list of PVs. The candidate must identify why binding fails. Common reasons: no PV matches the size or access mode, the PVC specifies a StorageClass that does not exist, or the PV is already bound to another PVC. The candidate might need to create a matching PV or modify the PVC.
Scenario-based questions: You are given a deployment of a MySQL database that crashes after a node failure because the data is stored in an emptyDir volume. The question asks you to reconfigure the deployment to use a PVC that persists data across pod restarts. The candidate must create a PVC and update the deployment to reference it.
Policy questions: A cluster has multiple storage classes. The question asks: Which storage class should be used for a shared filesystem that multiple pods need to write to simultaneously? The correct answer is a storage class that supports ReadWriteMany, such as an NFS-based class.
Reclaim policy questions: After deleting a PVC, the PV is not automatically released. The question asks: What reclaim policy is set on the PV? How can you manually make the PV available again? The candidate must change the PV’s status from Released to Available by editing the PV and removing the claimRef.
Dynamic provisioning questions: The exam may ask you to verify that a PVC triggers the creation of a corresponding PV. You might need to check the storage class and provisioner settings.
Ordering and troubleshooting: A common pattern is to create a pod, then notice it is in ContainerCreating state. You run describe pod and see a warning about persistentvolumeclaim not found. You then create the missing PVC and the pod starts. The exam expects you to follow this logical sequence.
Understanding these question patterns is critical for efficient time management during the exam. The tasks are usually straightforward if you know the YAML structure for PVCs and the related kubectl commands.
Study cncf-cka
Test your understanding with exam-style practice questions.
Example Scenario
A company runs an online store on a Kubernetes cluster. The store uses a Postgres database to store customer orders. One day, a node fails, and the database pod is rescheduled to another node. But because the database was using an emptyDir volume, all the order data from the last hour is lost. Customers complain about missing orders.
The operations team decides to implement persistent storage. They create a PVC named postgres-pvc that requests 50Gi of storage with ReadWriteOnce access mode, using the standard StorageClass. The Postgres deployment is updated to include this PVC as a volume, mounted at /var/lib/postgresql/data.
Now, when a node fails again, the database pod restarts on a healthy node. Kubernetes automatically mounts the same PVC, which is bound to a persistent disk in the cloud. All data remains intact. The store recovers without data loss.
This scenario shows exactly how PVCs solve real problems. The developers only needed to know that they wanted 50Gi of fast, reliable storage; they did not need to worry about the specific cloud disk name, availability zone, or mounting commands. The PVC abstracted that complexity.
Common Mistakes
Thinking a PVC is the actual storage device.
A PVC is only a request for storage, not the storage itself. The actual storage is the Persistent Volume (PV) that binds to the PVC.
Remember: PVC is like a form asking for storage; the PV is the storage hardware or cloud disk that fulfills that request.
Forgetting to specify the correct access mode.
If the PVC specifies ReadWriteOnce but the pod runs on multiple nodes and needs concurrent writes, the volume cannot be mounted correctly, causing pod failures.
Always match the access mode to your application’s needs. For single-pod write, use RWO. For multiple read-only pods, use ROX. For multiple writer pods, use RWX.
Assuming PVCs are automatically deleted when a pod is deleted.
PVCs are separate objects from pods. Deleting a pod does not delete its PVC. This is by design so that data persists, but it can lead to orphaned volumes if not managed deliberately.
Use a Helm chart or operator that handles PVC lifecycle, or implement a retention policy. Delete PVCs manually if the data is no longer needed.
Using a StorageClass that does not support the required access mode.
Many StorageClasses only support ReadWriteOnce. If you request ReadWriteMany but the underlying provisioner can only do RWO, the PVC will stay Pending.
Check the documentation of your StorageClass or provisioner to confirm supported access modes before writing the PVC YAML.
Specifying a storage size that is too small or too large.
If the application grows beyond the PVC size, it will run out of disk space. If you request far more than needed, you waste cloud storage costs.
Right-size the PVC based on historical usage or expected growth. Use monitoring to adjust size if needed. Some StorageClasses support volume expansion.
Creating a PVC without a matching PV or StorageClass in a cluster without dynamic provisioning.
If no PV exists that matches the PVC’s size and access mode, and no StorageClass provisioner is defined, the PVC will remain in Pending state indefinitely.
Either pre-provision a PV that matches, or create a StorageClass with a provisioner such as kubernetes.io/aws-ebs before creating the PVC.
Exam Trap — Don't Get Fooled
The exam presents a PVC in Pending state and a list of PVs, one of which has sufficient capacity and the correct access mode, but the candidate overlooks that the PV already has a claimRef pointing to a different PVC. When a PVC is Pending, always run kubectl describe pv to check the claimRef field. If it points to another PVC, that PV is already bound.
You must create another PV or delete the existing PVC that holds the claim. Look for PVs with a blank claimRef.
Commonly Confused With
A PV is the actual storage resource in the cluster, similar to a physical disk. A PVC is a request for storage that binds to a PV. The PV is the supply; the PVC is the demand.
Imagine a library with books on shelves. The book itself is the PV. The library card requesting a specific book is the PVC. You use the card (PVC) to get the book (PV) and read it.
A StorageClass defines the type and configuration of storage, such as fast SSD or slow HDD. A PVC can reference a StorageClass to request a specific storage profile. But a PVC is the request, while the StorageClass is the template for creating storage.
If you want a locker, the StorageClass is like choosing a locker with a combination lock versus a key lock. The PVC is the form you fill out to request a locker of that type.
emptyDir is ephemeral storage tied to a pod’s life: data exists only as long as the pod runs. A PVC persists data beyond pod restarts and even across pod deletions. emptyDir is temporary; PVC is durable.
emptyDir is like a whiteboard in a meeting room: it gets erased when the meeting ends. PVC is like a physical notebook you carry from room to room, always containing your notes.
hostPath mounts a directory from the Kubernetes node’s filesystem into a pod. It is node-specific and not portable. A PVC abstracts the storage from the node, providing portability and lifecycle management.
hostPath is like using a specific drawer at one desk. If you move to a different desk, you cannot access that drawer. PVC is like a locker that you can access from any desk in the building because it is centrally managed.
Step-by-Step Breakdown
Define the PVC YAML
You create a YAML file that specifies the apiVersion v1, kind PersistentVolumeClaim, metadata with a name, and spec containing accessModes, resources with requests.storage, and optionally storageClassName. This file declares what storage you need.
Submit the PVC to the cluster
Use kubectl apply -f pvc.yaml to send the PVC to the Kubernetes API server. The API server validates the object and stores it in etcd as part of the cluster state. The PVC enters the Pending state because it is not yet bound to a PV.
Kubernetes controller looks for matching PVs
The persistent volume controller watches for new PVCs. It scans all PVs in the cluster, checking each for sufficient capacity, compatible access mode, and matching storage class. It also checks if the PV has no existing claimRef or if the claimRef matches the PVC.
Binding occurs
If a matching PV exists, the controller binds the PVC to the PV by setting the claimRef field on the PV to point to the PVC, and updating the PVC status to Bound. The PVC now has a corresponding volume handle. If no matching PV exists, the controller checks for a StorageClass with dynamic provisioning.
Dynamic provisioning (if applicable)
If the PVC specifies a storageClassName that has a provisioner, the controller instructs the provisioner plugin (e.g., AWS EBS CSI driver) to create a new storage volume. The new volume is represented as a PV object, which is then bound to the PVC. The PVC transitions to Bound.
Pod uses the PVC
A pod spec includes a volumes list referencing the PVC by name. Kubernetes attaches the underlying PV to the node where the pod runs. The volume is mounted at the specified mountPath inside the container. The application can now read and write data persistently.
Reclaim and cleanup
When the PVC is deleted, the reclaim policy on the PV determines the next action. If the policy is Delete, Kubernetes tells the provisioner to remove the underlying storage. If Retain, the PV becomes Released and remains available for manual administration. If Recycle (deprecated), basic scrubbing occurs.
Practical Mini-Lesson
Persistent Volume Claims are a cornerstone of Kubernetes storage management. As a Kubernetes administrator or developer, you must understand how to create, configure, and troubleshoot PVCs in real clusters.
First, always plan your PVC naming convention and storage class design. In a production cluster, you may have multiple storage classes: standard (backed by HDD), ssd (backed by SSD), and shared (backed by NFS for ReadWriteMany). Define these in your cluster using StorageClass objects. Then, when creating PVCs, explicitly set the storageClassName field. If you omit it, the PVC uses the default storage class, which may not have the performance characteristics you expect.
Second, right-sizing is essential. Monitor your application’s actual disk usage with tools like Prometheus or kubectl top. Many cloud providers allow volume expansion, but not all. If expansion is supported, you can edit the PVC spec.resources.requests.storage field and the controller will resize the underlying volume. But be aware that the pod may need to be restarted to recognize the new size.
Third, understand the relationship between PVCs and StatefulSets. StatefulSets create a unique PVC for each pod replica using a volumeClaimTemplates block. This is perfect for databases where each instance needs its own dedicated storage. But managing many PVCs requires careful cleanup to avoid leaving behind orphaned volumes.
Troubleshooting is a critical skill. When a PVC is stuck in Pending, run kubectl describe pvc <name> and look for events. The error message usually indicates the reason: no persistent volumes available for this claim, no storage class found, or access mode mismatch. Then check the list of PVs with kubectl get pv. Determine if any PV matches. If not, you may need to create a PV manually or correct the StorageClass name.
Another common pitfall is pod mount failures. If a pod cannot start with a message like FailedMount, verify that the PVC is in Bound state and that the pod is in the same namespace as the PVC. Also confirm that the volume plugin is available on the node. For example, if you use CSI drivers, ensure the CSI driver pods are running.
Security considerations: Use RBAC to control who can create PVCs. By default, any user or service account can create PVCs, which could lead to excessive cloud storage costs. Implement namespace quotas for storage and enforce limits via ResourceQuotas.
Finally, always set appropriate reclaim policies. For development environments, use Delete to automatically clean up. For production databases, use Retain to prevent accidental data loss. You can change the reclaim policy of an existing PV by editing its YAML.
Connecting to broader IT concepts: PVCs embody the principle of abstraction, which is fundamental to cloud-native systems. By decoupling storage consumption from provisioning, Kubernetes gives operators centralized control while empowering developers with self-service. This is analogous to how cloud providers abstract virtual machines from physical hardware.
Memory Tip
Remember PVC as Please Verify Claim: The PVC is a request (Claim), not the actual storage. Always verify the PV exists and is bound before using the storage.
Covered in These Exams
Related Glossary Terms
802.1Q is the networking standard that allows multiple virtual LANs (VLANs) to share a single physical network link by tagging Ethernet frames with VLAN identification information.
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
An A record is a DNS record that maps a domain name to the IPv4 address of the server hosting that domain.
Frequently Asked Questions
Can multiple pods share the same PVC?
Yes, if the underlying PV supports ReadWriteMany access mode. Most cloud block storage does not, so you would need a network filesystem like NFS or a CSI driver that enables RWX.
What happens to a PVC if the pod using it is deleted?
The PVC continues to exist. It remains bound to its PV, and the data is preserved. Another pod can later use the same PVC by referencing it in its volume definition.
Can I change the size of a PVC after it is created?
If the StorageClass supports volume expansion, you can edit the PVC’s spec.resources.requests.storage to a larger value. Not all StorageClasses support it, and shrinking is generally not supported.
What is the difference between a PVC and a StorageClass in simple terms?
A PVC is your application’s request for storage, specifying how much and what type. A StorageClass is a template that defines the kind of storage to provision, like fast SSD or standard HDD.
Why is my PVC stuck in Pending state?
It means no matching Persistent Volume exists and dynamic provisioning is either not configured or cannot fulfill the request. Check events using kubectl describe pvc and ensure a PV exists or a StorageClass with a provisioner is defined.
Can I use a PVC across different namespaces?
No, PVCs are namespace-scoped. A PVC can only be used by pods in the same namespace. However, you could use a PV without a PVC (e.g., manually created PV with a claimRef that allows cross-namespace binding, but that is atypical).
What is a volumeClaimTemplates in a StatefulSet?
It is a template that StatefulSet uses to create a unique PVC for each pod replica. This ensures each pod gets its own dedicated persistent storage that follows the pod across rescheduling.
Summary
Persistent Volume Claims are a fundamental storage abstraction in Kubernetes that allow applications to request and consume persistent storage without needing to know the underlying storage infrastructure. A PVC is not the storage itself but a request that binds to a Persistent Volume, which represents actual storage resources like cloud disks or NFS shares. This separation gives cluster administrators the flexibility to manage storage centrally while enabling developers to deploy stateful applications with confidence.
PVCs support dynamic provisioning via StorageClasses, making it easy to automate storage allocation. Understanding PVCs is essential for the CKA exam, which tests your ability to create, configure, and troubleshoot them in various scenarios. Key points to remember: PVCs survive pod restarts, they bind to PVs based on size and access modes, and they can be released with different reclaim policies.
Avoid common mistakes like confusing PVCs with PVs, forgetting access mode compatibility, or neglecting to clean up unused PVCs. Mastery of PVCs is a critical step toward running production-grade Kubernetes clusters that handle data reliably.