Introduction

In Kubernetes, a PersistentVolume (PV) is a piece of provisioned storage, and a PersistentVolumeClaim (PVC) is a request for that storage. Whether you need to manually create a PV depends on whether your cluster supports dynamic provisioning. In most cloud environments, the answer is no — Kubernetes creates the PV automatically when you create a PVC.

Short Answer

• If dynamic provisioning is configured using a StorageClass, you do not need to create a PV. When a PVC is created, Kubernetes automatically provisions a new PV that matches the PVC's requirements.
• If there is no StorageClass configured or dynamic provisioning is not enabled, you must manually create a PV that meets the requirements of the PVC (size, access mode, etc.).

Dynamic Provisioning (Automatic)

Most cloud Kubernetes services (EKS, GKE, AKS) come with a default StorageClass that enables dynamic provisioning:

1# Just create a PVC — the PV is created automatically
2apiVersion: v1
3kind: PersistentVolumeClaim
4metadata:
5  name: my-data
6spec:
7  accessModes:
8    - ReadWriteOnce
9  resources:
10    requests:
11      storage: 10Gi
12  # storageClassName: gp2  # Optional: uses default if omitted

When you apply this, Kubernetes:

1. Finds the default StorageClass (or the one you specified)
2. Calls the storage provisioner to create a volume (e.g., an EBS volume on AWS)
3. Creates a PV that binds to your PVC

Check your cluster's default StorageClass:

kubectl get storageclass

Output:

NAME                 PROVISIONER            RECLAIMPOLICY   VOLUMEBINDINGMODE
gp2 (default)       kubernetes.io/aws-ebs  Delete          WaitForFirstConsumer

The (default) marker indicates this StorageClass is used when no storageClassName is specified.

Static Provisioning (Manual)

If your cluster does not support dynamic provisioning (bare-metal, on-premises, or you need specific storage), create the PV first:

1# Step 1: Create the PV
2apiVersion: v1
3kind: PersistentVolume
4metadata:
5  name: my-manual-pv
6spec:
7  capacity:
8    storage: 10Gi
9  accessModes:
10    - ReadWriteOnce
11  persistentVolumeReclaimPolicy: Retain
12  hostPath:
13    path: /data/my-volume  # For local testing only
14---
15# Step 2: Create the PVC that binds to it
16apiVersion: v1
17kind: PersistentVolumeClaim
18metadata:
19  name: my-data
20spec:
21  accessModes:
22    - ReadWriteOnce
23  resources:
24    requests:
25      storage: 10Gi
26  storageClassName: ""  # Empty string = no dynamic provisioning

Setting storageClassName: "" tells Kubernetes to only look for pre-existing PVs, not to dynamically provision one.

Using a PVC in a Pod

Regardless of how the PV was created, the pod references the PVC:

1apiVersion: v1
2kind: Pod
3metadata:
4  name: my-app
5spec:
6  containers:
7    - name: app
8      image: nginx
9      volumeMounts:
10        - mountPath: /data
11          name: storage
12  volumes:
13    - name: storage
14      persistentVolumeClaim:
15        claimName: my-data

Access Modes

PVs and PVCs must have matching access modes:

Not all storage types support all modes:

Reclaim Policies

When a PVC is deleted, the reclaim policy determines what happens to the PV:

1spec:
2  persistentVolumeReclaimPolicy: Retain  # Keep the data
3  # Or: Delete  (removes the volume — default for dynamic provisioning)
4  # Or: Recycle (deprecated)

• Delete: The PV and its underlying storage are deleted (default for dynamic provisioning)
• Retain: The PV remains with its data intact; must be manually cleaned up

Checking PV/PVC Status

1# List PVCs and their bound PVs
2kubectl get pvc
3# NAME      STATUS   VOLUME           CAPACITY   ACCESS MODES   STORAGECLASS
4# my-data   Bound    pvc-abc12345     10Gi       RWO            gp2
5
6# List PVs
7kubectl get pv
8# NAME            CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM
9# pvc-abc12345    10Gi       RWO            Delete           Bound    default/my-data
10
11# Describe for details
12kubectl describe pvc my-data

Common Pitfalls

• No default StorageClass: If kubectl get sc shows no (default) StorageClass, PVCs without a storageClassName will stay in Pending state indefinitely. Either create a default StorageClass or specify one explicitly.
• Size mismatch: A PVC requesting 10Gi will not bind to a PV with only 5Gi. The PV must be at least as large as the PVC request.
• Access mode mismatch: A PVC requesting ReadWriteMany will not bind to a PV that only supports ReadWriteOnce. Check your storage provider's supported modes.
• WaitForFirstConsumer binding: Some StorageClasses use WaitForFirstConsumer volume binding mode, meaning the PV is not created until a pod actually uses the PVC. The PVC will show Pending until then — this is normal.
• hostPath in production: hostPath volumes are for testing only. Data is tied to a specific node and is lost if the pod is rescheduled. Use cloud storage or NFS for production.

Summary

• In most cloud environments, just create a PVC and let dynamic provisioning handle the rest
• Set storageClassName: "" to force static binding (no dynamic provisioning)
• Check kubectl get sc to see available StorageClasses and their default status