To understand a PVC we first need six simple words: container, pod, volume, persistent volume, claim and storage class. Let us meet them one by one.

So what exactly is a PVC?

A Persistent Volume Claim is a Kubernetes object in which an application, or the person running it, asks for a certain amount and type of durable storage. A pod then mentions the claim by name and receives a folder that is backed by that storage. If the pod dies and a new one takes its place, the new pod can mention the same claim and see all the old files.

The clever part is the separation of jobs. The person writing the application only says what they need: how much space, how it will be accessed. They do not need to know whether the disk is an Amazon EBS volume, a Google persistent disk or a shelf in the company’s own data centre. Someone else, usually the platform team, decides what kinds of storage exist. The claim is the meeting point between the two.

A short history

Kubernetes was released as open source by Google in 2014. The earliest storage support was tied closely to specific vendors: the Kubernetes code itself contained special code for each cloud disk. Persistent volumes and claims arrived in the early years to give applications one common way to ask for storage. Later, dynamic provisioning let the cluster create disks automatically on request, and the Container Storage Interface (CSI) moved vendor-specific code out of Kubernetes into separate plug-in drivers. Today CSI drivers are the normal way to connect storage.

Kubernetes already gives pods some ways to store files. To see why PVCs were invented, we need to see why those ways are not enough for important data.

Why containers forget

A container starts from a fixed template called an image. Anything the application writes while running goes into a thin, temporary layer on top of that image. When the container stops, that layer is thrown away and the next container starts clean from the template again. This design makes containers easy to copy, replace and scale, which is exactly why Kubernetes loves them.

The same design means that database files, uploaded photos, message queues and search indexes cannot simply be written inside the container. They need a home that survives the container.

The simple options and their limits

emptyDir is a scratch folder created when a pod starts and deleted when the pod leaves its computer. It is perfect for temporary work files and for sharing files between containers in one pod. It is useless for data you want to keep.

hostPath connects a pod to a folder on the computer it happens to run on. The data survives a pod restart, but only if the new pod lands on the very same computer. If Kubernetes moves the pod elsewhere, the data stays behind. It also lets a pod touch the computer’s own files, which is a security risk. Treat it as a tool for special system programs, not for everyday applications.

Persistent volumes with claims separate the life of the data from the life of the pod and from the life of any particular computer. The data lives on independent storage, and Kubernetes reconnects it wherever the pod is placed next.

flowchart TB
  subgraph WITHOUT["Without a PVC: data dies with the pod"]
    direction LR
    A1["Database Pod v1"] --> D1["Container layer with data"]
    A1 -. "pod fails and is replaced" .-> A2["Database Pod v2"]
    A2 --> D2["Fresh empty layer"]
  end
  subgraph WITH["With a PVC: data outlives the pod"]
    direction LR
    B1["Database Pod v1"] --> C1["PVC named db-data"]
    B2["Database Pod v2"] --> C1
    C1 --> PV1["Persistent Volume on a real disk"]
  end
    

Storage has more settings than most beginners expect. Learn these eight ideas and every storage conversation in Kubernetes will make sense.

Understanding access modes

An access mode answers one question: how many computers or pods may use this volume at once, and may they write to it? There are four modes.

Notice that ReadWriteOnce is about computers, not pods. Two pods on the same computer can share an RWO volume. If a second pod lands on a different computer, it cannot attach the disk while the first one still holds it. When you see a “multi-attach” error, this rule is almost always the reason.

Also remember that the access mode is a promise about what the storage supports, not a guarantee that Kubernetes will police every write. Choose the mode the underlying storage truly supports, or the claim will stay stuck waiting.

Storage in Kubernetes is a team effort. Several small programs each do one job, and together they turn a short request into a working disk inside a pod.

flowchart LR
  DEV["Developer applies a PVC and a Pod"] --> API["Kubernetes API Server"]
  PVCC["PV Controller"] -->|"watches claims and volumes"| API
  PROV["CSI External Provisioner"] -->|"watches new claims"| API
  PROV --> DRVC["CSI Driver Controller Service"]
  DRVC --> STORE["Storage System such as a cloud disk service"]
  SCHED["Scheduler"] -->|"places the pod on a node"| API
  KUB["Kubelet on the chosen node"] -->|"asks to mount"| DRVN["CSI Driver Node Service"]
  DRVN --> STORE
  KUB --> POD["Pod with the folder mounted"]
    

Piece by piece

The API server is the cluster’s central notice board. Your claim, the volumes, the storage classes and the pods are all stored there. Every other component watches this board and reacts when something changes.

The PV controller is part of the built-in controller manager. Its job is matchmaking. It looks at every unbound claim and every available volume and connects a claim to a volume that satisfies its size, access mode and class. It also handles what happens when a claim is deleted, following the reclaim policy.

The CSI driver is the plug-in that knows how to talk to one particular storage system. There is a driver for Amazon EBS, another for Amazon EFS, one for Google persistent disks, one for Azure disks, and drivers for on-premises systems such as Ceph. The driver has two halves. The controller half creates, deletes, attaches and resizes volumes. The node half runs on every computer and formats and mounts volumes for pods.

The external provisioner is a helper container that runs alongside the driver. It watches for new claims that need dynamic storage and calls the driver to create the disk, then creates the matching PV object on the driver’s behalf. Similar helpers exist for attaching, resizing and taking snapshots.

The scheduler decides which computer a pod should run on. For storage it is careful: it prefers computers where the pod’s volume can actually be reached, such as the correct availability zone.

The kubelet is the agent on each computer. Once a pod is placed, the kubelet asks the driver’s node half to make the volume appear at a folder path and then hands that folder to the containers.

Here is what really happens between the moment you save a claim and the moment it says “Bound”.

The matching loop

Kubernetes controllers follow a habit called the control loop. They compare the world as you asked for it with the world as it is, and they take small steps to close the gap, again and again. The PV controller applies this habit to storage. Whenever a claim appears, changes or is deleted, it wakes up and works out what to do.

flowchart TD
  A["New PVC is created"] --> B{"Does a suitable PV already exist?"}
  B -->|"Yes"| C["PV controller binds the claim to that volume"]
  B -->|"No"| D{"Does the PVC name a usable StorageClass?"}
  D -->|"Yes"| E["Provisioner asks the driver to create a new disk"]
  E --> F["A new PV object is created and bound"]
  D -->|"No"| G["PVC stays Pending until a match appears"]
  C --> H["PVC status becomes Bound"]
  F --> H
    

Why “wait for first consumer” matters

Many cloud disks live in exactly one availability zone, which is a separate data centre within a region. An Amazon EBS disk created in one zone cannot be attached to a computer in another. If the disk is created immediately, before any pod is placed, it might be born in a zone where the pod can never run, and the pod would be stuck waiting forever.

Delaying creation until the scheduler has chosen a computer solves this. The disk is then created in the same zone as the pod. For zone-bound storage this is nearly always the correct setting.

Static provisioning: the manual way

Before dynamic provisioning existed, an administrator created disks by hand and then wrote a PV object for each one. Claims were matched to these ready-made volumes. This still has uses: for example, when you must attach an existing disk that already contains valuable data, or when compliance rules require that a human approves every disk. The price is more manual work and the risk of running out of pre-made volumes.

Now let us follow one claim through its whole life: from the first request, through daily use, to its final deletion.

From request to running pod

sequenceDiagram
  participant U as Developer
  participant A as API Server
  participant S as Scheduler
  participant P as Provisioner
  participant C as CSI Driver
  participant K as Kubelet
  participant D as Cloud Disk
  U->>A: Create the PVC and the Pod
  S->>A: Place the pod on a node
  A->>P: New claim needs storage
  P->>C: Create a volume of the requested size
  C->>D: Allocate the disk
  P->>A: Create the PV and bind it to the claim
  K->>C: Attach and mount the volume
  C->>D: Connect the disk to the node
  K-->>A: Report the pod running with its folder mounted
    

The life of a claim

Life after the pod: what happens to the data

Deleting a pod never deletes its claim. That is the whole point. The new pod simply names the same claim and finds the same files. Even if you scale a workload down to zero pods for a weekend, the claim and its data stay put.

Deleting the claim is different, and this is where the reclaim policy matters. With the Delete policy, removing the claim also removes the volume and, usually, the real disk with all its data. Dynamically created volumes use this policy by default, because it keeps clusters tidy and costs low. With the Retain policy, the volume moves to the “Released” phase and the disk is kept. An administrator can then copy the data out, or clean the volume and make it available again.

Kubernetes also protects you from one common accident. If a pod is still using a claim, deleting the claim does not take effect right away. It waits until no pod uses it. This safeguard is called storage object in use protection.

Most real-world storage setups are built from a small set of patterns. Learn to recognise them and you can read almost any configuration.

How a pod actually uses a claim

The pod does not talk to the disk directly. It lists the claim by name in its volume section and then tells each container which folder path to mount it at. From the application’s point of view, it is simply writing files to an ordinary folder, for example the folder where a database keeps its data. All the complexity of attaching disks, formatting and mounting is hidden below that folder.

Two details often surprise beginners. First, a new, empty disk usually starts with a lost-and-found folder inside it, which some databases refuse to accept as an empty data directory. Pointing the application at a sub-folder solves it. Second, file ownership matters: the application may run as a non-administrator user, so the volume must be writable by that user. Kubernetes lets you set a group ID for the volume in the pod’s security settings so that files become writable.

How big should a claim be?

Sizing is part science and part habit. Start by measuring how much data the application holds today, then estimate how fast it grows each week. Add room for the busiest season, for temporary files the application creates while it works, and for the safety margin that keeps the disk below about 80 percent full. A database also needs extra space for its logs and for maintenance jobs that rewrite tables.

Beginners often make one of two mistakes. Some order a huge disk “just in case”, and pay for empty space every month. Others order the bare minimum and face an emergency when it fills up. Because volumes can be enlarged later, starting modestly and watching the trend is usually the wiser path, as long as expansion is enabled and has been practised.

Remember, too, that size can affect speed. Some disk types give more operations per second to bigger disks, while newer types let you choose speed separately. Read the rules of the disk type you use, so you do not enlarge a disk to gain speed that the type never offered.

Persistent storage holds the most valuable thing your company owns: its data. Losing it is bad. Leaking it is worse. Let us look at the layers of protection.

Namespaces and isolation

A claim belongs to a single namespace, and a pod can only use claims from its own namespace. This is a helpful boundary between teams. Volumes, however, belong to the whole cluster. If the reclaim policy is Retain and a volume is later reused without being wiped properly, the next claim could see the previous owner’s data. Always clean or delete released volumes with care, and prefer dynamic provisioning, where the storage system starts each new disk fresh.

The driver’s own permissions

The CSI driver creates and deletes real disks, so it holds powerful cloud permissions. On Amazon EKS, give it a dedicated role using the platform’s identity features for service accounts or pod identity, and grant only the actions it needs. Do not attach broad administrator permissions to the computers themselves. If an attacker compromises a driver with wide rights, they can read, copy or destroy every disk in the account.

A PVC is only a request. What answers it decides the speed, cost and behaviour of your data. Choosing well is one of the most important design decisions you will make.

The AWS way

On Amazon EKS, most teams use the EBS CSI driver for databases and other single-writer workloads, and the EFS CSI driver when many pods need a shared folder. The older built-in cloud storage code has been replaced by CSI drivers, so new clusters should be built on the drivers from the start.

For EBS, the modern general-purpose disk type is gp3. It gives a baseline of 3,000 operations per second and 125 megabytes per second regardless of size, and lets you raise the speed independently of the size. That is usually cheaper and more predictable than the older gp2 type, where speed was tied to size. For heavy databases, the io2 family offers guaranteed high speed at a higher price.

Remember that an EBS disk lives in one availability zone. Use the “wait for first consumer” binding mode so that the disk is created in the same zone as the pod. If that zone is lost, you need a snapshot or replica in another zone to recover. EFS is different: it spreads data across several zones, so pods in any zone can share it, at the price of slightly higher latency.

Speed: three numbers to know

How to decide

No tool is perfect. A good engineer knows both what PVCs give and what they cost.

The trade-offs behind the lists

Block versus shared file. Block disks are fast and simple but serve one computer. Shared file systems serve many but add latency and cost. Choose by how the application really reads and writes, not by habit.

Safety versus tidiness. The Delete policy keeps the cluster clean and the bill low, but one accident can wipe out production data. Retain is safer, but unused disks pile up until someone cleans them. Many companies use Delete for test systems and Retain, plus backups, for production.

Storage in the cluster versus outside it. Running a database inside Kubernetes with PVCs gives portability and one way of working. Using a managed database service outside the cluster, such as Amazon RDS, hands backups, failover and patching to the provider. Neither is always right. Small teams often prefer the managed service, while teams with strong operations skills may prefer control.

Local versus network storage. Local disks give excellent speed but disappear if the computer dies, so the application itself must replicate data across computers. Network disks survive the loss of a computer but add a small delay to every operation.

A full disk fails quietly and then suddenly. Good monitoring gives you days of warning instead of a midnight emergency.

Logs and events

When storage misbehaves, the first clues are in the events attached to the claim and the pod. They tell you that provisioning failed, that a volume is waiting to attach, or that a mount timed out. Next look at the logs of the CSI driver and its helper containers, which record every call made to the cloud. Cloud audit logs show who created, changed or deleted a disk, which is invaluable after an accident.

Failure scenarios worth rehearsing

A pattern is a proven way of solving a common problem. An anti-pattern is a habit that looks sensible at first and causes pain later.

Patterns that work

Anti-patterns to avoid

These habits come from many teams running stateful applications in production. Follow them and you will avoid most of the painful surprises.

Common mistakes and their cures

Organisations from small start-ups to global enterprises use persistent volume claims. The stories below are simplified illustrations of common situations, not descriptions of any one company’s private setup.