Exercise 9.5 - Dynamic provision of a volume

ilmx

I am following Exercise 9.5 but I cannot get it to work.

$ k get sc
NAME         PROVISIONER                                     RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
nfs-client   cluster.local/nfs-subdir-external-provisioner   Delete          Immediate           true                   25m

On Step 6 I don't get the PVC:

$ k get pv,pvc
NAME                            STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
persistentvolumeclaim/pvc-one   Pending

I suppose I am missing something:

$ k describe pvc
Name:          pvc-one
Namespace:     default
StorageClass:  nfs-client
Status:        Pending
...
  Normal  ExternalProvisioning  15s (x16 over 3m50s)  persistentvolume-controller  Waiting for a volume to be created either by the external provisioner 'cluster.local/nfs-subdir-external-provisioner' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered.

$ helm list
NAME                            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART
        APP VERSION
nfs-subdir-external-provisioner default         1               2024-10-13 20:54:32.64658104 +0000 UTC  deployed        nfs-subdir-external-provisioner-4.0
        4.0.2

Is there any extra step that I have missed to have a provisioner?

infoduv

Hello,

You've got the pvc => persistentvolumeclaim/pvc-one. But this pvc can't find a suitable physicalVolume. You need to create one on the nfs server.

chrispokorni

Hi @ilmx,

Make sure that NFS installation and configuration steps have been completed on both cp and worker nodes, per instructions included in lab exercise 9.2.

Also, ensure you are consistent with the naming convention of the NFS server across the entire lab 9 - so either use the k8scp alias in all steps involved, or the cp-node hostname, or simply use the cp-node private IP address; but do not mix them as they may prevent the provisioner agent from generating the necessary artifacts.

Regards,
-Chris

ilmx

Thanks for the comment but I am still not able to find the issue....

I followed 9.2. The working node can access the NSF directory:

$ showmount -e k8scp
Export list for k8scp:
/opt/sfw *

$ sudo mount k8scp:/opt/sfw /mnt

$ ls /mnt/
bigfile  default-pvc-one-pvc-d966635f-b195-462d-9030-99e13c2226ef  hello.txt

I deleted the default-pvc-one... directory just in case, but didn't help.
And I have repeated the steps with similar (un)success:

$ helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner --set nfs.server=k8scp --set nfs.path=/opt/sfw/
NAME: nfs-subdir-external-provisioner
LAST DEPLOYED: Wed Oct 16 21:15:29 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

$ kubectl get sc
NAME         PROVISIONER                                     RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
nfs-client   cluster.local/nfs-subdir-external-provisioner   Delete          Immediate           true                   9s

$ kubectl get pv,pvc -A
No resources found

$ cd lesson9/
/lesson9$ k create -f pvc-sc.yml
persistentvolumeclaim/pvc-one created

/lesson9$ kubectl get pv,pvc
NAME                            STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
persistentvolumeclaim/pvc-one   Pending                                      nfs-client     <unset>                 6s

/lesson9$ k describe pvc
Name:          pvc-one
Namespace:     default
StorageClass:  nfs-client
Status:        Pending
Volume:
Labels:        <none>
Annotations:   volume.beta.kubernetes.io/storage-provisioner: cluster.local/nfs-subdir-external-provisioner
               volume.kubernetes.io/storage-provisioner: cluster.local/nfs-subdir-external-provisioner
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode:    Filesystem
Used By:       <none>
Events:
  Type    Reason                Age               From                         Message
  ----    ------                ----              ----                         -------
  Normal  ExternalProvisioning  4s (x5 over 42s)  persistentvolume-controller  Waiting for a volume to be created either by the external provisioner 'cluster.local/nfs-subdir-external-provisioner' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered.

I am addressing the CP with the k8scp alias.

chrispokorni

Hi @ilmx,

The default-pvc-one-pvc-d966635f-b195-462d-9030-99e13c2226ef directory was the storage backend of the PV object that should have been created by the NFS provisioner. What is unclear is the reason why the PV object creation never fully finalized.

I attempted to reproduce the issue, but I am unable to. I am looking back at the earlier issues you reported and I am wondering whether all the fixes and workarounds did not eventually impact your cluster overall.

Upon launching the nfs-provisioner, any events that are out of the ordinary while the nfs-subdir-external-provisioner-... Pod is scheduled and deployed?

kubectl describe po nfs-subdir-external-provisioner-...

Assuming a new PVC launch event, while waiting for the PV backend to be provisioned and PV object created, what are the logs of the nfs-provisioner Pod recording?

kubectl logs -f nfs-subdir-external-provisioner-...

The optional -f flag will follow/stream the logs.

Regards,
-Chris