Why do I need a PersistentVolume, if I have a PersistentVolumeClaim?
Every while I see these scenarios where people create a PV and a PVC to bind to it, and I wonder what's the need?
So, one can create a PVC with volumeName: my-volume, and have it bounded to an existing PV. Or create the PV later, in which case PVC wouldn't be bounded to any PV, and it would stay in Pending state forever, until the PV gets created with the given name.
Now, my question is why? Why do we need to create a PVC and then the PV? There are two scenarios I see it half useful:
- When you don't want the PVC to create a PV with random name, and you want to control the name of the PV, but even in that scenario, just create the PV with the name you want. Why to create the PVC?
- If you delete the PV with a PVC bound to it with
persistentVolumeReclaimPolicy: Retain, then the PV wouldn't get deleted, but would stay inTerminatingstate. Still, I am not sure if you can re-use this PV withTerminatingstate.
Openshift explains this as Binding and Pre-binding. Still doesn't give any details of the use cases.
EDIT
I know what is a PV and a PVC, and when to use them, so no need to explain the basics. I want to know the use case of creating both at the same time.
Similar Questions
2 Answers
The Persistent Volume is something physical let's say. An entity that exists just like node. On the other hand the PersistentVolumeClaim is just a request from a user.
Making an analogy you must think that the PersistentVolume is a node, and PersistentVolumeClaim is a pod. As pods consume node resources, PVCs consume PV resources. As it is stated in the official documentation :
While PersistentVolumeClaims allow a user to consume abstract storage resources, it is common that users need PersistentVolumes with varying properties, such as performance, for different problems. Cluster administrators need to be able to offer a variety of PersistentVolumes that differ in more ways than just size and access modes, without exposing users to the details of how those volumes are implemented.
In conclusion, I would say that PersistentVolumes and PersistentVolumeClaims are two complementary elements of the PV Subsystem, which work together and this is how the whole system was designed to be used from the beginning. The logical and natural way to go is to create the PV firstly, and then the PVC which needs to work with it. Now that there are different possible ways to achieve some stuff, this does not mean that it is the recommended, or the way it was designed to be.
Pvc enables light coupling between a pod and the persistent volume. The pod is not aware of what the underlying storage is and is not necessarily to know that. It just request the storage size it needs to run the application or service. That pvc claim will identify the persist volume that matches the pod storage requirements and binds the pv to the pod