Поделиться через


Управление хранилищем Kubernetes на устройстве GPU Azure Stack Edge Pro

ОБЛАСТЬ ПРИМЕНЕНИЯ: Да для SKU GPU ProAzure Stack Edge Pro — GPUДа для SKU Pro 2Azure Stack Edge Pro 2Да для SKU R ProAzure Stack Edge Pro RДа для номера SKU Mini RAzure Stack Edge Mini R

Кластер Kubernetes на устройстве Azure Stack Edge Pro создается при настройке вычислительной роли. После создания кластера Kubernetes контейнеризованные приложения можно развернуть в кластере Kubernetes в pod. Существуют различные способы предоставления хранилища модулям pod в кластере Kubernetes.

В этой статье описываются методы подготовки хранилища в кластере Kubernetes в целом и специально в контексте устройства Azure Stack Edge Pro.

Требования к хранилищу для модулей pod Kubernetes

Модули pod Kubernetes являются без отслеживания состояния, но выполняемые приложения обычно являются отслеживанием состояния. Так как модули pod могут быть короткими, и они перезапускаются, отработка отказа или перемещение между узлами Kubernetes, для хранилища, связанного с модулем pod, необходимо выполнить следующие требования.

Хранилище должно:

  • Живут вне модуля pod.
  • Не зависят от жизненного цикла pod.
  • Будьте доступны на всех узлах Kubernetes.

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

  • PersistentVolume (PV): это часть хранилища в кластере Kubernetes. Хранилище Kubernetes может быть статически подготовлено как PersistentVolume. Она также может быть динамически подготовлена как StorageClass.

  • PersistentVolumeClaim (PVC): это запрос на хранение пользователем. ПВ используют ресурсы PV. PVCs могут запрашивать определенные режимы размера и доступа.

    Так как пользователи нуждаются PersistentVolumes в различных свойствах для различных проблем, поэтому администраторы кластера должны иметь возможность предложить PersistentVolumes множество различных способов, чем просто режимы размера и доступа. Для этих потребностей требуется StorageClass ресурс.

Подготовка хранилища может быть статической или динамической. Каждый из типов подготовки рассматривается в следующих разделах.

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

Администраторы кластера Kubernetes могут статически подготавливать хранилище. Для этого они могут использовать серверную часть хранилища на основе файловых систем SMB/NFS или использовать диски iSCSI, которые присоединяются локально по сети в локальной среде или даже используют Файлы Azure или диски Azure в облаке. Этот тип хранилища не подготавливается по умолчанию, а администраторы кластера должны планировать подготовку и управлять ими.

Ниже приведена схема, на которую показано, как статически подготовленное хранилище используется в Kubernetes:

Статическая подготовка с помощью PersistentVolumes

Ниже приведены действия.

  1. Подготовка хранилища: администратор кластера подготавливает хранилище. В этом примере администратор кластера создает одну или несколько общих папок SMB, которые автоматически создают объекты постоянных томов в кластере Kubernetes, соответствующие этим общим папкам.

  2. Хранилище утверждений: вы отправляете развертывание ПВХ, которое запрашивает хранилище. Это утверждение для хранилища — PersistentVolumeClaim (PVC). Если размер и режим доступа PV совпадают с ПВ, то ПВХ привязан к PV. ПВХ и ПВ сопоставляют один к одному.

  3. Подключите ПВХ к контейнеру: когда ПВХ привязан к PV, вы можете подключить этот ПВХ на путь в контейнере. Когда логика приложения в контейнере считывает или записывает данные из этого пути, данные записываются в хранилище SMB.

Динамическая подготовка

Ниже приведена схема, на которую показано, как статически подготовленное хранилище используется в Kubernetes:

Динамическая подготовка с помощью StorageClasses

Ниже приведены действия.

  1. Определение класса хранилища: администратор кластера определяет класс хранилища в зависимости от операционной среды кластера Kubernetes. Администратор кластера также развертывает средство подготовки, которое является еще одним модулем pod или приложением, развернутым в кластере Kubernetes. У средства подготовки есть все сведения для динамической подготовки общих папок.

  2. Хранилище утверждений: вы отправляете приложение, которое будет утверждать хранилище. После создания ПВХ с помощью этой ссылки на класс хранения вызывается средство подготовки.

  3. Динамически подготавливать хранилище: средство подготовки динамически создает общую папку, связанную с локальным хранилищем дисков. После создания общей папки он также создает объект PV автоматически, соответствующий этой общей папке.

  4. Подключение ПВХ к контейнеру: после привязки ПВХ к PV вы можете подключить ПВХ к контейнеру на путь так же, как статическая подготовка и чтение из или запись в общую папку.

Подготовка хранилища в Azure Stack Edge Pro

На устройстве Azure Stack Edge Pro статически PersistentVolumes подготовленные создаются с помощью возможностей хранилища устройства. При подготовке общего ресурса и использовании общей папки с параметром вычислений Edge это действие автоматически создает ресурс PV в кластере Kubernetes.

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

Чтобы использовать распределение по уровням в облаке, можно создать общую папку Edge с включенным параметром вычислений Edge. Для этой общей папки снова создается ПС. Все данные приложения, записываемые в общую папку Edge, многоуровневые в облако.

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

Вы можете создать общие папки SMB и NFS для статической подготовки PV на устройстве Azure Stack Edge Pro. После подготовки PV вы отправите ПВХ для утверждения этого хранилища. Ниже приведен пример развертывания yaml ПВХ, который утверждает хранилище и использует подготовленные общие папки.

kind: PersistentVolumeClaim 
apiVersion: v1 
metadata: 
  name: pvc-smb-flexvol 
spec: 
  accessModes: 
  - ReadWriteMany 
  resources: 
    requests: 
      storage: 10Gi 
  volumeName: <nfs-or-smb-share-name-here> 
  storageClassName: ""

Чтобы получить значение volumeName поля, выберите локальную точку подключения для вычислительных модулей Edge при выборе общей папки SMB или NFS после создания. Это же имя общего ресурса.

Дополнительные сведения см. в статье "Развертывание приложения с отслеживанием состояния с помощью статической подготовки в Azure Stack Edge Pro с помощью kubectl".

Чтобы получить доступ к тому же статичному подготовленному хранилищу, соответствующие параметры подключения томов для привязок хранилища для Интернета вещей приведены ниже. /home/input— путь, по которому том доступен в пределах контейнера.

{
"HostConfig": {
"Mounts": [
{
"Target": "/home/input",
"Source": "<nfs-or-smb-share-name-here>",
"Type": "volume"
},
{
"Target": "/home/output",
"Source": "<nfs-or-smb-share-name-here>",
"Type": "volume"
}]
}
}

Azure Stack Edge Pro также имеет встроенный StorageClass вызов ase-node-local , который использует хранилище дисков данных, подключенное к узлу Kubernetes. Это StorageClass поддерживает динамическую подготовку. Вы можете сделать ссылку StorageClass в приложениях pod, и pv автоматически создается для вас. Дополнительные сведения см. на панели мониторинга Kubernetes для запроса ase-node-local StorageClass.

Встроенный класс хранилища на панели мониторинга Kubernetes

Дополнительные сведения см. в статье "Развертывание приложения с отслеживанием состояния с помощью динамической подготовки в Azure Stack Edge Pro с помощью kuebctl".

Выбор типа хранилища

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

  • Если требуется ReadWriteMany режим доступа для PersistentVolumes того, где тома подключены как операции чтения и записи во многих узлах, развертываемых, используйте статическую подготовку для общих папок SMB/NFS.

  • Если развернутые приложения имеют требование соответствия POSIX, например, приложения MongoDB, PostgreSQL, MySQL или Prometheus, используйте встроенный класс StorageClass. Режимы доступа или ReadWriteOnce том подключены в виде чтения и записи одним узлом.

Дополнительные сведения о режимах доступа см. в режиме доступа к томам Kubernetes.

Следующие шаги

Сведения о статической подготовке см. в следующей PersistentVolumeстатье:

Сведения о динамической подготовке см. в следующей StorageClassстатье: