The module lifecycle stage: Experimental

Before enabling the module, you need to allow the use of experimental modules in the deckhouse ModuleConfig. To do this, set the allowExperimentalModules parameter to true.

v0.1.0

Release date: 2026-11-06

The first release of sds-nfs: an NFSServer turns one ReadWriteOnce volume into ReadWriteMany storage served over NFS, with an NFSStorageClass of its own, a quota for every claim, encryption and mTLS between the nodes and the server, and a move to another node when the node of the server is lost.

Highlights

Changes in this release:

  • An NFSServer provisions a volume of the chosen StorageClass, serves it over NFS from a single pod and publishes an NFSStorageClass of the csi-nfs module with its name; every claim of the class gets its own directory, limited to the size of the claim by an XFS project quota.
  • The traffic between the nodes and the server is always encrypted with RPC-with-TLS, and the server admits only the nodes that present the client certificate csi-nfs issues for them (mTLS). Every volume is exported only to the nodes that run its pods, and the nodes mount it with nosuid and nodev.
  • With a replicated backend StorageClass and fencing enabled on its NodeGroups, the server moves off a lost node once the node is proven dead; status.interruption and status.lastInterruption show what the server waits for and how long the pause lasted.

New features

This release adds:

  • The NFSServer resource (storage.deckhouse.io/v1alpha1, cluster-scoped): spec.backend.size and spec.backend.storageClassName set the backend volume (the default StorageClass of the cluster unless named), spec.nodeSelector the nodes of the server (the system nodes by default), spec.storageClass.volumeBindingMode the binding mode of the published class. The backend StorageClass and the binding mode cannot change after creation, and the backend size can only grow.
  • The module grows the backend volume and its file system online as the claims of the class ask for more, and reports in the CapacityReady condition when the backend cannot hold them. df in a pod shows the size of the claim, and a write past it fails with ENOSPC.
  • Conditions of NFSServer say what is not ready and why: BackendReady, Serving, CapacityReady, NFSStorageClassReady, TLSReady, ClientNodesReady (nodes whose kernel lacks RPC-with-TLS), FencingReady (NodeGroups without fencing), ExportsApplied, QuotasApplied, Recovered and Ready. A change of Ready is recorded as a Kubernetes Event on the server.
  • An NFSServer is not deleted while PersistentVolumes of its class exist: it keeps serving them with Ready=False and the reason DeletionBlocked. An NFSServer cannot be created under the name of an existing StorageClass or NFSStorageClass.
  • The Grafana dashboard SDS-NFS / NFS servers shows the state of the servers, their interruptions and backend volumes, NFS operations, latency and throughput, and how full every volume is; the alerts SdsNfsServerInterrupted, SdsNfsServerNotReady, SdsNfsServerCapacityNotReady and SdsNfsServerFencingNotReady fire on the conditions of the servers.
  • NFSServer is part of the access roles of the storage subsystem: the viewer role and the User access level read the servers, the manager role and ClusterEditor and above create, change and delete them.

Known issues

Known limitations of this release:

  • The module is in the Experimental stage and ships in the EE and FE editions only. It requires the csi-nfs module 0.4.14 or newer.
  • Every node that mounts the volumes needs a kernel with RPC-with-TLS (6.5 or later, with CONFIG_TLS and CONFIG_NET_HANDSHAKE); pods on other nodes, such as Astra and Debian with kernel 6.1, cannot mount the volumes.
  • One server serves every volume of its class, so a restart or a move pauses the I/O of all of them, and an update of the module that changes the image of the server restarts the servers of every class at once, for about 15–30 seconds each. A move off a lost node takes minutes.
  • Synchronous writes are slow (about 250–1600 IOPS for 4 KiB random writes with direct=1 in the module’s load test): the module suits shared files and moderate writing, not databases.