nfs-subdir-external-provisioner: unable to successfully deploy PVC on raspberry pi

Hi,

I am trying to deploy nextcloud on k3s and store my data on a nfs-share.

I already setup the k3s on a (for now) single raspberry pi via k3s-ansible which worked perfectly fine. I tried to setup a PV+PVC for a NFS share and eventually found that I should use this nfs provisioner.

I have

setup a NFS mount (verified via showmount -e IP) and was able to mount it manually via mount.nfs and mount -t nfs
cloned this repository
modified deploy/helm/values.yaml (nfs.server, nfs.path, repository: quay.io/external_storage/nfs-client-provisioner-arm)
also changed kubeVersion to “>=1.9.0 <1.21.0” in deploy/helm/Chart.yaml because k3s version is “v1.20.0+k3s2”
deployed the helm chart in a namespace “nfs”

The deployment seems to be working fine. When I try to deploy deploy/test-claim.yml all I get is

Normal ExternalProvisioning 4m33s (x263 over 69m) persistentvolume-controller waiting for a volume to be created, either by external provisioner “fuseim.pri/ifs” or manually created by system administrator

$ kubectl describe deployment nfs-subdir-external-provisioner -n nfs
Name:               nfs-subdir-external-provisioner
Namespace:          nfs
CreationTimestamp:  Wed, 13 Jan 2021 19:31:07 +0100
Labels:             app=nfs-subdir-external-provisioner
                    app.kubernetes.io/managed-by=Helm
                    chart=nfs-subdir-external-provisioner-3.0.0
                    heritage=Helm
                    release=nfs-subdir-external-provisioner
Annotations:        deployment.kubernetes.io/revision: 1
                    meta.helm.sh/release-name: nfs-subdir-external-provisioner
                    meta.helm.sh/release-namespace: nfs
Selector:           app=nfs-subdir-external-provisioner,release=nfs-subdir-external-provisioner
Replicas:           1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:       Recreate
MinReadySeconds:    0
Pod Template:
  Labels:           app=nfs-subdir-external-provisioner
                    release=nfs-subdir-external-provisioner
  Service Account:  nfs-subdir-external-provisioner
  Containers:
   nfs-subdir-external-provisioner:
    Image:      quay.io/external_storage/nfs-client-provisioner-arm:v3.1.0-k8s1.11
    Port:       <none>
    Host Port:  <none>
    Environment:
      PROVISIONER_NAME:  cluster.local/nfs-subdir-external-provisioner
      NFS_SERVER:        192.168.0.227
      NFS_PATH:          /mnt/data
    Mounts:
      /persistentvolumes from nfs-subdir-external-provisioner-root (rw)
  Volumes:
   nfs-subdir-external-provisioner-root:
    Type:      NFS (an NFS mount that lasts the lifetime of a pod)
    Server:    192.168.0.227
    Path:      /mnt/data
    ReadOnly:  false
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nfs-subdir-external-provisioner-598475ff9b (1/1 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  65s   deployment-controller  Scaled up replica set nfs-subdir-external-provisioner-598475ff9b to 1

$ kubectl describe pvc test-claim -n nfs
Name:          test-claim
Namespace:     nfs
StorageClass:  nfs-client
Status:        Pending
Volume:        
Labels:        <none>
Annotations:   volume.beta.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  7s (x3 over 12s)  persistentvolume-controller  waiting for a volume to be created, either by external provisioner "cluster.local/nfs-subdir-external-provisioner" or manually created by system administrator

I tried to deploy without helm but still the same issue

Thank you for your help and sorry if I am missing any information. Quite new to the k8s universe 😉

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 20 (6 by maintainers)

Most upvoted comments

I had the same issue with not being able to run the Docker image on a Raspberry Pi 4. For anyone else stuck on this, this is how I was able to build the 32-bit ARM image in a clone of this repository:

$ make build BUILD_PLATFORMS="linux arm"
$ DOCKER_CLI_EXPERIMENTAL=enabled docker buildx build --tag nfs-subdir-external-provisioner:arm-linux-canary --platform=linux/arm --file Dockerfile --build-arg binary=./bin/nfs-subdir-external-provisioner  .
# last command is optional - import the image to target node running k3s if you don't have any image registry
$ docker save nfs-subdir-external-provisioner:arm-linux-canary | ssh PI_HOSTNAME sudo ctr i import -

@kmova for a permanent solution I would also like to ask to extend BUILD_PLATFORMS with linux arm.

tomasz-kuzemko on Feb 13, 2021

Thanks @hamid-elaosta. I used the multi-arch build in this fork https://github.com/groundhog2k/nfs-subdir-external-provisioner to check and it worked.

neinkeinkaffee on Feb 7, 2021

I have a similar problem setup as @bohnejoe in that I want to use the nfs storage provisioner for persistence in my k3s Raspberry Pi 4 cluster. When I deploy the provisioner on k3s with gcr.io/k8s-staging-sig-storage/nfs-subdir-external-provisioner:arm64-linux-v4.0.0 I get an exec format error. It might be due to the fact that most OS for the Raspberry Pi 4 are still 32-bit, including Raspbian OS Buster that I am using. Would be it be possible to add arm7 linux to BUILD_PLATFORMS?

neinkeinkaffee on Feb 7, 2021

@kmova arm7 is 32bit, what does it take to add it to the BUILD_PLATFORMS and multi-arch image?

yonatankahana on Feb 5, 2021