Использование драйвера Lustre CSI в Azure с Служба Azure Kubernetes

В этой статье вы узнаете, как планировать, устанавливать и использовать Azure Managed Lustre в службе Azure Kubernetes (AKS) с драйвером Azure Lustre CSI для Kubernetes. Этот драйвер основан на спецификации интерфейса поддержки контейнеров (CSI).

Драйвер CSI Azure Lustre для Kubernetes можно использовать для доступа к управляемому хранилищу Lustre Azure в качестве постоянных томов хранилища из контейнеров Kubernetes, развернутых в AKS.

Совместимые версии Kubernetes

Драйвер Azure Lustre CSI для Kubernetes совместим с AKS. Другие установки Kubernetes в настоящее время не поддерживаются.

Поддерживаются akS Kubernetes версии 1.21 и более поздних версий. Эта поддержка включает все версии, доступные в настоящее время при создании нового кластера AKS.

Совместимые версии Lustre

Драйвер Azure Lustre CSI для Kubernetes совместим с Управляемый Lustre Azure. Другие установки Lustre в настоящее время не поддерживаются.

Версии драйвера CSI для Azure Lustre

Поддерживаются следующие версии драйверов:

Полный список всех выпусков драйверов и их журнала изменений см. на странице выпусков драйверов Azure Lustre CSI.

Необходимые компоненты

• Учетная запись Azure с активной подпиской. Создайте учетную запись бесплатно .
• Среда терминала с установленными средствами Azure CLI. См. Начало работы с Azure CLI.
• kubectl, средство управления Kubernetes, установленное в среде терминала. См. Быстрый старт: развертывание кластера Службы Azure Kubernetes (AKS) с помощью Azure CLI.
• Развертывание Azure Managed Lustre. См. документацию по Управляемому Lustre Azure.
• Сетевое подключение между кластером AKS и виртуальной сетью Azure Managed Lustre. Сведения о параметрах конфигурации см. в разделе "Планирование сетевой архитектуры ".

Планирование развертывания AKS

При развертывании службы Azure Kubernetes несколько вариантов влияют на операцию между AKS и Azure Managed Lustre.

Определение типа сети для использования с AKS

AKS поддерживает несколько сетевых моделей, каждый из которых имеет различные возможности и варианты использования. Все сетевые модели работают с драйвером CSI Azure Lustre для Kubernetes, но они имеют разные требования к виртуальной сети и настройке кластера.

Подробные сведения о выборе подходящей сетевой модели для конкретных требований см. в обзоре сети CNI службы Azure Kubernetes.

При создании кластера AKS на портале Azure вы увидите следующие параметры сети:

Рекомендуемые параметры:

Azure CNI Overlay (рекомендуется)

• Экономия пространства IP-адресов виртуальной сети с помощью логически отдельных диапазонов CIDR для pod
• Поддерживает максимальный масштаб кластера до 5000 узлов и 250 pod на узел
• Простое управление IP-адресами
• Лучший выбор для большинства сценариев

Подсеть Pod Pod Azure CNI

• Модули Pod получают полное подключение к виртуальной сети и могут быть напрямую доступны через частный IP-адрес.
• Требуется большее, не фрагментированное пространство IP-адресов виртуальной сети
• Выберите это, если вам нужен прямой внешний доступ к IP-адресам pod

Устаревшие параметры (не рекомендуется для новых развертываний):

Подсеть узла CNI Azure (устаревшая версия)

• Ограниченное масштабирование и неэффективное использование IP-адресов виртуальной сети
• Рекомендуется только в том случае, если для кластера требуется управляемая виртуальная сеть, см. статью AKS Legacy Container Networking Interfaces (CNI)

Kubenet (выход на пенсию)

• Выход на пенсию 31 марта 2028 года. Дополнительные сведения см. в разделе AKS: использование Kubenet.
• Ограниченное масштабирование и требует ручного управления маршрутами
• Планирование миграции в Azure CNI Overlay до даты выхода на пенсию

Подробные сведения о сетевых моделях см. в обзоре сети Azure Kubernetes Service CNI.

Определить сетевую архитектуру для взаимосвязанности AKS и Azure Managed Lustre

Управляемый Lustre Azure работает в частной виртуальной сети. Экземпляр AKS должен иметь сетевое подключение к виртуальной сети Azure Managed Lustre. Существует два распространенных способа настройки сети между Azure Managed Lustre и Azure AKS:

• Установите AKS в собственной виртуальной сети и создайте пиринг виртуальной сети с виртуальной сетью Azure Managed Lustre.
• Используйте параметр Создание собственной виртуальной сети Azure в AKS для установки AKS в новой подсети в Azure Managed Lustre виртуальной сети.

Пиринг AKS и управляемые виртуальные сети Lustre Azure

Возможность пиринга двух виртуальных сетей имеет преимущество разделения управления сетями на разные привилегированные роли. Пиринг также может обеспечить дополнительную гибкость, так как его можно реализовать в подписках или регионах Azure. Пиринг между виртуальными сетями требует координации между двумя сетями, чтобы избежать выбора конфликтующих IP-адресных пространств.

Установка AKS в подсети в виртуальной сети Azure Managed Lustre

Возможность установки кластера AKS в виртуальной сети Azure Managed Lustre с функцией Подключение собственной виртуальной сети Azure в AKS может оказаться выгодной в сценариях, где сеть управляется централизованно. Вам потребуется создать дополнительную подсеть, размер которой соответствует требованиям к сети AKS, в виртуальной сети Azure Managed Lustre.

При подготовке AKS в виртуальной сети Azure Managed Lustre не существует разделения привилегий для управления сетями. Субъект-служба AKS нуждается в привилегиях в виртуальной сети Azure Managed Lustre.

Методы подготовки

Azure Lustre CSI Driver поддерживает два метода предоставления:

Динамическое предоставление ресурсов (доступна в версии 0.3.0+)

Динамическая подготовка позволяет драйверу CSI автоматически создавать управляемые Azure файловые системы Lustre по запросу при создании запросов на постоянный том.

Статическая подготовка

Статическая подготовка использует существующую файловую систему Azure Managed Lustre. Этот метод включает в себя:

• Создание классов хранилища, ссылающихся на существующие кластеры Lustre
• Указание имени файловой системы Lustre и IP-адреса MGS вручную
• Подходит для сценариев, когда у вас уже есть инфраструктура Lustre

Выберите метод, который лучше всего подходит вашему варианту использования. Динамическая подготовка сначала описана ниже, а затем приведены инструкции по статической подготовке.

Динамическое предоставление

Динамическая подготовка автоматически создает управляемые файловые системы Lustre в Azure по запросу при создании запросов на постоянные тома. Эта функция стала доступна в драйвере CSI версии 0.3.0.

Предпосылки для динамического выделения ресурсов

Permissions

Для удостоверения kubelet требуются следующие разрешения:

• Доступ на чтение и запись к группе ресурсов, в которой будут созданы кластеры
• Разрешения сети для создания подсетей и управления ими при необходимости
• Разрешения службы Azure Managed Lustre

Подробные требования к разрешениям см. в документации по параметрам драйвера.

Требования к сети

• Существующая виртуальная сеть и подсеть для управляемого кластера Lustre Azure
• Достаточно IP-адресов, доступных в подсети для кластера
• Правильные правила группы безопасности сети для разрешения трафика Lustre

Создание кластера AKS для динамического выделения ресурсов

Если вы еще не создали кластер AKS, создайте развертывание кластера. См. раздел Развертывание кластера Службы Azure Kubernetes (AKS) с помощью портала Azure.

Настройка пиринга виртуальной сети для динамического предоставления

Виртуальная сеть AKS создается в отдельной группе ресурсов из группы ресурсов кластера AKS. Вы можете найти имя этой группы ресурсов, перейдя в кластер AKS на портале Azure, перейдя к Свойстваи найдя группу ресурсов инфраструктуры. Эта группа ресурсов содержит виртуальную сеть, которая должна быть связана с виртуальной сетью Azure Managed Lustre. Он соответствует шаблону <.>

Чтобы выполнить пиринг виртуальной сети AKS с виртуальной сетью Azure Managed Lustre, обратитесь к ресурсу виртуальный пиринг сетей.

Подключитесь к кластеру AKS для динамического развертывания

1. Откройте сеанс терминала с доступом к средствам Azure CLI и войдите в свою учетную запись Azure:

   az login
   

2. Войдите на портал Azure.

3. Найдите кластер AKS. На панели Обзор нажмите кнопку Подключиться, а затем скопируйте команду для загрузки учетных данных кластера.

4. В сеансе терминала вставьте команду, чтобы скачать учетные данные. Команда похожа на следующую:

   az aks get-credentials --subscription <AKS_subscription_id> --resource_group <AKS_resource_group_name> --name <name_of_AKS>
   

5. Установите kubectl, если он отсутствует в вашей среде:

   az aks install-cli
   

6. Убедитесь, что текущий контекст является кластером AKS, где вы только что установили учетные данные и можете подключиться к нему:

   kubectl config current-context
   kubectl get deployments --all-namespaces=true
   

Установка драйвера для динамической подготовки

Чтобы установить драйвер CSI Azure Lustre для Kubernetes, выполните следующую команду:

curl -skSL https://raw.githubusercontent.com/kubernetes-sigs/azurelustre-csi-driver/main/deploy/install-driver.sh | bash

Чтобы получить примеры команд для локальной установки, см. установка драйвера Azure Lustre CSI в кластере Kubernetes.

Создание класса хранилища для динамической подготовки

Создайте файл с именем storageclass_dynprov_lustre.yaml и скопируйте его в следующем YAML. Измените параметры, необходимые для вашей среды:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurelustre-dynprov
provisioner: azurelustre.csi.azure.com
parameters:
  sku-name: "AMLFS-Durable-Premium-125"  # Choose appropriate SKU
  zone: "1"  # Specify zone if required for your SKU/location
  maintenance-day-of-week: "Sunday"
  maintenance-time-of-day-utc: "22:00"
  location: "eastus"  # Optional: defaults to AKS cluster location
  resource-group: "my-resource-group"  # Optional: defaults to AKS cluster RG
  vnet-name: "my-vnet"  # Optional: defaults to AKS cluster VNET
  subnet-name: "my-subnet"  # Optional: defaults to AKS cluster subnet
reclaimPolicy: Delete  # Change to "Retain" to keep clusters after PVC deletion
volumeBindingMode: Immediate
---
# Optional: Resource quota to limit number of clusters
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pvc-lustre-dynprov-quota
spec:
  hard:
    azurelustre-dynprov.storageclass.storage.k8s.io/persistentvolumeclaims: "1"

Примените класс хранилища к кластеру AKS:

kubectl apply -f storageclass_dynprov_lustre.yaml

Создать претензию на постоянный том для динамической подготовки

Создайте файл с именем pvc_storageclass_dynprov.yaml и скопируйте его в следующем YAML:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-lustre-dynprov
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurelustre-dynprov
  resources:
    requests:
      storage: 48Ti  # Minimum size for AMLFS-Durable-Premium-125

Примените ПВХ к кластеру AKS:

kubectl apply -f pvc_storageclass_dynprov.yaml

Мониторинг создания кластера

Создание управляемого кластера Lustre Azure может занять 10 минут или более. Вы можете отслеживать ход выполнения:

kubectl describe pvc pvc-lustre-dynprov

При создании состояние будет следующим: Pending с сообщением вида: Waiting for a volume to be created either by the external provisioner 'azurelustre.csi.azure.com'...

Когда он будет готов, статус Bound будет сопровождаться сообщением об успешном выполнении.

Создание pod для динамического предоставления

Создайте файл с именем pod_echo_date_dynprov.yaml и скопируйте его в следующем YAML:

apiVersion: v1
kind: Pod
metadata:
  name: lustre-echo-date-dynprov
spec:
  containers:
  - image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    name: lustre-echo-date-dynprov
    command:
      - "/bin/sh"
      - "-c"
      - "while true; do echo $(date) >> /mnt/lustre/outfile; sleep 1; done"
    volumeMounts:
    - name: lustre-storage
      mountPath: /mnt/lustre
  volumes:
  - name: lustre-storage
    persistentVolumeClaim:
      claimName: pvc-lustre-dynprov

Примените pod к кластеру AKS:

kubectl apply -f pod_echo_date_dynprov.yaml

Проверка динамического распределения ресурсов

После запуска pod можно убедиться, что динамически созданная файловая система Lustre Azure подключена правильно:

kubectl exec -it lustre-echo-date-dynprov -- df -h

Вы должны увидеть файловую систему Azure Managed Lustre, установленную на /mnt/lustre.

Очистка динамических ресурсов

Чтобы удалить динамически созданные ресурсы, выполните следующие действия.

kubectl delete pvc pvc-lustre-dynprov

Если у класса хранилища есть reclaimPolicy: Delete, это также приведет к удалению кластера Azure Managed Lustre. Если задано значение Retain, необходимо вручную удалить кластер, если он больше не нужен.

Статическая подготовка

Статическая подготовка позволяет использовать существующую файловую систему Azure Lustre с кластером AKS вручную, создав необходимые ресурсы Kubernetes.

Предварительные требования для статического предоставления

• Существующая файловая система Azure Managed Lustre. Дополнительные сведения о создании управляемой файловой системы Lustre Azure см. в статье "Создание управляемой файловой системы Lustre Azure".
• IP-адрес MGS и имя внутренней файловой системы из управляемого кластера Azure Lustre

Создание кластера управляемой файловой системы Azure Lustre для статического предоставления

Если вы еще не создали кластер файловой системы Azure Managed Lustre, создайте кластер. Инструкции см. в статье Создание управляемой файловой системы Lustre Azure с помощью портала Azure. Для статической подготовки требуется существующая файловая система Azure Managed Lustre.

Создание кластера AKS для статического выделения ресурсов

Если вы еще не создали кластер AKS, создайте развертывание кластера. См. раздел Развертывание кластера Службы Azure Kubernetes (AKS) с помощью портала Azure.

Создание пиринга виртуальной сети для статического обеспечения

Виртуальная сеть AKS создается в отдельной группе ресурсов из группы ресурсов кластера AKS. Вы можете найти имя этой группы ресурсов, перейдя в кластер AKS на портале Azure, перейдя к Свойстваи найдя группу ресурсов инфраструктуры. Эта группа ресурсов содержит виртуальную сеть, которая должна быть связана с виртуальной сетью Azure Managed Lustre. Он соответствует шаблону <.>

Чтобы выполнить пиринг виртуальной сети AKS с виртуальной сетью Azure Managed Lustre, обратитесь к ресурсу виртуальный пиринг сетей.

Подключение к кластеру AKS для статической подготовки

1. Откройте сеанс терминала с доступом к средствам Azure CLI и войдите в свою учетную запись Azure:

   az login
   

2. Войдите на портал Azure.

3. Найдите кластер AKS. На панели Обзор нажмите кнопку Подключиться, а затем скопируйте команду для загрузки учетных данных кластера.

4. В сеансе терминала вставьте команду, чтобы скачать учетные данные. Команда похожа на следующую:

   az aks get-credentials --subscription <AKS_subscription_id> --resource_group <AKS_resource_group_name> --name <name_of_AKS>
   

5. Установите kubectl, если он отсутствует в вашей среде:

   az aks install-cli
   

6. Убедитесь, что текущий контекст является кластером AKS, где вы только что установили учетные данные и можете подключиться к нему:

   kubectl config current-context
   kubectl get deployments --all-namespaces=true
   

Установка драйвера для статической настройки

Чтобы установить драйвер CSI Azure Lustre для Kubernetes, выполните следующую команду:

curl -skSL https://raw.githubusercontent.com/kubernetes-sigs/azurelustre-csi-driver/main/deploy/install-driver.sh | bash

Чтобы получить примеры команд для локальной установки, см. установка драйвера Azure Lustre CSI в кластере Kubernetes.

Создание и настройка постоянного тома для статического предоставления ресурсов

Чтобы создать постоянный том для существующей управляемой файловой системы Lustre Azure:

1. Скопируйте следующие файлы конфигурации из папки /docs/examples/ в репозитории azurelustre-csi-driver . Если вы клонировали репозиторий при установке драйвера, у вас уже есть локальные копии.

   • storageclass_existing_lustre.yaml
   • pvc_storageclass.yaml

   Если вы не хотите клонировать весь репозиторий, вы можете скачать каждый файл по отдельности. Откройте каждую из следующих ссылок, скопируйте содержимое файла и вставьте его содержимое в локальный файл с тем же именем файла.

   • storageclass_existing_lustre.yaml
   • pvc_storageclass.yaml

2. В файле storageclass_existing_lustre.yaml обновите внутреннее имя кластера Lustre и IP-адрес службы управления Lustre (MGS).

   

   Оба параметра отображаются на портале Azure на панели подключения клиента для управляемой файловой системы Azure Lustre.

   

   Сделайте следующее:

   • Замените EXISTING_LUSTRE_FS_NAME назначаемое системой внутреннее имя кластера Lustre в файловой системе Azure Managed Lustre. Обычно внутреннее имя .lustrefs Внутреннее имя не является именем, которое вы предоставили файловой системе при его создании.

     Предлагаемая mount команда содержит имя, выделенное в следующей строке адреса.

     

   • Замените EXISTING_LUSTRE_IP_ADDRESS IP-адресом MGS.

3. Чтобы создать класс хранилища и утверждение постоянного тома, выполните следующую kubectl команду:

   kubectl create -f storageclass_existing_lustre.yaml
   kubectl create -f pvc_storageclass.yaml
   

Создание pod для статического предоставления ресурсов

Создайте pod, который использует PVC для монтирования файловой системы Azure Managed Lustre.

Создайте файл с именем pod_echo_date.yaml и скопируйте его в следующем YAML:

apiVersion: v1
kind: Pod
metadata:
  name: lustre-echo-date
spec:
  containers:
  - image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    name: lustre-echo-date
    command:
      - "/bin/sh"
      - "-c"
      - "while true; do echo $(date) >> /mnt/lustre/outfile; sleep 1; done"
    volumeMounts:
    - name: lustre-storage
      mountPath: /mnt/lustre
  volumes:
  - name: lustre-storage
    persistentVolumeClaim:
      claimName: pvc-lustre

Примените pod к кластеру AKS:

kubectl apply -f pod_echo_date.yaml

Проверка статической подготовки

После запуска pod можно убедиться, что управляемая файловая система Lustre Azure подключена правильно:

kubectl exec -it lustre-echo-date -- df -h

Вы должны увидеть файловую систему Azure Managed Lustre, установленную на /mnt/lustre.

Чтобы просмотреть метки времени в консоли во время записи, выполните следующую команду:

kubectl logs -f lustre-echo-date

Очистка статических ресурсов

Чтобы очистить ресурсы после завершения, выполните следующие действия.

kubectl delete pod lustre-echo-date
kubectl delete pvc pvc-lustre
kubectl delete storageclass azurelustre-static

Валидация подписей образов контейнера

Azure Lustre CSI Driver подписывает образы контейнеров, чтобы пользователи могли проверить целостность и происхождение используемых образов. Подписывание использует пару открытого и закрытого ключа, чтобы доказать, что корпорация Майкрософт создала образ контейнера, создав цифровую подпись и добавив ее в образ. В этом разделе приведены действия по проверке подписи образа корпорацией Майкрософт.

Общие сведения о безопасности изображений в системных компонентах Kubernetes

Образы контейнеров, которые используются драйвером CSI Azure Lustre, развертываются в пространстве имен kube-system, которое рассматривается как доверенное системное пространство имен в Kubernetes. По соображениям безопасности и эксплуатации политики целостности образов обычно не применяются в пространствах имен системы, так как:

• Требования к Bootstrap: системные компоненты, такие как драйверы CSI, должны запускаться до того, как системы принудительного применения политик (такие как Gatekeeper и Ratify) станут доступными.
• Доверенные компоненты: образы в kube-system являются основными компонентами инфраструктуры Kubernetes, управляемыми доверенными поставщиками
• Операционная стабильность. Применение политик для компонентов принудительного применения политик может предотвратить функциональные возможности кластера.

Однако перед развертыванием можно проверить целостность образов драйверов CSI.

Проверка образа перед развертыванием

Перед развертыванием драйвера CSI Для Azure Lustre можно проверить цифровые подписи и подлинность образов контейнеров с помощью сертификатов общедоступной подписи Майкрософт:

Проверка подписей изображений с помощью Notation CLI

1. Скачать Notation CLI:

   export NOTATION_VERSION=1.3.2
   curl -LO https://github.com/notaryproject/notation/releases/download/v$NOTATION_VERSION/notation_$NOTATION_VERSION\_linux_amd64.tar.gz
   sudo tar xvzf notation_$NOTATION_VERSION\_linux_amd64.tar.gz -C /usr/bin/ notation
   

2. Скачайте общедоступный сертификат подписи Майкрософт:

   curl -sSL "https://www.microsoft.com/pkiops/certs/Microsoft%20Supply%20Chain%20RSA%20Root%20CA%202022.crt" -o msft_signing_cert.crt
   

3. Добавьте сертификат в командную строку Notation CLI

   notation cert add --type ca --store supplychain msft_signing_cert.crt
   

4. Проверьте нотацию сертификата:

   notation cert ls
   

   Выходные данные команды выглядят следующим образом:

   STORE TYPE  STORE NAME  CERTIFICATE 
   ca          supplychain msft_signing_cert.crt
   

5. Создайте файл trustpolicy для образов драйвера CSI Azure Lustre:

   Создайте файл с именем trustpolicy.json:

   {
       "version": "1.0",
       "trustPolicies": [
           {
               "name": "supplychain",
               "registryScopes": [ "*" ],
               "signatureVerification": {
                   "level" : "strict" 
               },
               "trustStores": [ "ca:supplychain" ],
               "trustedIdentities": [
                   "x509.subject: CN=Microsoft SCD Products RSA Signing,O=Microsoft Corporation,L=Redmond,ST=Washington,C=US"
               ]
           }
       ]
   }
   

6. Используйте нотацию для проверки образов драйверов CSI Azure Lustre:

   notation policy import trustpolicy.json
   export NOTATION_EXPERIMENTAL=1
   
   # Verify the controller image
   notation verify --allow-referrers-api mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi:v0.3.0
   

   Выходные данные успешной проверки выглядят следующим образом:

   Successfully verified signature for mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi@sha256:a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456
   

Целостность образа рабочей нагрузки приложения

Для повышения безопасности в производственных средах рекомендуется включить AKS Image Integrity для автоматической проверки подписей контейнерных образов для нагрузки вашего приложения. Хотя образы драйверов CSI в kube-system пространстве имен обычно исключаются из реализации политик, можно настроить политики целостности образов для пространств имен приложения.

Дополнительные сведения о реализации политик целостности изображений для рабочих нагрузок приложений см. в статье "Целостность образов" в службе Azure Kubernetes (AKS).

Устранение неполадок

Сведения об устранении неполадок с драйвером CSI Для Azure Lustre см. в руководстве по устранению неполадок драйвера CSI в репозитории GitHub.

Общие проблемы:

• Проблемы с сетевым подключением между AKS и Azure Managed Lustre — проверка пиринга виртуальной сети или конфигурации подсети
• Неправильная конфигурация — дважды проверьте IP-адрес MGS и имя файловой системы в конфигурации вашего класса хранилища.
• Проблемы с планированием pod — убедитесь, что вы используете SKU ОС Ubuntu Linux для пулов узлов, так как это единственная поддерживаемая конфигурация.
• Проблемы с разрешениями . Убедитесь, что субъект-служба AKS имеет соответствующие разрешения в виртуальной сети Azure Managed Lustre

Для динамического предоставления конкретных вопросов:

• Ошибки аутентификации/авторизации — проверьте права удостоверения kubelet для создания кластеров Azure Managed Lustre
• Ошибки валидации SKU и зоны - убедитесь, что указанный SKU поддерживается в вашем регионе, и конфигурация зоны правильная
• Доступность IP-адресов сети — убедитесь, что в целевой подсети доступны достаточные IP-адреса.
• Ограничения квот . Проверьте квоты ресурсов Kubernetes и квоты подписки Azure для кластеров Azure Managed Lustre

Дополнительные ресурсы по устранению неполадок см. в статье:

• Устранение неполадок с Управляемым Lustre в Azure
• Репозиторий GitHub драйвера CSI Azure Lustre

Связанное содержимое

• Создание задания экспорта для экспорта данных из Управляемого Lustre Azure