ReviseAlgo Logo

Kubernetes Storage

Persistent Volumes and Persistent Volume Claims

Understanding disk allocations and request configurations.

Interview: Understand the distinction between PV and PVC. Be ready to explain how the K8s control loop binds PVCs to PVs, the RWO/ROX/RWX/RWOP access modes, and reclaim policies (Retain, Delete). Explain how hostPath volumes behave in multi-node clusters.

Last Updated: June 15, 2026 • 10 min read

Introduction

In Kubernetes, container lifecycles are completely ephemeral. When a container inside a Pod crashes or gets rescheduled onto a different worker node, all files written to its local filesystem are permanently lost. To decouple container lifecycles from persistent data storage, Kubernetes introduces two resource primitives: Persistent Volumes (PV) and Persistent Volume Claims (PVC).

A PersistentVolume (PV) is a cluster-wide storage resource provisioned by a cluster administrator or dynamically by a StorageClass. It represents a physical slice of storage (e.g., an AWS EBS volume, a GCP Persistent Disk, an NFS mount, or a local NVMe disk).

A PersistentVolumeClaim (PVC) is a developer's request for storage. It is analogous to a Pod; just as a Pod requests CPU and Memory resources, a PVC requests a specific storage size, access modes (like read-write or read-only), and class of storage.

Why It Matters

Separating storage definition (PV) from storage consumption (PVC) allows application developers to write portable manifests. Developers don't need to know the underlying storage technology (SAN, NAS, or cloud disks) or vendor details; they simply submit a PVC, and Kubernetes handles the binding and mounting.

Real-World Analogy

Think of a Persistent Volume (PV) as a parking space in a garage. Think of a Persistent Volume Claim (PVC) as a parking permit or reservation. The application Pod is the car. When a driver needs to park, they request a permit for a vehicle of a certain size (PVC). The garage manager assigns a matching space (PV) and links it to the permit. If the car leaves or is replaced by another (Pod restart), the space remains reserved and the permit is still valid.

How It Works

The PV/PVC lifecycle consists of four distinct phases managed by the Kubernetes Controller Manager:

  1. Provisioning: Volumes are provisioned either statically (an admin creates a pool of PVs manually) or dynamically (a StorageClass automatically creates the PV when a PVC is submitted).
  2. Binding: The control loop matches the PVC's storage requirements (size, access mode) to an available PV. Once a match is found, they are bound in an exclusive 1:1 relationship. The PVC remains Pending if no matching PV is found.
  3. Using: The Pod specifies the PVC in its volume definitions. The kubelet mounts the physical volume into the container's designated filesystem directory.
  4. Reclaiming: When the user deletes the PVC, the bound PV is reclaimed. The policy on the PV determines what happens next: Retain (keep the PV and data for manual cleanup), Delete (destroy the backing physical disk), or Recycle (performs a simple scrub rm -rf, now deprecated).

Internal Architecture

Kubernetes storage mounts must specify an Access Mode. These modes define how many nodes can mount the volume concurrently:

  • ReadWriteOnce (RWO): The volume can be mounted as read-write by a single node. Highly standard for cloud block storage like AWS EBS.
  • ReadOnlyMany (ROX): The volume can be mounted as read-only by many nodes simultaneously. Good for static asset distribution.
  • ReadWriteMany (RWX): The volume can be mounted as read-write by many nodes at once. Typically requires network file systems like NFS, AWS EFS, or Ceph.
  • ReadWriteOncePod (RWOP): The volume can be mounted as read-write by a single Pod in the entire cluster (introduced in v1.22 to prevent multiple pods on the same node from concurrent writes).

Practical Example

Here are the declarative YAML manifests to provision a static PV (using local host directory storage), request it via PVC, and mount it in an Nginx Webserver Pod:

Common Mistakes

  • Multi-node scheduling failure with hostPath: Using hostPath or local PVs without setting node affinity. If a Pod restarts and is scheduled on a different worker node, it will search for the path on the new node, which won't contain the data.
  • RWO cross-node mount errors: Deploying replica sets mounting a single RWO volume. When Kubernetes attempts to roll out a new pod replica on a different node, the cloud provider will reject the mount because the block disk is already attached to the original node.

Quick Quiz

Q1: What happens if a PVC requests 10Gi with ReadWriteMany (RWX) access, but the available PV has 10Gi with ReadWriteOnce (RWO)?

A) The PVC will bind successfully and change the PV access mode.

B) The PVC will remain in Pending status because access modes must match exactly.

C) Kubernetes will automatically split the volume across nodes.

Answer: B — Access modes must match. The volume controller will not bind a PVC to a PV with incompatible access modes.

Scenario-Based Challenge

Production Scenario:

Your team is deploying a media library microservice where multiple web frontend pods need concurrent read-write access to a shared collection of video assets. What storage configuration should you propose?

View Solution

To allow multiple Pods running on different nodes to write concurrently, you must use a volume configured with the ReadWriteMany (RWX) access mode. Block storages (like AWS EBS or GCP Persistent Disk) are RWO and cannot be shared across nodes. You need a network-attached filesystem like AWS EFS, Google Cloud Filestore, NFS, or Ceph, managed by a CSI driver that supports RWX provisioning.

Debugging Exercise

Broken Manifest:

A developer complains their Pod is stuck in ContainerCreating. You run kubectl describe pod and see: Multi-Attach error for volume "pv-data" Volume is already used by pod-a-xxx on node-1.

View Solution

Root Cause: The Pod is trying to attach an RWO (ReadWriteOnce) volume that is currently locked and attached to another node (node-1). This often happens during rolling updates if the new pod schedules on node-2 before the old pod on node-1 is fully terminated.
Fix: Modify the Deployment's rolling update strategy to type: Recreate (which kills the old pod before launching the new one, releasing the volume attachment), or configure node affinity to force the Pod onto the same node, or use an RWX-compatible storage backend.

Interview Questions

1. What is the difference between the Retain and Delete reclaim policies?

Under Retain, deleting a PVC leaves the PV object intact. The data is preserved, and the PV status changes to Released, preventing other claims from binding until an admin manually cleans up. Under Delete, deleting a PVC automatically deletes the PV object and triggers the CSI driver to delete the underlying storage device (e.g. AWS EBS disk) to save costs.

2. Can a PV have multiple access modes configured simultaneously?

Yes. A PV can support multiple access modes (e.g. RWO and ROX). However, when a PVC binds to the PV, it requests a single access mode, and the volume is mounted using only that specific requested mode.

Production Considerations

In production environments, always default to the Retain policy for critical database volumes to prevent accidental data deletion. When working with cloud block storage, monitor standard IOPS ceilings and configure automated snapshots. Avoid using local path-based volumes on production worker nodes unless you have node-selector affinity constraints and proper raid/backup strategies configured.