Hello, readers! This article talks about Kubernetes Dynamic Persistent Volumes and a way to provide the same.
So, let us begin!! 🙂
Concept of Kubernetes Dynamic Persistent Volume
Kubernetes provides us with the concept of Persistent volumes that enables an application to have data that can persist. That is, data that can stay safe and available even after the deletion of pods or deployments.
Within Kubernetes, there are two ways of provisioning Persistent Volumes-
Static Persistent volumes follow a static approach to spin up a volume for an application/namespace. In this approach, the Cluster Admin needs to make calls to the storage providers, spin up a storage volume and then create Persistent volumes on top of it. Post which, application teams can create a Persistent Volume Claim to associate it to the static storage.
On the other hand, Dynamic Persistent Volumes, as the name suggests, helps us provision a volume at run-time i.e. dynamically.
With Dynamic provisioning, we can request volumes as and when needed. Also, it eliminates the role of a cluster-admin to provision storage.
By this, we mean to say that we can have a custom format to request a dynamic amount of memory space for persistent data storage without having to request it statically at the very beginning.
Step 1. Creation of a Storage class
In order to provide a dynamic persistent volume solution, we first need to have a storage class created for a dynamic Persistent volume claim.
Being a Kubernetes cluster-admin, we can provide multiple storage classes specifying a volume plugin (usually some provisioned such as NFS, NFS Ganesha, etc). We can have a separate storage class for a different request with some custom and addon parameters to it.
Have a look at the below code:
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: storage-dy provisioner: kubernetes.io/gce-pd parameters: type: pd-standard
The above storage class provisions standard persistent disk as the background to store the data through dynamic persistent volumes.
Step 2. Provisioning a Persistent Volume Claim
Post provisioning of a storage class now is the time to actually request for some persistent volume claim to have a storage class for our persistent data.
Let us have a look at the below code-
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: dynamic-pv-claim spec: accessModes: - ReadWriteOnce storageClassName: storage-dy resources: requests: storage: 10Gi
The above code creates a dynamic claim which makes use of the storage-dy storage class. So, at the backend, it provisions standard persistent disk storage blocking a volume of 10 Gi for use.
This persistent volume claim internally gets bound to a persistent volume at runtime and the blocked storage stays as long as the claim stays.
Step 3. Volume mounts to utilize the PVC
The last step is to make use of the persistent claim-related details within the deployment to be used by the application.
For the same, we actually need to specify the volume and persistent volume claim details in the deployment YAML file. Also, we can create different directories within the volume at runtime to store the data. For the same, we can make use of the volume mounts attribute to store the data at certain locations within the provisioner.
Let us have a look at the below example.
apiVersion: v1 kind: Pod metadata: name: demo-pod spec: volumes: - name: dynamic-column persistentVolumeClaim: claimName: dynamic-pv-claim containers: - name: demo-cn image: nginx ports: - containerPort: 80 volumeMounts: - mountPath: "/usr/data" name: dynamic-column
The above configuration stores the data using the dynamic volume attached to the persistent volume claim dynamic-pv-claim to store the data at the path /usr/data.
By this, we have approached the end of this topic. Feel free to comment below, in case you have any questions.
For more such posts related to Docker and Kubernetes, Stay tuned with us.
Till then, Happy Learning! 🙂