Storage
Mobility
Protection
Analysis and control
TOPICShare
What Is Kubernetes StorageClass?
A Kubernetes StorageClass is a Kubernetes storage mechanism that lets you dynamically provision persistent volumes (PV) in a Kubernetes cluster. Kubernetes administrators define classes of storage, and then pods can dynamically request the specific type of storage they need.
Storage classes can define properties of storage systems such as:
- Speed (for example, SSD vs. HDD storage)
- Quality of service levels
- Backup or replication policies
- Type of file system
- Or any other property defined by the administrator
In this article:
- Kubernetes StorageClass Concepts
- Kubernetes StorageClass Common Operations
- Kubernetes Storage Optimization with Cloud Volumes ONTAP
Kubernetes StorageClass Concepts
Creating a StorageClass is similar to creating other Kubernetes objects. Here is an example StorageClass manifest file:
The name of the StorageClass object is important because it enables requests to that particular class. Administrators specify class parameters, including the name, when they first create a StorageClass object. Once an object’s parameters are set, they cannot be updated.
Every StorageClass has the following fields:
- Provisioner—this is the plugin used to provision the storage volume
- Parameters—indicate properties of the underlying storage system
- reclaimPolicy—indicates under what conditions the storage is released by a pod and can be reclaimed for use by other pods
These are explained in more detail below.
Provisioner
A StorageClass object contains a provisioner that decides which volume plugin is used to provision PersistentVolumes. Admins must specify this field.
Kubernetes provides internal provisioners, which you can see listed here. Their names have a kubernetes.io prefix and they are shipped by default as part of Kubernetes.
Users can specify and run external provisioners - these are independent programs that follow a Kubernetes-defined specification. The author of an external provisioner has full discretion over the code’s storage location, the provisioner’s shipping and running, and the selection of volume plugins (including Flex). To see an example, read our blog about building a CSI driver.
An example of an external provisioner is the Network File System (NFS), which is not available as an internal provisioner, but offers an external provisioner. In some cases, third-party storage vendors provide their own external provisioners.
Related content: Read our guide to Kubernetes NFS
Parameters
Parameters describe volumes belonging to the StorageClass. The parameters depend on the provisioner plugin and the properties of the underlying storage system.
A StorageClass can have at most 512 parameters. The parameters object can have a total length of up to 256 KiB including keys and values.
Reclaim Policy
StorageClass can dynamically create PersistentVolumes that specify either Delete or Retain in the class’s reclaimPolicy field. If there is no specified reclaimPolicy in a StorageClass object (admins must specify it when creating the object), it is set to Delete by default:
- Setting the reclaim policy to Delete means that the storage volume is deleted when it is no longer required by the pod.
- Setting the reclaim policy to Retain means that the storage volume is retained when no longer required by the pod and can be reused by other pods.
A PersistentVolume that was created manually and managed using a StorageClass retains the reclaim policy assigned to it at creation.
Volume Binding Mode
The volumeBindingMode field of the StorageClass determines how pods bind to a storage volume. If it is not set, the Immediate mode is the default. Immediate indicates that dynamic provisioning and binding occur immediately upon the creation of a PersistentVolumeClaim. A PersistentVolumeClaim is an object that represents a request by a pod for a persistent storage volume.
A common problem is that storage backends are not globally accessible from all nodes in the cluster. In this case, PersistentVolumes might be provisioned without knowledge of the pod's scheduling requirements, resulting in unschedulable pods.
Cluster administrators can address issues like this by setting the volume binding mode to WaitForFirstConsumer. This mode delays the binding and provisioning of the PersistentVolume until the creation of a pod using a matching PersistentVolumeClaim.
PersistentVolumes are selected or provisioned according to the pod's scheduling constraints. These include:
- Resource requirements
- Node selectors
- Pod affinity, anti-affinity, taints, and tolerations
Kubernetes StorageClass Common Operations
Using a Default StorageClass
If a cluster has a default StorageClass that meets the user’s needs, all that is necessary is to create a PersistentVolumeClaim. The default provisioner should take care of the rest—there is no need to specify the storageClassName.
Below is an example of a PersistentVolumeClaim that does not use a storageClassName, and thus uses the default StorageClass.
Adding a Custom StorageClass
To add a custom StorageClass, it is first necessary to determine which provisioners will work in the cluster. The next step is to create a StorageClass object with custom parameters to meet the user’s needs.
For many users, the easiest way to create an object is to write a yaml file and use the following command to apply it:
kubectl create -f
The following example shows a custom StorageClass, which provides high performance cloud storage with solid state drives (SSD) via Google Cloud Storage. The administrator could leave the default StorageClass and add this special StorageClass for workloads that require high performance.
Checking if a Default StorageClass is Installed
It is possible to use kubectl to check for StorageClass objects. The following example shows two storage classes: high-perf and standard. The high-perf class is user-defined, and the standard class is the default installed by Kubernetes.
Run this command:
kubectl get sc
The output looks like this:
To see the details of each StorageClass run this command:
kubectl describe storageclass standard>
The output looks like this:
Changing the Default StorageClass
Depending on the installation method, the Kubernetes cluster might be deployed with an existing StorageClass marked as the default. The default StorageClass determines the dynamic provisioning of storage for PersistentVolumeClaims that don’t specify any particular StorageClass.
To change the default StorageClass:
- List the StorageClasses in the cluster by running this command:
kubectl get storageclass
The output should be similar to the following:
The default StorageClass is marked by (default).
- Mark the default StorageClass as non-default
The default StorageClass contains the annotation storageclass.kubernetes.io/is-default-class set to true. An absent annotation or one with any other value is interpreted as false.
To specify a StorageClass as non-default, this value must be changed to false:
kubectl patch storageclass high-perf -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
Only one StorageClass can be set as the default. If more objects are marked as default, it is not possible to create a PersistentVolumeClaim without an explicitly specified storageClassName.
- Verify that the chosen StorageClass is the default by running this command:
kubectl get storageclass
The output should be similar to this:
Kubernetes Storage Optimization with Cloud Volumes ONTAP
NetApp Cloud Volumes ONTAP, the leading enterprise-grade storage management solution, delivers secure, proven storage management services on AWS, Azure and Google Cloud. Cloud Volumes ONTAP capacity can scale into the petabytes, and it supports various use cases such as file services, databases, DevOps or any other enterprise workload, with a strong set of features including high availability, data protection, storage efficiencies, Kubernetes integration, and more.
In particular, Cloud Volumes ONTAP supports Kubernetes Persistent Volume provisioning and management requirements of containerized workloads.
Learn more about how Cloud Volumes ONTAP helps to address the challenges of containerized applications in these Kubernetes Workloads with Cloud Volumes ONTAP Case Studies.
