What's a conceptual difference between PersistentVolume and PersistentVolumeClaim in kubernetes?
I know that PVC can be used as a volume in k8s. I know how to create them and how to use, but I couldn't understand why there are two of them, PV and PVC.
Can someone give me an architectural reason behind PV/PVC distinction? What kind of problem it try to solve (or what historical is behind this)?
Similar Questions
2 Answers
Despite their names, they serve two different purposes: an abstraction for storage (PV) and a request for such storage (PVC). Together, they enable a clean separation of concerns (using a figure from our Kubernetes Cookbook here to illustrate this):
The storage admin focuses on provisioning PVs (ideally dynamically through defining storage classes) and the developer uses a PVC to acquire a PV and use it in a pod.
It is easy to be thrown by the names but the kubernetes documentation does have an explanation of the difference:
A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual pod that uses the PV.
And
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. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., can be mounted once read/write or many times read-only).
So the PVC decouples the application from the specific storage. It allows the application to say that it needs some storage satisfying certain requirements without saying specifically which piece of storage that is. This also makes it possible for cluster-level rules to be defined on how the storage requirements of apps are to be met.