How to use NFS in Kubernetes Cluster — Method 2.
By: Fabio Fernandes
Tags: Raspberry Pi, Persistent Volume, Cluster, Nfs Server, Kubernetes

In the previous article, we talked about one of the most common methods of using an NFS Server to store data from our apps in the Kubernetes cluster.

One of the drawbacks of that method is the necessity of manually configure the folder mappings in each node before creating the Persistent Volumes. It’s tedious and sometimes more complicated to manage than it should

This article will show a second way to connect to an NFS Server, only via Persistent Volumes configuration.

General Notes

Article Series

This article is part of a series about Kubernetes using NFS Server as a source for persistent volumes. Here is the list of articles of this series:

Source Code

All the files used in this article are published in this GitHub repository: https://github.com/fabiofernandesx/k8s-volumes. Feel free to clone it or even open a pull request if you find something that needs to be fixed or added.

Home Lab

For this article series, I’ll use my raspberry pi Kubernetes cluster, but the commands should work in any environment, including cloud or virtual machines. If you are interested in seeing how to create a raspberry pi k8s cluster, you can find it here: Yet Another Raspberry Pi k8’s Cluster, or if you interested in how to create this cluster using the virtual box, you can see this one: Preparing Virtual Box VM’s to run Kubernetes.

Connecting directly to the NFS server via persistent volume configuration

Ok, let's see the second way to use NFS Server to create persistent volumes in a k8s cluster.

The only configuration we need to change here is the PV configuration itself. Let’s do a quick recap of the k8’s object configurations we need to deploy a simple website using persistent volumes:

Persistent Volume Configuration — Here, we allocate a space in the disk to be used (claimed) by our applications. It can be a local drive, a virtual space in the cloud, or, in our case, an endpoint shared by an NFS server. Namespace — Excluding the persistent volume that cannot have a namespace, all other objects can. So, for a better organization, it is always good to group things in namespaces. Persistent Claim — This configuration “binds” the persistent volume to a claim. This claim is what will be used by the deployment. Deploy — It’s the application itself, in our case, an Nginx application to demonstrate the use of the persistent volumes. This configuration makes use of the claim. Service — With our application running, we need to expose it to the world. The service makes the requests get into the containers, inside the pods. Ingress — It’s basically the entry point to our application. We can configure a port-service instead, exposing the port directly into the service configuration. But the most common case is to use DNS and ingress.

Here is the PV configuration file:

As you can see, the only difference is that we are pointing it directly to the NFS Server instead of the map/mount in the host. I also use a different name for the storage class to make sure the matching claim will be the one we want. Any name here (different than the one we used before) will work.

The other parts are very similar to the ones we created on the first method (pay attention to the storage class names)

The PVC:

The Deploy File:

The service:

And, finally, the ingress:

If something goes wrong, take a look carefully at the examples; as the configuration files are too similar is easy to mistakenly forget to change a name, a selector, or application name. Be aware that sometimes when we use the same name in 2 configurations, k8’s creates a mess, and we need to delete and recreate the instances manually to make it work.

It’s always better to check the file several times before applying it to the cluster.

After that, the only thing still missing is to copy the HTML file to the NFS server, and the site should be assessable at the address configured in the ingress file: nfs-direct.192.168.2.101.nip.io (we use the same nip.io trick I described in the previous article, check here if you don’t know what it is).

Again, I’m using scp command to send the file via ssh, but you can choose whatever method you want to copy the file into the NFS shared folder.

And that’s it. In the next article, we will finish this series by showing the most “automated” way to do these operations via storage class. This way, we will not have to even create persistent volumes anymore. The claim configuration will trigger the persistent volume creation automatically.