Criação dinâmica de um subdiretório do SFS Turbo usando StorageClass

Plano de fundo

A capacidade mínima de um sistema de arquivos do SFS Turbo é de 500 GiB e o sistema de arquivos do SFS Turbo não pode ser cobrado pelo uso. Por padrão, o diretório raiz de um sistema de arquivos do SFS Turbo é montado em um contêiner que, na maioria dos casos, não requer uma capacidade tão grande.

O complemento everest permite criar dinamicamente subdiretórios em um sistema de arquivos SFS Turbo e montar esses subdiretórios em contêineres. Dessa forma, um sistema de arquivos do SFS Turbo pode ser compartilhado por vários contêineres para aumentar a eficiência do armazenamento.

Restrições

• Somente clusters da v1.15 ou posterior são suportados.
• O cluster deve usar o complemento everest da versão 1.1.13 ou posterior.
• Não há suporte para contêineres de Kata.
• Quando o complemento everest anterior a 1.2.69 ou 2.1.11 é usado, um máximo de 10 PVCs podem ser criados simultaneamente por vez usando a função de subdiretório. é recomendado o everest de 1.2.69 ou posterior ou de 2.1.11 ou posterior.
• Um volume subPath é um subdiretório de um sistema de arquivos de SFS Turbo. Aumentar a capacidade de um PVC desse tipo altera apenas o intervalo de recursos especificado pelo PVC, mas não altera a capacidade total do sistema de arquivos de SFS Turbo. Se a capacidade total de recursos do sistema de arquivos de SFS Turbo não for suficiente, a capacidade disponível do volume subPath será restringida. Para corrigir isso, você deve aumentar a capacidade de recursos do sistema de arquivos de SFS Turbo no console do SFS Turbo.

  A exclusão do volume subPath não resulta na exclusão dos recursos do sistema de arquivos de SFS Turbo.

Criação de um volume de SFS Turbo do tipo subPath

1. Crie um sistema de arquivos do SFS Turbo na mesma VPC e sub-rede que o cluster.
2. Crie um arquivo YAML de StorageClass, por exemplo, sfsturbo-subpath-sc.yaml.

   O seguinte é um exemplo:

   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

   Neste exemplo:

   • name: indica o nome do StorageClass.
   • mountOptions: indica as opções de montagem. Este campo é opcional.
     • Em versões posteriores ao everest 1.1.13 e anteriores ao everest 1.2.8, somente o parâmetro nolock pode ser configurado. Por padrão, o parâmetro nolock é usado para a operação de montagem e não precisa ser configurado. Se nolock for definido como false, o campo lock será usado.
     • A partir do everest 1.2.8, mais opções de montagem são suportadas. Para obter detalhes, consulte Configuração das opções de montagem do SFS Turbo. Não defina nolock como true. Caso contrário, a operação de montagem falhará.

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

   • everest.io/volume-as: este parâmetro é definido como subpath para usar o volume subPath.
   • everest.io/share-access-to: este parâmetro é opcional. Em um volume de subPath, defina esse parâmetro como o ID da VPC onde o sistema de arquivos do SFS Turbo está localizado.
   • everest.io/share-expand-type: este parâmetro é opcional. Se o tipo do sistema de arquivos de SFS Turbo for SFS Turbo Standard – Enhanced ou SFS Turbo Performance – Enhanced, defina esse parâmetro como bandwidth.
   • everest.io/share-export-location: este parâmetro indica o diretório de montagem. Consiste no caminho compartilhado e no subdiretório do SFS Turbo. O caminho compartilhado pode ser obtido no console do SFS Turbo. O subdiretório é definido pelo usuário. Os PVCs criados usando o StorageClass estão localizados nesse subdiretório.
   • everest.io/share-volume-type: este parâmetro é opcional. Especifica o tipo de sistema de arquivos de SFS Turbo. O valor pode ser STANDARD ou PERFORMANCE. Para tipos avançados, este parâmetro deve ser usado em conjunto com everest.io/share-expand-type (cujo valor deve ser bandwidth).
   • everest.io/zone: este parâmetro é opcional. Defina-o como a AZ em que o sistema de arquivos de SFS Turbo está localizado.
   • everest.io/volume-id: este parâmetro indica o ID do volume do SFS Turbo. Você pode obter o ID do volume na página de SFS Turbo.
   • everest.io/archive-on-delete: se esse parâmetro for definido como true e Delete for selecionado para Reclaim Policy, os documentos originais do PV serão arquivados no diretório chamado archived-{$PV name.timestamp} antes que o PVC seja excluído. Se esse parâmetro for definido como false, o subdiretório de SFS Turbo do PV correspondente será excluído. O valor padrão é true, indicando que os documentos originais do PV serão arquivados no diretório denominado archived-{$PV name.timestamp} antes que o PVC seja excluído.

3. Execute kubectl create -f sfsturbo-subpath-sc.yaml.
4. Crie um arquivo YAML do PVC chamado sfs-turbo-test.yaml.

   O seguinte é um exemplo:

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

   Neste exemplo:

   • name: indica o nome do PVC.
   • storageClassName: especifica o nome de StorageClass.
   • storage: em um volume de subPath, modificar o valor deste parâmetro não afeta a capacidade do recurso do sistema de arquivos de SFS Turbo. Um volume de subPath é essencialmente um caminho de arquivo dentro de um sistema de arquivos de SFS Turbo. Como resultado, o aumento da capacidade do volume subPath em um PVC não leva a um aumento nos recursos do sistema de arquivos de SFS Turbo.
     

     A capacidade de um volume de subPath é restrita pela capacidade geral de recursos do sistema de arquivos de SFS Turbo correspondente. Se os recursos do sistema de arquivos do SFS Turbo forem inadequados, você poderá ajustar a capacidade do recurso por meio do console do SFS Turbo.

5. Execute kubectl create -f sfs-turbo-test.yaml.

Criação de um Deployment e montagem de um volume existente

1. Crie um arquivo YAML para o Deployment, por exemplo, deployment-test.yaml.
   O seguinte é um exemplo:

   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

   Neste exemplo:

   • name: indica o nome da carga de trabalho criada.
   • image: especifica a imagem usada pela carga de trabalho.
   • mountPath: indica o caminho de montagem do contêiner. Neste exemplo, o volume é montado no diretório /tmp.
   • claimName: indica o nome de um PVC existente.

2. Crie o Deployment.

   kubectl create -f deployment-test.yaml

Criação dinâmica de um volume de subPath para um StatefulSet

1. Crie um arquivo YAML para um StatefulSet, por exemplo, statefulset-test.yaml.

   O seguinte é um exemplo:

   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

   Neste exemplo:

   • name: indica o nome da carga de trabalho criada.
   • image: especifica a imagem usada pela carga de trabalho.
   • mountPath: indica o caminho de montagem do contêiner. Neste exemplo, o volume é montado no diretório /tmp.
   • spec.template.spec.containers.volumeMounts.name e spec.volumeClaimTemplates.metadata.name: devem ser consistentes porque têm um relacionamento de mapeamento.
   • storageClassName: especifica o nome de um StorageClass local.

2. Crie o StatefulSet.

   kubectl create -f statefulset-test.yaml