In this RX-M Cloud Native Short Take, Christian Lacsina explains the matching behavior of resources in the Kubernetes Persistent Volume (PV) subsystem. He demonstrates how a Persistent Volume Claim (PVC) interacts with a Persistent Volume object in a Kubernetes cluster. The PV subsystem abstracts storage requirements for applications, making it easier for developers to request storage without concerning themselves with specific implementation details.
Video Transcript
Hello all. Welcome back for another RX-M Cloud Native Short Take. My name is Christian Lacsina.
Today I will short take the matching behavior of the resources involved with the Kubernetes persistent volume subsystem. Specifically, we’ll be taking a look at the behavior of how a persistent volume claim interacts with a persistent volume object in a Kubernetes cluster.
As a refresher, the persistent volume subsystem allows users to abstract their claims for storage for the applications and let the cluster provide that storage. This makes it easier for developers who are likely more aware of their generic storage and access requirements for the application but not necessarily the specific implementation of that storage in the environment they want to deploy to.
In the PV subsystem, clients declare requests for storage in terms of a size and an access mode requirement and then the implementation-specific details are handled by the cluster management and those would describe things such as the backing volumes or the allocated sizes to be consumed by the application. Let’s begin by taking a look at the persistent volume claim.
The persistent volume claim is at the heart of the PV subsystem and this is the request for storage that a user must create alongside their pod in an application. The PVC declares the amount of storage that is required for the application and also any access modes that may that must be made available on the actual volumes that back this claim. On this slide, I have a PVC that’s requesting 128 megabytes of storage and requires that the storage have the ReadWriteOnce access mode enabled; this means that the volume can be consumed by only one node at a time.
Now before I can use this PVC with an application I do need to bind it to an actual volume that will fulfill the storage request. This is where the persistent volume or PV comes in. This is the representation of some kind of storage in the API where the cluster maintainers specify implementation specific details, such as the path or nature of the actual storage to be consumed. To fulfill my PVC’s request I’ve prepared a PV that presents the following details: It has 512 megabytes of storage. It has the ReadWriteOnce and ReadOnlyMany access modes. It will be instructed to delete the data after this PV is ever deleted, which is useful in cases where perhaps you want to save money in the cloud. And then, finally, we discuss what the actual backing storage is. In this case, it’s a network file share mounted at the path of `/tmp` coming in from a container-based server.
So let’s go ahead and see how these will interact. I have my Kubernetes cluster here and I have my PV right here and I have my PVC right here. The order that I create these doesn’t really matter as there is an ongoing evaluation that’s going to match these two together. So I’ll go ahead and apply the PVC first. Now we can see that I have my PVC and it’s currently waiting or “pending” for a PV that’s going to fulfill the request.
Next I’ll go ahead and apply my PV. Now we can see that the PV is created and that the PVC has not quite yet actually bound to it. Now let’s go ahead and take a look at whether they have been bound at this point. We can see here that after a short little while, a couple of seconds really, we now have the PVC ready to go. It can now be consumed as a piece of storage within a Kubernetes pod.
Now you might be wondering, I only requested 128 megabytes of storage. How did they match up? So this matching, as I mentioned before, is done automatically by a controller built into the kube-controller-manager, which periodically evaluates whether the PV and PVC should bind. So what’s going to happen is that if the PV’s capacity can accommodate the PVC’s claim, that is, if the capacity on the PV is greater than or equal to the claim size then that’s going to allow that claim to bind to that PVC. Likewise, if the PV presents at least the access mode that’s been requested it’s also going to allow the PVC to bind to it because it actually exceeds the requirements put forth by the PVC.
So with this kind of logic you might also be wondering how can I control this matching so that I can avoid having a potentially very small PVC, having it bind to a very large PV? And in that case there are a couple of things we can rely on. First off, our Kubernetes labels and the second is this Kubernetes storage class name.
So, as with all Kubernetes objects, both persistent volume claims and persistent volumes can have labels put into their metadata. So here, I’ve modified our persistent volume to include a label of zone to zone-1 and in the persistent volume claim I’ve actually placed a selector which will allow the persistent volume claim to only search for persistent volumes that bear this label. If I were to create these in my cluster, the only PVs that this PVC could potentially bind to are the ones with this label.
The other method that I can potentially use to filter my PV and PVC matches is the storage class name.
The storage class name is another identifier on the persistent volume and this is something that is added by either the user or perhaps if the PV was created by a more dynamic solution created by that dynamic solution. Either way the storage class name is yet another identifier which can be called upon inside the persistent volume claim and thus give you the same behavior of restricting the persistent volume claim to only search for PVs within this specific storage class and these two are not mutually exclusive. You can use them together just in case you had multiple PVs within the same storage class you can absolutely have both of them as I have shown here.
Persistent volume claims and persistent volumes are the de facto bedrock of Kubernetes-based storage these days and it’s very important to understand how they can match up together. Topics like these are just some of the some of the things that you’ll learn about if you take a course from RX-M. You can look at our collection of pre-made classes or even build your own custom course with the custom course builder.
That’s it for today’s RX-M Cloud Native Short Take. Thank you very much for watching.