PVC bound but not ready

[zazim13]

I have been experiencing some issues with volumes that cause pending pods. Sometimes Persistent Volume Claims(pvc) are not associated with their corresponding Persistent Volume(pv) and are pending with the following warning (from kubectl describe pvc pvc_name) Warning ProvisioningFailed 1s (x18 over 4m2s) persistentvolume-controller storageclass.storage.k8s.io "default" not found

The fact is that the remaining persistent volumes doesn't fits the persistent volume claim requirements. As the output of kubectl get pvc shows:

  NAME                     STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mongodb-data             Bound     foo-pv4   5Gi        RWO,ROX,RWX    default        8m7s
videoserver-logs         Bound     foo-pv3   1Gi        RWO,ROX,RWX    default        8m7s
videoserver-video        Bound     foo-pv2   5Gi        RWO,ROX,RWX    default        8m7s
videoserver-videofiles   Pending                                       default        8m7s

You can see that the last pvc videoserver-videofiles (reclaiming at least 5Gi as shown here ) that should claim the pv foo-pv4 (as you can see here) is pending. while foo-pv4 is already associated with the pvc mongodb-data.

It must be a matter of scheduling cause redeploying the cluster several times can solve the problem.

Note: Here the output of kubectl get pv

NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                       STORAGECLASS   REASON   AGE
foo-pv    512M       RWO,ROX,RWX    Retain           Available                               default                 6m11s
foo-pv2   5Gi        RWO,ROX,RWX    Retain           Bound       default/videoserver-video   default                 6m11s
foo-pv3   1Gi        RWO,ROX,RWX    Retain           Bound       default/videoserver-logs    default                 6m11s
foo-pv4   5Gi        RWO,ROX,RWX    Retain           Bound       default/mongodb-data        default                 6m11s

Note2: I am using local volumes

[zazim13]

One solution could be to add for each pvc in the pvcs configuration file (deployment/vp-cloud/templates/06-pvc.yaml), the name of the corresponding pv that it should claim. We can do it by adding the key volumeName. And we shall obtain such file:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: videoserver-videofiles
spec:
  storageClassName: {{.Values.storageClassName}}
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  volumeName: foo-pv4
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: videoserver-logs
spec:
  storageClassName: {{.Values.storageClassName}}
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  volumeName: foo-pv3
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: videoserver-video
spec:
  storageClassName: {{.Values.storageClassName}}
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  volumeName: foo-pv2
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mongodb-data
spec:
  storageClassName: {{.Values.storageClassName}}
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 512M
  volumeName: foo-pv

[aleskandro]

Apparently foo-pv4 is bound to mongodb-data.

foo-pv4   5Gi        RWO,ROX,RWX    Retain           Bound       default/mongodb-data        default                 6m11s

Could we create a new persistent-volume, foo-pv5, and also bind the videoserver-videofiles PVC to foo-pv5 ? Finally note that we'd keep the requested capacity and the bound PV capacity equal

[zazim13]

Adding the key volumeName solved the issue for me. But I don't know if it is working with other type of pv provisioning. (I am doing local provisioning)
Should I commit this change anyway ? I don't know if adding a new pv will solve the issue at deployment as some pv could still be bound to the wrong pvc.