Help Center/ Cloud Container Engine/ User Guide (Kuala Lumpur Region)/ Best Practices/ Storage/ Dynamically Creating an SFS Turbo Subdirectory Using StorageClass
Updated on 2024-10-14 GMT+08:00

Dynamically Creating an SFS Turbo Subdirectory Using StorageClass

Background

The minimum capacity of an SFS Turbo file system is 500 GiB. By default, the root directory of an SFS Turbo file system is mounted to a container which, in most case, does not require such a large capacity.

The everest add-on allows you to dynamically create subdirectories in an SFS Turbo file system and mount these subdirectories to containers. In this way, an SFS Turbo file system can be shared by multiple containers to increase storage efficiency.

Constraints

  • Only clusters of v1.15 or later are supported.
  • The cluster must use the everest add-on of version 1.1.13 or later.
  • When the everest add-on earlier than 1.2.69 or 2.1.11 is used, a maximum of 10 PVCs can be created concurrently at a time by using the subdirectory function. everest of 1.2.69 or later or of 2.1.11 or later is recommended.
  • A subPath volume is a subdirectory of an SFS Turbo file system. Increasing the capacity of a PVC of this type only changes the resource range specified by the PVC, but does not change the total capacity of the SFS Turbo file system. If the SFS Turbo file system's total resource capacity is not enough, the available capacity of the subPath volume will be restricted. To fix this, you must increase the resource capacity of the SFS Turbo file system on the SFS Turbo console.

    Deleting the subPath volume does not result in the deletion of the resources of the SFS Turbo file system.

Creating an SFS Turbo Volume of the subPath Type

  1. Create an SFS Turbo file system in the same VPC and subnet as the cluster.
  2. Create a YAML file of StorageClass, for example, sfsturbo-subpath-sc.yaml.

    The following is an example:

    apiVersion: storage.k8s.io/v1
    allowVolumeExpansion: true
    kind: StorageClass
    metadata:
      name: sfsturbo-subpath-sc
    mountOptions:
    - lock
    parameters:
      csi.storage.k8s.io/csi-driver-name: sfsturbo.csi.everest.io
      csi.storage.k8s.io/fstype: nfs
      everest.io/archive-on-delete: "true"
      everest.io/share-access-to: 7ca2dba2-1234-1234-1234-626371a8fb3a
      everest.io/share-expand-type: bandwidth
      everest.io/share-export-location: 192.168.1.1:/sfsturbo/
      everest.io/share-source: sfs-turbo
      everest.io/share-volume-type: STANDARD
      everest.io/volume-as: subpath
      everest.io/volume-id: 0d773f2e-1234-1234-1234-de6a35074696
    provisioner: everest-csi-provisioner
    reclaimPolicy: Delete
    volumeBindingMode: Immediate

    In this example:

    • name: indicates the name of the StorageClass.
    • mountOptions: indicates the mount options. This field is optional.
      • In versions later than everest 1.1.13 and earlier than everest 1.2.8, only the nolock parameter can be configured. By default, the nolock parameter is used for the mount operation and does not need to be configured. If nolock is set to false, the lock field is used.
      • Starting from everest 1.2.8, more mount options are supported. Do not set nolock to true. Otherwise, the mount operation will fail.
        mountOptions:
        - vers=3
        - timeo=600
        - nolock
        - hard
    • everest.io/volume-as: This parameter is set to subpath to use the subPath volume.
    • everest.io/share-access-to: This parameter is optional. In a subPath volume, set this parameter to the ID of the VPC where the SFS Turbo file system is located.
    • everest.io/share-expand-type: This parameter is optional. If the type of the SFS Turbo file system is SFS Turbo Standard – Enhanced or SFS Turbo Performance – Enhanced, set this parameter to bandwidth.
    • everest.io/share-export-location: This parameter indicates the mount directory. It consists of the SFS Turbo shared path and sub-directory. The shared path can be obtained on the SFS Turbo console. The sub-directory is user-defined. The PVCs created using the StorageClass are located in this sub-directory.
    • everest.io/share-volume-type: This parameter is optional. It specifies the SFS Turbo file system type. The value can be STANDARD or PERFORMANCE. For enhanced types, this parameter must be used together with everest.io/share-expand-type (whose value should be bandwidth).
    • everest.io/zone: This parameter is optional. Set it to the AZ where the SFS Turbo file system is located.
    • everest.io/volume-id: This parameter indicates the ID of the SFS Turbo volume. You can obtain the volume ID on the SFS Turbo page.
    • everest.io/archive-on-delete: If this parameter is set to true and Delete is selected for Reclaim Policy, the original documents of the PV will be archived to the directory named archived-{$PV name.timestamp} before the PVC is deleted. If this parameter is set to false, the SFS Turbo subdirectory of the corresponding PV will be deleted. The default value is true, indicating that the original documents of the PV will be archived to the directory named archived-{$PV name.timestamp} before the PVC is deleted.

  1. Run kubectl create -f sfsturbo-subpath-sc.yaml.
  2. Create a PVC YAML file named sfs-turbo-test.yaml.

    The following is an example:

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: sfs-turbo-test
      namespace: default
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 50Gi
      storageClassName: sfsturbo-subpath-sc
      volumeMode: Filesystem

    In this example:

    • name: indicates the name of the PVC.
    • storageClassName: specifies the name of the StorageClass.
    • storage: In a subPath volume, modifying the value of this parameter does not impact the resource capacity of the SFS Turbo file system. A subPath volume is essentially a file path within an SFS Turbo file system. As a result, increasing the capacity of the subPath volume in a PVC does not lead to an increase in the resources of the SFS Turbo file system.

      The capacity of a subPath volume is restricted by the overall resource capacity of the corresponding SFS Turbo file system. If the resources of the SFS Turbo file system are inadequate, you can adjust the resource capacity via the SFS Turbo console.

  1. Run kubectl create -f sfs-turbo-test.yaml.

Creating a Deployment and Mounting an Existing Volume

  1. Create a YAML file for the Deployment, for example, deployment-test.yaml.

    The following is an example:
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: test-turbo-subpath-example
      namespace: default
      generation: 1
      labels:
        appgroup: ''
    spec: 
      replicas: 1 
      selector: 
        matchLabels: 
          app: test-turbo-subpath-example 
      template: 
        metadata: 
          labels: 
            app: test-turbo-subpath-example 
        spec: 
          containers: 
          - image: nginx:latest 
            name: container-0 
            volumeMounts: 
            - mountPath: /tmp
              name: pvc-sfs-turbo-example 
          restartPolicy: Always 
          imagePullSecrets:
          - name: default-secret
          volumes: 
          - name: pvc-sfs-turbo-example 
            persistentVolumeClaim: 
              claimName: sfs-turbo-test

    In this example:

    • name: indicates the name of the created workload.
    • image: specifies the image used by the workload.
    • mountPath: indicates the mount path of the container. In this example, the volume is mounted to the /tmp directory.
    • claimName: indicates the name of an existing PVC.

  1. Create the Deployment.

    kubectl create -f deployment-test.yaml

Dynamically Creating a subPath Volume for a StatefulSet

  1. Create a YAML file for a StatefulSet, for example, statefulset-test.yaml.

    The following is an example:

    apiVersion: apps/v1
    kind: StatefulSet
    metadata:
      name: test-turbo-subpath
      namespace: default
      generation: 1
      labels:
        appgroup: ''
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: test-turbo-subpath
      template:
        metadata:
          labels:
            app: test-turbo-subpath
          annotations:
            metrics.alpha.kubernetes.io/custom-endpoints: '[{"api":"","path":"","port":"","names":""}]'
            pod.alpha.kubernetes.io/initialized: 'true'
        spec:
          containers:
            - name: container-0
              image: 'nginx:latest'
              resources: {}
              volumeMounts:
                - name: sfs-turbo-160024548582479676
                  mountPath: /tmp
              terminationMessagePath: /dev/termination-log
              terminationMessagePolicy: File
              imagePullPolicy: IfNotPresent
          restartPolicy: Always
          terminationGracePeriodSeconds: 30
          dnsPolicy: ClusterFirst
          securityContext: {}
          imagePullSecrets:
            - name: default-secret
          affinity: {}
          schedulerName: default-scheduler
      volumeClaimTemplates:
        - metadata:
            name: sfs-turbo-160024548582479676
            namespace: default
            annotations: {}
          spec:
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 10Gi
            storageClassName: sfsturbo-subpath-sc
      serviceName: wwww
      podManagementPolicy: OrderedReady
      updateStrategy:
        type: RollingUpdate
      revisionHistoryLimit: 10

    In this example:

    • name: indicates the name of the created workload.
    • image: specifies the image used by the workload.
    • mountPath: indicates the mount path of the container. In this example, the volume is mounted to the /tmp directory.
    • spec.template.spec.containers.volumeMounts.name and spec.volumeClaimTemplates.metadata.name: must be consistent because they have a mapping relationship.
    • storageClassName: specifies the name of an on-premises StorageClass.

  1. Create the StatefulSet.

    kubectl create -f statefulset-test.yaml