Container Service for Kubernetes:Mount a dynamically provisioned NAS volume

Use scenarios

• Your application requires high disk I/O.

• You need a storage service that offers higher read and write throughput than Object Storage Service (OSS).

• You want to share files across hosts. For example, you want to use a NAS file system as a file server.

Limits

• NAS is a shared storage service. A PVC that is used to mount a NAS file system can be used by multiple pods.

• Do not delete the mount target before you unmount the NAS file system. Otherwise, the operating system hang may occur.

• After a mount target is created, wait until the state of the mount target changes to Available.

• We recommend that you use NFSv3.

• Before you use NAS volumes, we recommend that you upgrade the CSI plug-in to the latest version.

• General-purpose and Extreme NAS file systems have different limits on mounting scenarios, the number of file systems, and file sharing protocols. For more information, see Limits.

Considerations

• NAS is a shared storage service. A persistent volume claim (PVC) that is used to mount a NAS file system can be shared among pods. For more information about the limits on concurrent writes to NAS, see How do I prevent exceptions that may occur when multiple processes or clients concurrently write data to a log file? and How do I resolve the latency in writing data to an NFS file system?

• To mount an Extreme NAS file system, set the path parameter in the StorageClass of the NAS volume to a subdirectory of /share. For example, a value of 0cd8b4a576-g****.cn-hangzhou.nas.aliyuncs.com:/share/subpath indicates that the mounted subdirectory of the NAS file system is /share/subpath.

• The capacity of the PVC that is used to mount a NAS file system takes effect only when the file system type is General-purpose and the allowVolumeExpansion parameter of the StorageClass is set to true. In this case, CSI sets the quota of a NAS directory based on the PVC capacity. The actual quota is calculated by rounding up the PVC capacity to the next integer. The quota is measured in GiB.

  The NAS directory quota takes effect asynchronously. After a persistent volume (PV) is dynamically provisioned, the directory quota does not immediately take effect, and the quota may be exceeded if a large amount of data is written within a short period of time. For more information about NAS directory quotas, see Manage directory quotas.

• If the securityContext.fsgroup parameter is set in the application template, the kubelet performs the chmod or chown operation after the volume is mounted, which increases the time consumption.

  Note

  For more information about how to accelerate the mounting when the securityContext.fsgroup parameter is set, see Why does it require a long time to mount a NAS volume?

Mount a dynamically provisioned NAS volume

The CSI plug-in allows you to mount a dynamically provisioned NAS volume in subpath or filesystem mode in the ACK console or by using kubectl.

subpath mode: You can use the ACK console or kubectl to mount NAS volumes in subpath mode.

If multiple applications or pods need to use the same NAS volume to share data, or you want to mount different subdirectories of a NAS file system to different pods, you can use the subpath mode.

filesystem mode: You can use only kubectl to mount NAS volumes in filesystem mode.

If your application needs to dynamically create and delete NAS file systems and mount targets, you can use the filesystem mode.

Verify that the NAS file system can be used to persist data

NAS provides persistent storage. When a pod is deleted, the recreated pod automatically synchronizes the data of the deleted pod.

Perform the following steps to verify that NAS file system can be used to persist data:

1. Query the pods that are created for the application and the files in the mounted NAS file system.

   1. Run the following command to query the pods that are created for the application:

      kubectl get pod 

      Expected output:

      NAME                                READY   STATUS    RESTARTS   AGE
      deployment-nas-1-5b5cdb85f6-n****   1/1     Running   0          32s
      deployment-nas-2-c5bb4746c-4****    1/1     Running   0          32s

   2. Run the following command to query files in the /data path of a pod. In this example, the pod deployment-nas-1-5b5cdb85f6-n**** is used.

      kubectl exec deployment-nas-1-5b5cdb85f6-n**** -- ls /data

      No output is returned. This indicates that no file exists in the /data path.

2. Run the following command to create a file named nas in the /data path of the pod deployment-nas-1-5b5cdb85f6-n****:

   kubectl exec deployment-nas-1-5b5cdb85f6-n**** -- touch /data/nas

3. Run the following command to query the files in the /data path of the pod deployment-nas-1-5b5cdb85f6-n****:

   kubectl exec deployment-nas-1-5b5cdb85f6-n**** -- ls /data

   Expected output:

   nas

4. Run the following command to delete the pod:

   kubectl delete pod deployment-nas-1-5b5cdb85f6-n****

5. Open another CLI and run the following command to view how the pod is deleted and recreated:

   kubectl get pod -w -l app=nginx

6. Verify that the file still exists after the pod is deleted.

   1. Run the following command to query the name of the recreated pod:

      kubectl get pod

      Expected output:

      NAME                                READY   STATUS    RESTARTS   AGE
      deployment-nas-1-5b5cdm2g5-m****    1/1     Running   0          32s
      deployment-nas-2-c5bb4746c-4****    1/1     Running   0          32s

   2. Run the following command to query files in the /data path of the pod deployment-nas-1-5b5cdm2g5-m****.

      kubectl exec deployment-nas-1-5b5cdm2g5-m**** -- ls /data

      Expected output:

      nas

      The nas file still exists in the /data path. This indicates that data is persisted in the NAS file system.

Verify that data in the NAS file system can be shared across pods

You can mount a NAS volume to multiple pods. When the data is modified in one pod, the modifications are automatically synchronized to other pods.

Perform the following steps to verify that data in the NAS file system can be shared across pods:

1. Query the pods that are created for the application and the files in the mounted NAS file system.

   1. Run the following command to query the pods that are created for the application:

      kubectl get pod 

      Expected output:

      NAME                                READY   STATUS    RESTARTS   AGE
      deployment-nas-1-5b5cdb85f6-n****   1/1     Running   0          32s
      deployment-nas-2-c5bb4746c-4****    1/1     Running   0          32s

   2. Run the following command to query files in the /data path of each pod:

      kubectl exec deployment-nas-1-5b5cdb85f6-n**** -- ls /data
      kubectl exec deployment-nas-2-c5bb4746c-4**** -- ls /data

2. Run the following command to create a file named nas in the /data path of a pod:

    kubectl exec deployment-nas-1-5b5cdb85f6-n**** -- touch /data/nas

3. Run the following command to query files in the /data path of each pod:

   1. Run the following command to query the files in the /data path of the pod deployment-nas-1-5b5cdb85f6-n****:

      kubectl exec deployment-nas-1-5b5cdb85f6-n**** -- ls /data

      Expected output:

      nas

   2. Run the following command to query files in the /data path of the pod deployment-nas-2-c5bb4746c-4****.

      kubectl exec deployment-nas-2-c5bb4746c-4**** -- ls /data

      Expected output:

      nas

      After you create a file in the /data path of one pod, you can find the file in the /data path of the other pod. This indicates that data in the NAS file system is shared by the two pods.

Enable user isolation or user group isolation

1. Use the following YAML template to create an application. The containers of the application start processes and create directories as the nobody user. The user identifier (UID) and group identifier (GID) of the nobody user are 65534.

   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: nas-sts
   spec:
     selector:
       matchLabels:
         app: busybox
     serviceName: "busybox"
     replicas: 1
     template:
       metadata:
         labels:
           app: busybox
       spec:
         securityContext:
           fsGroup: 65534    # The containers create directories as the nobody user. The UID and GID of the nobody user are 65534. 
           fsGroupChangePolicy: "OnRootMismatch"    # Permissions and ownership are changed only if the permissions and the ownership of the root directory do not meet the requirements of the volume. 
         containers:
         - name: busybox
           image: busybox
           command:
           - sleep
           - "3600"
           securityContext:
             runAsUser: 65534    # All processes in the containers run as the nobody user (UID 65534). 
             runAsGroup: 65534   # All processes in the containers run as the nobody user (GID 65534). 
             allowPrivilegeEscalation: false
           volumeMounts:
           - name: nas-pvc
             mountPath: /data
     volumeClaimTemplates:
     - metadata:
         name: nas-pvc
       spec:
         accessModes: [ "ReadWriteOnce" ]
         storageClassName: "alicloud-nas-subpath"
         resources:
           requests:
             storage: 100Gi

2. Run the following top command in a container to check whether the command is run as the nobody user:

   kubectl exec nas-sts-0 -- "top"

   Expected output:

   Mem: 11538180K used, 52037796K free, 5052K shrd, 253696K buff, 8865272K cached
   CPU:  0.1% usr  0.1% sys  0.0% nic 99.7% idle  0.0% io  0.0% irq  0.0% sirq
   Load average: 0.76 0.60 0.58 1/1458 54
     PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
      49     0 nobody   R     1328  0.0   9  0.0 top
       1     0 nobody   S     1316  0.0  10  0.0 sleep 3600

   The output shows that the top command is run as the nobody user.

3. Run the following to check whether the nobody user is used to create the directories and files in the mount directory of the NAS file system:

   kubectl exec nas-sts-0 -- sh -c "touch /data/test; mkdir /data/test-dir; ls -arlth /data/"

   Expected output:

   total 5K
   drwxr-xr-x    1 root     root        4.0K Aug 30 10:14 ..
   drwxr-sr-x    2 nobody   nobody      4.0K Aug 30 10:14 test-dir
   -rw-r--r--    1 nobody   nobody         0 Aug 30 10:14 test
   drwxrwsrwx    3 root     nobody      4.0K Aug 30 10:14 .

   The output shows that the nobody user is used to create the test file and the test-dir directory in the /data directory.

References

• For more information about how to use CNFS to manage NAS file systems, see Use CNFS to manage NAS file systems (recommended) and Use CNFS to manage NAS file systems.

• For more information about how to dynamically expand a NAS volume, see Use CNFS to automatically expand NAS volumes.

• For more information about how to use the directory quota feature of NAS to manage the storage space of volumes, see Expand a NAS volume.