Skip to main content

Setup an NFS client provisioner in Kubernetes

Setup an NFS client provisioner in Kubernetes

One of the most common needs when deploying Kubernetes is the ability to use shared storage. While there are several options available, one of the most commons and easier to setup is to use an NFS server.
This post will explain how to setup a dynamic NFS client provisioner on Kubernetes, relying on an existing NFS server on your systems.

Step 1. Setup an NFS server (sample for CentOS)

First thing you will need, of course, is to have an NFS server. This can be easily achieved with some easy steps:

  • Install nfs package: yum install -y nfs-utils
  • Enable and start nfs service and rpcbind:
    systemctl enable rpcbind
    systemctl enable nfs-server
    systemctl start rpcbind
    systemctl start nfs-server

  • Create the directory that will be shared by NFS, and change the permissions:
    mkdir /var/nfsshare
    chmod -R 755 /var/nfsshare
    chown nfsnobody:nfsnobody /var/nfsshare

  •  Share the NFS directory over the network, creating the /etc/exports file:
    vi /etc/exports
    /var/nfsshare * (rw,sync,no_root_squash,no_all_squash)
  • Restart the nfs service to apply the content:
    systemctl restart nfs-server
  • Add NFS and rpcbind services to firewall:
    firewall-cmd --permanent --zone=public --add-service=nfs
    firewall-cmd --permanent --zone=public --add-service=rpcbind
    firewall-cmd --reload

    The NFS server is now ready to be used

Step 2. Install NFS client provisioner

To achieve that, we will rely on Kubernetes external storage provisioner ( . An external provisioner is a dynamic volume provisioner, whose code lives outside kubernetes code.
It relies on an StorageClass object, that defines the external provisioner instance. Then, that instance will wait for PersistentVolumeClaims asking for that specific StorageClass, and will automatically create PersistentVolumes.
In that case we are relying on NFS-client provisioner ( , that will provide those volumes, relying on an existing NFS server.

In order to use that, several steps are needed:
  • Clone the external-storage repository and switch to the nfs-client folder:
    git clone
    cd external-storage/nfs-client
  • Customize the deploy/class.yaml file, to give a custom provisioner name to your instance:
    kind: StorageClass
      name: managed-nfs-storage
    provisioner: fuseim.pri/ifs # or choose another name, must match deployment's env PROVISIONER_NAME'
      archiveOnDelete: "false"
  • Customize the deploy/deployment.yaml file, to specify the location and folder for your NFS server, and to give the right provisioner name:
    kind: ServiceAccount
      name: nfs-client-provisioner
    kind: Deployment
    apiVersion: extensions/v1beta1
      name: nfs-client-provisioner
      replicas: 1
        type: Recreate
          app: nfs-client-provisioner
         serviceAccountName: nfs-client-provisioner
           - name: nfs-client-provisioner
               - name: nfs-client-root
                 mountPath: /persistentvolumes
               - name: PROVISIONER_NAME
                 value: fuseim.pri/ifs
    # or choose another name, must match
               - name: NFS_SERVER
                 value: <<IP_OF_YOUR_NFS_SERVER>>
               - name: NFS_PATH
                 value: <<PATH_TO_NFS_SHARED_FOLDER>>
           - name: nfs-client-root
               server: <<IP_OF_YOUR_NFS_SERVER>>
               path: <<PATH_TO_NFS_SHARED_FOLDER>>
               apiVersion: v1
  • Create the objects into your kubernetes cluster:
    kubectl create -f deploy/rbac.yaml
    kubectl create -f deploy/class.yaml
    kubectl create -f deploy/deployment.yaml
  • To actually start testing the system, you will need to create a PersistentVolumeClaim using that StorageClass. Then you will need to create a pod that uses this PersistentVolumeClaim:
    kind: PersistentVolumeClaim
    apiVersion: v1
      name: test-claim
      annotations: "managed-nfs-storage"
        - ReadWriteMany
          storage: 1Mi

    kind: Pod

    apiVersion: v1
      name: test-pod
       - name: test-pod
           - "/bin/sh"
           - "-c"
           - "touch /mnt/SUCCESS && exit 0 || exit 1"
           - name: nfs-pvc
             mountPath: "/mnt"
    restartPolicy: "Never"
       - name: nfs-pvc
           claimName: test-claim

    kubectl create -f deploy/claim.yaml
    kubectl create -f deploy/pod.yaml
    You can see that the pods can be started now with NFS volumes that are dynamically provisioned, relying on your existing NFS server installation.


  1. I've got a great kubernetes interview guide here

  2. Thank you so much for this nice information. Hope so many people will get aware of this and useful as well. And please keep update like this.

    Big Data Services

    Data Lake Services

    Advanced Analytics Solutions

    Full Stack Development Services

  3. Few people are very much confused to make a clear picture of machine learning in their mind. This is the reason why they have different opinions for machine learning in both good and bad sense. Now it all depends upon machine learning development services and their output.

  4. Really it is very useful for us..... the information that you have shared is really useful for everyone.Nice article i have ever read information's like's really awesome the way you have delivered your ideas.i hope you will add more content in your blog PHP Training in Chennai | Certification | Online Training Course | Machine Learning Training in Chennai | Certification | Online Training Course | iOT Training in Chennai | Certification | Online Training Course | Blockchain Training in Chennai | Certification | Online Training Course | Open Stack Training in Chennai |
    Certification | Online Training Course


Post a Comment

Popular posts from this blog

Create and restore external backups of virtual machines with libvirt

A common need for deployments in production, is to have the possibility of taking backups of your working virtual machines, and export them to some external storage.
Although libvirt offers the possibility of taking snapshots and restore them, those snapshots are intended to be managed locally, and are lost when you destroy your virtual machines.
There may be the need to just trash all your environment, and re-create the virtual machines from an external backup, so this article offers a procedure to achieve it.
First step, create an external snapshot So the first step will be taking an snapshot from your running vm. The best way to take an isolated backup is using blockcopy virsh command. So, how to proceed?

1. First you need to extract all the disks that your vm has. This can be achieved with domblklist command:
DISK_NAME=$(virsh domblklist {{domain}} --details | grep 'disk' | awk '{print $3}')

This will extract the name of the device that the vm is using (vda, hda, et…

Automating local mirrors creation in RHEL

Sometimes there is a need to consume RHEL mirrors locally, not using the Red Hat content delivery network. It may be needed to speed up some deployment, or due to network constraints.

I create an ansible playbook, rhel-local-mirrors (, that can help with that.
What does rhel-local-mirrors do? It is basically a tool that connects to the Red Hat CDN, and syncs the repositories locally, allowing to populate the desired mirrors, that can be accessed by other systems via HTTP.

The playbook is performing several tasks, that can be run together or independently:
register a system on the Red Hat Networkprepare the system to host mirrorscreate the specified mirrorsschedule automatic updates of the mirrors How to use it?It is an Ansible playbook, so start by installing it, in any prefered format. Then continue by cloning the playbook:
git clone playbook expects a group of servers called