flash sale banner

HomeBlogDevOpsKubernetes StorageClass: Concepts and Common Operations

Kubernetes StorageClass: Concepts and Common Operations

08th Sep, 2023
view count loader
Read it in
7 Mins
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. 

Kubernetes Storage Class

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 
Name: standard 
provisioner: kubernetes.io/aws-ebs 
type: gp3 
reclaimPolicy: Retain 
allowVolumeExpansion: true 
  • 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. 


(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 


(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.  


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 


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 





































default (default) 






























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. 

Azure Storage

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 
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 
name: my-claim 
- ReadWriteOnce 
storageClassName: my-storageclass
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 
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 
name: my-pod 
- name: stclass-test 
image: nginx 
- mountPath: "/app/data" 
name: my-volume 
- name: my-volume 
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 
my-pod 1/1 Running 0 3m 

Step 3: Check PVC status again 

$ kubectl get pvc my-claim 
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
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. 


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! 

Frequently Asked Questions (FAQs)

1Does Kubernetes have storage?

Storage in Kubernetes is by default momentary (non-persistent). Any storage designated as a component of a container in a Pod is kept in the host's temporary storage area for the duration of the pod's existence, after which it is deleted. Although not durable, container storage is transportable.

2Is Kubernetes hard to learn?

No. Getting started is quite easy. You can explore various DevOps online courses to get yourself started. 

3How long will it take to learn Kubernetes?

Learning time tends to vary from learner to learner. However, KnowledgeHut’s Docker and Kubernetes training and certification course provide you with 32 hours of live classes along with 28 hours of hands-on training on docker and Kubernetes. Choose according to your need and specifications. 


Mayank Modi

Blog Author

Mayank Modi is a Red Hat Certified Architect with expertise in DevOps and Hybrid Cloud solutions. With a passion for technology and a keen interest in Linux/Unix systems, CISCO, and Network Security, Mayank has established himself as a skilled professional in the industry. As a DevOps and Corporate trainer, he has been instrumental in providing training and guidance to individuals and organizations. With over eight years of experience, Mayank is dedicated to achieving success both personally and professionally, making significant contributions to the field of technology.

Share This Article
Ready to Master the Skills that Drive Your Career?

Avail your free 1:1 mentorship session.

Your Message (Optional)

Upcoming DevOps Batches & Dates

NameDateFeeKnow more
Course advisor icon
Course Advisor