Module csi-nfs

The csi-nfs module provides a CSI driver for managing NFS volumes in Kubernetes. Use it to provision PersistentVolumes on an NFS server through the NFSStorageClass custom resources.

Main features

The csi-nfs module provides the following capabilities:

• Provision NFS-backed PersistentVolumes through the NFSStorageClass custom resource.
• Support RWO and RWX access modes, including RWX in Deckhouse Virtualization Platform.
• Restrict volume mounting to selected cluster nodes with the workloadNodes parameter.
• Support RPC-with-TLS mode (tls / mtls) for connections to an NFS server (in commercial editions of DKP).
• Clean volume data before PV deletion with the volumeCleanup parameter (in commercial editions of DKP).

System requirements and recommendations

Requirements

Before using the module, make sure the following requirements are met:

• Use stock kernels provided with supported distributions;
• Ensure that the NFS server is correctly configured and running:
  • For DKP modules where StorageClass is used, it may be necessary to allow access to clients with root privileges. In Linux, this is implemented via the no_root_squash option. On other operating systems and storage systems, a similar setting may have a different name;
  • For virtual disk storage in the Deckhouse Virtualization Platform, the no_root_squash option is mandatory.
• To support RPC-with-TLS, enable CONFIG_TLS and CONFIG_NET_HANDSHAKE options in the Linux kernel.
• The snapshot-controller module must be enabled for this module to operate.

Recommendations

For module pods to restart when the tlsParameters parameter is changed, make sure the pod-reloader module is enabled (enabled by default).

Limitations

Creating volume snapshots

When creating snapshots of NFS volumes, it is important to understand their creation scheme and associated limitations. Avoid using snapshots in csi-nfs when possible:

1. The CSI driver creates a snapshot at the NFS server level.
2. For this, tar is used, which packages the volume contents, with all the limitations that may arise from this.
3. Before creating a snapshot, be sure to stop the workload (pods) using the NFS volume.
4. NFS does not ensure atomicity of operations at the file system level when creating a snapshot.

RPC-with-TLS mode limitations

The following limitations apply to RPC-with-TLS mode:

• For the mtls security policy, only one client certificate is supported.
• A single NFS server cannot simultaneously operate in different security modes: tls, mtls, and standard (non-TLS) mode.
• The tlshd daemon must not be running on the cluster nodes, otherwise it will conflict with the module daemon. To prevent conflicts when enabling TLS, the third-party tlshd is automatically stopped on the nodes and its autostart is disabled.

Quickstart

Run all commands on a machine that has administrator access to the Kubernetes API.

Enabling the module

Perform the following steps:

1. Enable the csi-nfs module. This will result in the following actions across all cluster nodes:

   • registration of the CSI driver;
   • launch of service pods for the csi-nfs components.

2. Wait for the module to become Ready:

   d8 k get module csi-nfs -w

Creating a StorageClass

To create a StorageClass, use the NFSStorageClass resource. Example:

d8 k apply -f - <<EOF
apiVersion: storage.deckhouse.io/v1alpha1
kind: NFSStorageClass
metadata:
  name: nfs-storage-class
spec:
  connection:
    host: 10.223.187.3
    share: /
    nfsVersion: "4.1"
  reclaimPolicy: Delete
  volumeBindingMode: WaitForFirstConsumer
  workloadNodes:
    nodeSelector:
      matchLabels:
        storage: "true"
EOF

CSI driver control pods are placed on cluster nodes according to the summarization of the workloadNodes parameters from all NFSStorageClass resources. If the workloadNodes parameter is missing in an NFSStorageClass, the workload will be placed on all nodes.

A directory <directory from share>/<PV name> will be created for each PV.