Read it in 7 Mins
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!
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 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 PersistentVolume 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:
Developing a Kubernetes storage class is somewhat similar to other Kubernetes objects. The mandatory fields in each K8s storage class include -
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.
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.
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.
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.
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.
Some common Kubernetes storage class operations are -
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.)
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 -
Example:
(This is an example showing custom SupportClass in order to provide high-performance cloud functions along with SSD via Google Cloud Storage.)
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> )
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 -
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.
Following are the steps to create a Kubernetes 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
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.
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.
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!
Avail your free 1:1 mentorship session.
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.
No. Getting started is quite easy. You can explore various DevOps online courses to get yourself started.
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.
