Use dynamically provisioned NAS volumes to implement persistent storage - Container Compute Service

For scenarios that require high disk I/O throughput and data sharing, you can use File Storage NAS (NAS) as a persistent storage volume. This topic describes how to mount dynamically provisioned NAS volumes. This topic also describes how to check whether a dynamically provisioned NAS volume can be used to persist data and whether the data in a dynamically provisioned NAS volume can be shared across pods.

Background information

NAS is a distributed file system service that features shared access, scalability, high reliability, and high performance. NAS is suitable for scenarios where data sharing and high IOPS are required. For more information, see Storage overview.

Note

Alibaba Cloud Container Compute Service (ACS) supports dynamically provisioned NAS volumes and statically provisioned NAS volumes. This topic describes how to mount a dynamically provisioned NAS volume. For more information about how to mount a statically provisioned NAS volume, see Mount a statically provisioned NAS volume.

Prerequisites

The latest version of managed-csiprovisioner is installed in your Alibaba Cloud Container Compute Service (ACS) cluster.

Note

Go to the ACS cluster management page in the ACS console. In the left-side navigation pane of the cluster management page, choose Operations > Add-ons. On the Storage tab, you can check whether managed-csiprovisioner is installed.

Limits

You cannot mount NAS file systems that use the Server Message Block (SMB) protocol.
When you mount a NAS file system to multiple pods, the pods must be deployed in the same virtual private cloud (VPC). You cannot mount a NAS file system to pods in different VPCs.
You can use only the NFSv3 protocol to mount a NAS file system.

Usage notes

NAS is a shared storage service. You can mount a NAS file system to multiple pods. If a NAS file system is mounted to multiple pods, the data in the file system is shared by the pods. In this case, the application must be able to synchronize data across the pods if the data in the NAS file system is modified by multiple pods.
When you mount a NAS file system to an application, do not add the securityContext.fsgroup parameter to the YAML file of the application. Otherwise, the NAS file system may fail to be mounted.
Note
You cannot grant the permissions to access the / directory of the NAS file system. The user account and user group to which the directory belongs cannot be modified.
After you mount a NAS file system, do not delete the mount target of the NAS file system. Otherwise, an operating system hang issue may occur.

Mount a dynamically provisioned NAS volume

Step 1: Create a StorageClass

Connect to your ACS cluster. For more information, see Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster and Use kubectl on Cloud Shell to manage ACS clusters.

Create a file named nas-sc.yaml and copy the following template to the file. Modify the parameters in the template as required.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: alicloud-nas-fs
mountOptions:
- nolock,tcp,noresvport
- vers=3
parameters:
  volumeAs: filesystem
  fileSystemType: standard
  storageType: Performance
  regionId: cn-shanghai
  zoneId: cn-shanghai-e
  vpcId: "vpc-2ze2fxn6popm8c2mzm****"
  vSwitchId: "vsw-2zwdg25a2b4y5juy****"
  accessGroupName: DEFAULT_VPC_GROUP_NAME
  deleteVolume: "false"
provisioner: nasplugin.csi.alibabacloud.com
reclaimPolicy: Retain

The following table describes the parameters.

Important

NAS file systems of different types and storage specifications support different regions and zones. Specify the region, zone, virtual private cloud (VPC), and vSwitch of the NAS file system and mount target that you want to create based on the storage requirements of your business, the region of the ACS cluster, and the VPC and vSwitch that are used by pods in the ACS cluster. For more information, see the following topics:

For more information about the storage specifications, performance, billing, and supported regions and zones of each type of NAS file system, see General-purpose NAS file systems and Extreme NAS file systems.
General-purpose NAS file systems and Extreme NAS file systems have different limits on mounting connectivity, the number of file systems, and file sharing protocols. For more information, see Limits.
Run the kubectl get cm -n kube-system acs-profile -o yaml command to view the YAML file of the acs-profile, and obtain the VPC ID and vSwitch ID of the pod based on the values of the vpcId and vSwitchIds parameters.

Parameter	Description
`volumeAs`	Only `filesystem` is supported, which indicates that a NAS file system is automatically created. Each NAS volume corresponds to a NAS file system.
`fileSystemType`	The type of the NAS file system. `standard` (default): General-purpose NAS file system. For more information, see General-purpose NAS file systems. `extreme`: Extreme NAS file system. For more information, see Extreme NAS file systems.
`storageType`	The storage type of the NAS file system. For General-purpose NAS file systems, the following values are supported: `Performance` (default) `Capacity` For Extreme NAS file systems, the following values are supported: `standard` (default) `advanced`
`regionId`	The ID of the region to which the NAS file system belongs. The region ID must be the same as that of the ACS cluster.
`zoneId`	The ID of the zone to which the NAS file system belongs. Select a zone based on the vSwitch used by the pod in the ACS cluster.
`vpcId`, `vSwitchId`	The IDs of the VPC and the vSwitch to which the mount target of the NAS file system belongs. Set the values to the IDs of VPC and vSwitch used by pods in the ACS cluster.
`accessGroupName`	The permission group to which the mount target of the NAS file system belongs. Default value: `DEFAULT_VPC_GROUP_NAME`.
`provisioner`	The type of the driver. The parameter must be set to `nasplugin.csi.alibabacloud.com`. This indicates that the Container Storage Interface (CSI) plug-in provided by Alibaba Cloud for NAS is used.
`reclaimPolicy`	The reclaim policy of the persistent volume (PV). Only `Retain` is supported, which indicates that when a PV is deleted, the related NAS file system and mount target are retained.

Create a StorageClass.
```
kubectl create -f nas-sc.yaml
```

View the StorageClass.

kubectl get sc

Expected output:

NAME                             PROVISIONER                       RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
alicloud-nas-fs                  nasplugin.csi.alibabacloud.com    Retain          Immediate              false                  13m
......

Step 2: Create a PVC

Save the following content as a YAML file named nas-pvc-fs.yaml:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: nas-pvc-fs
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: alicloud-nas-fs
  resources:
    requests:
      storage: 20Gi

The following table describes the parameters.

Parameter	Description
`accessModes`	The access mode.
`storage`	The storage capacity allocated to pods. This refers to the capacity of the NAS volume that you want to create. Note An Extreme NAS file system has a minimum capacity limit of 100 GiB. If the NAS file system type defined in the StorageClass is Extreme NAS file system, the value of the `storage` parameter must be greater than or equal to 100 GiB. Otherwise, the corresponding PV cannot be created.
`storageClassName`	The name of the StorageClass that you want to associate.

Create a persistent volume claim (PVC).
```
kubectl create -f nas-pvc-fs.yaml
```

View the PVC.

kubectl get pvc

The following example is returned. The PVC is associated with the PV that is automatically created. You can log on to the NAS console to view the NAS file system.

NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      VOLUMEATTRIBUTESCLASS  AGE
nas-pvc-fs   Bound    nas-04a730ba-010d-4fb1-9043-476d8c38****   20Gi       RWX            alicloud-nas-fs   <unset>                14s

Step 3: Create an application and mount a NAS volume

Create a file named nas-test-fs.yaml and add the following content to the file:

The following YAML template provides an example on how to create a Deployment that contains two pods. The two pods use a PVC named nas-pvc-fs to apply for storage resources. The two pods are mounted to the /data path.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nas-test
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginx:latest
        ports:
        - containerPort: 80
        volumeMounts:
          - name: pvc-nas
            mountPath: /data
      volumes:
        - name: pvc-nas
          persistentVolumeClaim:
            claimName: nas-pvc-fs

Create a Deployment and mount a NAS volume.
```
kubectl create -f nas-test-fs.yaml
```

Check whether the pods provisioned by the Deployment are deployed.

kubectl get pod | grep nas-test

The following output shows that two pods are created:

nas-test-****-***a   1/1     Running   0          40s
nas-test-****-***b   1/1     Running   0          40s

View files in the mount path.
Run the following command to view files in the mount path. The data in the mount directory of the NAS file system is expected to be returned. By default, no data is returned.
```
kubectl exec nas-test-****-***a -- ls /data
```

Check whether data sharing and persistence are enabled based on the NAS file system

The Deployment created in the preceding example provisions two pods and a NAS file system is mounted to the pod. Perform the following steps to test whether data sharing and persistence are enabled:

Create a file in one pod and access the file from the other pod. If the access succeeds, data sharing is enabled.
Recreate the Deployment. Access the NAS volume from a recreated pod to check whether the original data still exists in the NAS file system. If the data still exists, data persistence is enabled.

View the pod information.

kubectl get pod | grep nas-test

Expected output:

nas-test-****-***a   1/1     Running   0          40s
nas-test-****-***b   1/1     Running   0          40s

Check whether data sharing is enabled.
1. Create a file in a pod.
  In this example, the nas-test-****-***a pod is used.
```
kubectl exec nas-test-****-***a -- touch /data/test.txt
```
2. Access the file you created from the other pod.
  In this example, the nas-test-****-***b pod is used.
```
kubectl exec nas-test-****-***b -- ls /data
```
  The following output shows that the test.txt file you created in the nas-test-****-***a pod can be accessed from the nas-test-****-***b pod.
```
test.txt
```
Check whether data persistence is enabled.
1. Recreate the Deployment.
```
kubectl rollout restart deploy nas-test
```
2. After the pods are recreated, check the recreated pods.
```
kubectl get pod | grep nas-test
```
  Expected output:
```
nas-test-****-***c   1/1     Running   0          67s
nas-test-****-***d   1/1     Running   0          49s
```
3. Log on to a recreated pod and check whether the file still exists in the file system.
  In this example, the nas-test-c*** pod is used.
```
kubectl exec nas-test-****-***c -- ls /data
```
  The following output shows that the file still exists in the NAS volume and can be accessed from the mount directory in the recreated pod.
```
test.txt
```