The NFS subdir external provisioner dynamically creates a subdirectory for each PVC on an existing NFS export. This guide validates the export, installs the maintained Helm chart, creates a claim, and tests multi-Pod persistence.
1. Prepare and execute
Confirm the active kubeconfig context and namespace before applying changes. Save commands and manifests in version control without credentials.
showmount -e 10.0.0.20
sudo apt install -y nfs-common
sudo mount -t nfs 10.0.0.20:/srv/k8s /mnt
touch /mnt/.write-test && rm /mnt/.write-test
sudo umount /mnt
helm repo add nfs-subdir-external-provisioner
https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
helm repo update
helm upgrade --install nfs-client nfs-subdir-external-provisioner/nfs-subdir-external-provisioner
-n nfs-provisioner --create-namespace
--set nfs.server=10.0.0.20 --set nfs.path=/srv/k8s
--set storageClass.name=nfs-client
2. Declarative configuration
Save the following example in a clearly named YAML file, review it, then use server-side dry-run when the API is available.
apiVersion: v1
kind: PersistentVolumeClaim
metadata: {name: shared, namespace: default}
spec:
accessModes: [ReadWriteMany]
storageClassName: nfs-client
resources: {requests: {storage: 1Gi}}
3. Verify the result
A successful command is not enough. Inspect resource state, conditions, events, endpoints, logs, and an end-to-end request where applicable.
kubectl -n nfs-provisioner rollout status deployment/nfs-client-nfs-subdir-external-provisioner
kubectl apply -f nfs-pvc.yaml
kubectl get pvc,pv
kubectl describe pvc shared
4. Troubleshooting
Provisioning errors are normally visible in provisioner logs and PVC events. Validate server reachability, export permissions, root-squash behavior, node NFS client packages, and firewall ports.
5. Rollback and cleanup
Review the exact target before deleting resources, especially namespaces, claims, Secrets, and cluster-wide add-ons.
kubectl delete -f nfs-pvc.yaml
helm uninstall nfs-client -n nfs-provisioner
Production checklist
- The active context, namespace, and target version were verified.
- Manifests passed client or server-side validation.
- Resource conditions and recent events show no unresolved error.
- Access, network exposure, resource limits, persistence, and rollback were reviewed.
- Commands and expected output were recorded for the operating team.
References: topic documentation and Kubernetes documentation.
