Docs

Volcengine Kubernetes Engine

NFS access methods

Using dynamic EFS PVs via NFS

This topic describes how to create an EFS StorageClass (SC) and PersistentVolumeClaim (PVC) by using NFS, and how a workload uses a dynamic EFS PV.

Prerequisites

The csi-nas add-on has been installed. For details, see csi-nas.

An EFS filesystem and mount point have been created. For details, see Creating an EFS filesystem and Managing mount points.

(Optional) The kubectl tool has already been installed locally, and the target cluster has been connected by using kubectl. For details, see Connecting to a cluster.

Usage limits

StatefulSets require exclusive access to a volume, and do not support a manually created PVC.

Creating through the console

Step 1: Create an SC

In the left navigation bar, click Cluster. Click the name of the target cluster to go to the cluster management page.

In the left navigation bar on the cluster management page, click Storage > StorageClass.

Click Create StorageClass and configure parameters on the page that appears.

Parameter	Description
Name	Specify a name for the StorageClass. The name must be unique within the cluster.
StorageClass type	Select the storage type. In this scenario, select EFS.
Access type	Select an access type for the PV. In this scenario, select NFS.
Availability zone	Availability Zones (AZs) are physically isolated infrastructure units within a single region, featuring independent power and networking systems. AZs communicate with each other over internal networks.
Billing type	Select a resource billing type as needed. Currently, pay-as-you-go is supported.
Project	Assign the StorageClass to a project so that you can perform operations such as maintenance and authorization at the project level. By default, the default project is selected. For details, see Project management.
Mount point	Select the EFS filesystem and mount point.
Subdirectory	Enter a valid subdirectory that complies with the on-screen rules. By default, the root directory (/) is used. tip Ensure that the subdirectory already exists in in the NFS file system.
NFS version	Select an NFS version for the PV. NFSv3 and NFSv4.1 are supported.
Reclaim policy	The PV reclaim policy. Available options include: Delete: When you delete the PVC, the specified Delete policy applies. When Delete policy is set to Delayed deletion, the PV and EFS data will be archived and will not be permanently deleted. When Delete policy is set to Delete now, the PV and EFS data will be deleted. Retain: When you delete the PVC, the PV and EFS data will not be deleted. If necessary, you can manually delete them. tip We recommend that you select Retain to prevent accidental data deletions.
PersistentVolume binding mode	Select a PV binding mode. The following information is included: Immediate: Performs PV binding and allocation when the PVC is created. WaitForFirstConsumer: Delays PV binding and allocation until a pod that uses the PVC is created.

Click Confirm.

Step 2: Create a PVC

In the left navigation bar on the cluster management page, click Storage > PersistentVolumeClaim.

Click Create PersistentVolumeClaim and configure parameters on the page that appears.

Parameter	Description
Namespace	Select the namespace to which the PVC belongs. We recommend selecting a custom namespace or the system-created default namespace. For details about namespaces, see Namespace overview.
Name	Specify a name for the PVC. The name must be unique within the cluster.
StorageClass type	Select the storage type. In this scenario, select EFS.
Access mode	Select a PVC access mode. Currently, you can select ReadWriteMany, which enables read and write access by multiple nodes.
Billing type	Select a resource billing type as needed. Currently, pay-as-you-go is supported.
How to create	Configure the method for creating a PVC. In this scenario, select Create based on StorageClass.
StorageClass	Select a StorageClass. The system automatically binds a PV that has the same StorageClass and a capacity greater than or equal to the capacity size defined in the PVC.
Capacity	Configure the PV capacity in Gi.

Click Confirm.

Step 3: Create an application and mount the PV

After the PV is created, add it to a workload that will use it. Supported workloads include Deployment, StatefulSet, Job, CronJob, and DaemonSet.

You can add a PV to a workload when creating it or updating it. For details, see Workloads.

Creating through kubectl

Step 1: Create an SC

Create a YAML file for the SC. The following vke-efs-sc.yaml file serves as an example:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: vke-efs-sc # StorageClass name.
provisioner: nas.csi.volcengine.com # (Required) The driver required for volume mounting. In this example, set the value to nas.csi.volcengine.com, which indicates the csi-nas add-on.
parameters:
fsType: efs # (Required) The filesystem type. The value is efs in this scenario.
volumeAs: subpath # (Required) Subdirectory type. Value: subpath (indicating a subpath) or filesystem (indicating a filesystem).
server: cnbja5ef96***.3pspvsoy8hyps6c***.efs.ivolces.com # (Required) The domain of the EFS filesystem mount point when you create a PV as a subdirectory.
subPath: / # (Required) The subdirectory of the subpath-type EFS filesystem after the mount operation. The csi-nas add-on creates directories in the subdirectory as the back-end storage of the dynamic PV.
archiveOnDelete: "true" # (Required) Whether to enable the delayed deletion policy. Valid values include true and false. true indicates that the PV and EFS data will be archived and not deleted. false indicates that the PV and EFS data will be deleted.
mountOptions:
- nolock,proto=tcp,noresvport
- vers=3 # Protocol version for mounting the data volume. Value: 3 (indicating NFSv3) or 4.1 (indicating NFSv4.1).
reclaimPolicy: Delete # PV reclaim policy. Value: Retain or Delete.
volumeBindingMode: Immediate # Volume binding mode. Values include Immediate (indicating immediate binding and allocation) and WaitForFirstConsumer (indicating delayed binding and allocation).

The key parameters are described in the following table.

Parameter	Description
provisioner	The driver for mounting a PV. In this example, you need to set the value to nas.csi.volcengine.com, which indicates the csi-nas add-on.
fsType	Filesystem type. In this example, set the value to efs to specify EFS.
volumeAs	Specify the subdirectory type of EFS storage. Available options include: subpath: Create a subdirectory in an existing filesystem. filesystem: Create a new filesystem.
server	The domain of the EFS filesystem mount point. tip When volumeAs is set to subpath (creating a subdirectory in an existing filesystem), this field is required.
subPath	The subdirectory after EFS mounting. The system will create directories within this subdirectory as the backend storage for dynamically provisioned volumes.
archiveOnDelete	Whether to synchronously delete PVs when the PVC is deleted. Valid values include: true: Delayed PV deletion. When the PVC is deleted, the EFS data will not be deleted synchronously. false: Immediate deletion. When the PVC is deleted, the EFS data will be deleted synchronously.
volumeHandle	The unique identifier of the PV. Keep it consistent with the name of the PV.
mountOptions	Configure PV mount parameters, which support dynamic modification and only take effect on newly mounted PVs instead of those already mounted. You can use the vers parameter to specify the NFS version number for mounting the PV. Valid values: 3: Indicates NFSv3. 4.1: Indicates NFSv4.1.
reclaimPolicy	The PV reclaim policy. Valid values: Delete: When you delete the PVC, the PV and the data in the PV will be simultaneously deleted. Retain: When you delete the PVC, the PV and the data in the PV will not be simultaneously deleted. You need to manually delete them. warning We recommend that you select Retain to prevent accidental data deletions. Under the Delete policy, deleted data cannot be restored. Proceed with prudence when selecting the Delete policy.
volumeBindingMode	The binding mode of the PV. Values: Immediate: Performs PV binding and allocation when the PVC is created. WaitForFirstConsumer: Delays PV binding and allocation until a pod that uses the PVC is created.

Run the following command to create the StorageClass.

kubectl create -f vke-efs-sc.yaml

Step 2: Create a PVC

Create a YAML file for the PVC. The following vke-efs-pvc.yaml serves as an example:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: vke-efs-pvc # PVC name.
namespace: default # Namespace to which the PVC belongs.
spec:
accessModes: # PVC access mode. Currently, only ReadWriteMany is supported. ReadWriteMany allows read and write access from multiple nodes.
- ReadWriteMany
resources:
requests:
storage: 100Gi # The declared storage capacity. Unit: Gi.
storageClassName: vke-efs-sc # StorageClass name.
volumeMode: Filesystem # The PV type. Valid values: Filesystem (using the volume as a file system) or Block (using the volume as a block device).

The key parameters are described in the following table.

Parameter	Description
accessModes	The PVC access mode. You can only select ReadWriteMany, which enables read and write access by multiple nodes.
storage	The declared storage capacity in Gi. The value is an integer within the range of 1 to 16384.
storageClassName	The name of the created SC.
volumeMode	The PV types. Valid values: Filesystem: (Default) Use the PV as a file system. The PV will be formatted and mounted to a file system (such as ext4 and xfs), and the file system will be mounted to a specified path in the container. You can use the ls command (such as ls /data) in the container to view the mounted directories or files, and directly read and write files. Block: Use the volume as a block device. It is directly exposed to the container without being formatted or mounted to a file system. You can perform operations on the block device by using paths such as /dev/block/xxx, and applications must support read and write operations on the raw block device.

Run the following command to create the PVC.

kubectl create -f vke-efs-pvc.yaml

Run the following command to check whether the dynamic volume declared by the PVC has been created.

kubectl get pvc

The expected result is as follows:

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
vke-efs-pvc Bound pvc-6318***-3d355a768220 100Gi RWX vke-efs-sc 5s

Step 3: Create an application and mount the PV

Create a YAML file for the Deployment. The following vke-dynamic-efs-deployment.yaml serves as an example:

apiVersion: apps/v1
kind: Deployment
metadata:
name: dynamic-efs-deploy
spec:
replicas: 1
selector:
matchLabels:
app: dynamic-efs-deploy
template:
metadata:
labels:
app: dynamic-efs-deploy
spec:
containers:
- image: doc-cn-beijing.cr.volces.com/vke/nginx-demo:v1.0
name: nginx
volumeMounts:
- mountPath: /tmp # The location where the EFS storage is mounted in the container.
name: efs-pv
volumes:
- name: efs-pv
persistentVolumeClaim:
claimName: vke-efs-pvc # The name of the created PVC.

Run the following command to create the Deployment.

kubectl create -f vke-dynamic-efs-deployment.yaml

Validate the result

After creating a workload and mounting a PV to it as described in the preceding steps, you can verify the volume mounting status and persistent storage via the following methods.

Run the following command to check whether the PV is mounted to the specified path in the pod.

kubectl exec dynamic-efs-deploy-665769f*** -- df | grep tmp

The expected response is as follows.

cnshb***.3qda7dut***.efs.ivolces.com:/tmp/pvc-6318d*** 10995116277760 0 10995116277760 0% /tmp

Check the mount path in the pod to view the data in the PV.

kubectl exec dynamic-efs-deploy-665769f*** -- ls /tmp

The expected response is as follows.

lost+found

Write a file to the PV.

kubectl exec dynamic-efs-deploy-665769f*** -- touch /tmp/test

Delete the pod.

kubectl delete pod dynamic-efs-deploy-665769f***

Check the mount path of the PV in the newly created pod.

kubectl exec dynamic-efs-deploy-665769f*** -- ls /tmp

The expected result is as follows. You can see that the file written to the PV still exists and is not deleted along with the pod. This indicates that persistent storage of data is achieved.

lost+found
test