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

• Если используются OBS тома, группа владельца и разрешения точки монтирования нельзя изменить.
• Каждый раз, когда OBS том монтируется к рабочей нагрузке через PVC, в бэкенде создаётся резидентный процесс. Когда рабочая нагрузка использует слишком много OBS томов или читает и записывает большое количество файлов объектного хранилища, резидентные процессы будут потреблять значительное количество памяти. Чтобы обеспечить стабильную работу нагрузки, убедитесь, что количество используемых OBS томов не превышает запрошенную память. Например, если нагрузка запрашивает 4 GiB памяти, количество OBS томов должно быть не более 4.
• Secure containers не поддерживают OBS тома.
• Hard links не поддерживаются, когда монтируются общие бакеты.
• Read-only не поддерживается, когда OBS PVC монтируется к рабочей нагрузке.

• OBS позволяет одному пользователю создать максимум 100 бакетов. Если создаётся большое количество динамических PVC, количество бакетов может превысить верхний предел, и больше нельзя создать OBS бакеты. В этом случае используйте OBS, вызывая его API или SDK, и не монтируйте OBS бакеты к рабочим нагрузкам.

1. Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера.
2. Динамически создайте PVC и PV.
   1. Выберите Storage в панели навигации. В правой панели нажмите вкладку PVCs. Нажмите Create PVC в правом верхнем углу. На выдвижной панели настройте параметры PVC.

      Параметр	Описание
      PVC Type	В этом примере выберите OBS.
      PVC Name	Введите имя PVC, которое должно быть уникальным в namespace.
      Creation Method	Если подложное хранилище недоступно, выберите Dynamically provision для создания PVC, PV и подложного хранилища в консоли в каскадном режиме. Если подложное хранилище доступно, создайте PV или используйте существующий PV для статического создания PVC. Подробности см. в Using an Existing OBS Bucket Through a Static PV. В этом примере выберите Dynamically provision.
      Storage Classes	Имя StorageClass по умолчанию для томов OBS — csi-obs. Вы можете указать пользовательский StorageClass и настроить его политику возврата и режим привязки. Подробности см. в Creating a StorageClass Through the Console.
      (Optional) Storage Volume Name Prefix	Доступно только при версии кластера v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0 или более новой, а также при установленном в кластере Everest v2.4.15 или более новой. Этот параметр указывает имя подложного хранилища, которое создаётся автоматически. Фактическое имя подложного хранилища формируется по шаблону «Storage volume name prefix + PVC UID». Если параметр оставлен пустым, будет использован префикс по умолчанию pvc. Например, если префикс имени тома хранилища установлен в test, фактическое имя подложного хранилища будет test-{UID}.
      Instance Type	Parallel file system: высокопроизводительная файловая система, предоставляемая OBS. Она обеспечивает задержку доступа на уровне миллисекунд, пропускную способность уровня TB/s и IOPS уровня миллионов. Object bucket: обеспечивает надёжное, высокопроизводительное, безопасное и экономичное хранилище данных. Нет ограничений на количество файлов или объём хранилища.
      OBS Class	Вы можете выбрать следующие типы object bucket: Standard: Применимо, когда требуется частый доступ (в среднем несколько раз в месяц) к большому количеству популярных файлов или небольших файлов и необходим быстрый отклик доступа. Infrequent access: Применимо, когда данные не часто запрашиваются (в среднем менее 12 раз в год), но требуется быстрый отклик доступа.
      Access Mode	OBS volumes поддерживают только ReadWriteMany, что означает, что том хранилища может быть смонтирован на несколько узлов в режиме чтения/записи. Подробнее см. Volume Access Modes.
      Access Key (AK/SK)	Пользовательские ключи доступа: разные пользователи IAM используют собственные ключи доступа (AK/SK). Вы можете использовать IAM для управления правами пользователей IAM на доступ к OBS. (Рекомендуемый метод.) Подробнее см. Using a Custom Access Key (AK/SK) to Mount an OBS Volume. Можно выбрать только секреты с меткой secret.kubernetes.io/used-by = csi. Тип секрета — cfe/secure-opaque. Если секрет недоступен, нажмите Create Secret для его создания. Name: введите имя секрета. Namespace: выберите пространство имён, в котором находится секрет. Access Key (AK/SK) Permanent: Загрузите файл ключа в формате .csv. Для получения подробной информации см. Obtaining Access Keys. Global access secret (paas.longaksk): Все кластеры используют AK/SK учетной записи. Этот метод прост, но детальный контроль прав доступа реализовать нельзя. Если вы создали глобальный секрет доступа при использовании OBS‑томов в кластере, система создаст секрет с именем paas.longaksk в пространстве имён kube-system кластера. Этот секрет используется для хранения глобального AK/SK. Глобальный секрет доступа (paas.longaksk) используется проектом. После использования глобального секрета доступа он автоматически создаётся для каждого кластера в рамках того же проекта. Отключить глобальный секрет доступа можно в Settings > Cluster Settings. Если кластер не использует глобальный секрет доступа, эта опция не отображается. CAUTION: Если AK/SK будет удалён или отключён случайно, контейнер не сможет использовать OBS‑том.
      Enterprise Project	Этот параметр доступен только для корпоративных учётных записей с включёнными enterprise projects. enterprise project может быть проектом по умолчанию, проектом, в котором находится кластер, или проектом, указанным в StorageClass.
      Resource Tag	Вы можете добавлять resource tags для классификации ресурсов. Это поддерживается только при версии Everest в кластере v2.4.204 или более новой. Вы можете создать predefined tags в консоли TMS. Эти теги доступны всем ресурсам, поддерживающим теги. Вы можете использовать эти теги для повышения эффективности создания тегов и миграции ресурсов. NOTE: После создания динамического PV типа OBS теги ресурсов нельзя обновить в консоли CCE. Чтобы обновить OBS‑теги ресурсов, перейдите в консоль OBS.

   2. Нажмите Create для создания PVC и PV.

      Вы можете выбрать Storage в панели навигации и просмотреть созданные PVC и PV на вкладках PVCs и PVs соответственно.

3. Создайте приложение.
   1. Выберите Workloads в панели навигации. В правой панели нажмите вкладку Deployments.
   2. Нажмите Create Workload в правом верхнем углу. На отображаемой странице нажмите Data Storage в области Container Information под Container Settings и выберите Add Volume > PVC.

      Подключите и используйте тома хранения. Для получения подробной информации о параметрах см. Table 1. Для остальных параметров см. Workloads.

      Table 1Подключение тома хранения

      Параметр	Описание
      PVC	Выберите существующий OBS‑том.
      Путь монтирования	Введите путь монтирования, например, /tmp. Этот параметр указывает путь контейнера, в который будет монтироваться том данных. Не монтируйте том в системный каталог, например / или /var/run. Это может привести к ошибкам контейнера. Монтируйте том в пустой каталог. Если каталог не пуст, убедитесь, что в нём нет файлов, влияющих на запуск контейнера. В противном случае файлы будут заменены, что приведёт к сбоям при запуске контейнера или создании workload. ПРИМЕЧАНИЕ: Если том монтируется в каталог с высоким риском, используйте учётную запись с минимальными правами для запуска контейнера. В противном случае файлы с высоким риском на хосте могут быть повреждены.
      Подпуть	Введите подпуть тома хранения и смонтируйте путь тома в контейнер. Таким образом, разные папки одного тома хранения могут использоваться в одном pod. tmp, например, указывает, что данные в пути монтирования контейнера хранятся в папке tmp тома хранения. Если параметр оставлен пустым, по умолчанию будет использоваться корневой путь.
      Разрешение	Read-only: Вы можете только читать данные в смонтированных томах. Read-write: Вы можете изменять тома данных, смонтированные в путь. Новые записанные данные не будут мигрированы, если контейнер будет мигрирован, что может привести к потере данных.

      В этом примере диск монтируется в путь /data контейнера. Данные контейнера, генерируемые в этом пути, сохраняются в OBS‑томе.

   3. После настройки нажмите Create Workload.

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

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

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: pvc-obs-auto
        namespace: default
        annotations:
          everest.io/obs-volume-type: STANDARD    # OBS
          csi.storage.k8s.io/fstype: obsfs        # Instance type
          csi.storage.k8s.io/node-publish-secret-name: <your_secret_name>       # Custom secret name
          csi.storage.k8s.io/node-publish-secret-namespace: <your_namespace>    # Namespace of the custom secret
          everest.io/enterprise-project-id: <your_enterprise_project_id>  # (Optional) Enterprise project ID
          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 OBS.
        resources:
          requests:
             storage: 1Gi                # OBS volume capacity
         storageClassName: csi-obs     # The StorageClass is OBS.
      
      

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

      Параметр	Обязательно	Описание
      everest.io/obs-volume-type	Yes	OBS StorageClass. Если fsType установлен в s3fs, поддерживаются стандартные бакеты (STANDARD) и бакеты с редким доступом (WARM). Этот параметр недействителен, когда fsType установлен в obsfs.
      csi.storage.k8s.io/fstype	Yes	Instance type. Значение может быть obsfs или s3fs. obsfs: параллельная файловая система s3fs: объектный бакет
      csi.storage.k8s.io/node-publish-secret-name	No	Custom secret name. (Рекомендуется) Выберите эту опцию, если вы хотите назначить разные разрешения пользователей разным OBS storage devices. Для подробностей см. Using a Custom Access Key (AK/SK) to Mount an OBS Volume.
      csi.storage.k8s.io/node-publish-secret-namespace	No	Пространство имён пользовательского секрета.
      everest.io/enterprise-project-id	No	Этот параметр указывает идентификатор проекта предприятия, в котором создаётся OBS‑том. Применяется только к корпоративным учётным записям с включёнными проектами предприятия. Чтобы получить идентификатор проекта предприятия, войдите в консоль EPS, нажмите название целевого проекта предприятия и скопируйте идентификатор проекта предприятия.
      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 или более новой версии. Этот параметр указывает имя базового хранилища, которое создаётся автоматически. Фактическое имя базового хранилища имеет формат «Storage volume name prefix + PVC UID». Если параметр оставлен пустым, будет использован префикс по умолчанию pvc. Введите от 1 до 26 символов, которые не могут начинаться или заканчиваться дефисом (-). Допустимы только строчные буквы, цифры и дефисы (-). Например, если префикс имени тома хранилища установлен в test, фактическое имя базового хранилища будет test-{UID}.
      storage	Yes	Запрошенный объём в PVC, в Gi. Для OBS этот параметр используется только для проверки. Он не должен быть пустым или 0, его значение фиксировано на уровне 1. Любое установленное вами значение не вступит в силу.
      storageClassName	Yes	Имя StorageClass, которое является csi-obs для тома OBS.
      everest.io/obs-volume-tags	No	(Optional) Этот параметр поддерживается, когда версия Everest в кластере v2.4.204 или новее. Вы можете добавить теги ресурсов для классификации ресурсов. Вы можете создать predefined tags в консоли TMS. Эти теги доступны всем ресурсам, поддерживающим теги. Вы можете использовать эти теги для повышения эффективности создания тегов и миграции ресурсов.

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

      kubectl apply -f pvc-obs-auto.yaml
      
      

3. Создайте приложение.
   1. Создайте файл с именем web-demo.yaml. В этом примере том OBS монтируется в путь /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-obs-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-obs-volume    # Volume name, which is user-defined
                persistentVolumeClaim:
                   claimName: pvc-obs-auto     # Name of the created PVC
      
      

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

      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 
      
      

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

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 3.