Using Default StorageClasses

Default StorageClasses

Working with dynamic provisioning simplifies a few things. Still, a user needs to know which volume type to use. While in many cases that is an important choice, there are often situations when a user might not want to worry about that. It might be easier to use the cluster administrator’s choice for volume types and let all claims that do not specify storageClassName get a default volume. We’ll try to accomplish that through one of the admission controllers.

Default StorageClass admission controllerController

Admission controllers intercept requests to the Kubernetes API server. We won’t go into the details of admission controllers since the list of those supported by Kubernetes is relatively extensive.

We are interested only in the DefaultStorageClass, which happens to be already enabled in the cluster we created with kOps.

DefaultStorageClass admission controller observes the creation of PersistentVolumeClaims. Through it, those that do not request any specific storage class are automatically assigned a default storage class. As a result, PersistentVolumeClaims that do not request any special storage class are bound to PersistentVolumes created from the default StorageClass. From a user’s perspective, there’s no need to care about volume types since they will be provisioned based on the default type unless they choose a specific class.

Available StorageClasses

Let’s look at the storage classes currently available in our cluster: