When several application pods need access to the same files, they need storage that can serve those files across machines. NFS server provisioner packages a Network File System server and a controller that creates storage for Kubernetes volume requests. Unlike a client provisioner, it supplies the server as well as the connection to it. That makes the server’s own durable storage, backups and availability central to the design: shared access does not create independent copies of the data.
Current guidance
The Kubernetes SIG Storage continuation publishes the NFS Ganesha server and external provisioner chart. Its README explicitly says the package includes a built-in NFS server and is not intended to connect to an existing one. That distinction matters when choosing between this project, an NFS client provisioner and an NFS CSI driver.
The same README warns that the default deployment does not make provisioned data persistent. Configure and verify the backing storage before treating a successfully bound PVC as durable. Its hostPath example is tied to one node and is explicitly unsuitable as a production failover design.
Review filesystem ownership, export access, reclaim policy and how server loss affects mounted applications. Test a write, server restart and restoration from an independent backup, including the client’s behavior during an outage. Do not assume that ReadWriteMany access creates multiple durable copies or that adding server replicas safely shares the same backing files. This review verifies the project continuation and storage boundaries without certifying performance, availability or a transparent migration of existing volumes.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Original publication: 2018-09-15T11:24:48+00:00. Preserved for context. Commands, versions, prices and results below reflect the original research.
nfs-provisioner is an out-of-tree dynamic provisioner for Kubernetes 1.4+. You can use it to quickly & easily deploy shared storage that works almost anywhere. Or it can help you write your own out-of-tree dynamic provisioner by serving as an example implementation of the requirements detailed in the proposal. Go here for a demo of how to use it and here for an example of how to write your own.
It works just like in-tree dynamic provisioners: a StorageClass object can specify an instance of nfs-provisioner to be its provisioner like it specifies in-tree provisioners such as GCE or AWS. Then, the instance of nfs-provisioner will watch for PersistentVolumeClaims that ask for the StorageClass and automatically create NFS-backed PersistentVolumes for them.
External Provisioners
This repository houses community-maintained external provisioners plus a helper library for building them. Each provisioner is contained in its own directory so for information on how to use one, enter its directory and read its documentation. The library is contained in the lib directory.
What is an ‘external provisioner’?
An external provisioner is a dynamic PV provisioner whose code lives out-of-tree/external to Kubernetes. Unlike in-tree dynamic provisioners that run as part of the Kubernetes controller manager, external ones can be deployed & updated independently.
External provisioners work just like in-tree dynamic PV provisioners. A StorageClass object can specify an external provisioner instance to be its provisioner like it can in-tree provisioners. The instance will then watch for PersistentVolumeClaims that ask for the StorageClass and automatically create PersistentVolumes for them.
Persistent Volumes
Managing storage is a distinct problem from managing compute. The PersistentVolume subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed. To do this we introduce two new API resources: PersistentVolume and PersistentVolumeClaim.
A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.
A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., can be mounted once read/write or many times read-only).
While PersistentVolumeClaims allow a user to consume abstract storage resources, it is common that users need PersistentVolumes with varying properties, such as performance, for different problems. Cluster administrators need to be able to offer a variety of PersistentVolumes that differ in more ways than just size and access modes, without exposing users to the details of how those volumes are implemented. For these needs there is the StorageClass resource.
The post NFS Server Provisioner appeared first on kubedex.com.
Sources & further reading
Spotted something that needs another look?
Help improve this page →