Summary

Dynamic volume provisioning in Kubernetes allows for on-demand creation of storage volumes using StorageClasses, which abstract underlying storage details and facilitate the provisioning process through persistent volume claims (PVCs) and persistent volumes (PVs).

Abstract

Kubernetes supports dynamic volume provisioning, a feature that enables the creation of storage volumes as needed, leveraging StorageClass objects to define the type of storage and provisioner to be used. Cluster administrators can create multiple StorageClasses, each tailored with specific provisioners and parameters. When a PVC is made, it uses the defined StorageClass to request the provisioning of storage, which is then automatically managed by the Kubernetes cluster, including the creation of PVs and handling storage operations in cloud environments. The process involves defining access modes, storage capacity, and optionally setting a StorageClass as default. The storage plugin dynamically provisions the storage, creates a PV, and binds it to the PVC, with the status changing to "Bound" once completed. The PVC can then mount the storage to a pod. StorageClasses also include important fields such as reclaimPolicy and volumeBindingMode, which dictate the lifecycle of storage after PVC deletion and control the timing of volume binding and provisioning, respectively.

Opinions

The author emphasizes the simplicity and abstraction provided by StorageClasses in managing complex storage configurations.
The use of dynamic provisioning is presented as a convenient and efficient method for handling storage in Kubernetes, particularly in cloud environments.
The WaitForFirstConsumer mode of volumeBindingMode is highlighted as a useful feature for multi-zone clusters, suggesting its importance in specific use cases.
The author intends to delve deeper into the WaitForFirstConsumer mode in a follow-up discussion, indicating its significance and potential complexity.
The post concludes with an encouragement to continue learning, reflecting the author's belief in the value of understanding and mastering Kubernetes storage concepts.

Kubernetes Storage — Dynamic Volume Provisioning

In Kubernetes, Dynamic volume provisioning is a mechanism which allows storage volumes to be created on-demand. Kubernetes Cluster uses concept of Storage class to achieve the same. Storage class another type of object in Kubernetes which allows you to abstract the details of underlying storage in a simple fashion. Kubernetes uses a system of persistent volume claim (PVC) and persistent volume (PV) to simplify storage operations with help of Storage Class (SC).

A cluster administrator can define as many StorageClass objects as needed, each specifying a volume plugin ( provisioner) that provisions a volume and the set of parameters to pass to that provisioner when provisioning.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fastdisk
provisioner: kubernetes.io/azure-disk
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  storageaccounttype: Premium_LRS
  kind: Managed

#You can make any StorageClass as default, by adding the #storageclass.kubernetes.io/is-default-class annotation to it.

To access the Storage you must create the object PVC (PersistentVolumeClaim). PVC is the request to provision persistent storage with a specific type and configuration. PVC uses Storage class to create specific request to provisioner for storage creation. That’s it once PVC is in the system, rest of the things will be taken care by k8s cluster. ex: storage creation in cloud, PV creation and management etc.

This is dynamic volume provisioning !

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: storage-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fastdisk
  resources:
    requests:
      storage: 10Gi

Creating a PVC in a cluster automatically triggers the storage plug-in for the requested type of storage to provision storage with the given specification.

You StorageClass will have storage account definition to use otherwise default storage account will be used to create storage.

Storage plug-in automatically creates a persistent volume (PV, virtual storage device) in the cluster, which maps to storage in Cloud. Status of the PVC and the PV changes to Bound

Now PVC Mounts that storage in POD if it is part of POD definition.

Storage Class

SC plays an important role in case of Dynamic provisioning. Each StorageClass has a provisioner that determines what volume plugin is used for provisioning PVs. Above mentioned SC defines Azure File Storage.

Another fieldreclaimPolicy defines what will happen to storage once you delete the PVC. Delete or Retain are two values which can be used here. As the name

The volumeBindingMode field controls when volume binding and dynamic provisioning should occur. Two values — Immediate or WaitForFirstConsumer

Immediate mode indicates that volume binding and dynamic provisioning occurs once the PersistentVolumeClaim is created. WaitForFirstConsumer mode will delay the binding and provisioning of a PersistentVolume until a Pod using the PersistentVolumeClaim is created. This is useful when storage backends that are topology-constrained and not globally accessible. This Mode suits when you have a multi-zone cluster in place and storage is bound to Zones.

We will talk about more on WaitForFirstConsumer mode in next post.

That’s all for this post. Thanks.

Keep Learning !