PersistentVolumeClaim stuck in Pending

KubernetesKubernetes

Fix a PVC stuck in Pending: run kubectl describe pvc, then add the CSI driver, set a valid StorageClass, fix zone or access mode. Covers WaitForFirstConsumer.

medium fix·7 min read·5 causes

By Vishvesh Patel·DevOps Engineer·Updated 16 September 2026

Run these in order. Each one tells you what its output means before you change anything.

• Read the PVC events

'no persistent volumes available' with no provisioner named means nothing is there to create one. 'waiting for first consumer' is not a fault, that PVC binds when a Pod that mounts it is scheduled.

• Check a StorageClass exists and one is default

If no class is marked (default) and the PVC names no storageClassName, nothing will ever provision it. Either set the class on the PVC or mark one as default.

• Check the CSI driver is actually running

On EKS the EBS CSI driver is not installed by default. No controller pods means no dynamic provisioning no matter how the StorageClass is written.

If the steps above did not settle it, these are the causes in the order they are usually responsible. Each section explains why it happens and how to confirm it.

A Pending PVC means Kubernetes has nothing to bind the claim to, and the Pod waits indefinitely as a result, 0/3 nodes are available: pod has unbound immediate PersistentVolumeClaims is the scheduler reporting that it cannot place a Pod whose storage does not exist.

Four causes account for nearly all of it, and the PVC's own events distinguish them.

The message maps directly to the cause:

The most common cause on a new cluster, and the one with the least helpful symptom: the PVC sits Pending with no events whatsoever, because nothing exists to act on it.

Since Kubernetes 1.23 the in-tree cloud provisioners have been removed, so a cluster needs the CSI driver for its platform installed separately. On EKS that is an add-on a fresh cluster does not include:

The role matters. The driver needs EC2 permissions to create volumes, and without IRSA configured it installs, runs, and fails every provisioning attempt with an access denied in its logs:

Pending PVCs bind on their own once the driver is working. No need to recreate them.

The manifest asks for gp3 and the cluster has gp2. Either create the class or change the claim.

Creating gp3 is usually worth doing anyway, since it is cheaper and faster than gp2:

The other variant is a claim with no storageClassName on a cluster with no default class:

Make sure only one class is marked default. Two produces unpredictable binding.

This is correct behaviour, not a fault. A storage class with volumeBindingMode: WaitForFirstConsumer deliberately delays creating the volume until a Pod is scheduled, so the volume is created in the same availability zone as the node that will use it.

If the PVC stays here, the problem is the Pod, not the claim:

Usually the Pod is unschedulable for an unrelated reason, insufficient CPU, a taint, a node selector, and fixing that binds the PVC automatically.

The alternative mode, Immediate, creates the volume straight away and is what causes cause 4.

An EBS volume exists in one availability zone and can only attach to a node in that zone. With volumeBindingMode: Immediate, the volume is created before anything knows where the Pod will run, so it can land in a zone with no capacity, or no nodes at all.

The volume is in a zone with no nodes.

The fix is WaitForFirstConsumer on the storage class, which prevents the whole class of problem. For the stranded volume, either add a node in that zone or delete the PVC and let it be recreated once the binding mode is corrected. After taking a snapshot if it holds anything.

EBS does not support ReadWriteMany. A block device attaches to one node at a time, so a claim asking several Pods to mount it read-write cannot be satisfied and simply stays Pending.

If you genuinely need shared access across Pods, use EFS with the EFS CSI driver. If you do not, and often a StatefulSet giving each replica its own volume is the right shape. Change the mode to ReadWriteOnce.

Note ReadWriteOnce means one node, so several Pods on the same node can share it. ReadWriteOncePod restricts it to a single Pod, which is what you want for a database.

Worth noticing RECLAIM POLICY: Delete. Deleting the PVC destroys the volume and its data. For anything you care about, use a class with reclaimPolicy: Retain, or accept that kubectl delete pvc is a destructive command.

Why is my PersistentVolumeClaim stuck in Pending?

Kubernetes has nothing to bind it to, and kubectl describe pvc names the reason in its events. The four common causes are: no CSI driver installed, so nothing is listening for claims at all; a storage class that does not exist or no default class set; a zone mismatch where the volume and the nodes are in different availability zones; and an access mode the backend cannot provide. A PVC with no events whatsoever almost always means the driver is missing.

Why does a new EKS cluster fail to provision volumes?

Because the EBS CSI driver is not included. Since Kubernetes 1.23 the in-tree cloud provisioners were removed, so volume provisioning requires the CSI driver installed as a separate add-on, and a freshly created EKS cluster does not have it. Install aws-ebs-csi-driver with an IRSA role granting the EC2 permissions it needs; without the role it runs but fails every provisioning attempt with access denied in its logs. Pending claims bind by themselves afterwards.

What does "waiting for first consumer to be created" mean?

That the storage class uses volumeBindingMode: WaitForFirstConsumer, which deliberately delays creating the volume until a Pod using the claim is scheduled, so the volume can be created in the same availability zone as the node. It is correct behaviour rather than an error. If the PVC stays in that state, the problem is that the Pod cannot be scheduled: check the Pod's events for insufficient resources, taints or node selectors.

What causes "volume node affinity conflict"?

The volume exists in one availability zone and no schedulable node is in that zone, so the Pod cannot be placed anywhere that can attach it. EBS volumes are zonal, and with volumeBindingMode: Immediate the volume is created before the scheduler has decided where the Pod will run, so it can easily land in the wrong zone. Using WaitForFirstConsumer prevents this entirely by creating the volume only once the node is known.

Why can't I use ReadWriteMany with EBS?

Because EBS is block storage and a volume attaches to one node at a time, so several Pods on different nodes cannot mount it read-write simultaneously. The claim is unsatisfiable and stays Pending with no useful error. For genuinely shared access, use EFS with the EFS CSI driver, which supports ReadWriteMany. Often, though, the better answer is a StatefulSet giving each replica its own ReadWriteOnce volume.

Will deleting a PVC delete my data?

With the default reclaim policy, yes. Most dynamic storage classes use reclaimPolicy: Delete, so removing the PVC destroys the underlying volume and everything on it. Check with kubectl get pv. The RECLAIM POLICY column shows which applies. For anything you care about, use a storage class with reclaimPolicy: Retain, which leaves the volume in place for manual recovery, and take snapshots regardless.

Free, comprehensive DevOps tutorials and learning roadmaps. Master Docker, Kubernetes, CI/CD, and more.

Get notified about new tutorials and features.

• Roadmaps

• Interview Prep

• Certifications

• Company

© 2026 DevOpsLesson. All rights reserved.