Kubernetes Volume Provisioning: Dynamic VS Static

Are you facing issues in allocating resources in the Kubernetes Environment? If yes, look no further guides. We are here to help you with this insightful article which covers a detailed explanation of the Kubernetes Volume Provisioning. If you reach to end of this guide, all your doubts about the Kubernetes Volume Provisioning will be resolved.

Deploying applications in the form of containers is one of the most widely acceptable approaches in today’s world. But, allocating storage to those containers is equally important. This helps us to ensure the durability and high availability of the containerized workloads. Hence, it becomes important to learn various Volume Provisioning Strategies to make our Kubernetes Environment scalable.

In this article, we will learn about Volume Provisioning and its types namely, static and dynamic. So, let us start without any delay.

Overview Of Kubernetes

Kubernetes, also known as K8 is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. In the Kubernetes, the containers are the entities that store the applications along with their dependencies. These containers are grouped into logical units called pods. These pods are present inside the Node, which may be physical or virtual machines. Each Node runs a Kubernetes agent called Kubelet that manages the containers and communicates with the Kubernetes control plane. However, when it comes to storing the data, the pods require some storage volumes in which the data persist even after the lifecycle of the container.

What Is Volume Provisioning?

Whenever we create the files or store the data in Kubernetes, all the data storage goes away once the Container Stops running. To prevent this, we have to allocate some volumes to the Kubernetes Containers so that the data remains persistent even if the container stops. This technique is known as Volume Provisioning in the Kubernetes.

However, before provisioning the resources, there should be a Storage Class in the Kubernetes Cluster. This is due to the fact that the StorageClass Objects store the provisioner, parameters, and reclaimPolicy for the data. Let us first see the types of Volumes that can be provisioned.

• Ephemeral Volumes: Ephemeral volumes in Kubernetes are temporary storage volumes that are tightly coupled with the lifecycle of a pod. They are created and destroyed along with the pod instance.

• Project Volumes: These volumes are accessible only to pods within the same project or namespace, providing isolation and encapsulation of storage resources. Thus, their scope is within a specific project or namespace within a Kubernetes cluster.

• Persistent Volumes: Persistent volumes in Kubernetes are storage volumes that persist beyond the lifecycle of individual pods. Thus, we can dynamically provision or statically allocate them based on user-defined specifications.

What Is Static Volume Provisioning?

Static volume provisioning in Kubernetes refers to the manual allocation and configuration of storage volumes before they are needed by pods. Static provisioning requires administrators to pre-allocate and manage storage resources in advance so that the data remains persistent after the containers stop running. This is implemented using the Persistent Volumes (storage resources in Kubernetes) and PersistentVolumes Claims (PVC), which are the requests made by pods for storage. This process is illustrated as shown below.

• Administrators manually create PV objects with the desired storage configurations using YAML or JSON.

• When a pod requires persistent storage, it creates a PVC object specifying the storage requirements, such as storage class, access mode, and storage size.

• Kubernetes attempts to bind the PVC to a suitable PV based on the matching criteria. If a matching PV is found and available, the PVC is bound to the PV. If no suitable PV is available, the PVC remains in a pending state.

• Once the PVC is bound to a PV, the pod can mount the persistent volume and access it as a filesystem or block device. The pod can read from and write to the volume.

Implementation Of Static Volume Provisioning

• Navigate To your Kubernetes Cluster.
• Create a kubernetes Persistent Volume yaml file as provided in below and save it with a name such as a sample.yaml
• The implementation of Static Volume Provisioning is shown below in the below YAML code.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /data/my-pv
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

• After saving this file as ‘sample.yaml,’ run the command ‘kubectl apply -f sample.yaml’ to create Static Kubernetes Volume. The terminal should appear as shown below.

OUTPUT

What Is Dynamic Volume Provisioning?

There might be a case when the PersistentVolumeClaims (request for storage) does not match with the Persistent Volume created by the administrator. In this case, the cluster dynamically provisions the volume for the PVC. This is implemented using the concept of StorageClass.

First, the administrator defines the StorageClass that contains the fields provisioner, parameters, and reclaimPolicy. Then, the PVC requests the StorageClass to dynamically provision the storage volumes to the pod. You can understand the entire workflow through the below points.

• The pods create a PVC object specifying its storage requirements, such as storage class, access mode, and storage size. Then, they submit it to the Kubernetes API server.

• Kubernetes evaluates the PVC and selects an appropriate StorageClass based on the requested parameters. The selected StorageClass determines the type of storage to be provisioned and the backend storage provider to use.

• After determining the Storage Class, Kubernetes requests the corresponding provisioner to dynamically provision a PersistentVolume (PV) as per the PVC’s requirements.

• After the PV is provisioned, Kubernetes automatically binds it to the requesting PVC so that the pod can access the storage volumes. Hence, the pod can read from and write to the volume as needed, ensuring data persistence across pod restarts and rescheduling events.

Implementation Of Dynamic Volume Provisioning

• If you implement this kind of Volume Provisioning, the YAML file should look as shown below.

 kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fast
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-dynamic-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

• Save the file with ‘sampleDynamic.yaml’ and run the command ‘kubectl apply -f sampleDynamic.yaml’ to provision the Dynamic Kubernetes Volume. The terminal should appear as shown below.

OUTPUT

Static Vs Dynamic Volume Provisioning: Key Differences

The following are the key differences between static and dynamic volume provisioning:

Static Provisioning	Dynamic Provisioning
In this technique, the Administrators manually allocate and configure storage volumes.	Here, the Storage volumes are automatically provisioned based on demand.
It requires manual intervention and pre-allocation of resources.	It automates the provisioning process and reduces the manual effort.
If resources are allocated more or less the than the requirement, this may lead to the underutilization of resources.	This technique optimizes resource usage by provisioning volumes on demand.
It is more complex to manage and maintain at scale.	This simplifies storage management and improves cluster efficiency.
Ideal for environments with predictable storage requirements.	It is well-suited for dynamic workloads and cloud-native environments.

Conclusion

To conclude, Kubernetes is popular and efficient for containerization of the applications. However, we may face challenges when the container stops running as the data storage goes away. Kubernetes provides Storage Provisioning to overcome this challenge. It involves the allocation of the storage volumes to the pods.

We can provision the storage volumes both statically through the manual configuration or dynamically using the StorageClass Objects. After we have gained a clear understanding of the Storage Provisioning the Kubernetes, we can easily optimize our Kubernetes Workflow.

Kubernetes Volume Provisioning – FAQ’s

Which Storage Providers Are Supported For Dynamic Volume Provisioning In Kubernetes?

Kubernetes supports various storage providers for dynamic volume provisioning, including cloud storage services like AWS EBS, GCP PD, and Azure Disk, as well as network-attached storage (NAS) and local storage options.

What Is The Difference Between Volume Mounting And Volume Binding In Kubernetes?

Volume mounting refers to the process of attaching a storage volume to a specific directory within the filesystem of a pod. But the Volume binding is the process of associating a PersistentVolume (PV) with a PersistentVolumeClaim (PVC). First, the Volume binding between the PV and PVC is done. Then, the Kubernetes mounts the PV into the designated directory within the pod so that they can access and utilize the storage volume.

What Is The Difference Between PV And PVC In Kubernetes?

In the Kubernetes Storage Provisioning, the PersistentVolumes represent actual storage resources available in the cluster. On the other hand, PersistentVolumeClaims serve as requests made by pods for access to those storage resources. Thus PVC specifies the storage requirements, such as size and access mode and PVs represent the available storage pool.

What Are Stateful And Stateless Workloads In Kubernetes?

Stateful workloads are applications that require persistent data storage and maintain some form of state or data between sessions or instances. For example, the databases, file systems, and messaging queues require that our data should be persistent. However, the applications that do not maintain any state or data between sessions or instances are stateless workloads. The stateless applications may include web servers, microservices, and API gateways.