Kubernetes PersistentVolumes and PersistentVolumeClaims: Essential Concepts for DevOps Interviews

PersistentVolumes (PV) and PersistentVolumeClaims (PVC) abstract storage management in Kubernetes, allowing pods to consume durable storage without knowing underlying infrastructure details.

According to the litu54/DevOps-Interview-Guide repository, understanding PV and PVC concepts is critical for Kubernetes interviews at companies like TCS and EY. These resources separate storage provisioning from consumption, enabling administrators to manage physical storage while developers simply request what they need.

Understanding PersistentVolumes (PV)

A PersistentVolume (PV) is a cluster-wide resource that represents a piece of storage in the Kubernetes ecosystem. As documented in EY/DevOps_Engineer_2.md, PVs abstract the physical storage layer, exposing consumption details like capacity, access modes, and reclaim policies.

PVs can be provisioned in two ways:

• Static provisioning – Administrators manually create PVs that reference existing physical storage (NFS, EBS, local disks).
• Dynamic provisioning – The system automatically creates PVs when PVCs request storage classes that support dynamic provisioning.

Understanding PersistentVolumeClaims (PVC)

A PersistentVolumeClaim (PVC) is a namespace-scoped resource that functions as a pod-level request for storage. According to TCS/SRE_1.md, PVCs allow workloads to request specific storage characteristics without requiring knowledge of where that storage physically resides.

When a developer creates a PVC, they specify desired parameters including storage size, access modes, and optionally a StorageClass name. The Kubernetes control plane then attempts to match this claim to an available PV that meets the requirements.

The Binding Process

The binding mechanism operates through a matching algorithm:

1. When a PVC is created, the scheduler searches for an unclaimed PV that satisfies the claim's requirements (capacity, access mode, labels).
2. If a suitable PV exists, the system binds the PVC to that volume.
3. Once bound, the PV's status.phase transitions from Available to Bound.
4. The PVC becomes available for mounting into pods, while other PVCs can no longer claim that specific PV.

Key Configuration Attributes

Access Modes

Access modes define how many nodes can simultaneously mount the volume. The three supported modes are:

• ReadWriteOnce (RWO) – The volume can be mounted as read-write by a single node. This is the most common mode for block storage like AWS EBS or GCE PD.
• ReadOnlyMany (ROX) – Multiple nodes can mount the volume as read-only simultaneously. Useful for shared configuration or static content.
• ReadWriteMany (RWX) – Multiple nodes can mount the volume as read-write simultaneously. Requires specialized storage like NFS, CephFS, or Azure Files.

Reclaim Policies

The persistentVolumeReclaimPolicy determines the fate of a PV after its bound PVC is deleted:

• Retain – The PV is released but its data remains intact. Administrators must manually reclaim the storage.
• Delete – The underlying storage asset is automatically removed. This is common for dynamically provisioned cloud volumes.
• Recycle – (Deprecated) Previously performed a basic scrub (rm -rf) before making the volume available again.

StorageClasses and Dynamic Provisioning

StorageClasses enable on-demand storage provisioning without manual PV creation. They define the "class" of storage (performance tier, provider) and reference specific provisioners such as kubernetes.io/aws-ebs, kubernetes.io/gce-pd, or CSI drivers.

When a PVC specifies a storageClassName, the system triggers the provisioner defined in that StorageClass to create the underlying storage asset and corresponding PV automatically.

Practical Implementation Examples

The following YAML configurations demonstrate static provisioning, PVC binding, pod consumption, and dynamic provisioning patterns.

Static PersistentVolume Definition

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-local
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /mnt/data

PersistentVolumeClaim Binding

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-local
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  # Optional: specify storageClassName if using dynamic provisioning

  # storageClassName: standard

Pod Volume Consumption

apiVersion: v1
kind: Pod
metadata:
  name: pod-using-pvc
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: www
  volumes:
  - name: www
    persistentVolumeClaim:
      claimName: pvc-local

Dynamic Provisioning with StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs   # example for AWS

parameters:
  type: gp2
  fsType: ext4
reclaimPolicy: Delete

PVC Requesting Dynamic Storage

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-dynamic
spec:
  storageClassName: fast-ssd
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

StatefulSets vs Deployments with PVCs

A critical distinction highlighted in TCS/SRE_2.md concerns how different workload controllers handle persistent storage. While Deployments can mount PVCs, they do not maintain a unique identity for each replica.

StatefulSets, conversely, automatically create and maintain a unique PVC for each pod replica. When a StatefulSet scales up, it generates a new PVC using the defined volumeClaimTemplate. When scaling down, the PVCs persist, ensuring that if the pod reschedules, it reattaches to the same data volume. This stable storage per pod is why StatefulSets are required for truly stateful applications like databases, whereas Deployments with PVCs create shared storage scenarios that can lead to conflicts.

Interview Perspectives

The litu54/DevOps-Interview-Guide repository identifies PV and PVC concepts as frequent interview topics:

• EY/DevOps_Engineer_2.md explicitly lists: "What is a Persistent Volume in Kubernetes?"
• TCS/SRE_1.md asks candidates to differentiate between PV and PVC, and to explain the purpose of PVCs in the storage architecture.
• TCS/SRE_2.md tests understanding of why PVCs alone cannot make a Deployment truly stateful, probing knowledge of StatefulSet behavior.

Interviewers expect candidates to explain not just the definitions, but the relationship between static and dynamic provisioning, the implications of different reclaim policies, and the access mode limitations of various storage backends.

Summary

• PVs are cluster-scoped storage resources provisioned by administrators or StorageClasses; PVCs are namespace-scoped requests for that storage used by pods.
• The binding process matches PVC requirements to available PVs, transitioning the PV state from Available to Bound.
• Access modes (RWO, ROX, RWX) determine concurrent node access patterns, while reclaim policies (Retain, Delete) determine data persistence after PVC deletion.
• StorageClasses enable dynamic provisioning, automatically creating PVs when PVCs request specific storage tiers.
• StatefulSets provide unique PVCs per replica, unlike Deployments, making them essential for applications requiring stable, persistent identities and storage.

Frequently Asked Questions

What is the difference between a PV and a PVC in Kubernetes?

A PersistentVolume (PV) is a cluster-level resource representing actual physical storage, created by administrators or provisioned dynamically. A PersistentVolumeClaim (PVC) is a user-level request for storage that pods use to consume PV resources. The PVC abstracts the underlying storage implementation from the application, allowing developers to request storage by size and access mode without knowing the specific storage provider.

What happens to a PV when its PVC is deleted?

The outcome depends on the PV's reclaimPolicy. If set to Retain, the PV enters a Released state and the data remains intact but inaccessible to new claims until manually reclaimed. If set to Delete, the underlying storage asset is automatically removed by the provisioner. The deprecated Recycle policy previously scrubbed data and reset the volume to Available, but this is no longer recommended.

Can multiple pods share a single PVC?

Yes, but only if the PVC's access mode supports it and the underlying storage technology allows multi-node attachment. Using ReadWriteMany (RWX) mode permits multiple pods across different nodes to mount the volume simultaneously. However, ReadWriteOnce (RWO) volumes can only be mounted by pods running on the same node, limiting sharing to co-located containers within that node.

Why can't a Deployment use PVCs to achieve true statefulness?

While Deployments can mount PVCs, they treat all replicas as interchangeable; scaling down removes random pods, and scaling up creates new pods that may attach to any available PVC. As noted in TCS/SRE_2.md, this breaks the "stable identity" requirement of stateful applications. StatefulSets solve this by generating unique PVCs for each pod ordinal (e.g., pvc-web-0, pvc-web-1) and maintaining that binding throughout rescheduling events, ensuring each replica consistently accesses its own dedicated storage.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}