Use Statically Provisioned NAS Volumes-Container Compute Service-阿里云帮助中心

Mount an existing NAS file system to a workload as a static volume to provide persistent storage that multiple pods can share.

A NAS file system, provided by File Storage NAS (NAS), is a distributed file system that offers shared access, elastic scalability, high reliability, and high performance. It suits scenarios such as big data analytics, data sharing, web applications, and log storage. To use an existing NAS file system in a cluster, use the Container Storage Interface (CSI) plugin to create a PersistentVolume and a PersistentVolumeClaim, and then mount the resulting volume to a workload.

Static volume — A static volume requires you to create a PersistentVolume in advance to represent an existing storage resource, such as a NAS file system. An application then creates a PersistentVolumeClaim to match and request that PersistentVolume. This method is commonly used to manage existing storage resources. However, the PersistentVolumeClaim bound to a static volume does not support online extension by default.
Dynamic volume — A dynamic volume does not require you to create a PersistentVolume in advance. When an application creates a PersistentVolumeClaim, the system automatically creates a new volume and a corresponding PersistentVolume based on the StorageClass that is specified in the PersistentVolumeClaim. This mode is more flexible and supports volume extension.
To reuse an existing NAS file system, follow the steps in this topic to create a static volume. If you need online extension or want the system to create the volume automatically, use a dynamic volume instead. For instructions, see Use dynamic NAS volumes.

Prerequisites

An existing NAS file system that meets the following requirements. If no such file system is available, create one or use a dynamic NAS volume. For instructions, see Create a file system or Use NAS dynamic volumes.
- The protocol type must be Network File System (NFS). NAS file systems that use the SMB protocol cannot be mounted.
- The mount target must reside in the same Virtual Private Cloud (VPC) as the cluster nodes, and the Status of the mount target must be Available. To add a mount target, see Manage mount targets.
kubectl connected to the cluster. For instructions, see Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster.

Usage notes

Concurrent writes — NAS is shared storage. A single NAS volume can be mounted to multiple pods, so multiple pods may write data at the same time. Your application must ensure data consistency. For the limits on concurrent writes to NAS, see the following topics:
- How do I prevent exceptions that might occur when multiple processes or clients write to the same log file concurrently?
- How do I resolve the latency issue when writing data to an NFS file system?
Mount duration — If the securityContext.fsgroup parameter is configured in the application template, kubelet runs a chmod or chown operation after the volume is mounted, which increases the mount time. If you have configured the securityContext.fsgroup parameter and want to reduce the mount time, see Long mount times for NAS volumes.
VPC scope — A NAS file system can be mounted only to pods in the same VPC. Cross-VPC mounting is not supported. Within the same VPC, a NAS file system can be mounted across zones.
Encryption — To encrypt the data in a NAS volume, configure the encryption type when you create the NAS file system.

Important

After you mount a NAS volume, do not delete the NAS mount target. Otherwise, the system becomes unresponsive.

Mount a static NAS volume by using kubectl

Only the kubectl method is described.

Step 1: Create a PersistentVolume

Modify the following YAML content and save it as pv-nas.yaml.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nas
  labels:
    alicloud-pvname: pv-nas
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  csi:
    driver: nasplugin.csi.alibabacloud.com
    volumeHandle: pv-nas   # Must be the same as the PersistentVolume name.
    volumeAttributes:
      server: "0c47****-mpk25.cn-shenzhen.nas.aliyuncs.com"  # The NAS mount target address. The VPC of the mount target must be the same as the VPC of the cluster.
      path: "/csi"  # The mount subdirectory.
  mountOptions:
  - nolock,tcp,noresvport
  - vers=3

The following table describes the parameters in the YAML file.

Parameter	Description
`name`	The name of the PersistentVolume.
`labels`	The labels of the PersistentVolume.
`storage`	The capacity of the PersistentVolume. Note The actual available capacity of a NAS volume is not limited by this setting. It is determined by the specifications of the NAS file system. To confirm the available capacity, see General-purpose NAS and Extreme NAS.
`accessModes`	The access mode. Default value: `ReadWriteMany`. Valid values: `ReadWriteMany`, `ReadWriteOnce`, and `ReadOnlyMany`.
`driver`	The driver type. Set this parameter to `nasplugin.csi.alibabacloud.com`, which indicates that the Alibaba Cloud NAS CSI plugin is used.
`volumeHandle`	The unique identifier of the PersistentVolume. The value must be the same as the PersistentVolume name. If you use multiple PersistentVolumes at the same time, this value must be unique for each PersistentVolume.
`server`	The NAS mount target address. The VPC of the mount target must be the same as the VPC of the cluster. To view the mount target address, see Manage mount targets.
`path`	The NAS subdirectory to mount. If this parameter is not set, the root directory is mounted by default. If the directory does not exist in the NAS file system, it is created automatically before the volume is mounted. Note The root directory of a General-purpose NAS file system is `/`, and the root directory of an Extreme NAS file system is `/share`. When you mount a subdirectory of an Extreme NAS file system, `path` must start with `/share`, such as `/share/data`.
`mountOptions`	The mount options of the NAS file system, such as the NFS protocol version. (Recommended) Use NFSv3. Extreme NAS supports only NFSv3. For more information about the NFS protocol, see NFS protocols.

Create the PersistentVolume.
```
kubectl create -f pv-nas.yaml
```
View the PersistentVolume.
```
kubectl get pv
```
Expected output:
```
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM    STORAGECLASS     VOLUMEATTRIBUTESCLASS   REASON   AGE
pv-nas   5Gi        RWX            Retain           Available                             <unset>                          25s
```
Verify that STATUS is Available and CLAIM is empty. This state indicates that the PersistentVolume was created and is not yet bound to a PersistentVolumeClaim. If the PersistentVolume is in another state, see the FAQ section of this topic to troubleshoot the issue.

Step 2: Create a PVC

Save the following YAML template as pvc-nas.yaml:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-nas
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  selector:
    matchLabels:
      alicloud-pvname: pv-nas

Parameter	Description
`name`	Name of the PVC.
`accessModes`	Must match the PV’s access mode. Default: `ReadWriteMany`. You can also set the value to `ReadWriteOnce` or `ReadOnlyMany`.
`storage`	Requested storage capacity. Cannot exceed the PV's capacity. Important The actual available capacity is determined by the NAS file system specifications, not this value. See General-purpose NAS and Extreme NAS for details.
`matchLabels`	Labels used to bind the PVC to the PV.

Create the PVC:
```
kubectl create -f pvc-nas.yaml
```

View the PVC:

kubectl get pvc

Expected output:

NAME       STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
pvc-nas    Bound    pv-nas    5Gi        RWX                           <unset>                 5s

Step 3: Create an application and mount a NAS volume

Save the following YAML as nas.yaml:

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: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        ports:
        - containerPort: 80
        volumeMounts:
          - name: pvc-nas
            mountPath: "/data"
      volumes:
        - name: pvc-nas
          persistentVolumeClaim:
            claimName: pvc-nas

Parameter	Description
`mountPath`	Container path where the NAS volume is mounted.
`claimName`	Name of the PVC to bind.

Deploy the application:
```
kubectl create -f nas.yaml
```

Check pod status:

kubectl get pod -l app=nginx

Expected output:

NAME                  READY   STATUS    RESTARTS   AGE
nas-test-****-***a    1/1     Running   0          32s
nas-test-****-***b    1/1     Running   0          32s

Verify the shared storage and persistent storage features of NAS

The Deployment created in the preceding example provisions two pods and mounts a NAS file system to the pods. You can use the following methods to verify this:

Create a file in one pod and view the file from the other pod to verify shared storage.
Recreate the Deployment. Then, check whether data stored in the file system exists in the newly created pod to verify persistent storage.

View the pod information.

kubectl get pod | grep nas-test

Sample result:

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

Verify shared storage.
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. View the file from the other pod.
  In this example, the nas-test-*****b pod is used:
```
kubectl exec nas-test-*****b -- ls /data
```
  Expected output shows that the newly created file test.txt is shared:
```
test.txt
```
Verify persistent storage.
1. Recreate the Deployment.
```
kubectl rollout restart deploy nas-test
```
2. Wait until the pods are recreated.
```
kubectl get pod | grep nas-test
```
  Sample result:
```
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 file system and can be accessed from the mount directory in the recreated pod.
```
test.txt
```

FAQ

If an error occurs when you mount or use a NAS volume, see the following topics to troubleshoot the issue:

FAQ about NAS volumes — for issues that occur when you mount or manage NAS volumes.
File read and write access issues — for issues that occur when you read data from or write data to a NAS file system.