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 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 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 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 Storage Classes#

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

The output is as follows.

This is not the first time we’re listing the storage classes in our cluster. However, we did not discuss that one of the two (gp2) is marked as the default StorageClass.

Let’s describe the gp2 class.

The output, limited to the relevant parts, is as follows.

The important part lies in the annotations. One of them is ".../is-default-class":"true". It sets that StorageClass as default. As a result, it will be used to create PersistentVolumes by any PersistentVolumeClaim that does not specify a StorageClass name.

Dynamic Volume Provision#

Let’s try to adapt Jenkins stack to use the ability to dynamically provision a volume associated with the DefaultStorageClass.

Looking into the Definitions#

The new Jenkins definition is as follows.

The output, limited to the PersistentVolumeClaim, is as follows.

It’s hard to spot the difference between that YAML file and the one we used before. It is very small and hard to notice change so we’ll execute diff to compare the two.

The output is as follows.

As you can see, the only difference is that pv/jenkins-dynamic.yml doesn’t have storageClassName: gp2. That field is omitted from the new definition. Our new PersistentVolumeClaim does not have an associated StorageClass.

Applying the Definition#

Let’s apply the new definition.

The output is as follows.

Verifying PersistentVolumes#

What we’re interested in are PersistentVolumes, so let’s retrieve them.

As you can see, even though we did not specify any StorageClass, a volume was created based on the gp2 class, which happens to be the default one.

Deleting the Resources#

We’ll delete the jenkins Deployment and PersistentVolumeClaim before we explore how we can create our own Storage Classes.

The output is as follows.

In the next lesson, we will explore how to create our own Storage Classes.