[Question] Is running Trident in CSI Node-only mode outside Kubernetes supported or feasible?

[nineonine]

Greetings!

We are exploring the feasibility of running Trident's CSI Node service in standalone mode — outside of a Kubernetes cluster — to serve NodePublishVolume/NodeUnpublishVolume RPCs for NFS mounts on a non-K8s container orchestrator.

From reviewing the codebase, we see that Trident supports --csi_role=node and has a plainnodehelper code path (main.go#L480) that activates when no K8s API server is configured. A minimal invocation might look like:

trident --csi_endpoint=unix:///var/run/csi.sock \
        --csi_node_name=my-node \
        --csi_role=node \
        --no_persistence \
        --config=/path/to/backend.json

Questions

1. Is this a supported or tested configuration? Has Trident been tested running in CSI Node mode without a
   Kubernetes cluster?

2. What is the minimum required configuration? Specifically:

• Is a backend configuration file (--config) required for node-only mode, or can volume context (DNS name,
  export path) be passed entirely through NodePublishVolume requests?
• Is --no_persistence viable for a node-only deployment where the orchestrator manages volume state externally?

3. What is the expected resource footprint? We noticed that even in node mode, the full Trident orchestrator is
   bootstrapped (main.go#L392). Is there a lightweight mode that only initializes the CSI Node service without the orchestrator runtime?

4. Are there plans to support non-K8s orchestrators? We see the plainnodehelper and Docker plugin mode as precedents for non-K8s usage. Is there interest in making standalone CSI Node mode a first-class supported configuration?

Context

We are evaluating storage integration options and are interested in leveraging Trident for FSx for
NetApp ONTAP NFS mounts. Our use case only requires the CSI Node service (mount/unmount) — volume
provisioning and lifecycle management are handled by the control plane.

Any guidance on feasibility, limitations, or recommended approaches would be appreciated.

Thank you!

[clintonk]

Hello, @nineonine. Interesting proposition!

As you have noticed most of Trident is orchestrator-agnostic, because 1) we support both Kubernetes & Docker, and 2) we run the CSI Sanity test suite which knows nothing about Kubernetes. With Sanity, we run "All in one" mode where all 3 CSI interfaces are in a single binary. That means we don't have any reason to test the node-only configuration with the Plain personality and don't know its resource footprint. That said, I don't know any reason it couldn't be made to work. Storage backends are only used at the controller, so the node doesn't need such configuration. Yes, the node instantiates the core, but that isn't active on the node and can be ignored. Trident was designed before Kubernetes became the dominant orchestrator, so it could be adapted to a different orchestrator with some effort, but we don't currently have plans to do that or run in any configuration other than the ones we test today.

[nineonine]

Thanks for the quick and detailed response, @clintonk!

This is very helpful context. We went ahead and ran an experiment to test the node-only + plain personality
configuration. Here's what we found:

Setup:

docker run --rm -d --name trident-node --privileged \
  -v /tmp/trident-test:/var/run/trident \
  -v /tmp/trident-test/certs:/certs \
  --entrypoint /trident_orchestrator \
  netapp/trident:24.10.0 \
  --csi_endpoint=unix:///var/run/trident/csi.sock \
  --csi_node_name=test-node \
  --csi_role=node \
  --no_persistence \
  --log_level=debug

The plain CSI helper activates correctly, node capabilities are registered (STAGE_UNSTAGE_VOLUME, GET_VOLUME_STATS,
etc.), and service discovery warnings (missing systemctl, nvme) are non-fatal. So far so good.

The blocker we hit: The CSI gRPC socket is never created because nodeRegisterWithController is called with timeout=0 (retry forever) in plugin.go#L340, and grpc.Start() at plugin.go#L365 is sequential — it only runs after registration succeeds. Since there's no controller to register with, the node retries indefinitely
and the socket is never created.

The call stack:
Activate()                                    // plugin.go#L330
  └─ nodeRegisterWithController(ctx, 0)       // plugin.go#L340 (0 = retry forever)
       └─ MaxElapsedTime = timeout            // node_server.go#L799 (0 = never stop)
  └─ p.grpc.Start(p.endpoint, p, p, p)       // plugin.go#L365 (never reached)

Potential fix: If nodeRegisterWithController were run in its own goroutine (or grpc.Start were moved before it),
the CSI socket would be created immediately and node RPCs could be served while registration retries in the
background. Alternatively, a non-zero timeout or a flag to skip registration would work.

We've put together a reproducible test script (below) that demonstrates the issue.

#!/bin/bash
# Prerequisites
mkdir -p /tmp/trident-test/certs
openssl req -x509 -newkey rsa:2048 \
  -keyout /tmp/trident-test/certs/clientKey \
  -out /tmp/trident-test/certs/clientCert \
  -days 1 -nodes -subj '/CN=test' 2>/dev/null
cp /tmp/trident-test/certs/clientCert /tmp/trident-test/certs/caCert
echo -n "0123456789abcdef0123456789abcdef" > /tmp/trident-test/certs/aesKey

# Run
docker run --rm -d --name trident-node --privileged \
  -v /tmp/trident-test:/var/run/trident \
  -v /tmp/trident-test/certs:/certs \
  --entrypoint /trident_orchestrator \
  netapp/trident:24.10.0 \
  --csi_endpoint=unix:///var/run/trident/csi.sock \
  --csi_node_name=test-node \
  --csi_role=node \
  --no_persistence \
  --log_level=debug

# Check after 15s
sleep 15
echo "Socket:" && find /tmp/trident-test/ -name "*.sock" || echo "NOT CREATED"
docker logs trident-node 2>&1 | grep 'node registration' | tail -3

We are seeing

Could not update Trident controller with node registration, will retry.
error="failed during retry for CreateNode: could not log into the Trident CSI Controller: 
error communicating with Trident CSI Controller; 
Put \"https://trident-csi:34571/trident/v1/node/test-node\": 
dial tcp: lookup trident-csi on 10.4.4.10:53: no such host"

Would the Trident team be open to a change that makes grpc.Start() non-blocking with respect to controller
registration? Happy to contribute a PR if that would be welcome.