PersistentVolumeClaim Pending for NFS Volume

8/10/2018

What specific changes need to be made to the yaml below in order to get the PersistentVolumeClaim to bind to the PersistentVolume?

An EC2 instance in the same VPC subnet as the Kubernetes worker nodes has an ip of 10.0.0.112 and and has been configured to act as an NFS server in the /nfsfileshare path.

Creating the PersistentVolume

We created a PersistentVolume pv01 with pv-volume-network.yaml:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv01
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: "/nfsfileshare"
    server: "10.0.0.112"

and by typing:

kubectl create -f pv-volume-network.yaml

Then when we type kubectl get pv pv01, the pv01 PersistentVolume shows a STATUS of "Available".

Creating the PersistentVolumeClaim

Then we created a PersistentVolumeClaim named `` with pv-claim.yaml:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: my-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

And by typing:

kubectl create -f pv-claim.yaml

STATUS is Pending

But then when we type kubectl get pvc my-pv-claim, we see that the STATUS is Pending. The STATUS remains as Pending for as long as we continued to check back.

Note this OP is different than this other question, because this problem persists even with quotes around the NFS IP and the path.

Why is this PVC not binding to the PV? What specific changes need to be made to resolve this?

-- CodeMed
kubernetes
nfs
persistent-volume-claims
persistent-volumes

1 Answer

8/10/2018

I diagnosed the problem by typing kubectl describe pvc my-pv-claim and looking in the Events section of the results.

Then, based on the reported Events, I was able to fix this by changing storageClassName: manual to storageClassName: slow.

The problem was that the PVC's StorageClassName did not meet the requirement that it match the class specified in the PV.

-- CodeMed
Source: StackOverflow