How to Monitor NFS Subdir External Provisioner with Vigilmon (HTTP + TCP + Alerts)

The NFS Subdir External Provisioner gives Kubernetes clusters dynamic PVC provisioning backed by an existing NFS server — no manual PV creation, no storage class gymnastics. But the provisioner itself is a single-pod controller sitting between your workloads and your NFS server, and when it silently fails, PVCs stay Pending indefinitely while applications stall without any obvious error.

In this tutorial you'll set up comprehensive uptime monitoring for the NFS Subdir External Provisioner — and the NFS server underneath it — using Vigilmon — free tier, no credit card required.

Why NFS Subdir External Provisioner needs external monitoring

The provisioner has no built-in alerting. Kubernetes internal probes only tell you the provisioner pod is alive, not that it can actually reach the NFS server and create subdirectories:

• NFS server unreachable — the provisioner pod is Running but the NFS mount is stale or the server is down; new PVCs bind timeout silently
• Provisioner pod OOMKilled — the provisioner restarts silently; any PVC creation request during the restart window fails without notification
• NFS export permissions changed — an NFS server config change revokes the provisioner's write access; subdirectory creation fails, PVCs queue up
• StorageClass misconfigured after upgrade — a Helm upgrade changes the provisioner name in the StorageClass, breaking the link between PVCs and the provisioner
• NFS server disk full — the provisioner can reach the NFS share and create directory entries, but write I/O fails once the underlying disk fills

External monitoring catches the failure modes where the provisioner pod reports Running but your storage pipeline is broken.

What you'll need

• A Kubernetes cluster with the NFS Subdir External Provisioner installed (via Helm or manifest)
• An NFS server reachable from the cluster
• A free Vigilmon account (sign up takes 30 seconds)

Step 1: Expose the provisioner health endpoint and NFS server

Expose the provisioner health endpoint

The NFS Subdir External Provisioner exposes a health check on port 8080 by default. Expose it via a NodePort service:

# nfs-provisioner-healthcheck-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: nfs-provisioner-health
  namespace: nfs-provisioner
spec:
  type: NodePort
  selector:
    app: nfs-subdir-external-provisioner
  ports:
    - name: healthz
      port: 8080
      targetPort: 8080
      nodePort: 30880
      protocol: TCP

Apply it:

kubectl apply -f nfs-provisioner-healthcheck-svc.yaml

Verify the health endpoint:

curl http://<node-ip>:30880/healthz
# ok

Verify NFS server reachability

The NFS server itself needs to be monitored independently. Identify your NFS server's IP and port (default TCP 2049):

# Check what NFS server the provisioner is connecting to
kubectl get deployment -n nfs-provisioner nfs-subdir-external-provisioner -o jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="NFS_SERVER")].value}'

# Test NFS mount from a node
showmount -e <nfs-server-ip>

If your NFS server exposes an HTTP health page or metrics endpoint, note that URL. If it only exposes TCP ports, you'll use Vigilmon's TCP monitor for it.

Step 2: Set up HTTP monitoring in Vigilmon

With the provisioner health endpoint exposed, add it to Vigilmon:

1. Log in to vigilmon.online and go to Monitors → New Monitor
2. Choose HTTP / HTTPS as the type
3. Set the URL to http://<node-ip>:30880/healthz
4. Set the check interval to 1 minute
5. Under Expected response, set:
   • Status code: 200
   • Response body contains: ok
6. Save the monitor

If your NFS server has an HTTP management interface (many NAS devices expose one), add a second HTTP monitor for it:

1. Add a new HTTP monitor
2. Set the URL to http://<nfs-server-ip>/api/health (or your NFS management dashboard URL)
3. Save the monitor

The multi-region consensus advantage

Vigilmon probes your endpoints from multiple geographic regions simultaneously. For a storage provisioner, this means a single transient network blip between one probe and your node won't trigger a false alert. Vigilmon's multi-region consensus waits for independent probes from different locations to agree before declaring an outage — you get accurate storage alerts without noise.

Step 3: Monitor your TCP layer

TCP monitoring catches failures at the network layer before they appear as HTTP errors. Add TCP monitors for both the provisioner and the NFS server.

In Vigilmon:

1. Go to Monitors → New Monitor
2. Choose TCP Port
3. Enter your node IP and port 30880 (provisioner health port)
4. Save the monitor
5. Add a second TCP monitor for your NFS server: enter <nfs-server-ip> and port 2049

The NFS TCP monitor is especially valuable — if the NFS server becomes unreachable on port 2049, the provisioner pod stays Running but all storage operations fail. This is exactly the kind of silent failure that external monitoring catches.

# Verify NFS port from a cluster node
nc -zv <nfs-server-ip> 2049
# Connection to <nfs-server-ip> 2049 port [tcp/nfs] succeeded!

Step 4: Configure alert channels

A broken NFS provisioner silently stalls pod scheduling for every stateful workload. You need to know the moment it becomes unhealthy.

Email alerts

1. In Vigilmon, go to Alert Channels → Add Channel → Email
2. Enter your on-call or platform-team email address
3. Assign the channel to your NFS provisioner and NFS server monitors

Webhook alerts (Slack, PagerDuty, etc.)

1. Go to Alert Channels → Add Channel → Webhook
2. Enter your webhook URL
3. Assign the channel to your monitors

Example payload Vigilmon sends when a monitor goes down:

{
  "monitor_name": "nfs-provisioner /healthz",
  "status": "down",
  "url": "http://203.0.113.50:30880/healthz",
  "started_at": "2024-01-15T10:23:00Z",
  "duration_seconds": 90
}

When you receive a NFS provisioner alert, correlate it with the cluster:

# Check provisioner pod status
kubectl get pods -n nfs-provisioner -l app=nfs-subdir-external-provisioner

# Check for pending PVCs
kubectl get pvc -A | grep Pending

# Check provisioner logs for NFS mount errors
kubectl logs -n nfs-provisioner deploy/nfs-subdir-external-provisioner --tail=50

# Check NFS server connectivity from a node
kubectl run nfs-debug --image=busybox --rm -it --restart=Never -- \
  sh -c "nc -zv <nfs-server-ip> 2049"

# Check events for PVC provisioning failures
kubectl get events -A --field-selector reason=ProvisioningFailed | tail -20

Step 5: Create a public status page

Storage health is foundational to every stateful workload in your cluster. A public status page lets platform teams and application owners see NFS provisioner health without cluster access.

1. In Vigilmon, go to Status Pages → New Status Page
2. Give it a name: "Storage Infrastructure — NFS Provisioner"
3. Add your monitors: provisioner health, NFS server TCP, provisioner TCP
4. Group them: Provisioner, NFS Server
5. Publish the page

Share the status page URL in your runbook so teams know where to check when PVCs aren't binding.

Putting it all together

Here's a summary of the monitors to create for an NFS Subdir External Provisioner deployment:

| Monitor | Type | What it catches | |---------|------|-----------------| | http://<node-ip>:30880/healthz | HTTP | Provisioner pod health, OOMKill, crash loops | | http://<nfs-server-ip>/api/health | HTTP | NFS server management plane health (if available) | | <node-ip>:30880 | TCP | Provisioner port reachability | | <nfs-server-ip>:2049 | TCP | NFS server reachability — catches mount failures before PVC timeouts |

Verify the full provisioner state in your cluster:

# Check provisioner deployment
kubectl get deployment -n nfs-provisioner

# List all StorageClasses backed by the NFS provisioner
kubectl get sc | grep nfs

# Check currently provisioned PVs
kubectl get pv | grep nfs

# Verify the provisioner can reach NFS by checking a test PVC
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-test-pvc
  namespace: default
spec:
  accessModes: [ReadWriteMany]
  storageClassName: nfs-client
  resources:
    requests:
      storage: 1Mi
EOF
kubectl get pvc nfs-test-pvc -w

What's next

• NFS server disk monitoring — pair Vigilmon's uptime checks with node-exporter metrics to alert when the NFS server's underlying disk approaches full
• Heartbeat monitoring — if you run backup CronJobs that write to NFS-backed volumes, Vigilmon's heartbeat monitors alert you when a job stops reporting in
• Multi-provisioner coverage — if you run multiple NFS provisioner instances for different storage classes, add a Vigilmon monitor for each

Get started free at vigilmon.online — no credit card, monitors start running in under a minute.