Управление хранилищем Kubernetes на устройстве GPU Azure Stack Edge Pro
ОБЛАСТЬ ПРИМЕНЕНИЯ: Azure Stack Edge Pro — GPUAzure Stack Edge Pro 2Azure Stack Edge Pro 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:
Ниже приведены действия.
Подготовка хранилища: администратор кластера подготавливает хранилище. В этом примере администратор кластера создает одну или несколько общих папок SMB, которые автоматически создают объекты постоянных томов в кластере Kubernetes, соответствующие этим общим папкам.
Хранилище утверждений: вы отправляете развертывание ПВХ, которое запрашивает хранилище. Это утверждение для хранилища — PersistentVolumeClaim (PVC). Если размер и режим доступа PV совпадают с ПВ, то ПВХ привязан к PV. ПВХ и ПВ сопоставляют один к одному.
Подключите ПВХ к контейнеру: когда ПВХ привязан к PV, вы можете подключить этот ПВХ на путь в контейнере. Когда логика приложения в контейнере считывает или записывает данные из этого пути, данные записываются в хранилище SMB.
Динамическая подготовка
Ниже приведена схема, на которую показано, как статически подготовленное хранилище используется в Kubernetes:
Ниже приведены действия.
Определение класса хранилища: администратор кластера определяет класс хранилища в зависимости от операционной среды кластера Kubernetes. Администратор кластера также развертывает средство подготовки, которое является еще одним модулем pod или приложением, развернутым в кластере Kubernetes. У средства подготовки есть все сведения для динамической подготовки общих папок.
Хранилище утверждений: вы отправляете приложение, которое будет утверждать хранилище. После создания ПВХ с помощью этой ссылки на класс хранения вызывается средство подготовки.
Динамически подготавливать хранилище: средство подготовки динамически создает общую папку, связанную с локальным хранилищем дисков. После создания общей папки он также создает объект PV автоматически, соответствующий этой общей папке.
Подключение ПВХ к контейнеру: после привязки ПВХ к PV вы можете подключить ПВХ к контейнеру на путь так же, как статическая подготовка и чтение из или запись в общую папку.
Подготовка хранилища в Azure Stack Edge Pro
На устройстве Azure Stack Edge Pro статически PersistentVolumes
подготовленные создаются с помощью возможностей хранилища устройства. При подготовке общего ресурса и использовании общей папки с параметром вычислений Edge это действие автоматически создает ресурс PV в кластере Kubernetes.
Чтобы использовать распределение по уровням в облаке, можно создать общую папку Edge с включенным параметром вычислений Edge. Для этой общей папки снова создается ПС. Все данные приложения, записываемые в общую папку Edge, многоуровневые в облако.
Вы можете создать общие папки 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
.
Дополнительные сведения см. в статье "Развертывание приложения с отслеживанием состояния с помощью динамической подготовки в Azure Stack Edge Pro с помощью kuebctl".
Выбор типа хранилища
Возможно, вам потребуется выбрать тип хранилища в зависимости от развернутой рабочей нагрузки.
Если требуется
ReadWriteMany
режим доступа дляPersistentVolumes
того, где тома подключены как операции чтения и записи во многих узлах, развертываемых, используйте статическую подготовку для общих папок SMB/NFS.Если развернутые приложения имеют требование соответствия POSIX, например, приложения MongoDB, PostgreSQL, MySQL или Prometheus, используйте встроенный класс StorageClass. Режимы доступа или
ReadWriteOnce
том подключены в виде чтения и записи одним узлом.
Дополнительные сведения о режимах доступа см. в режиме доступа к томам Kubernetes.
Следующие шаги
Сведения о статической подготовке см. в следующей PersistentVolume
статье:
Сведения о динамической подготовке см. в следующей StorageClass
статье: