Pending status of the PVCs could mean you have no corresponding PVs. If you use a PersistentVolumeClaim you typically need a volume provisioner for Dynamic Volume Provisioning
Unless you configure your cluster with dynamic volume provisioning , you will have to make the PV manually each time.
You have to define a PersistentVolume providing disk space to be consumed by the PersistentVolumeClaim. PersistentVolumeClaims will remain unbound indefinitely if a matching PersistentVolume does not exist.
When using storageClass Kubernetes is going to enable "Dynamic Volume Provisioning" which is not working with the local file system.
Dynamic volume provisioning allows storage volumes to be created on-demand. Without dynamic provisioning, cluster administrators have to manually make calls to their cloud or storage provider to create new storage volumes, and then create PersistentVolume objects to represent them in Kubernetes.
To solve your issue:
- Provide a PersistentVolume fulfilling the constraints of the claim (a size >= 100Mi).
- Remove the storageClass from the PersistentVolumeClaim or provide it with an empty value ("").
- Remove the StorageClass from your cluster.
Also make sure that PV capacity >= PVC capacity then PVC should be bound to PV. The capacity in the PV needs to be the same as in the claim to fix the unbound immediate PersistentVolumeClaims issue. If not then we'll get the unbound immediate PersistentVolumeClaims error in the pod level and no volume plugin matched name when describing the PVC.
Refer Configure a Pod to Use a PersistentVolume for Storage which describes how to create a PersistentVolume with a hostPath and refer stackpost for more information on pod has unbound PersistentVolumeClaims error.