5th May 2020

Tanzu Kubernetes Cluster ‘default’ storage class not persisting

In my last post, when I was deploying kubernetes resources via kubeapps I came across what seemed to be an issue where the default storage class I was passing to the cluster wasn’t persevering. To try and resolve the issue I’d been passing the below from within my Tanzu Kubernetes Cluster but it wasn’t remaining in place;

“kubectl patch storageclass vi-cluster1-vsan-storage-policy -p ‘{“metadata”: {“annotations”:{“storageclass.kubernetes.io/is-default-class”:”true”}}}'”

I flagged it as I wasn’t sure if this was expected behaviour from the TKG Cluster and was pointed toward to following documentation. That highlighted that there is a configurable field in the YAML for setting up TKG under spec.storage called defaultClass. :doh:

If like me, you’d only deployed TKG with the minimal YAML, this configuration is not present in the cluster.

So for anyone that like me didn’t set the spec.settings.storage.defaultClassat the time of build, this can be edited post deployment.

Connect to the vSPhere supervisor cluster with ‘kubectl-vsphere’ and switch context to your TKG context ‘kubectl config use-context [tkg-context]’

Edit the Tanzu Kubernetes Cluster resource;

kubectl edit tanzukubernetescluster/tkgclustername

This will open up a text editor (pictured vi);

Underneath spec and settings, I’ve added (‘i’ to insert in vi ‘esc’ to stop inserting text) a storage section with the ‘defaultClass’ flag set. Save the file and quit (‘:wq!’). Logout of the vSphere supervisor cluster (‘kubectl-vsphere’) and into your Tanzu Kubernetes Cluster.

Querying the SC with TKG should now list the SC as default.

Success!

I hit this as an issue trying to deploy resources via Helm and Kubeapps – where some charts appear to reference ‘defaultClass’ unless this is manually specified. Setting the defaultStorage class fixed these issues for me in both.

Thanks

Simon