Good-bye, nfs-subdir-external-provisioner ! Hello, csi-driver-nfs !
SAS Viya needs shared storage and the most common way to provide shared storage for a deployment of SAS Viya in Kubernetes is to rely on an NFS Server.
From the beginnings of SAS Viya, the recommended way to expose the NFS Server to SAS Viya in Kubernetes was to use the "NFS subdir external provisioner" (which corresponds to this open-source project).
From SAS Viya 2025.06, though, the "Hardware and Resource Requirements" section of the SAS documentation has been updated and now references the "NFS CSI Driver for Kubernetes" (CSI plugin name: nfs.csi.k8s.io) instead of the "NFS subdir external provisioner".
In parallel, the viya4-deployment project (aka "DaC" for "Deployment as Code") recently updated the NFS provisioner from the nfs-subdir-external-provisioner to the csi-driver-nfs provisioner. The change in the DaC project and was released with the v9.0.0 version.
In this post, we'll explore the "why?" and "how?" questions related to this change.
Why ?
While it has been very helpful for years, the nfs-subdir-external-provisioner project is now outdated, unmaintained and has known vulnerabilities.
A visit on the GitHub repository confirms that no new release for this open-source software has been produced since March 2023 :
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
Here is a screenshot from a security scan of the nfs-subdir-external-provisioner image:
We can see that several vulnerabilities have been identified for this image…
However a new open-source tool that could provide the same functionality was identified by SAS and it is called the NFS CSI Driver.
Here is a screenshot of the associated GitHub repository page :
Looking at the release dates, we can see that the project is way more active, with new releases published approximatively every 3 months.
How ?
Now the question is how to install this new NFS CSI Driver tool ?
Install the csi-driver-nfs with the DaC
Historically, the DaC (viya4-deployment project) code offers a "baseline" option to deploy the SAS Viya deployment pre-requisites (which include the NFS provisioner).
At the time of this write up, the DaC tool already has the code to install the new NFS CSI driver (which is located in the roles/baseline/tasks/nfs-csi-provisioner.yaml YAML file).
It could be a breaking change in the environment for a customer having deployed with an older DaC version, who wants to update to the version that install the new NFS provisioner. So before the csi-driver-nfs code was pushed in release v9.0.0, additional guidance for the customers already running a "DaC-deployed" environment has been added.
If you update from an earlier DaC version than v9.0.0 to a new one, make sure you read this page before running the "baseline" playbook again.
Install the csi-driver-nfs manually
For those who don’t use the DaC (viya4-deployment) tool to deploy SAS Viya and/or the pre-requisites (baseline), it is possible to run the Helm commands directly to install the csi-driver-nfs application.
Here is an example :
helm repo add csi-driver-nfs https://raw.githubusercontent.com/kubernetes-csi/csi-driver-nfs/master/charts
helm repo update
helm install csi-driver-nfs-sas \
--set driver.mountPermissions="0777" \
--set storageClass.create=true \
--set storageClass.name="sas-csi-nfs" \
--set storageClass.reclaimPolicy=Delete \
--set storageClass.volumeBindingMode=Immediate \
--namespace kube-system \
--version 4.11.0 \
--set storageClass.parameters.server=${NFSIP} \
--set storageClass.parameters.share=/export \
--set storageClass.parameters.subdir=\${pvc.metadata.namespace}/\${pvc.metadata.name}/\${pv.metadata.name} \
--set storageClass.mountOptions="{noatime,nodiratime,rsize=262144,wsize=262144,vers=4.1}" \
csi-driver-nfs/csi-driver-nfs
If the Helm installation is successful, you should see this, when you list the storage classes:
Notice the storageClass.parameters.subdir option that lets you specify how you want to organize the structure and names of the folders for the data stored in the Persistent Volumes.
It means that if we, now, create a new Persistent Volume Claim using the sas-csi-nfs storage class, a folder with the "Persistence Volume name" is created under a folder with the with the "Persistence Volume Claim name", itself under a folder with PVC namespace, under the /export root folder on the NFS server.
For example it would look like that:
However for a customer already running a Viya environment with the “old” NFS subdir-external provisioner, what would be the impact of switching from the "old" version to the new csi-driver-nfs ?
Switching from "nfs-subdir-external-provisioner" to "csi-driver-nfs"
So what are the steps to switch from the nfs-subdir-external-provisioner to the NFS CSI Driver and what is the impact on the volumes for an existing environment ?
We have explored this scenario in the "Appendix" section below.
Basically :
- We stopped the environment,
- Deleted the existing Storage Class associated to the old NFS provisioner,
- Installed the new NFS CSI Driver and attach it to the Storage Class name (used by SAS Viya)
- Restarted the environment.
and it turns out that there are NO impact at all on the existing Persistent Volumes : they are left untouched and are still mounted as when they were initially created with the old nfs-subdir-external-provisioner. The data remains there and the Kubernetes pods are still pointing to the same physical location on the NFS host for the existing Persistent Volume. As far as Viya knows, it should find its data right where it left it.
The reason is that in Kubernetes, a PersistentVolume (PV) has immutable properties which includes the volume ID, after creation. This means you cannot modify the volume's underlying storage details (like the specific disk or location) after it's been created.
So when we follow the procedure above, we are not really changing anything for what already exists in the environment. While there is now a new NFS provisioner installed and configured in the environment, it is not used for the existing Persistent Volumes.
If we wanted to truly move from using the old NFS provisioner to using the new NFS CSI driver, then we would need to DELETE and recreate all the PVs with the new provisioner. In such case we would need a way to recover what already existed in the PVs (either using backup/restore or setting the PV reclaim policy to RETAIN)...but I haven't tested any of these scenarios.
Observed differences
So what are the technical differences between the old NFS provisioner and the new one ? In one of the https://github.com/kubernetes-csi discussion, I found this comment with a pretty good answer to the question :
"nfs-subdir-external-provisioner use the in-tree NFS support, meaning it just creates PV's with .spec.nfs populated. Kubernetes natively supported many different kinds of storage (Ceph RBD, AWS EBS and other cloud specific storage). That supports is now getting moved out of core kubernetes into "drivers" which projects can support on their own, where the CSI standard says what the control plane will require of you. In simple terms the CSI driver calls mount instead of core kubernetes/kubelet itself."
Then it is explained that while the "in-tree" NFS support will not be removed for now, there are still some advantages such as the Volume snapshot support, and future extra features (such as NFS authentication with credentials, etc.).
Here are some other differences that we’ve noticed in our tests:
- In the Helm installation command, the quotes around mount parameters (such as rsize, wsize or vers) can cause problems with the CSI driver installation (while it does not with the NFS subdir provisioner).
- Options to organize the PV content in the NFS subfolders
- Default behavior with the nfs-subdir-external-provisioner :
- <NFS path>/<pvc namespace>-<pvc name>-<pv name>
- Example:
- Default behavior with the nfs-subdir-external-provisioner :
-
-
- However you can change this behavior with the pathPattern option
-
-
- Default behavior with the CSI driver:
- <NFS path>/<pv name>
- Example:
- Default behavior with the CSI driver:
-
-
- However you can easily change this behavior with the subdir option
-
- More pods !
- While there was only one pod (with one container) created as part of the nfs-subdir-external provisioner, (as shown below),
- The CSI driver setup creates many more of them, the NFS controller pod is managed by a ReplicaSet, while other pods are managed by a Daemonset object and run on each node.
Conclusion
If you are about to deploy a brand new SAS Viya environment, make sure you install the new recommended CSI NFS Driver.
If you are working in an environment where the old NFS subdir-external-provisioner has already been used to create and expose the Persistent Volumes, then switching to the new NFS CSI Driver does not change anything (until you create or recreate PVs).
Some lessons learned and recommendations:
- Choose carefully your subdir (don’t choose the default values if you want to be able to easily identify the content of your Persistent volumes),
- Switching to the new CSI NFS driver doesn't change anything for your existing Persistent Volumes (until you start to use your new NFS provisioner to create new Persistent Volumes).
- Finally, you should also set at least 2 replicas for your CSI controller for better availability (in this case make sure that you have at least 2 nodes where the CSI Controller pods can be scheduled separately).
Special Thanks go to my colleagues, Rob Collum and Mike Goddard for sharing their findings on this topic and their collaboration in this post.
References
Find more articles from SAS Global Enablement and Learning here.
