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:
In this article:
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:
These are explained in more detail below.
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 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.
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:
A PersistentVolume that was created manually and managed using a StorageClass retains the reclaim policy assigned to it at creation.
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:
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.
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.
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:
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:
kubectl get storageclass
The output should be similar to the following:
The default StorageClass is marked by (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.
kubectl get storageclass
The output should be similar to this:
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.