Using Default Storage Classes

Default Storage Classes

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.

DefaultStorageClass Admission Controller

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

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

DefaultStorageClass admission controller observes creation of PersistentVolumeClaims. Through it, those that do not request any specific storage class are automatically added a default storage class to them. As a result, PersistentVolumeClaims that do not request any special storage class are bound to PersistentVolumes created from the default StorageClass. From 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 Storage Classes

Let’s take a look at the storage classes currently available in our cluster.