Dynamic Provisioning for Kubernetes storage is implemented by most cloud providers with a simple cloud attach disk type as the default. If you’ve used Kubernetes provided by any of the public clouds, chances are you’ve to experience creating Persistent Volume Claims (PVC) which magically got fulfill by the underlying, default persistent volume storage.
A PersistentVolume (PV) is a piece of storage in the cluster that has been provision by an administrator. It is a resource in the cluster just like a node is a cluster resource
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.
Why do we need provisioning
Dynamic provisioning in a Kubernetes cluster adds a number of benefits:
- Reduced storage spending: As Dynamic provisioning allows automatically allocating and deallocating PVs in response to PVCs helps to reduce storage wastage that is allocate but never used. It also eliminates the overhead of pre-provisioning volumes and managing their lifecycle.
- Automatic provisioning: As dynamic provisioning creates volumes as soon as they are requires, it reduces a lot of the administrative overhead involved in manually creating PVs.
- Optimized performance: PVCs that are fulfill dynamically make use of a storage class attribute to specify the type of storage required.
You’ve seen how using PVs and PersistentVolumeClaims(PVCs) makes it easy to obtain persistent storage without the developer having to deal with the actual storage technology used underneath. But this still requires a cluster administrator to provide the actual storage upfront. Fortunately, Kubernetes can also perform this job automatically through dynamic provisioning of PersistentVolumes.
Kubernetes includes provisioners for the most popular cloud providers, so the admin doesn’t always need to deploy a provisioner. But if Kubernetes deploy on-premises, a custom provisioner needs to be deploy.
Defining the available storage types through StorageClass resources
The StorageClass resource specifies which provisioner should be use for provisioning the PersistentVolume when a PersistentVolumeClaim requests this StorageClass. The parameters defined in the StorageClass definition are passes to the provisioned.
Provisioner: k8s.io/minikube-hostpath
Here, I am using the default provisioner available in minikube which creates the host path directory when the volume is requires to store the data.
ReclaimPolicy : Retain
It signifies that’s even after the pod fails or crashed then also the stored data remain there until you manually delete it.
Requesting the storage class in a PersistentVolumeClaim
After the StorageClass resource is created, Now we can refer to the mystorage by name in their PVCs.
Creating a PVC definition requesting a specific Storage Class
your PersistentVolumeClaim now also specifies the class of storage you want to use. When you create the claim, the
PersistentVolume is created by the provisioner reference in the Mystorage StorageClass resource. The provisioner is use even if an existing manually provisioned PV matches PVC.
Examining the created PVC and the Dynamically Provisioned PV
$ kubectl get pvc demo-pvc
The VOLUME column shows the PV that’s bound to this claim. Now you can try listing PV to see that a new PV has indeed been creates automatically:
You can see the dynamically provisioned PV. Its capacity and access modes are what you requested in the PVC. Its reclaim policy is Retain.
Conclusion
In Conclusion, You came to know about the Dynamic provisioning, Now you know kow to Create dynamic storage class and how to claim it through PVC.
