This section describes how to use StorageClasses to dynamically create PVs and PVCs for data persistence and sharing in workloads.
apiVersion: v1kind: PersistentVolumeClaimmetadata:name: pvc-sfs-autonamespace: defaultannotations:everest.io/csi.volume-name-prefix: test # (Optional) Storage volume name prefix of the automatically-created underlying storagespec:accessModes:- ReadWriteMany # The value must be ReadWriteMany for SFS.resources:requests:storage: 1Gi # SFS volume capacitystorageClassName: csi-nas # The StorageClass is SFS.
Parameter | Mandatory | Description |
|---|---|---|
storage | Yes | Requested capacity in the PVC, in Gi. For SFS, this parameter is only for verification. It must not be empty or 0, and its value is fixed at 1. Any value you set will not take effect. |
everest.io/csi.volume-name-prefix | No | (Optional) This parameter is available only when the cluster version is v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0, or later, and Everest v2.4.15 or later is installed in the cluster. This parameter specifies the name of the underlying storage that is automatically created. The actual underlying storage name is in the format of "Storage volume name prefix + PVC UID". If this parameter is left blank, the default prefix pvc will be used. Enter 1 to 26 characters that cannot start or end with a hyphen (-). Only lowercase letters, digits, and hyphens (-) are allowed. For example, if the storage volume name prefix is set to test, the actual underlying storage name is test-{UID}. |
kubectl apply -f pvc-sfs-auto.yaml
apiVersion: apps/v1kind: Deploymentmetadata:name: web-demonamespace: defaultspec:replicas: 2selector:matchLabels:app: web-demotemplate:metadata:labels:app: web-demospec:containers:- name: container-1image: nginx:latestvolumeMounts:- name: pvc-sfs-volume # Volume name, which must be the same as the volume name in the volumes fieldmountPath: /data # Location where the storage volume is mountedimagePullSecrets:- name: default-secretvolumes:- name: pvc-sfs-volume # Volume name, which is user-definedpersistentVolumeClaim:claimName: pvc-sfs-auto # Name of the created PVC
kubectl apply -f web-demo.yaml
After the workload is created, the data in the container mount directory will be persistently stored. Verify the storage by referring to Verifying Data Persistence and Sharing.
kubectl get pod -n <namespace> | grep web-demo
Expected output:
kubectl exec -n <namespace> web-demo-846b489584-mjhm9 -- ls /datakubectl exec -n <namespace> web-demo-846b489584-wvv5s -- ls /data
If no result is returned for both pods, no file exists in the /data path.
kubectl exec -n <namespace> web-demo-846b489584-mjhm9 -- touch /data/static
kubectl exec -n <namespace> web-demo-846b489584-mjhm9 -- ls /data
Expected output:
static
kubectl delete pod -n <namespace> web-demo-846b489584-mjhm9
Expected output:
pod "web-demo-846b489584-mjhm9" deleted
After the deletion, the Deployment controller automatically creates a replica.
kubectl get pod -n <namespace> | grep web-demo
The expected output is as follows, in which web-demo-846b489584-d4d4j is the newly created pod:
kubectl exec -n <namespace> web-demo-846b489584-d4d4j -- ls /data
Expected output:
static
The static file is retained, indicating that the data can be stored persistently.
kubectl get pod -n <namespace> | grep web-demo
Expected output:
kubectl exec -n <namespace> web-demo-846b489584-d4d4j -- touch /data/share
Check the files in the /data path of the pod.
Expected output:
sharestatic
kubectl exec -n <namespace> web-demo-846b489584-wvv5s -- ls /data
Expected output:
sharestatic
After you create a file in the /data path of a pod, if the file is also created in the /data path of the other pod, the two pods share the same volume.
You can also perform the operations listed in Table 2.
Operation | Description | Procedure |
|---|---|---|
Viewing events | View event names, event types, number of occurrences, Kubernetes events, first occurrence time, and last occurrence time of the PVC or PV. |
|
Viewing a YAML file | View, copy, or download the YAML file of a PVC or PV. |
|
Editing Reclaim Policy | Modify the reclaim policy of a PV. |
|
Synchronizing PVC capacity (supported only for PVCs created from non-subdirectories of SFS Capacity-Oriented file systems) | When the underlying storage outgrows the PVC, resize the PVC capacity on the CCE console to match the new size. |
|