Kubernetes StorageClass: Concepts and Common Operations

With problems like integrity, preservation, replication, and transfer of big data volumes, storage has always been difficult for IT professionals. Even with today's decentralized, container-based systems, these difficulties persist. Kubernetes is the most widely used orchestrator, for containerized workloads. Containers are transitory by nature, which makes it difficult for many different types of workloads to employ them because they use default settings to destroy all stored data. Kubernetes, on the other hand, offers a number of features that minimize this issue and allow stateful applications in a containerized environment.

In Kubernetes, a StorageClass defines what storage configuration and features are available to containers deployed on the cluster. Configuration options include replication factor, read-only mode, persistent volumes, and more. Kubernetes StorageClass is a relatively new feature that was added in Kubernetes 1.5. It enables administrators to create and manage storage classes independently from pods and bind them to a particular namespace.

However, Kubernetes pods are inefficient to store data persistently on their own. Learn how to work with Kubernetes, how to process data, and create Kubernetes StorageClass with comprehensive skill-oriented professional course. KnowledgeHut is an online platform focused on providing outcome-based immersive learning experiences to learners. Get started with your Kubernetes Certification preparation with instructor-backed-up training and industry-approved curriculum and take a step forward toward your dream career in no time! 

What is Kubernetes StorageClass?

Kubernetes is an open-source platform for orchestrating containers. In a cloud or cluster environment, Kubernetes provides required services and management capabilities for efficiently deploying, operating, and scaling containers in a cloud or in a cluster environment. 

Kubernetes storage is important for storage administrators when managing containerized environments since it allows them to keep multiple types of persistent and non-persistent data together and orchestrated in a Kubernetes cluster. As a result, it makes it possible to create and develop dynamic storage resources which can support various kinds of applications. 

A Kubernetes resource called a StorageClass makes it possible to dynamically provide storage. The StorageClass is configured by the administrator and is then fixed. The StorageClass, PersistentVolumeClaim (PVC), and Pod are all constructed in their respective order. When a PVC is successfully created in the StorageClass configuration, the VolumeBindingMode determines how a PersistentVolume is bound to the PVC. To check a StorageClass test case, these three Kubernetes objects are needed depending on the VolumeBindingMode selected in the StorageClass settings.

Why Use Kubernetes Storage Classes?

Kubernetes provides potent primitives for managing storage, which is a crucial component of operating stateful containers. Kubernetes-only dynamic volume provisioning enables the instant creation of storage volumes. Prior to dynamic provisioning, Kubernetes administrators had to place calls manually to their cloud or storage provider to add new storage volumes, after which they were allowed to construct Persistent Volume objects to represent such objects in Kubernetes. 

Kubernetes storage classes provide a way to dynamically provision persistent storage for applications running on a Kubernetes cluster. By using storage classes, you can create and attach storage volumes to your applications on-demand, without having to manually provide and manage the underlying storage infrastructure. This can significantly reduce the time and effort required to deploy and manage storage for your applications. In addition, storage classes provide a number of other benefits, including the ability to fine-tune performance and control costs. As a result, they are an essential part of any Kubernetes deployment. 

Kubernetes storage classes help an administrator define some extensive properties of storage system that include: 

• Quality of service 
• Speed specifications (like HDD or SSD storage) 
• Quality and type of file systems 
• Replication or Backup 
• Any additional storage properties as defined by the Kubernetes administrator

Kubernetes StorageClass Concepts

Developing a Kubernetes storage class is somewhat similar to other Kubernetes objects. The mandatory fields in each K8s storage class include - 

1. Provisioner: the mandatory plug-in required to provision the volume of the storage. 
2. Parameters: to indicate specific properties of the said storage system 
3. ReclaimPolicy: to describe a pod's release conditions and how it can be reclaimed for other pods 
4. Volume Binding Mode: to determine how the pods need to bind with a storage volume

Here’s a Kubernetes storage class example for a better understanding of the elements in the storage class -

apiVersion: storage.k8s.io/v1 
Kind: StorageClass 
metadata: 
Name: standard 
provisioner: kubernetes.io/aws-ebs 
parameters: 
type: gp3 
reclaimPolicy: Retain 
allowVolumeExpansion: true 
mount0ptions: 

debug 

volumeBindingMode: Immediate 

The StorageClass object's name is crucial since it permits requests to that specific class. When creating a new StorageClass object, administrators must provide class parameters, along with the name. The parameters of an item are fixed and cannot be changed. 

1. Provisioner

The provisioner, which chooses which volume plugin to use to provision PersistentVolumes, is a part of a StorageClass object. This field is to be specified by administrators. One may find a list of the internal provisioners offered by Kubernetes that are delivered by default with Kubernetes and have names with a kubernetes.io prefix.

External provisioners are independent programs that adhere to a Kubernetes-defined standard; where users can define and run them. An external provisioner's creator has complete control over the code's storage location, the provisioner's shipping and operation, and the choice of volume plugins. 

An example of a provisioner is the NFS or Network File System. However, NFS is not available internally and thus only offers external provisions. Another example of external provisioners is the third-party storage providers who arrange for their own external provisioners. 

2. Parameters

Parameters describe the volumes in a StorageClass. They are determined by the parameters of the provisioner plugin and the characteristics of the underlying storage system. There are a maximum of 512 parameters for a StorageClass. The length of the parameters object, including keys and values, is up to 256 KiB. 

3. Reclaim Policy

PersistentVolumes can be created dynamically by StorageClass using either Delete or Retain as the reclaimPolicy field. ReclaimPolicy is set to Delete by default if it is not specified in a StorageClass object. 

1. As soon as the pod no longer requires the storage volume, the reclaim policy is set to Delete. 
2. When the pod is no longer needed, the storage volume is retained and can be reused by other pods by setting the reclaim policy to Retain.
3. Manually created and managed PersistentVolumes are created to retain their reclaim policies.

 Volume Binding Mode

Pods are bound to storage volumes in accordance with the volumeBindingMode attribute of the StorageClass. If it is not configured, the Prompt mode is used by default. Immediate signifies that dynamic provisioning and binding start as soon as a PersistentVolumeClaim is created. An object called a PersistentVolumeClaim represents a pod's request for a persistent storage volume. 

Volume binding can be done in two ways: 

1. Immediate

PVCs are created in this mode immediately after volume and storage bindings are created. You can see the bound state when creating a new PVC with the standard storage StorageClass. It is universally supported. 

2. WaitForFirstConsumer

This mode does not create a volume until a pod consuming the PVC is created. There are only a few plug-ins that support this mode, including Amazon Elastic Block Store, Azure Disk, Google Compute Engine Persistent Disk, etc. 

Kubernetes StorageClass Common Operations [with Examples]

Some common Kubernetes storage class operations are - 

1. Default StorageClass

It is sufficient to build a PersistentVolumeClaim if the cluster's default StorageClass satisfies the user's requirements. The storageClassName does not need to be specified as the default provisioner handles the remaining tasks. 

Example:

(This is an example of a PersistentVolumeClaim without a storageClassName, and thus uses the default StorageClass.) 

2. Custom StorageClass

In order to add a custom StorageClass, it is important to first determine the provisioners' to work in the cluster. When the first step is completed, one can create a custom StorageClass with custom parameters as per the user’s needs.

The simplest way to create a StorageClass object is - 

1. Create a yaml file 
2. Use the command - kubectl create -f 

Example:

(This is an example showing custom SupportClass in order to provide high-performance cloud functions along with SSD via Google Cloud Storage.) 

3. Checking whether a Default StorageClass is Installed

It is possible for an admin to check StorageClass objects using kubectl.  

Example:

a. For a high-perf

(The output is the byproduct of command - kubectl get sc) 

b. Standard

(Command used - kubectl describe storageclass standard> ) 

4. Changing the Default StorageClass if/when necessary

The Kubernetes cluster might be set up with an existing StorageClass set as the default, depending on the configuration. When PersistentVolumeClaims don't provide a specific StorageClass, the storage will be provisioned dynamically according to the default StorageClass. 

Steps to change default StorageClass: 

Step 1: List the cluster StorageClasses using - kubectl get storageclass 

Output -

As it is seen, the default StorageClass is marked - (default) 

Step 2: Mark the default StorageClass as non-default using -

kubectl patch storageclass high-perf -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'

Step 3: Run and verify the chosen StorageClass by running - kubectl get storageclass 

The final output should look like this -

List Storage Classes in Kubernetes

All the respective storage class in a cluster can be found with the command - kubectl getsc, (where sc = StorageClass). 

For Example:

patricia@Azure:~/storage$ kubectl get sc

NAME	PROVISIONER	RECLAIMPOLICY	VOLUMEBINDINGMODE	ALLOWVOLUMEEXPANSION	AGE
azure-storage	kubernetes.io/azure-disk	Delete	Immediate	false	10s
azurefile-csi	file.csi.azure.com	Delete	Immediate	true	23d
azurefile	file.csi.azure.com	Delete	Immediate	true	23d
azurefile-premium	file.csi.azure.com	Delete	Immediate	true	23d
azurefile-csi-premium	file.csi.azure.com	Delete	Immediate	true	23d
default (default)	disk.csi.azure.com	Delete	WaitForFirstConsumer	true	23d
managed	disk.csi.azure.com	Delete	WaitForFirstConsumer	true	23d
managed-csi-premium	disk.csi.azure.com	Delete	WaitForFirstConsumer	true	23d
managed-csi	disk.csi.azure.com	Delete	WaitForFirstConsumer	true	23d
managed-premium	disk.csi.azure.com	Delete	WaitForFirstConsumer	true	23d

azure-storage is the first listing you created. The volume is created immediately after a PVC is created due to the Immediate reclaim policy. The remaining storage classes on the list are the ones that come with an Azure cluster by default. Explore DevOps online courses and start your preparation today.

How to Create Storage Classes in Kubernetes

Following are the steps to create a Kubernetes StorageClass: 

Stage 1: Create a StorageClass

Step 1: Firstly, create a file with any editor or vim - $ vim st-class.yaml 

Step 2: Create a StorageClass with kubectl create command after copying the above StorageClass manifest file into a yaml file.

$ kubectl create –f st- class.yaml 
Storageclass.storage.k8s.io/my-storageclass created 

Step 3: After implementing, check for the details of the StorageClass.

$ kubectl get sc my-storageclass 
 
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE AGE 
my-storageclass kubernetes.io/aws-ebs Delete WaitForFirstConsumer 9s 

Stage 2: Create a PVC

The StorageClass name defined in stage 1 should be inserted as a storageClassName field with the value my-storageclass in the PVC manifest file. If this parameter is left blank, the PVC will be provisioned with the "Standard" StorageClass by default. It is always advised to use the chosen StorageClass by referencing its name in the PVC. The final configuration will resemble the following:

apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
name: my-claim 
spec: 
accessModes: 
- ReadWriteOnce 
storageClassName: my-storageclass
resources: 
requests: 
storage: 2Gi 

Step 1: Enter kubectl create to create a PVC

$ kubectl create -f my-pvc.yaml 
persistentvolumeclaim/my-claim created 

Step 2: Check PVC status

$ kubectl get pvc my-claim 
 
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE 
my-claim Pending my-storageclass 9s

Step 3: Check PersistentVolume status by the command - kubectl get

$ kubectl get pv
No resources found 

A PVC has been generated, but you cannot see any available persistent volumes on the cluster. After erasing the PVC and StorageClass, construct the two objects once more, modify the volumeBindingMode value to Immediate, and then check the status. You can now construct a Pod at stage 3. 

Stage 3: Create a Pod

With the same configuration as used in PVC, the PVC name needs to be the same as persistentClaimVolume.claimName field’s value in the Pod.

The outcome should show like this -

$ vim st-pod.yaml 
 
apiVersion: v1 
kind: Pod 
metadata: 
name: my-pod 
spec: 
containers: 
- name: stclass-test 
image: nginx 
volumeMounts: 
- mountPath: "/app/data" 
name: my-volume 
volumes: 
- name: my-volume 
persistentVolumeClaim: 
claimName: my-claim 

Step 1: Create Pod with kubectl create

$ kubectl create -f st-pod.yaml 
pod/my-pod created 

Step 2: Examine the Status of the Pod

$ kubectl get pods my-pod 
 
NAME READY STATUS RESTARTS AGE 
my-pod 1/1 Running 0 3m 

Step 3: Check PVC status again

$ kubectl get pvc my-claim 
 
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE 
my-claim Bound pvc-6e5dae64 2Gi RWO my-storageclass 10m 

The PVC's status has changed from pending to bond, as seen above. Simply said, all three newly formed objects are now tied to or link one another. Use the kubectl get command to recheck the status of the persistent volume in the next step:

$ kubectl get pv
 
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS AGE
pvc-6e5dae64 2Gi RWO Delete Bound default/my-claim my-storageclass 99s 

Lastly, with exact implementation. You’ll receive output as mentioned above, and thus a successful creation of a dynamic volume provisioning using StorageClass. 

Conclusion

Kubernetes StorageClasses are objects for storing application data in the cloud. A StorageClass's provisioning is determined by which volume plugin is used. The static provisioning method does not require manual provisioning of PersistentVolume in advance. It is instead necessary to create the StorageClass object before creating the PersistentVolumeClaim object. 

On average, a Kubernetes Administrator can expect to make $120,297 per year. Faster scaling, deployment, and development are continually in demand. This fuels the demand for experts with tool-use expertise as well as the significance of tools like Kubernetes. An important factor in the efficiency of creating and deploying crucial apps is the knowledge a Kubernetes administrator possesses. KnowledgeHut is one of the most trusted platforms, used by many for their unique skill-based course module.

And if you’re still confused about which one would suit your career, enroll in our comprehensive Docker and Kubernetes Training and Certification and become a docker and Kubernetes expert!