Использование файловой системы SFS через динамический PV

• Вы создали кластер и установили дополнение CCE Container Storage (Everest) в кластере.
• Для создания кластера с помощью команд убедитесь, что используется kubectl. Подробности см. в Accessing a Cluster Using kubectl.

1. Используйте kubectl для доступа к кластеру.
2. Используйте StorageClass для динамического создания PVC и PV.
   1. Создайте файл pvc-sfs-auto.yaml.

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: pvc-sfs-auto
        namespace: default
        annotations: 
      
      
      
          everest.io/csi.volume-name-prefix: test  # (Optional) Storage volume name prefix of the automatically-created underlying storage
      spec:
        accessModes:
          - ReadWriteMany             # The value must be  ReadWriteMany  for SFS.
        resources:
          requests:
             storage: 1Gi              # SFS volume capacity
         storageClassName: csi-nas     # The StorageClass is SFS. 
      
      

      Table 1 Ключевые параметры

      Параметр	Обязательно	Описание
      storage	Yes	Запрошенная ёмкость в PVC, в Gi. Для SFS этот параметр используется только для проверки. Он не должен быть пустым или 0, а его значение фиксировано на 1. Любое установленное вами значение не вступит в силу.
      everest.io/csi.volume-name-prefix	No	(Optional) Этот параметр доступен только при версии кластера v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0 или более новой, а также при установленном в кластере Everest v2.4.15 или более новой версии. Этот параметр указывает имя базового хранилища, которое создаётся автоматически. Фактическое имя базового хранилища имеет формат «Префикс имени тома хранилища + PVC UID». Если параметр оставлен пустым, будет использован префикс по умолчанию pvc. Введите от 1 до 26 символов, которые не могут начинаться или заканчиваться дефисом (-). Допустимы только строчные буквы, цифры и дефисы (-). Например, если префикс имени тома хранилища установлен в test, фактическое имя базового хранилища будет test-{UID}.

   2. Выполните следующую команду для создания PVC:

      kubectl apply -f pvc-sfs-auto.yaml
      
      

3. Создайте приложение.
   1. Создайте файл с именем web-demo.yaml. В этом примере том SFS монтируется в путь /data.

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: web-demo
        namespace: default
      spec:
        replicas: 2
        selector:
          matchLabels:
            app: web-demo
        template:
          metadata:
            labels:
              app: web-demo
          spec:
            containers:
            - name: container-1
              image: nginx:latest
              volumeMounts:
              - name: pvc-sfs-volume    # Volume name, which must be the same as the volume name in the  volumes  field
                mountPath: /data  # Location where the storage volume is mounted
            imagePullSecrets:
              - name: default-secret
            volumes:
              - name: pvc-sfs-volume    # Volume name, which is user-defined
                persistentVolumeClaim:
                   claimName: pvc-sfs-auto     # Name of the created PVC
      
      

   2. Выполните следующую команду для создания рабочей нагрузки, к которой монтируется том SFS:

      kubectl apply -f web-demo.yaml
      
      

      После создания рабочей нагрузки данные в каталоге монтирования контейнера будут сохраняться постоянно. Проверьте хранилище, обратившись к Verifying Data Persistence and Sharing.

1. Просмотрите развернутое приложение и файлы.
   1. Выполните следующую команду, чтобы просмотреть созданный pod:

      kubectl get pod -n <namespace> | grep web-demo
      
      

      Ожидаемый вывод:

      web-demo-846b489584-mjhm9   1/1     Running   0             46s
      web-demo-846b489584-wvv5s   1/1     Running   0             46s
      
      

   2. Выполните следующие команды последовательно, чтобы проверить файлы в пути /data pod'ов:

      kubectl exec -n <namespace> web-demo-846b489584-mjhm9 -- ls /data
      kubectl exec -n <namespace> web-demo-846b489584-wvv5s -- ls /data
      
      

      Если для обоих pod'ов не возвращается результат, файл в пути /data не существует.

2. Выполните следующую команду, чтобы создать файл с именем static в пути /data:

   kubectl exec -n <namespace> web-demo-846b489584-mjhm9 --  touch /data/static
   
   

3. Выполните следующую команду, чтобы проверить файлы в пути /data:

   kubectl exec -n <namespace> web-demo-846b489584-mjhm9 -- ls /data
   
   

   Ожидаемый вывод:

    static 
   
   

4. Проверьте постоянство данных.
   1. Выполните следующую команду, чтобы удалить pod с именем web-demo-846b489584-mjhm9:

      kubectl delete pod -n <namespace> web-demo-846b489584-mjhm9
      
      

      Ожидаемый вывод:

      pod "web-demo-846b489584-mjhm9" deleted
      
      

      После удаления контроллер Deployment автоматически создает реплику.

   2. Выполните следующую команду, чтобы просмотреть созданный pod:

      kubectl get pod -n <namespace> | grep web-demo
      
      

      Ожидаемый вывод выглядит следующим образом, где web-demo-846b489584-d4d4j — это только что созданный pod:

       web-demo-846b489584-d4d4j    1/1     Running   0             110s
      web-demo-846b489584-wvv5s    1/1     Running   0             7m50s
      
      

   3. Выполните следующую команду, чтобы проверить, изменились ли файлы в пути /data нового pod'а:

      kubectl exec -n <namespace> web-demo-846b489584-d4d4j -- ls /data
      
      

      Ожидаемый вывод:

       static 
      
      

      Файл static сохранён, указывая, что данные могут храниться постоянно.

5. Проверьте совместное использование данных.
   1. Выполните следующую команду, чтобы просмотреть созданный pod:

      kubectl get pod -n <namespace> | grep web-demo
      
      

      Ожидаемый вывод:

      web-demo-846b489584-d4d4j   1/1     Running   0             7m
      web-demo-846b489584-wvv5s   1/1     Running   0             13m
      
      

   2. Выполните приведённую ниже команду, чтобы создать файл с именем share в пути /data любого pod. В этом примере выберите pod с именем web-demo-846b489584-d4d4j.

      kubectl exec -n <namespace> web-demo-846b489584-d4d4j --  touch /data/share
      
      

      Проверьте файлы в пути /data pod.

      kubectl exec -n <namespace> web-demo-846b489584-d4d4j -- ls /data
      
      

      Ожидаемый вывод:

       share 
      static
      
      

   3. Проверьте, существует ли файл share в пути /data другого pod (web-demo-846b489584-wvv5s), чтобы также подтвердить совместное использование данных.

      kubectl exec -n <namespace> web-demo-846b489584-wvv5s -- ls /data
      
      

      Ожидаемый вывод:

       share 
      static
      
      

      После создания файла в пути /data pod, если файл также создаётся в пути /data другого pod, два pod'а используют один и тот же том.

Вы также можете выполнить операции, перечисленные в Table 2.