Manage NAS file systems with CNFS - File Storage NAS - Alibaba Cloud Documentation Center

Container Network File System (CNFS) lets you manage NAS file systems as native Kubernetes resources. Use a declarative approach to create, adopt, and mount NAS storage for workloads such as websites and data analytics, with flexible support for data sharing and isolation.

Prerequisites

You have an ACK Pro cluster running version 1.20 or later. To update your cluster, see Manually update an ACK cluster.
CNFS supports version 1.20 when used with kubectl.
Ensure that the storage components meet the following version requirements. To update the components, see Components.
- csi-plugin and csi-provisioner: v1.24.11-5221f79-aliyun or later.
- storage-operator: v1.26.2-1de13b6-aliyun or later.
You have enabled Apsara File Storage NAS. The following limits apply to NAS file systems. For more information, see Limits.
- Only the Capacity, Performance, and Extreme storage types of General-purpose NAS are supported. Extreme Speed NAS is not supported.
- The number of NAS file systems you can create per account in a single region is limited.
- To use KMS encryption for your NAS file systems, you must enable Key Management Service (KMS). For more information, see Purchase a dedicated KMS instance.

Create a NAS file system

Methods for adding a NAS file system

Choose how to add a NAS file system to your cluster.

Method	Description	Volume provisioning mode	Use cases
Method 1: Automatically create and use a NAS file system	CNFS automatically creates and manages a NAS file system with a fixed configuration for fast mounting.	Dynamic volume	For quick feature validation. You do not need to manage the underlying storage details. However, the created NAS file system has a fixed configuration, which means you cannot select the storage type, customize the encryption method, or manage the recycle bin with fine-grained controls.
Method 2: Create and use a NAS file system with custom parameters	CNFS creates a new, customizable NAS file system based on the parameters you specify.	Dynamic volume Static volume	Ideal for use cases with specific requirements for performance, encryption, or cost, or that require fine-grained storage control.
Method 3: Adopt and use an existing NAS file system	CNFS adopts an existing NAS file system for unified management.	Dynamic volume Static volume	For seamlessly integrating an existing NAS file system into your cluster.

Method 1: Automatically create and use a NAS file system

CNFS automatically creates a NAS file system with a default configuration based on your cluster environment. Encryption is disabled by default. If Capacity NAS is unavailable in the current region, Performance NAS is used instead.

After you create the CNFS resource and StorageClass, workloads can request storage through a PersistentVolumeClaim (PVC), which dynamically provisions a PersistentVolume (PV) on the NAS file system and mounts it to a pod.

kubectl

1. Create a CNFS resource

Create aContainerNetworkFileSystem object. If you do not specify theserver parameter or other custom parameters, CNFS automatically creates a default NAS file system.

apiVersion: storage.alibabacloud.com/v1beta1
kind: ContainerNetworkFileSystem
metadata:
  name: cnfs-nas-filesystem
spec:
  description: "cnfs"
  type: nas
  # Only Retain is supported. Deleting the CNFS resource does not delete the backend NAS instance.
  reclaimPolicy: Retain
  parameters:
    # Specifies the server-side encryption method. SSE-KMS enables encryption with keys managed by NAS.
    encryptType: SSE-KMS
    # Enables the recycle bin feature when set to "true".
    enableTrashCan: "true"

Parameters

Parameter	Description
`description`	The description of the CNFS resource.
`type`	The type of storage volume to create. Set the value to`nas`.
`reclaimPolicy`	The reclaim policy. Only`Retain` is supported. This policy prevents data loss by ensuring the backend NAS file system is not deleted when you delete the CNFS resource.
`parameters.encryptType`	Optional. Specifies whether to enable anencryption method. `None`: Disables encryption. `SSE-KMS`: Enables server-side encryption with keys managed by NAS. NAS creates and manages a key in KMS to encrypt each file system.
`parameters.enableTrashCan`	Specifies whether to enable the recycle bin feature to prevent business disruptions or data loss caused by accidental file deletion. `true`: Enables the feature. `false`: Disables the feature.

Runkubectl get cnfs to view the created NAS file system.
Runkubectl get cnfs/cnfs-nas-filesystem -o yaml to view the details of the NAS file system.
For more information about the YAML file, see CNFS YAML reference.

2. Create a StorageClass

Create aStorageClass object to serve as a storage template. Use thecontainerNetworkFileSystem parameter to associate it with the CNFS resource that you created.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: alibabacloud-cnfs-nas
provisioner: nasplugin.csi.alibabacloud.com
parameters:
  # Creates a separate subdirectory on the NAS file system for each PVC.
  volumeAs: subpath
  # Associates the StorageClass with the CNFS resource defined earlier.
  containerNetworkFileSystem: cnfs-nas-filesystem
  path: "/"
# Set to Retain to keep the subdirectory data after the PVC is deleted.
reclaimPolicy: Retain
# Allows volume expansion.
allowVolumeExpansion: true
mountOptions:
  - nolock,tcp,noresvport
  - vers=3

3. Create a PersistentVolumeClaim

The application requests a storage volume by using a PersistentVolumeClaim (PVC) and references the StorageClass as its configuration template.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: cnfs-nas-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: alibabacloud-cnfs-nas
  resources:
    requests:
      # If allowVolumeExpansion is set to true, the value of storage is used as the quota for the subdirectory that corresponds to this PVC. This sets a quota of 70 GiB for the subdirectory.
      storage: 70Gi

4. Create an application and mount the PVC

After the PVC is created, deploy a sample application, such as a Deployment or StatefulSet, and mount the PV bound to the PVC to the application.

Deployment: All pod replicas reference the same PVC and mount the same directory on the backend NAS file system to share data.

Sample code

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cnfs-nas-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        volumeMounts:
        - mountPath: "/data"
          name: cnfs-nas-pvc
      volumes:
      - name: cnfs-nas-pvc
        persistentVolumeClaim:
          claimName: cnfs-nas-pvc

StatefulSet: A separate PVC is automatically created for each pod replica based on thevolumeClaimTemplates template. Each replica mounts a dedicated subdirectory on the backend NAS file system to isolate data.

Sample code

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: cnfs-nas-sts
  labels:
    app: nginx
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        volumeMounts:
        - mountPath: "/data"
          name: www
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "alibabacloud-cnfs-nas"
      resources:
        requests:
          # If allowVolumeExpansion is set to true, the storage parameter takes effect. This sets a quota of 50 GiB for the subdirectory.
          storage: 50Gi

5. Verify the result

Runkubectl get pvc to view the PVC status.
The PVC'sSTATUS should beBound, indicating it is bound to a PV.
Runkubectl get pods -l app=nginx to view the application status.
Verify the shared and persistent storage for the Deployment.
Verify the data isolation and persistent storage for the StatefulSet.

Console

1. Create a CNFS resource	Log on to the ACK console. In the left navigation pane, click Clusters. On the Clusters page, click the name of your cluster. In the left navigation pane, click Volumes > CNFS. Click Create CNFS File System and configure the CNFS resource as prompted. Select NAS File System. Select Create Default NAS File System. If needed, enable End-to-end Data Acceleration to accelerate mounting and optimize data access performance. For more information, see Mount a NAS file system by using an EFC client with CNFS. After the CNFS resource is created, find it in the list and click its name for details. Click the NAS ID to go to the NAS file system's details page. Click Mount Targets to get the mount target address from the Mount Target column.
2. Create a StorageClass	On the Clusters page, click the name of your cluster. In the left navigation pane, click Volumes > StorageClasses. On the StorageClasses page, click Create, select PV Type for NAS, and then configure the StorageClass as prompted. The following table describes the key parameters. For more information, see Create a StorageClass. Select Mount Target: Select the mount target of the NAS file system that was created or adopted by using CNFS. For more information about how to view a mount target, see Manage mount targets. Mount Path: The NAS subdirectory to mount. If unspecified, the root directory (`/`) is mounted by default. If the directory does not exist in the NAS file system, the system automatically creates and mounts it. Reclaim Policy: `Retain` (Recommended): After the PVC is deleted, the PV enters the `Released` state. The backend NAS data is retained and must be manually deleted. `Delete`: Deletes the PV when the associated PVC is deleted. This policy requires `archiveOnDelete`. However, static PVs do not support `archiveOnDelete`. Therefore, when this policy is set to `Delete`, deleting the PVC does not delete the PV or the files on the NAS file system. To configure `archiveOnDelete`, see Use dynamically provisioned NAS volumes.
3. Create a PersistentVolumeClaim	In the left navigation pane of the cluster management page, choose Storage > PVCs. On the Persistent Volume Claims page, click Create, select NAS for PVC Type, and then configure the PVC as prompted. Allocation Mode: The mode in which the storage volume is used. Existing StorageClass: Click Select Storage Class and select the StorageClass that you created. Capacity: The storage volume capacity. This value cannot exceed the available capacity of the underlying NAS file system. Access Mode: The default value is ReadWriteMany. You can also select ReadWriteOnce or ReadOnlyMany.
4. Create an application and mount the NAS volume	When you create a Deployment or create a StatefulSet, you can mount a PVC to a container in the Volumes section of the Container page. This example shows how to mount the PVC to the/data path in a container. For Volume Type, select Cloud Volume. For Mount Source, select cnfs-nas-pvc. For Container Path, enter`/data`.

Method 2: Create and use a custom NAS file system

Use CNFS to create a NAS file system with custom parameters.

Define aContainerNetworkFileSystem resource to provision a new NAS file system.
Make the file system available to applications in your cluster by creating a static persistent volume or a storage class.

kubectl

1. Create a custom NAS file system

Create aContainerNetworkFileSystem object and specify the NAS details, such as storage type, encryption type, and vSwitch.

apiVersion: storage.alibabacloud.com/v1beta1
kind: ContainerNetworkFileSystem
metadata:
  name: cnfs-nas-filesystem
spec:
  description: "cnfs"
  type: nas
  reclaimPolicy: Retain
  parameters:
    filesystemType: standard
    storageType: Capacity
    protocolType: NFS
    encryptType: SSE-KMS
    enableTrashCan: "true"
    trashCanReservedDays: "5"
    vSwitchId: vsw-2ze9l3ppwzg6bl02j****

Parameters

Parameter	Description
`description`	The description of the CNFS resource.
`type`	The type of storage volume to create. Set the value to`nas`.
`reclaimPolicy`	The reclaim policy. Only`Retain` is supported. This policy prevents data loss by ensuring the backend NAS file system is not deleted when you delete the CNFS resource.
`parameters.filesystemType`	The file system type. The default is`standard` for general-purpose NAS.
`parameters.storageType`	The storage type. general-purpose NAS supports`Performance`,`Capacity`, and`Premium`.
`parameters.protocolType`	The file transfer protocol. Only NFS is supported.
`parameters.encryptType`	Optional. Specifies whether to enable anencryption method. `None`: Disables encryption. `SSE-KMS`: Enables server-side encryption with keys managed by NAS. NAS creates and manages a key in KMS to encrypt each file system.
`parameters.enableTrashCan`	Specifies whether to enable the recycle bin feature to prevent business disruptions or data loss caused by accidental file deletion. `true`: Enables the feature. `false`: Disables the feature.
`parameters.trashCanReservedDays`	The maximum retention period for files in the recycle bin. The default is 7 days. In the example,`trashCanReservedDays: 5` indicates that files are retained for up to 5 days.
`parameters.vSwitchId`	The ID of the vSwitch for the NAS file system. For information about the regions and zones that support general-purpose NAS, see Regions and zones.

Runkubectl get cnfs to view the created NAS file system.
Runkubectl get cnfs/cnfs-nas-filesystem -o yaml to view the details of the NAS file system.
For more information about the YAML file, see CNFS YAML reference.

2. Create a persistent volume or storage class

After you create the CNFS resource, choose how applications will access the NAS file system.

Static persistent volume: Manually bind a persistent volume to an existing directory on the NAS file system. This is suitable for scenarios where you need to access specific existing data.
Dynamic storage class: Create a storage class to serve as a template, allowing applications to automatically create new, independent subdirectories on demand.

Static provisioning

apiVersion: v1
kind: PersistentVolume
metadata:
  name: cnfs-nas-pv
  labels:
    alicloud-pvname: cnfs-nas-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  csi:
    driver: nasplugin.csi.alibabacloud.com
    # Must be the same as the PV name.
    volumeHandle: cnfs-nas-pv 
    volumeAttributes:
      # Specify the CNFS resource to use.
      containerNetworkFileSystem: cnfs-nas-filesystem
      # The mount path used by the volume in CNFS.
      path: "/"
  mountOptions:
    - nolock,tcp,noresvport
    - vers=3

For more information about persistent volume parameters, see Use a static NAS volume.

Dynamic provisioning

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: alibabacloud-nas-cnfs
mountOptions:
  - nolock,tcp,noresvport
  - vers=3
parameters:
  volumeAs: subpath
  # Specify the CNFS resource to use.
  containerNetworkFileSystem: cnfs-nas-filesystem
  # The mount path used by the volume in CNFS.
  path: "/"
provisioner: nasplugin.csi.alibabacloud.com
reclaimPolicy: Retain
# Set to true to allow the directory quota of the volume to be expanded.
allowVolumeExpansion: true

For more information about storage class parameters, see Use a dynamic NAS volume.

3. Create a persistent volume claim

Create a persistent volume claim that uses the static persistent volume or the storage class that you created.

Static provisioning

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cnfs-nas-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  selector:
    matchLabels:
      # Precisely match the persistent volume created earlier by using a label.
      alicloud-pvname: cnfs-nas-pv

Dynamic provisioning

apiVersion: v1
kind: PersistentVolumeClaim
metadata: 
  name: cnfs-nas-pvc
spec:
  accessModes:
  - ReadWriteMany 
  storageClassName: alibabacloud-nas-cnfs
  resources: 
    requests:
      storage: 70Gi

4. Create an application and mount the NAS file system

After the persistent volume claim is created, mount it in your application.

Sample code

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cnfs-nas-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
          ports:
            - containerPort: 80
          volumeMounts:
            - name: cnfs-nas-pvc
              mountPath: "/data"
      volumes:
        - name: cnfs-nas-pvc
          persistentVolumeClaim:
            claimName: cnfs-nas-pvc

5. Verify the result

Runkubectl get pod -l app=nginx to check the application status.
Verify shared and persistent storage for a Deployment.

Console

Create a CNFS resource	Log on to the ACK console. In the left navigation pane, click Clusters. On the Clusters page, click the name of your cluster. In the left navigation pane, click Volumes > CNFS. Click Create CNFS File System and configure the CNFS resource as prompted. Select a NAS file system Select Select Existing NAS File System, and then click Create NAS File System to create a custom NAS file system. After the file system is created, select it. For more information about how to create a NAS file system, see Create a general-purpose NAS file system in the console. As needed, enable End-to-end Data Acceleration to use the elastic acceleration feature for mounting and optimize data access performance. For more information, see Use an EFC client to mount a NAS file system through CNFS.
Create a persistent volume or storage class	PV On the Clusters page, click the name of your cluster. In the left navigation pane, click Volumes > Persistent Volumes. Click Create, select PV Type for PV Type, and then configure the persistent volume as prompted. Key parameters are described below. For detailed descriptions of all parameters, see Create a PV. Capacity: The capacity of the persistent volume. Kubernetes uses this value to bind the PV to a PVC and does not enforce a capacity limit. The actual usable storage is the total capacity of the underlying NAS file system. The actual capacity limit of a NAS file system depends on its specifications. For more information, see General-purpose NAS. Enable CNFS: Specifies whether to use a CNFS resource to manage the volume. Select CNFS: The CNFS resource to use. Advanced Options (Optional): Mount Path: The NAS subdirectory to mount. If you do not specify this parameter, the root directory is mounted by default. The root directory of a general-purpose NAS file system is`/`. If the directory does not exist in the NAS file system, the system automatically creates and mounts it. Reclaim Policy: CNFS supports only Retain. Enable CNFS Acceleration: Specifies whether to enable the CNFS acceleration feature. For more information, see Use an EFC client to mount a NAS file system through CNFS. Storage class On the Clusters page, click the name of your cluster. In the left navigation pane, click Volumes > StorageClasses. On the StorageClasses page, click Create, select PV Type for NAS, and then configure the StorageClass as prompted. The following table describes the key parameters. For more information, see Create a StorageClass. Select Mount Target: Select the mount target of the NAS file system that was created or adopted by using CNFS. For more information about how to view a mount target, see Manage mount targets. Mount Path: The NAS subdirectory to mount. If unspecified, the root directory (`/`) is mounted by default. If the directory does not exist in the NAS file system, the system automatically creates and mounts it. Reclaim Policy: `Retain` (Recommended): After the PVC is deleted, the PV enters the `Released` state. The backend NAS data is retained and must be manually deleted. `Delete`: Deletes the PV when the associated PVC is deleted. This policy requires `archiveOnDelete`. However, static PVs do not support `archiveOnDelete`. Therefore, when this policy is set to `Delete`, deleting the PVC does not delete the PV or the files on the NAS file system. To configure `archiveOnDelete`, see Use dynamically provisioned NAS volumes.
Create a PVC	In the left navigation pane of the cluster management page, choose Storage > PVCs. On the Persistent Volume Claims page, click Create, select NAS for PVC Type, and then configure the PVC as prompted. Allocation Mode: The mode in which the storage volume is used. Existing StorageClass: Click Select Storage Class and select the StorageClass that you created. Capacity: The storage volume capacity. This value cannot exceed the available capacity of the underlying NAS file system. Access Mode: The default value is ReadWriteMany. You can also select ReadWriteOnce or ReadOnlyMany.
Create an application and mount the NAS file system	When you create a Deployment or create a StatefulSet, you can mount a PVC to a container in the Volumes section of the Container page. This example shows how to mount the PVC to the/data path in a container. For Volume Type, select Cloud Volume. For Mount Source, select cnfs-nas-pvc. For Container Path, enter`/data`.

Method 3: Use an existing NAS file system

Use CNFS to adopt an existing NAS file system into your cluster so applications can mount and access it.

kubectl

1. Create a CNFS resource from an existing NAS file system

Create aContainerNetworkFileSystem resource that references a NAS mount target.

apiVersion: storage.alibabacloud.com/v1beta1
kind: ContainerNetworkFileSystem
metadata:
  name: cnfs-nas-filesystem
spec:
  description: "cnfs"
  type: nas
  reclaimPolicy: Retain
  parameters:
    server: 17f7e4****-h****.cn-beijing.nas.aliyuncs.com

Parameters

Parameter	Description
`description`	A description of the CNFS resource.
`type`	The type of storage to create.
`reclaimPolicy`	The reclaim policy. Only`Retain` is supported. This policy prevents data loss by ensuring the backend NAS file system is not deleted when you delete the CNFS resource.
`parameters.server`	The address of the NAS mount target.

Runkubectl get cnfs to view the created NAS file system.
Runkubectl get cnfs/cnfs-nas-filesystem -o yaml to view the details of the NAS file system.
For more information about the YAML file, see CNFS YAML reference.

2. Create a persistent volume or storage class

After you create the CNFS resource, choose how applications will access the NAS file system.

Static persistent volume: Manually bind a persistent volume to an existing directory on the NAS file system. This is suitable for scenarios where you need to access specific existing data.
Dynamic storage class: Create a storage class to serve as a template, allowing applications to automatically create new, independent subdirectories on demand.

Static provisioning

apiVersion: v1
kind: PersistentVolume
metadata:
  name: cnfs-nas-pv
  labels:
    alicloud-pvname: cnfs-nas-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  csi:
    driver: nasplugin.csi.alibabacloud.com
    # Must be the same as the PV name.
    volumeHandle: cnfs-nas-pv 
    volumeAttributes:
      # Specify the CNFS resource to use.
      containerNetworkFileSystem: cnfs-nas-filesystem
      # The mount path used by the volume in CNFS.
      path: "/"
  mountOptions:
    - nolock,tcp,noresvport
    - vers=3

For more information about persistent volume parameters, see Use a static NAS volume.

Dynamic provisioning

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: alibabacloud-nas-cnfs
mountOptions:
  - nolock,tcp,noresvport
  - vers=3
parameters:
  volumeAs: subpath
  # Specify the CNFS resource to use.
  containerNetworkFileSystem: cnfs-nas-filesystem
  # The mount path used by the volume in CNFS.
  path: "/"
provisioner: nasplugin.csi.alibabacloud.com
reclaimPolicy: Retain
# Set to true to allow the directory quota of the volume to be expanded.
allowVolumeExpansion: true

For more information about storage class parameters, see Use a dynamic NAS volume.

3. Create a persistent volume claim

Create a persistent volume claim that uses the static persistent volume or the storage class that you created.

Static provisioning

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cnfs-nas-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  selector:
    matchLabels:
      # Precisely match the persistent volume created earlier by using a label.
      alicloud-pvname: cnfs-nas-pv

Dynamic provisioning

apiVersion: v1
kind: PersistentVolumeClaim
metadata: 
  name: cnfs-nas-pvc
spec:
  accessModes:
  - ReadWriteMany 
  storageClassName: alibabacloud-nas-cnfs
  resources: 
    requests:
      storage: 70Gi

4. Create an application and mount the NAS file system

After the persistent volume claim is created, mount it in your application.

Sample code

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cnfs-nas-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
          ports:
            - containerPort: 80
          volumeMounts:
            - name: cnfs-nas-pvc
              mountPath: "/data"
      volumes:
        - name: cnfs-nas-pvc
          persistentVolumeClaim:
            claimName: cnfs-nas-pvc

5. Verify the result

Runkubectl get pod -l app=nginx to check the application status.
Verify shared and persistent storage for a Deployment.

Console

Create a CNFS resource from an existing NAS file system	Log on to the ACK console. In the left navigation pane, click Clusters. On the Clusters page, click the name of your cluster. In the left navigation pane, click Volumes > CNFS. Click Create CNFS File System and configure the CNFS resource as prompted. On the Create CNFS File System panel, configure the parameters and click OK. Select a NAS file system. Select Select Existing NAS File System and then choose an existing NAS mount target from the drop-down list. If needed, enable End-to-end Data Acceleration to accelerate mounting and optimize data access performance. For more information, see Mount a NAS file system by using an EFC client with CNFS.
Create a persistent volume or storage class	PV On the Clusters page, click the name of your cluster. In the left navigation pane, click Volumes > Persistent Volumes. Click Create, select PV Type for PV Type, and then configure the persistent volume as prompted. Key parameters are described below. For detailed descriptions of all parameters, see Create a PV. Capacity: The capacity of the persistent volume. Kubernetes uses this value to bind the PV to a PVC and does not enforce a capacity limit. The actual usable storage is the total capacity of the underlying NAS file system. The actual capacity limit of a NAS file system depends on its specifications. For more information, see General-purpose NAS. Enable CNFS: Specifies whether to use a CNFS resource to manage the volume. Select CNFS: The CNFS resource to use. Advanced Options (Optional): Mount Path: The NAS subdirectory to mount. If you do not specify this parameter, the root directory is mounted by default. The root directory of a general-purpose NAS file system is`/`. If the directory does not exist in the NAS file system, the system automatically creates and mounts it. Reclaim Policy: CNFS supports only Retain. Enable CNFS Acceleration: Specifies whether to enable the CNFS acceleration feature. For more information, see Use an EFC client to mount a NAS file system through CNFS. Storage class On the Clusters page, click the name of your cluster. In the left navigation pane, click Volumes > StorageClasses. On the StorageClasses page, click Create, select PV Type for NAS, and then configure the StorageClass as prompted. The following table describes the key parameters. For more information, see Create a StorageClass. Select Mount Target: Select the mount target of the NAS file system that was created or adopted by using CNFS. For more information about how to view a mount target, see Manage mount targets. Mount Path: The NAS subdirectory to mount. If unspecified, the root directory (`/`) is mounted by default. If the directory does not exist in the NAS file system, the system automatically creates and mounts it. Reclaim Policy: `Retain` (Recommended): After the PVC is deleted, the PV enters the `Released` state. The backend NAS data is retained and must be manually deleted. `Delete`: Deletes the PV when the associated PVC is deleted. This policy requires `archiveOnDelete`. However, static PVs do not support `archiveOnDelete`. Therefore, when this policy is set to `Delete`, deleting the PVC does not delete the PV or the files on the NAS file system. To configure `archiveOnDelete`, see Use dynamically provisioned NAS volumes.
Create a PVC	In the left navigation pane of the cluster management page, choose Storage > PVCs. On the Persistent Volume Claims page, click Create, select NAS for PVC Type, and then configure the PVC as prompted. Allocation Mode: The mode in which the storage volume is used. Existing StorageClass: Click Select Storage Class and select the StorageClass that you created. Capacity: The storage volume capacity. This value cannot exceed the available capacity of the underlying NAS file system. Access Mode: The default value is ReadWriteMany. You can also select ReadWriteOnce or ReadOnlyMany.
Create an application and mount the NAS file system	When you create a Deployment or create a StatefulSet, you can mount a PVC to a container in the Volumes section of the Container page. This example shows how to mount the PVC to the/data path in a container. For Volume Type, select Cloud Volume. For Mount Source, select cnfs-nas-pvc. For Container Path, enter`/data`.

Configuring shared and isolated storage

After you create or onboard a NAS file system, configure it for data sharing or data isolation to match your workload requirements.

Configure a shared NAS volume

To share data between pods, mount the same directory from a NAS file system to multiple pods.

Core mechanism: This method uses a static storage volume. In a persistent volume (PV), the declaredpath is identical to the final path mounted by the Container Storage Interface (CSI). Therefore, when multiple pods mount this static PV by using the same persistent volume claim (PVC), they all access the same storage directory, enabling data sharing.
Key configuration: In the pod template (.spec.template) of your workload, set thepersistentVolumeClaim.claimName parameter under thevolumes field to the same PVC name.

1. Create a PV and PVC that point to a specific directory

View sample code

apiVersion: v1
kind: PersistentVolume
metadata:
  name: cnfs-nas-static-pv
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 50Gi
  csi:
    driver: nasplugin.csi.alibabacloud.com
    fsType: nfs
    volumeAttributes:
      # Specify the CNFS resource.
      containerNetworkFileSystem: cnfs-nas-filesystem
      mountProtocol: nfs
      path: /
      volumeAs: subpath
      volumeCapacity: "true"
    volumeHandle: cnfs-nas-static-pv
  mountOptions:
  - nolock,tcp,noresvport
  - vers=3
  persistentVolumeReclaimPolicy: Retain
  storageClassName: cnfs-nas-sc
  volumeMode: Filesystem
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cnfs-nas-static-pvc
  namespace: default
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 50Gi
  storageClassName: cnfs-nas-sc
  volumeMode: Filesystem
  # Reference the PV.
  volumeName: cnfs-nas-static-pv
status:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 50Gi

2. Create a sample deployment

View sample code

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cnfs-nas-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        volumeMounts:
        - mountPath: "/data"
          # Reference the volume defined under volumes.
          name: cnfs-nas-pvc
      volumes:
      # Define a volume named cnfs-nas-pvc.
      - name: cnfs-nas-pvc
        # All pod replicas reference the same PVC through this configuration to enable shared storage.
        persistentVolumeClaim:
          claimName: cnfs-nas-static-pvc

3. Verify the result

Check the mount status

Check the mount status of the pod.

kubectl exec cnfs-nas-deployment-*****a -- mount | grep nfs

The expected output includes the mount point, which confirms a successful mount.

66bd9493d6-*****.cn-zhangjiakou.nas.aliyuncs.com:/ on /data type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,noresvport,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.XX.XX.199,mountvers=3,mountport=2049,mountproto=tcp,local_lock=all,addr=10.XX.XX.199)

Verify the shared and persistent storage of the deployment.

Configure an isolated NAS volume

To achieve data isolation for scenarios like multi-tenancy, you can provide an independent and isolated storage directory for each pod or group of pods.

Core mechanism: This method uses a dynamic storage volume. In the storage class, the CSI driver automatically creates a separate subdirectory with the same name as the PV under the declaredpath. This subdirectory serves as the mount point. As a result, each PVC binds to a separate storage directory, enabling data isolation.
Key configuration:
- In the storage class associated with the statefulset, use the volumeAs: subpath parameter (the default value) underparameters to create an isolated subdirectory for each PVC.
- In the statefulset, definevolumeClaimTemplates to automatically create and bind a separate PVC for each pod.

1. Create a storage class that supports dynamic subdirectories

View sample code

This storage class references the specified CNFS, andvolumeAs: subpath instructs the CSI driver to dynamically create an isolated subdirectory for each PVC request.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: cnfs-nas-sc
mountOptions:
  - nolock,tcp,noresvport
  - vers=3
parameters:
  # The core parameter for implementing isolated storage volumes.
  volumeAs: subpath
  # Reference the created CNFS resource.
  containerNetworkFileSystem: cnfs-nas-filesystem
  # Specify the root path for creating subdirectories on the NAS file system.
  # The CSI driver creates a subdirectory under this path. The directory name is the same as the automatically generated PV name.
  path: "/"
  archiveOnDelete: "false"
provisioner: nasplugin.csi.alibabacloud.com
# Automatically deletes the corresponding NAS subdirectory when the PVC is deleted.
reclaimPolicy: Delete
allowVolumeExpansion: true

2. Create a sample statefulset

View sample code

Dynamically creates and mounts an isolated storage volume for each pod based on the volumeClaimTemplates.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: cnfs-nas-sts
  labels:
    app: nginx
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        command: ["/bin/sh"]
        args: ["-c", "sleep 3600;"]
        volumeMounts:
        - mountPath: "/data"
          name: pvc
  # The volumeClaimTemplates section automatically creates a PVC for each pod based on the following template.
  volumeClaimTemplates:
  - metadata:
      name: pvc
    spec:
      accessModes: [ "ReadWriteOnce" ]
      # Reference the previously created storage class.
      storageClassName: "cnfs-nas-sc" 
      resources:
        requests:
          # This is used only for scheduling decisions and does not represent a real quota limit. The actual available capacity is the total capacity of the NAS file system.
          storage: 50Gi

3. Verify the result

Check the mount status

Check the mount information for a pod, such as cnfs-nas-sts-0.

kubectl exec cnfs-nas-sts-0 -- mount |grep nfs

The expected output shows that a subdirectory of the NAS file system is successfully mounted to the/data path of the pod.

66bd9493d6-*****.cn-zhangjiakou.nas.aliyuncs.com:/nas-e7242ba0-47ec-4410-9107-b0e247a***** on /data type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,noresvport,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.XX.XX.199,mountvers=3,mountport=2049,mountproto=tcp,local_lock=all,addr=10.XX.XX.199)

Verify the data isolation and persistent storage of the statefulset.

Recommendations for production environments

Data security
- Data encryption: When you create a new NAS file system, set parameters to encryptType: SSE-KMS in CNFS to enable data encryption at rest on the NAS server and improve data security.
- Data protection and reclaim policy: The reclaimPolicy for CNFS is fixed to Retain. Deleting a CNFS object in Kubernetes does not delete the backend NAS instance. However, the reclaim policy of a PV is defined by its StorageClass. In a production environment, we recommend that you set the policy to Retain to prevent accidental deletion.
- Recycle bin feature: When you create a NAS, we recommend that you enable the recycle bin feature with the enableTrashCan: "true" parameter to prevent accidental deletion.
- Concurrent writes: When multiple Pods mount the same shared storage volume, design your application to prevent concurrent writes to the same file, which can cause data corruption.
Operations and management
- Performance isolation: Although isolated storage volumes provide data-level isolation, they all share the IOPS and throughput of the same backend NAS instance. For core applications that require strict I/O performance and stable latency, provision a dedicated NAS file system.
- Capacity management: Set allowVolumeExpansion: true in the StorageClass to expand the directory quota of the storage volume.
  The requests.storage value in a PVC is used primarily for scheduling decisions and is not the quota limit for the entire NAS file system.
- Monitoring and alerting: Use container storage monitoring to configure alerts for key metrics such as capacity utilization, IOPS, and throughput to proactively identify capacity or performance bottlenecks.
Cost optimization
- Choose the right storage type: Select a NAS type based on your cost and performance requirements. For guidance, see Select a NAS type. For example, Capacity NAS offers a lower price point and is suitable for file sharing or archival workloads that do not require low latency.
- Release resources promptly: When an application is decommissioned, clean up unused resources. Confirm whether you need to delete the backend NAS file system to avoid incurring unnecessary costs.

References

Verify shared storage, data isolation, and persistent storage

After mounting the NAS file system, follow these steps to verify that the storage works as expected.

Verify shared and persistent storage for a deployment

Steps

Shared storage

Persistent storage

Create a file in one pod and view it in another to verify shared storage.

List the pods to get their names.

kubectl get pod | grep cnfs-nas-deployment

Expected output:

cnfs-nas-deployment-*****a 1/1 Running 0 40s
cnfs-nas-deployment-*****b 1/1 Running 0 40s

Create a file in one of the pods. This example uses the pod namedcnfs-nas-deployment-*****a:
```
kubectl exec cnfs-nas-deployment-*****a -- touch /data/test.txt
```
Check if the file exists in the other pod. This example uses the pod namedcnfs-nas-deployment-*****b:
```
kubectl exec cnfs-nas-deployment-*****b -- ls /data
```
Expected output:
```
test.txt
```
This output confirms that data is shared between pods.
Important
CNFS does not guarantee data consistency when multiple pods write to shared storage. To prevent file corruption, avoid concurrent writes to the same file.

Recreate the deployment and check if data exists in the new pods to verify persistent storage.

Restart the deployment to trigger pod recreation.

kubectl rollout restart deploy cnfs-nas-deployment

List the pods and wait for the new pods to start and enter the Running state.

kubectl get pod | grep cnfs-nas-deployment

Expected output:

cnfs-nas-deployment-*****c 1/1 Running 0 67s
cnfs-nas-deployment-*****d 1/1 Running 0 49s

In a new pod, check if the previously created file exists. This example uses the pod namedcnfs-nas-deployment-*****c:
```
kubectl exec cnfs-nas-deployment-*****c -- ls /data
```
Expected output:
```
test.txt
```
This output confirms that the storage is persistent.

Verify data isolation and persistent storage for a StatefulSet

Steps

Each pod in a StatefulSet has its own PVC, so its data is kept isolated.

Data isolation

Persistent storage

Create a file in one pod and confirm it does not exist in another. This verifies data isolation between the pods' storage volumes.

List the pods to get their names.

kubectl get pod | grep cnfs-nas-sts

Expected output:

cnfs-nas-sts-0 1/1 Running 0 5m
cnfs-nas-sts-1 1/1 Running 0 5m

Create a file in one of the pods. The following example uses the pod namedcnfs-nas-sts-0 to create a file with a distinct name:
```
kubectl exec cnfs-nas-sts-0 -- touch /data/sts-0-data.txt
```
Check if the file exists in the other pod. This example uses the pod namedcnfs-nas-sts-1:
```
kubectl exec cnfs-nas-sts-1 -- ls /data
```
The expected output does not show the file created incnfs-nas-sts-0. This confirms that each StatefulSet pod uses an independent storage volume and the data is isolated.

Delete a specific pod, wait for it to be recreated, and check if the data still exists in the new pod.

Delete a pod to trigger its recreation. This example deletescnfs-nas-sts-0:
```
kubectl delete pod cnfs-nas-sts-0
```

List the pods and wait for the pod with the same name to reach the Running state. A StatefulSet recreates a pod with the same name and identity.

kubectl get pod | grep cnfs-nas-sts

Expected output:

cnfs-nas-sts-0                        1/1     Running   0          19s
cnfs-nas-sts-1                        1/1     Running   0          102s

In the new pod, check if the previously created file exists.
```
kubectl exec cnfs-nas-sts-0 -- ls /data
```
This output confirms that the storage is persistent.
```
sts-0-data.txt
```

CNFS YAML

Run thekubectl get cnfs/<cnfsName> -o yaml command to view the complete configuration and real-time status of a CNFS object.

This section provides an example of the output from running thekubectl get cnfs/cnfs-nas-filesystem -o yaml command for the scenario described in Method 2.

Sample YAML

YAML

apiVersion: storage.alibabacloud.com/v1beta1
kind: ContainerNetworkFileSystem
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"storage.alibabacloud.com/v1beta1","kind":"ContainerNetworkFileSystem","metadata":{"annotations":{},"name":"cnfs-nas-filesystem"},"spec":{"description":"cnfs","parameters":{"encryptType":"SSE-KMS","enableTrashCan":"true","filesystemType":"standard","protocolType":"NFS","storageType":"Capacity","trashCanReservedDays":"5","vSwitchId":"vsw-2ze9l3ppwzg6bl02j****"},"reclaimPolicy":"Retain","type":"nas"}}
  creationTimestamp: "20**-05-14T08:20:09Z"
  finalizers:
  - protection.alibabacloud.com/cnfs
  generation: 6
  name: cnfs-nas-filesystem
  resourceVersion: "122342382"
  uid: a9e9650c-68b2-405b-8274-0f5b6063****
spec:
  description: "cnfs"
  reclaimPolicy: Retain
  type: nas
  parameters:
    encryptType: SSE-KMS
    enableTrashCan: "true"
    filesystemType: standard
    protocolType: NFS
    storageType: Capacity
    trashCanReservedDays: "5"
    vSwitchId: vsw-2ze9l3ppwzg6bl02j****
status:
  conditions:
  - lastProbeTime: "20**-05-14 16:20:15"
    reason: The nas filesystem and mount target complete initialization.
    status: Ready
  fsAttributes:
    accessGroupName: DEFAULT_VPC_GROUP_NAME
    encryptType: SSE-KMS
    enableTrashCan: "true"
    filesystemId: 17f7e*****
    filesystemType: standard
    protocolType: NFS
    regionId: cn-beijing
    server: 17f7e48ece-h****.cn-beijing.nas.aliyuncs.com
    storageType: Capacity
    vSwitchId: vsw-2ze9l3ppwzg6bl02j****
    vpcId: vpc-2ze9sgmehjvwv5x74****
    zoneId: cn-beijing-h
  status: Available

Parameters

Parameters

Parameter	Description
`status`	The current status of the CNFS object. Possible values include Pending, Creating, Initialization (the file system is being created), Available, Unavailable (can be restored), Fatal (cannot be restored), and Terminating.
`conditions.lastProbeTime`	The timestamp of the last health probe.
`conditions.reason`	The reason for the current status.
`conditions.status`	`Ready` indicates the resource is available; `NotReady` indicates it is unavailable.
`fsAttributes.accessGroupName`	The name of the permission group applied to the mount target. Currently, only`DEFAULT_VPC_GROUP_NAME` (the default VPC permission group) is supported.
`fsAttributes.encryptType`	Optional. Specifies whether to enable anencryption method. `None`: Disables encryption. `SSE-KMS`: Enables server-side encryption with keys managed by NAS. NAS creates and manages a key in KMS to encrypt each file system.
`fsAttributes.enableTrashCan`	Specifies whether to enable the recycle bin feature to prevent business disruptions or data loss caused by accidental file deletion. `true`: Enables the feature. `false`: Disables the feature.
`fsAttributes.filesystemId`	The file system ID.
`fsAttributes.filesystemType`	The file system type. The default is General-purpose NAS, specified as `standard`.
`fsAttributes.protocolType`	The file transfer protocol type. Currently, only the NFS protocol is supported.
`fsAttributes.regionId`	The region where the CNFS object is located.
`fsAttributes.server`	The address of the NAS mount target.
`fsAttributes.storageType`	The storage type. General-purpose NAS supports `Performance`, `Capacity`, and `Premium` types.
`fsAttributes.vSwitchId`	The vSwitch used by the CNFS object.
`fsAttributes.vpcId`	The VPC where the CNFS object is located.
`fsAttributes.zoneId`	The availability zone where the CNFS object is located.

Resource cleanup

To avoid unexpected charges and ensure data security, follow these steps to release resources that you no longer need.

Delete the workload
- Action: Delete all applications that use the relevant PVC, such as deployments and StatefulSets. This action stops the pods and unmounts the storage volumes.
- Sample command:kubectl delete deployment <your-deployment-name>
Delete the PVC
- Action: Delete the PVC associated with the application. The outcome of the PV deletion depends on thereclaimPolicy.
  - Retain (recommended): After you delete the PVC, the data and directory on the backend NAS are preserved.
  - Delete: After you delete the PVC, the bound PV is also deleted. How the backend NAS handles the data and directory depends on thearchiveOnDelete parameter in theStorageClass.
    - "true" (default): Instead of being deleted, the directory and files are renamed toarchived-{pvName}.{timestamp}.
    - "false" : The data is permanently deleted. This action is irreversible. Use this setting with caution.
- Sample command:kubectl delete pvc <your-pvc-name>
Delete the PV
- Action: Delete the PV. This step primarily applies to statically provisioned PVs or PVs that are in theReleased state because their reclaim policy is set to Retain.
  This action removes only the resource definition from Kubernetes and does not delete the backend NAS data.
- Sample command:kubectl delete pv <your-pv-name>
Delete Kubernetes storage definitions (Optional)
- Action: Delete the StorageClass and CNFS objects if they are no longer needed.
  This action removes only the resource definitions from Kubernetes and does not delete the backend NAS data.
- Sample commands:kubectl delete sc <your-storageclass-name>,kubectl delete cnfs <your-cnfs-name>
Delete the backend NAS file system
- Action: See Delete a file system. This action permanently deletes all data on the NAS and is irreversible. Proceed with caution. Before performing this action, ensure that no workloads depend on this NAS.

Prerequisites

Create a NAS file system

Methods for adding a NAS file system

Method 1: Automatically create and use a NAS file system

kubectl

Console

Method 2: Create and use a custom NAS file system

kubectl

Static provisioning

Dynamic provisioning

Static provisioning

Dynamic provisioning

Console

PV

Storage class

Method 3: Use an existing NAS file system

kubectl

Static provisioning

Dynamic provisioning

Static provisioning

Dynamic provisioning

Console

PV

Storage class

Configuring shared and isolated storage

Configure a shared NAS volume

Configure an isolated NAS volume

Recommendations for production environments

References

Verify shared storage, data isolation, and persistent storage

CNFS YAML

Sample YAML

Parameters

Resource cleanup