Missing StorageClass on vSphere Supervisor Workload Cluster after adding new Storage policy to Namespace

Products

• VMware vSphere Kubernetes Service

Issue/Introduction

After adding new storage policy to a Namespace, the equivalent StorageClass is present in the Supervisor cluster context.

kubectl get storageclasses -A

However, it does not show up in the Workload Cluster context when you run the command:

kubectl get storageclasses -A

Environment

vSphere Supervisor 8.0 and higher

Cause

When describing the affected workload cluster, the following storageClasses or availableStorageClasses parameter is present:

v1beta1 Clusters

Clusters using v1beta1 and tanzukubernetescluster cluster class use storageClasses

    name: storageClasses
    value:
      - <storage class>

See Cluster v1beta1 Documentation for details.

 

ClusterClass 3.2.0 and higher

Clusters using clusterclass version 3.2.0 and higher use availableStorageClasses

variables:
- name: vsphereOptions
  value:
    persistentVolumes:
      availableStorageClasses:
      - <storage class>

See ClusterClass 3.2.0+ Documentation on availableStorageClasses for details.

 

As per documentation, this storageClasses parameter limits the storage classes made available in the corresponding workload cluster to only the storage classes noted under this parameter.

Without this storageClasses parameter, any new storage class added to the corresponding namespace is automatically made available in the workload clusters associated with the namespace.

Resolution

The storage classes parameter will need to be edited to add the desired storage class(es) or it can be removed to allow for any storage classes to be available in the namespace's workload clusters.

 

Workaround A - Add Additional Storage Class(es)

1. Connect into the Supervisor cluster context
   
   
2. Edit the affected workload cluster that has the storage classes parameter and add the desired storage class(es):

   v1beta1 or tanzukubernetescluster

   kubectl edit cluster -n <workload cluster namespace> <workload cluster name>
   
   - name: storageClasses
   value:
   - <storage class A>
   

   CHANGE TO:

   - name: storageClasses
   value: [<storage class A>, <storage class B>]

   
   ClusterClass 3.2.0 and higher
   

   kubectl edit cluster -n <workload cluster namespace> <workload cluster name>
   
   variables:
   - name: vsphereOptions
     value:
       persistentVolumes:
         availableStorageClasses:
         - <storage class>

   CHANGE TO:
   

   variables:
   - name: vsphereOptions
     value:
       persistentVolumes:
         availableStorageClasses:
         - <storage class A>
         - <storage class B>

    

3. Connect into the affected workload cluster's context
   
   
4. Confirm that all storage classes listed under storageClasses parameter are present:

   kubectl get storageclasses -A

 

Workaround B - Remove the StorageClasses Section

1. Connect into the Supervisor cluster context
   
   
2. Edit the affected workload cluster that has the storage classes parameter and remove the storageClasses section:

   v1beta1 or tanzukubernetescluster

   kubectl edit cluster -n <workload cluster namespace> <workload cluster name>
   
   - name: storageClasses
     value:
       - <storage class>

   
   ClusterClass 3.2.0 and higher

   kubectl edit cluster -n <workload cluster namespace> <workload cluster name>
   
         availableStorageClasses:
         - <storage class>

    

3. Connect into the affected workload cluster's context
   
   
4. Confirm that all storage classes attached to the namespace are present:

   kubectl get sc -A
   

Additional Information

See Cluster v1beta1 Documentation for details on storageClasses parameter.

See ClusterClass 3.2.0+ Documentation for details on availableStorageClasses section.

 

Storage classes cannot be created through YAML and instead must be created through the vSphere web UI as a corresponding storage policy.