Kubernetes Dynamic Persistent Volume – A Basic Overview

Filed Under: Random
Kubernetes Dynamic Persistent Volume (1)

Hello, readers! This article talks about Kubernetes Dynamic Persistent Volumes and a way to provide the same.

So, let us begin!! 馃檪

Also read: Bootstrapping a Kubernetes cluster using Kubeadm


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-

  1. Static
  2. Dynamic

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.


Conclusion

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! 馃檪

Leave a Reply

Your email address will not be published. Required fields are marked *

close
Generic selectors
Exact matches only
Search in title
Search in content