This is a short blog post that covers an aspect of Kubernetes dynamic provisioning which often trips up folks when they are first exploring it (confused me for sure!)
In order to use a StorageClass
, all you need to do is reference it from a PersistentVolumeClaim
. But StorageClass
is not a mandatory field - so it is possible to not use it at all, or provide an empty string (""
) as its value. It's important to understand these options and the impact they'll have.
Let's clarify these permutations and combinations, once and for all!
Kubernetes
StorageClass
concepts (and more) were covered in-depth in "The definitive guide to Kubernetes Volumes (Part 2)"
Just like a PersistentVolume
encapsulates storage related details, a StorageClass
provides a way to describe the "classes" of storage. Here is an example of a StorageClass
for an Azure Disk.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
labels:
kubernetes.io/cluster-service: "true"
name: default
parameters:
cachingmode: ReadOnly
kind: Managed
storageaccounttype: Standard_LRS
provisioner: kubernetes.io/azure-disk
reclaimPolicy: Delete
volumeBindingMode: Immediate
When storageClass
attribute is absent
You can choose not to include storageClass
attribute in your PersistentVolumeClaim
if you want to use the default
Storage Class in your cluster. For example, Azure Kubernetes Service includes two pre-seeded storage classes.
You can check the same by running kubectl get storageclass
command
NAME PROVISIONER AGE
default (default) kubernetes.io/azure-disk 6d10h
managed-premium kubernetes.io/azure-disk 6d10h
-
default
storage class: provisions a standard Azure Disk backed by a Standard HDD -
managed-premium
storage class: provisions a premium Azure Disk backed by Premium SSD
In this case, the
default
Storage Class (and its associatedprovisioner
) is used even if aPersistentVolume
exists and it matches the requirements in thePersistentVolumeClaim
.
When storageClass
attribute is set to an empty string
This is a tricky one!
You already have a PersistentVolume
along with the corresponding storage medium provisioned and want to use that (without referring to a custom Storage Class or the default
one)
In this case, just set storageClass
to an empty string (""
) in the PersistentVolumeClaim
. This will suppress dynamic provisioning!
Check out "How to add persistent storage to your Kubernetes apps on Azure" to see this in action
When a specific storageClass
attribute is referenced
The "How to use custom Storage Classes in Kubernetes" blog post demonstrates this scenario with an example
In many cases, you might want to create custom Storage Classes in addition to what's already installed in your Kubernetes cluster e.g. to change the way you want to handle removal of your PersistentVolume
and storage medium once the PersistentVolumeClaim
is deleted.
In this case, the provisioner
specified in your custom Storage Class will be used to create the storage medium (and the corresponding PersistentVolume
object) to satisfy the storage request details in the PersistentVolumeClaim
.
Note: If you reference an invalid storage class from a PersistentVolumeClaim
, dynamic provisioning will fail
That's all for now. I would love to have your feedback and suggestions! Just tweet or drop a comment. Also, don't forget to like and follow 😃😃
Top comments (0)