Alauda Container Platform

Creating an NFS Shared Storage Class

Based on the community NFS CSI (Container Storage Interface) storage driver, it provides the capability to access multiple NFS storage systems or accounts.

Unlike the traditional client-server model of NFS access, NFS shared storage utilizes the community NFS CSI (Container Storage Interface) storage plugin, which is more aligned with Kubernetes design principles and allows client access to multiple servers.

TOC

Prerequisites

  • An NFS server must be configured, and its access methods must be obtained. Currently, the platform supports three NFS protocol versions: v3, v4.0, and v4.1. You can execute nfsstat -s on the server side to check the version information.

Deploying the Alauda Container Platform NFS CSI plugin

Deploying via Web Console

  1. Enter Administrator.

  2. In the left navigation bar, click Storage > StorageClasses.

  3. Click Create StorageClass.

  4. On the right side of NFS CSI, click Deploy to navigate to the Plugins page.

  5. On the right side of the Alauda Container Platform NFS CSI plugin, click ⋮ > Install.

  6. Wait for the deployment status to indicate Deployment Successful before completing the deployment.

Deploying via YAML

Refs to Installing via YAML

Alauda Container Platform NFS CSI is a Non-config plugin, and the module-name is nfs

Creating an NFS Shared Storage Class

  1. Click Create Storage Class.

    Note: The following content is presented in a form, but you may also choose to complete the operation using YAML.

  2. Select NFS CSI and click Next.

  3. Refer to the following instructions to configure the relevant parameters.

    ParameterDescription
    NameThe name of the storage class. It must be unique within the current cluster.
    Service AddressThe access address of the NFS server. For example: 192.168.2.11.
    PathThe mount path of the NFS file system on the server node. For example: /nfs/data.
    NFS Protocol VersionCurrently supports three versions: v3, v4.0, and v4.1.
    Reclaim PolicyThe reclaim policy for the persistent volume.
    - Delete: When the persistent volume claim is deleted, the bound persistent volume will also be deleted.
    - Retain: Even if the persistent volume claim is deleted, the bound persistent volume will still be retained.
    Access ModesAll access modes supported by the current storage. During the subsequent declaration of persistent volumes, only one of these modes can be selected for mounting persistent volumes.
    - ReadWriteOnce (RWO): Can be mounted as read-write by a single node.
    - ReadWriteMany (RWX): Can be mounted as read-write by multiple nodes.
    - ReadOnlyMany (ROX): Can be mounted as read-only by multiple nodes.
    Allocated ProjectsPlease allocate the projects that can use this type of storage.
    If there are currently no projects needing this type of storage, you may choose not to allocate any projects at this time and update them later.
    subDirEach PersistentVolumeClaim (PVC) created using the NFS Shared Storage Class corresponds to a subdirectory within the NFS share. By default, subdirectories are named using the pattern ${pv.metadata.name} (i.e., the PersistentVolume name). If the default generated name does not meet your requirements, you can customize the subdirectory naming rules.
    NOTE

    The subDir field supports only the following three variables, which the NFS CSI Driver automatically resolves:

    • ${pvc.metadata.namespace}: PVC Namespace.
    • ${pvc.metadata.name}: PVC Name.
    • ${pv.metadata.name}: PV Name.

    The subDir naming rule MUST guarantee unique subdirectory names. Otherwise, multiple PVCs may share the same subdirectory, causing data conflicts.

    Recommended Configurations:

    • ${pvc.metadata.namespace}_${pvc.metadata.name}_${pv.metadata.name}
    • <cluster-identifier>_${pvc.metadata.namespace}_${pvc.metadata.name}_${pv.metadata.name}

    Designed for multiple Kubernetes clusters sharing the same NFS Server, this configuration ensures clear cluster differentiation by incorporating a cluster-specific identifier (e.g., the cluster name) into the subdirectory naming rules.

    Not Recommended Configurations:

    • ${pvc.metadata.namespace}-${pvc.metadata.name}-${pv.metadata.name} Avoid - as separators, may lead to ambiguous subdirectory names. For example: If two PVCs are named ns-1/test and ns/1-test, both could generate the same subdirectory ns-1-test.

    • ${pvc.metadata.namespace}/${pvc.metadata.name}/${pv.metadata.name} Do NOT configure subDir to create nested directories. The NFS CSI Driver only deletes the last-level directory ${pv.metadata.name} when a PVC is removed, leaving orphaned parent directories on the NFS Server.

  4. Once you have confirmed that the configuration information is correct, click Create.