Hello, I am trying to understand the purpose of PersistentVolumeClaim? What is t . . .

Kubernetes-Slack Discussions
#1

Arun Natarajan:
Hello,
I am trying to understand the purpose of PersistentVolumeClaim? What is the actual value it brings?

I understand how PV, PVC and nodes need to be mapped to get a container the needed persistent storage, but it is not clear as to why PVCs were created by K8s developers in the first place? Why couldn’t a PV be directly used in Pods to define volumes and made available to a container? What is the value this additional layer of PVC brings in?

I see documentation like this:
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.
But PVCs are not like Pods; once a PVC is bound to a PV, it always stays bound to that PVC unlike a POD that can move across nodes (and we want storage to behave that way). So while the behavior is similar, there is no value in that behavior when it comes to storage.

So, what real value does a PVC bring to the K8s set up? What would I loose if the concept of PVC’s did not exist?
Thanks in advance.

#2

Mohamed Ayman:
Hello @Arun Natarajan,
In the real world, a system admin will create the PersistentVolume then a developer will create a PersistentVolumeClaim which will be referenced in a pod. A PersistentVolumeClaim is created by specifying the minimum size and the access mode they require from the persistent volume.
So A major advantage of the PVC pattern in Kubernetes is that it allows developers to dynamically request storage resources, without being aware of the implementation of underlying storage devices.

#3

gopi:
Without pvc, developers will have to get the exact pv details and use it. With pvc you can just specify what type of pv you need, you dont need to specify the exact pv. At run time a matching PV will be mapped to this pvc. With pv, it’s like you ordering a mobile in amazon with the exact serial number… with pvc, it’s like ordering the type of mobile you want, you dont need to specify the exact serial number. I hope it’s clear.

#4

Anushka hasini:
Thank you for you clarification…But how should we specify the value for parameters that is used in PVC creation for dynamic resource request. I mean in case we dont know what value for accessmode and memory specified in PV

#5

Anushka hasini:
If I am corrrect after pvc creation, pv is created

#6

Anushka hasini:
or it should be in other way

#7

Arun Natarajan:
Thanks @Mohamed Ayman, @gopi for the replies, but I am still not clear on the value this brings.

  1. Admin create a pv which has all the details of the actual storage
  2. Developer creates a pvc - here he doesn’t need to know the specifics of the storage but needs to know enough to find a matching pv
  3. Developer then uses the pvc in his pod. For this developer specifies the name of the pvc in the pod spec
    If step 2 didn’t exist, the Developer would specify the name of the pv in the pod spec and could still not have to worry about the storage specifics of the pv. Right?

Attaching a sample pvc, pv, pod file… in the last two lines,
persistentVolumeClaim:
claimName: pvc
if I could instead specify the persistentVolume by name, that would be a little more simpler and it’s the admin that is still creating pv.

#8

Arun Natarajan:
@Anushka hasini PV first and then PVC. See sample file attached in earlier post.

#9

Anushka hasini:
@Arun Natarajan Thanks