Creación y montaje dinámico de subdirectorios de un sistema de archivos de SFS Turbo

Antecedentes

La capacidad mínima de un sistema de archivos de SFS Turbo es de 500 GiB, y el sistema de archivos de SFS Turbo no se puede facturar por uso. De forma predeterminada, el directorio raíz de un sistema de archivos de SFS Turbo está montado en un contenedor que, en la mayoría de los casos, no requiere una capacidad tan grande.

El complemento everest le permite crear de forma dinámica subdirectorios en un sistema de archivos de SFS Turbo y montar estos subdirectorios en contenedores. De esta manera, un sistema de archivos de SFS Turbo puede ser compartido por múltiples contenedores para aumentar la eficiencia del almacenamiento.

Restricciones

• Solo se admiten clústeres de v1.15 o posterior.
• El clúster debe utilizar el complemento everest de la versión 1.1.13 o posterior.
• No se admiten contenedores de Kata.
• Cuando se utiliza el complemento everest anterior a 1.2.69 o 2.1.11, se puede crear un máximo de 10 PVC simultáneamente mediante la función de subdirectorio. se recomienda everest de 1.2.69 o posterior o de 2.1.11 o posterior.

Creación de un volumen de SFS Turbo del tipo de subpath

No expanda, disocie ni elimine un volumen subpath.

1. Cree un sistema de archivos de SFS Turbo en la misma VPC y subred que el clúster.
2. Cree un archivo YAML de StorageClass como, por ejemplo, sfsturbo-subpath-sc.yaml.

   A continuación, se presenta un ejemplo:

   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

   En este ejemplo:

   • name: indica el nombre del StorageClass.
   • mountOptions: indica las opciones de montaje. Este campo es opcional.
     • En versiones posteriores a everest 1.1.13 y anteriores a everest 1.2.8, solo se puede configurar el parámetro nolock. De forma predeterminada, se utiliza el parámetro nolock para la operación de montaje y no es necesario configurarlo. Si nolock se establece en false, se utiliza el campo lock.
     • A partir de everest 1.2.8, se admiten más opciones de montaje. Para obtener más información, consulte Configuración de las opciones de montaje de SFS Turbo. No ponga nolock a true. De lo contrario, la operación de montaje fallará.

       mountOptions:
       - vers=3
       - timeo=600
       - nolock
       - hard

   • everest.io/volume-as: Este parámetro se establece en subpath para usar el volumen subpath.
   • everest.io/share-access-to: Este parámetro es opcional. En un volumen subpath, establezca este parámetro en el ID de la VPC donde se encuentra el sistema de archivos de SFS Turbo.
   • everest.io/share-expand-type: Este parámetro es opcional. Si el tipo del sistema de archivos de SFS Turbo es SFS Turbo Standard – Enhanced o SFS Turbo Performance – Enhanced, establezca este parámetro en bandwidth.
   • everest.io/share-export-location: Este parámetro indica el directorio de montaje. Consiste en la ruta compartida de SFS Turbo y el subdirectorio. La ruta compartida se puede obtener en la consola de SFS Turbo. El subdirectorio está definido por el usuario. Los PVC creados con StorageClass se encuentran en este subdirectorio.
   • everest.io/share-volume-type: Este parámetro es opcional. Especifica el tipo de sistema de archivos de SFS Turbo. El valor puede ser STANDARD o PERFORMANCE. Para los tipos mejorados, este parámetro debe usarse junto con everest.io/share-expand-type (cuyo valor debe ser bandwidth).
   • everest.io/zone: Este parámetro es opcional. Establezca la AZ donde se encuentra el sistema de archivos de SFS Turbo.
   • everest.io/volume-id: Este parámetro indica el ID del volumen de SFS Turbo. Puede obtener el ID de volumen en la página de SFS Turbo.
   • everest.io/archive-on-delete: Si este parámetro se establece en true y se selecciona Delete para Reclaim Policy, los documentos originales del PV se archivarán en el directorio llamado archived-{$PV name.timestamp} antes de eliminar el PVC. Si este parámetro se establece en false, se eliminará el subdirectorio de SFS Turbo del PV correspondiente. El valor predeterminado es true, que indica que los documentos originales del PV se archivarán en el directorio llamado archived-{$PV name.timestamp} antes de eliminar el PVC.

3. Ejecute kubectl create -f sfsturbo-subpath-sc.yaml.
4. Cree un archivo YAML de PVC denominado sfs-turbo-test.yaml.

   A continuación, se presenta un ejemplo:

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

   En este ejemplo:

   • name: indica el nombre del PVC.
   • storageClassName: especifica el nombre del StorageClass creado en el paso anterior.
   • storage: En el modo de ruta secundaria, es inútil especificar este parámetro. La capacidad de almacenamiento está limitada por la capacidad total del sistema de archivos de SFS Turbo. Si la capacidad total del sistema de archivos de SFS Turbo es insuficiente, amplíe la capacidad en la página SFS Turbo de manera oportuna.

5. Ejecute el comando kubectl create -f sfs-turbo-test.yaml para crear un PVC.

No tiene sentido llevar a cabo la expansión de la capacidad en un volumen de SFS Turbo creado en el modo de ruta secundaria. Esta operación no amplía la capacidad del sistema de archivos de SFS Turbo. Asegúrese de que la capacidad total del sistema de archivos de SFS Turbo no se agote.

Creación de un Deployment y montaje de un volumen existente

1. Cree un archivo YAML para el Deployment, por ejemplo, deployment-test.yaml.
   A continuación, se presenta un ejemplo:

   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

   En este ejemplo:

   • name: indica el nombre del Deployment.
   • image: especifica la imagen utilizada por el Deployment.
   • mountPath: indica el camino de montaje del contenedor. En este ejemplo, el volumen se monta en el directorio /tmp.
   • claimName: indica el nombre de un PVC existente.

2. Cree el Deployment.

   kubectl create -f deployment-test.yaml

Creación dinámica de un volumen de ruta secundaria para un StatefulSet

1. Cree un archivo YAML para un StatefulSet como, por ejemplo, StatefulSet-test.yaml.

   A continuación, se presenta un ejemplo:

   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

   En este ejemplo:

   • name: indica el nombre del StatefulSet.
   • image: especifica la imagen utilizada por el StatefulSet.
   • mountPath: indica el camino de montaje del contenedor. En este ejemplo, el volumen se monta en el directorio /tmp.
   • spec.template.spec.contenedores.volumeMounts.name y spec.volumeClaimTemplates.metadata.name deben ser coherentes porque tienen una relación de asignación.
   • storageClassName: indica el nombre del StorageClass.

2. Cree el StatefulSet.

   kubectl create -f statefulset-test.yaml