In the cloud world, people provision storage or data volume dynamically. While PersistentVolumeClaim is based on existing static PersistentVolume that is provisioned by administrators, it might be really beneficial if the cloud volume could be requested dynamically when it needs to be. Storage classes are designed to resolve this problem. To make storage classes available in your cluster, three conditions need to be met. First, the DefaultStorageClass admission controller has to be enabled (refer to Chapter 7, Building Kubernetes on GCP). Then PersistentVolumeClaim needs to request a storage class. The last condition is trivial; administrators have to configure a storage class in order to make dynamic provisioning work:

The default storage classes are various, basically based on your underlying cloud provider. Storage classes are the abstract way to define underlying storage providers. They have different syntax based on different types of providers. Default storage classes can be changed, but cannot be deleted. The default storage class has an annotation storageclass.beta.kubernetes.io/is-default-class=true on. Removing that annotation can disable the dynamic provisioning. Moving the annotation to another storage class can switch the default storage class. If no storage classes have that annotation, dynamic provisioning will not be triggered when there is a new PersistentVolumeClaim.