What is the difference between persistent volume (PV) and persistent volume claim (PVC) in simple terms?

Question

What is the difference between persistent volume (PV) and persistent volume claim (PVC) in Kubernetes/ Openshift by referring to documentation?

What is the difference be

Answer 1

From the docs

PVs are resources in the cluster. PVCs are requests for those resources and also act as claim checks to the resource.

So a persistent volume (PV) is the "physical" volume on the host machine that stores your persistent data. A persistent volume claim (PVC) is a request for the platform to create a PV for you, and you attach PVs to your pods via a PVC.

Something akin to

Pod -> PVC -> PV -> Host machine

Answer 2

1. A PersistentVolume (PV) is a piece of storage in the cluster or central storage that has been provisioned by an administrator or dynamically provisioned using Storage Classes.

2. A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources.

In real life example, Suppose your parents have a lot of money(PV) but they only provide you once you request them according to your needs(PVC).

Answer 3

A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by server/storage/cluster administrator or dynamically provisioned using Storage Classes. It is a resource in the cluster just like node.

A PersistentVolumeClaim (PVC) is a request for storage by a user which can be attained from PV. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted ReadWriteOnce, ReadOnlyMany or ReadWriteMany.

Answer 4

PVC is a declaration of need for storage that can at some point become available / satisfied - as in bound to some actual PV.

It is a bit like the asynchronous programming concept of a promise. PVC promises that it will at some point "translate" into storage volume that your application will be able to use, and one of defined characteristics like class, size, and access mode (ROX, RWO, and RWX).

This is a way to abstract thinking about a particular storage implementation away from your pods/deployments. Your application in most cases does not need to declare "give me NFS storage from server X of size Y"; it is more like "I need persistent storage of default class and size Y".

With this, deployments on different clusters can choose to differently satisfy that need. One can link an EBS device, another can provision a GlusterFS, and your core manifests are still the same in both cases.

Furthermore, you can have Volume Claim Templates defined in your deployment, so that each pod gets a reflecting PVC created automatically (i.e., supporting infrastructure-agnostic storage definition for a group of scalable pods where each needs its own dedicated storage).