Persistent Volume Claims (PVC) remain in "Pending" state due to missing StorageClass

Products

• VMware Telco Cloud Automation

Issue/Introduction

• Persistent Volume Claims (PVCs) fail to bind and remain in a Pending state.
• Describing the affected PVC reveals events or messages indicating the StorageClass is missing.
• Example error/event: storageclass.storage.k8s.io ### not found
• Listing available StorageClasses confirms that the specific class defined in the PVC does not exist in the cluster.

Environment

3.2

Cause

The StorageClass specified in the PVC's storageClassName field does not exist in the Kubernetes cluster. This prevents the provisioner from dynamically creating the Persistent Volume (PV).

Resolution

To resolve this issue, the missing StorageClass must be created. If a similar valid StorageClass exists (such as the default vsphere-sc), its configuration can be used as a template.

1. Verify the missing StorageClass: Run the following command to confirm the StorageClass defined in the PVC is missing:
   

   kubectl get sc

2. Export configuration from an existing StorageClass: Identify a working StorageClass (e.g., vsphere-sc) and export its YAML configuration:
   

   kubectl get sc vsphere-sc -o yaml > new-sc.yaml

3. Modify the configuration: Edit the new-sc.yaml file. Change the name in the metadata section to match the missing StorageClass name. Ensure the provisioner (e.g., csi.vsphere.vmware.com) and parameters are correct for your storage requirements.
   

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name:    # <--- Update this to the required name
   provisioner: csi.vsphere.vmware.com
   parameters:
     storagePolicyName: "Tanzu Storage Policy"

4. Apply the new StorageClass: Create the new StorageClass using the modified YAML:
   

   kubectl apply -f new-sc.yaml

5. Verify PVC Binding Check the status of the PVCs. They should now transition from Pending to Bound:
   

   kubectl get pvc