Kubernetes NFS PersistentVolumes: Remote storage explained

Both emptyDir and hostPath have the same fundamental limitation: the data is tied to a specific node. If a pod is rescheduled to a different node, it no longer has access to the data it wrote previously. For production workloads, this is not acceptable.

Remote storage solves this problem. A remote volume lives outside the Kubernetes cluster entirely, on a separate server or storage system. When a pod mounts a remote volume and is later rescheduled to a different node, it reconnects to the same storage and finds the same data. The pod's location in the cluster is irrelevant.

NFS (Network File System) is one of the most common remote storage options. It is simple to set up, widely supported, and provides ReadWriteMany access mode, meaning multiple pods across different nodes can mount and write to the same volume simultaneously.

The recommended pattern for using NFS in Kubernetes is to create a PersistentVolume backed by the NFS server, then claim storage via a PVC. This abstracts the NFS server details away from the application developer.

Prerequisites

Before running this demo, ensure:

• An NFS server is running and reachable from all cluster nodes
• The shared path is exported with appropriate permissions on the NFS server
• The nfs-common package is installed on all cluster nodes (Debian/Ubuntu):

1sudo apt-get install -y nfs-common

On RHEL/CentOS, install nfs-utils instead:

1sudo yum install -y nfs-utils

Without the NFS client packages installed on the nodes, pods will fail to mount the volume and the pod will stay in a waiting state.

Static vs dynamic NFS provisioning

This page covers static provisioning: the NFS server details are known upfront and the PersistentVolume is created manually. This is straightforward and works well when you have a single NFS server and a small number of volumes to manage.

For self-service NFS storage where developers can request volumes on demand via a StorageClass, see the dynamic provisioning guide, which covers using nfs-subdir-external-provisioner to provision NFS-backed PVs automatically.

Step 1: Create the PersistentVolume

Replace <nfs-server-ip> with the IP address of your NFS server and <shared-path> with the exported directory path.

1apiVersion: v1
2kind: PersistentVolume
3metadata:
4  name: pv-nfs
5spec:
6  storageClassName: manual
7  capacity:
8    storage: 1Gi
9  accessModes:
10  - ReadWriteMany
11  nfs:
12    server: <nfs-server-ip>
13    path: <shared-path>

1kubectl create -f pv.yaml

Step 2: Create the PersistentVolumeClaim

1apiVersion: v1
2kind: PersistentVolumeClaim
3metadata:
4  name: pvc-nfs
5spec:
6  storageClassName: manual
7  accessModes:
8  - ReadWriteMany
9  resources:
10    requests:
11      storage: 1Gi

1kubectl create -f pvc.yaml

Verify both are bound:

1kubectl get pv,pvc

Expected output:

1NAME                      CAPACITY   ACCESS MODES   STATUS   STORAGECLASS
2persistentvolume/pv-nfs   1Gi        RWX            Bound    manual
3
4NAME                           STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS
5persistentvolumeclaim/pvc-nfs  Bound    pv-nfs    1Gi        RWX            manual

The PVC binds immediately without waiting for a pod. With static provisioning there is no WaitForFirstConsumer binding mode. The PV and PVC match on StorageClass name and access mode and bind straight away.

Step 3: Create a pod that uses the PVC

This pod mounts the NFS volume at /mnt and writes memory information to a file:

1apiVersion: v1
2kind: Pod
3metadata:
4  name: pod-using-nfs
5spec:
6  volumes:
7  - name: nfs-volume
8    persistentVolumeClaim:
9      claimName: pvc-nfs
10  containers:
11  - name: alpine
12    image: alpine
13    command: ["sh", "-c", "cat /proc/meminfo > /mnt/memory.txt && while true; do sleep 3600; done"]
14    volumeMounts:
15    - mountPath: /mnt
16      name: nfs-volume

1kubectl create -f pod.yaml
2kubectl get pods

Expected output:

1NAME            READY   STATUS    RESTARTS   AGE
2pod-using-nfs   1/1     Running   0          10s

Step 4: Verify the data

Exec into the pod:

1kubectl exec -it pod-using-nfs -- sh

Navigate to the mount path and check the file:

1cd /mnt
2ls

Expected output:

1memory.txt

1cat memory.txt

The file contains memory information written by the container. The same file is simultaneously visible on the NFS server at the shared path. If the pod is deleted and recreated on a different node, it will reconnect to the same NFS share and find the file still there.

Why remote storage matters for production

emptyDir data is lost when the pod is deleted. hostPath data stays on a specific node and is inaccessible if the pod moves. NFS and other remote storage options decouple data from both pod and node lifecycle. Even if the entire Kubernetes cluster is lost, the data on the NFS server remains intact and recoverable.

This makes remote storage the right choice for any workload where data must survive pod restarts, rescheduling, or cluster failures.