Data Management Center (DMC) is a storage management solution offered by Volcano Engine that enables unified storage management, data orchestration, and data mobility. It encapsulates multiple storage services and provides a unified access point to facilitate centralized storage management. This topic describes how to configure and mount a static DMC PV in a VKE cluster using the FSX client.

Prerequisites

The csi-fsx add-on has been installed and upgraded to v0.7.0 or later.

The fsx-service add-on has been installed and upgraded to v0.12.0 or later.

You have created data sources, for example, TOS buckets, EFS filesystems, or vePFS filesystems.

You have created the required access key (AK/SK) for mounting the DMC dataset storage. For details on obtaining the AK/SK, see Obtaining API access keys. To use a temporary token for authentication, you need to implement the logic for refreshing tokens.

(Optional) If you perform configuration by using YAML, make sure that the kubectl tool has been installed in the local environment and is connected to the target cluster. For details, see Connecting to a cluster.

Usage limits

DMC is available only in certain regions. Refer to the console for DMC availability in a specific region.

If a Pod mounting a DMC PV experiences conflicts with other PV types, the system prioritizes DMC PV mounting and fails the mounting of other PV types.

Online updates of a unified access point are not supported. If the access point ID changes, we recommend re-creating a PV.

Procedure

Step 1: Create a DMC dataset

Log in to the DMC console.

In the left navigation pane, click Data set management. On the resulting page, click Create dataset. Create a DMC dataset and bind the desired data source. This example binds both EFS volumes and TOS volumes to the DMC dataset. For details, see Creating datasets.

Click Confirm.

Step 2: Create a unified access point

Click the name of the target dataset.

In the left navigation pane, click Unified integrated point. On the page that appears, click Create. For more configuration details, see Managing access points.

Click Confirm.

After the configuration is complete, obtain the access point ID and view details of the mounted volumes on the access point details page.

Step 3: Create a Secret

Create a YAML file for the Secret. The following fsx-secret.yaml file serves as an example:

apiVersion: v1
kind: Secret
metadata:
name: fsx-key # Secret name. If the cluster version is 1.26.x, the name cannot contain the . character. Other cluster versions do not have this limit.
namespace: default # Namespace of the Secret.
type: Opaque # Secret type. In this example, select it to Opaque to store arbitrary key-value pairs.
data:
AccessKeyId: ${ak} # The Base64-encoded account AK. Replace the value with your actual information.
SecretAccessKey: ${sk} # The Base64-encoded SK that matches the AK. Replace the value with your actual information.
ExpiredTime: ${Temporary Token expiration time} # The Base64-encoded expiration time of the temporary token. If you use an AK and SK, do not specify this field.
SessionToken: ${Temporary Token content} # The Base64-encoded content of the temporary token. If you use an AK and SK, do not specify this field.

Run the following command to create the Secret.

kubectl create -f fsx-secret.yaml

Step 4: Create a PV

Creating through the console

Creating through kubectl

Log in to the VKE console.

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 > PersistentVolume.

Click Create PersistentVolume to create a DMC PV that is accessible over FSX.

Parameter	Description
How to create	Select a method for creating the PV. Currently, you can select Static creation.
Name	Specify a name for the PV. The name must be unique within the cluster.
StorageClass type	Select a storage type. In this scenario, select Data management center.
Access type	Select an access type for the PV. In this scenario, select FSX.
Unified access point	The unique identifier for DMC storage. Select the access point in the same region as the cluster from the drop-down list. If the list is empty, create one in the DMC console.
Access key	Select the access key for DMC storage. The access key specified here is used to authorize VKE to access DMC storage. If no access key is available, click Create key and configure the key name, associated namespace, and the AK and SK of the IAM user. warning If you use clusters running on Kubernetes v1.26.x, you cannot use Secrets whose names contain dots (.). Otherwise, the PV will fail to be created.

Click Confirm.

Create a YAML file for the PV. The following pv-dmc-demo.yaml file serves as an example:

apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-dmc-demo
spec:
accessModes: # PV access mode. The only supported mode is ReadWriteMany, which allows read and write access by multiple nodes.
- ReadWriteMany
capacity:
storage: 100Gi # Declared PV capacity in Gi. This field is only for validation, and does not actually impose a capacity limit.
csi:
driver: fsx.csi.volcengine.com # Driver required for storage mount.
volumeAttributes:
type: "DMC" # The PV type. In this example, set it to "DMC" to specify Data Management Center.
oneAccessPointId: "dmc-oap-42cca***" # The ID of the unified access point for the DMC dataset.
oneAccessPointVersion: "v1" # The version number of the DMC access point. The default is v1.
enableMultiMount: "true" # Specify system-level nested mount propagation logic. It must be set to true.
secretName: "fsx-key" # The name of the Secret for authentication.
secretNamespace: "default" # The namespace of the Secret for authentication.
volumeHandle: pv-dmc-demo # The unique identifier of the PV. Keep it consistent with the PV name.
persistentVolumeReclaimPolicy: Delete # PV reclaim policy. Value: Retain or Delete.
volumeMode: Filesystem # PV type. Only Filesystem is supported (using PVs as filesystems).

The key parameters are described in the following table.

Parameter	Description
accessModes	The PV access mode. Only ReadWriteMany is supported, which allows the PV to be read and written by multiple pods.
storage	The PV capacity. Unit: Gi.
driver	The driver required for PV mounting. In this example, set it to fsx.csi.volcengine.com to specify the csi-fsx add-on.
type	The PV type. In this example, set it to "DMC" to specify Data Management Center.
oneAccessPointId	The ID of the access point for the DMC dataset.
oneAccessPointVersion	The version number of the DMC access point. The default is v1.
enableMultiMount	Specify system-level nested mount propagation logic. It must be set to true.
secretName	The name of the created Secret when you use AK/SK authentication. If you use IRSA authentication, this parameter can be omitted.
secretNamespace	The namespace to which the created Secret belongs when you use AK/SK authentication. If you use IRSA authentication, this parameter can be omitted.
volumeHandle	The unique identifier of the PV. Keep it consistent with the PV name.
persistentVolumeReclaimPolicy	The PV reclaim policy. The following information is included: Retain: The Retain policy. When the PVC bound to the PV is deleted, the PV is retained. Delete: The Delete policy. When the PVC bound to the PV is deleted, the PV is deleted synchronously.
volumeMode	The PV type. Only Filesystem is supported. This means the PV is used 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.

Run the following command to create the PV.

kubectl create -f pv-dmc-demo.yaml

Step 5: Create a PVC

Creating through the console

Creating through kubectl

Click the name of the target cluster. In the left navigation bar of the cluster management page, click Storage > PersistentVolumeClaim.

Click Create PersistentVolumeClaim to configure the PVC.

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 a storage type. In this scenario, select Data management center.
PersistentVolume	Select the PV created in the previous step.

Click Confirm.

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

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-dmc-demo # PVC name.
namespace: default # Namespace to which the PVC belongs.
spec:
accessModes: # PVC access mode. You can select only ReadWriteMany, which allows read-write access by multiple nodes. Keep it consistent with that in the PV configuration.
- ReadWriteMany
resources:
requests:
storage: 100Gi # Declared storage usage in Gi. This field is only for validation, and does not actually impose a capacity limit.
volumeMode: Filesystem # PV type. Only Filesystem is supported (using PVs as filesystems).
volumeName: pv-dmc-demo # Name of the created PV.

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. Keep it consistent with that in the PV configuration.
storage	The declared storage capacity. Unit: Gi.
volumeMode	The PV type. It must be consistent with the type configured for the PV. Only Filesystem is supported. This means the PV is used 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.
volumeName	The name of the PV, which must be consistent with the name configured for the PV.

Run the following command to create the PVC.

kubectl create -f pvc-dmc-demo.yaml

Run the following command to view the result of the static association between the PVC and PV.

kubectl get pvc

If the response is similar to the following one, the binding is successful.

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pv-dmc-demo Bound pv-dmc-demo 100Gi RWX 2m36s

Step 6: Create an application and mount the PV

Creating through the console

Creating through kubectl

After the static DMC PV is created, you can mount it to a workload for use: Deployment, StatefulSet, Job, CronJob, or DaemonSet.

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

warning

Since the data source path is already bound during DMC dataset configuration, do not configure the subPath parameter when mounting DMC in the workload.

Validate the result

After creating the workload and mounting the PV, you can validate the DMC storage mounting, shared storage, and persistent storage by following the steps below.

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

kubectl exec fsx-demo-5f55*** -- df | grep tmp

The expected output is similar to the following one. In this example, since DMC mounts both an EFS PV and a TOS PV, you can see that different PVs correspond to different paths in the Pod.

BFB6F***:ap-df8***.cnbja5ef***.3pspvso***.cn-beijing.efs.ivolces.com:/ 10995116277760 0 10995116277760 0% /tmp/efs
BFC74***:doc-tos-demo:/ 9007199254740992 0 9007199254740992 0% /tmp/tos

Run the following command to view the data in the PV of the Pod. This example shows how to view data in the TOS PV.

kubectl exec fsx-demo-5f55*** -- ls /tmp/tos

The expected response is as follows.

lost+found

Write a file to the PV.

kubectl exec fsx-demo-5f55*** -- touch /tmp/tos/test

Delete the pod.

kubectl delete pod fsx-demo-5f55***

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

kubectl exec fsx-demo-7678*** -- ls /tmp/tos

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

Volcengine Kubernetes Engine