Beginners guide to PersistentVolume and PersistentVolumeClaim

Saiyam Pathak avatar
By Saiyam Pathak
Director of Technical Evangelism

Description

Discovering how to do static and dynamic provisioning with a PersistentVolume and PersistentVolumeClaim.


Transcription

What is a PersistentVolumeClaim?

In this video, we'll be discussing Kubernetes volume plug-in PersistentVolume claim. Now, let us start with the pod itself. Now, inside a pod spec section, in the volumes, we have defined PersistentVolume claim and the claim name as demo-pvclaim. Now, it is referencing the original PVC spec. Now, PVC is a PersistentVolumeClaim, and it is a Kubernetes object. And here is a YAML file for creating a PVC, the kind is PersistentVolume claim. Then, in the specs section, we defined how much storage is needed, the storage class name, and the access mode. Whenever a PVC is created, the master control loop will look for the new PVCs and try to find the corresponding PV and bind it to that.

What is a PersistentVolume?

Now, what is a PV? PV is a PersistentVolume. This PersistentVolume is the actual storage, basically, the abstraction of the actual storage backend, and it is also a Kubernetes object. And in this, we defined the storage class name, capacity, and access mode. Now, the PersistentVolume has to be created by the admin, it can be created statically or dynamically.

Provisioning with PV and PVC

If a storage class is present, it is dynamic provisioning, else it's static provisioning. Now, say that you have created a PVC and there is no storage class, so the PersistentVolume claim remains unbound. Now you create a PV manually, and once the PV is created manually, the PVC gets bound to that PV. So, this was an example of static provisioning. In the case of dynamic provisioning, we need to define a storage class. Now, in Kubernetes, different types of storage classes can be used and have different sets of configurations.

So, you define the provisioner, define the URLs if it's NFS or GlusterFS, and so on. And based on that, when the user creates the PVC, the PV gets automatically created. Now, there are a lot of benefits to it, so we only have to define a pod spec, volume, and a PersistentVolumeClaim. In the claim, users can define what storage and capacity are needed, and the corresponding PV automatically gets created. And based on the reclaim policy, the PV also gets deleted if it's deleted. Once the PV is deleted, and if it's retained, then the PV is retained. And if it's recycled, it can again be used by another PVC. Now, we have discussed a few concepts, one is PersistentVolume. A PersistentVolume is a cumulative object that defines the storage inside the cluster, and it's also the abstraction linked to the external storage.

The storage class defines what kind of storage will be provisioned when a PVC is created dynamically. And in the case of static provisioning, we create a PV manually. Then, a PersistentVolumeClaim is provided by the user. Users may not know the PV or the external storage details, so all these things are abstracted. So, they'll say, "I need a storage of this much capacity with access mode of read-write once, read-only many, or read-write many," and the PV automatically gets created. PVC is also helpful when a pod goes down and a new pod comes up on a different node. Then also, the new pod uses the same PVC because that's the Kubernetes object, and it is separate from the pod life cycle, and persistent volume claim and persistent volume have their life cycle. So, you can use persistent volume and persistent volume claim inside a pod, and you can define a storage class for dynamic provisioning.

In conclusion

All these things are covered in more detail in the demo section, where I'll be showing you the static provisioning, the dynamic provisioning, and how you can create all these components. That's it for this lecture. Thank you for watching. See you in the next one.

Don't stop now, check out your next lesson