Поставщик хранилища Kubernetes, который использует диски узла кластера

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

  • Будьте независимы от ОС. Любой Linux с нормальным ядром и монтируется в cgroup.
  • Предлагайте постоянное хранилище, используя диски узла кластера.
  • Предложите ReadWriteMany тома или способ реализации общего хранилища.
  • POD не должны быть привязаны к определенному узлу (например, для локальных постоянных томов)
  • Тома автоматически повторно присоединяются при миграции POD (например, из-за утечки узлов или состояния потери узла)
  • Предлагает репликацию данных на уровне хранилища
  • Не предполагайте, что для каждого узла доступно выделенное необработанное блочное устройство.

Я обращаюсь к первому пункту, используя статические двоичные файлы для компонентов k8s и движка контейнера. В сочетании с минимальным набором инструментов для хоста это также статические двоичные файлы.

Я все еще ищу решение для постоянного хранилища.

Что я оценивал / использовал до сих пор:

  • Rook: хотя он отвечает требованиям с точки зрения функций, есть ошибка, и тома не перемещаются вместе с POD https://github.com/rook/rook/issues/1507
  • OpenEBS: он не отвечает требованию независимости от ОС. Требуется клиент iSCSI и инструменты на каждом узле, что зависит от ОС хоста https://docs.openebs.io/docs/next/prerequisites.html

Итак, вопрос в том, какой еще вариант у меня есть для постоянного хранилища Kubernetes при использовании дисков узлов кластера.

Источник

4 ответа

Решение

Приведенные ниже варианты можно рассмотреть

  1. kubernetes версии 1.14.0 на wards поддерживает локальные постоянные тома. Вы можете использовать локальные pv, используя метки узлов. Возможно, вам придется запускать рабочие нагрузки с отслеживанием состояния в режиме HA (главный-подчиненный), чтобы данные были доступны в случае сбоев узла.

  2. Вы можете установить сервер nfs на одном из узлов кластера и использовать его как хранилище для своих рабочих нагрузок. nfs storage поддерживает ReadWriteMany. Это может сработать, если вы настроите кластер на baremetal

  3. Rook - также один из хороших вариантов, который вы уже пробовали, но он еще не готов к производству.

Первый из трех вариантов соответствует вашим требованиям. Хотелось бы услышать другие варианты от сообщества.

Источник

Прошло два с половиной года, но это может помочь тем, кто попал сюда через поиск Google.
OpenEBS предлагает решение, позволяющее использовать диски узлов для создания PersistentVolumes с именем rawfile-localpv; Установите его в своем кластере, создайте StorageClass, подобный этому, а затем подготовьте свои PersistentVolumeClaims, используя этот StorageClass:

      apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-sc
provisioner: rawfile.csi.openebs.io
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Имейте в виду, что при использовании этого решения ваши модули по-прежнему привязаны к определенному узлу (где находится pv), и при необходимости вы должны выполнять весь процесс миграции самостоятельно. Но он предоставляет аккуратное и простое решение для использования высокопроизводительного хранилища внутри кластера Kubernetes.

Ссылка на проект на Github: https://github.com/openebs/rawfile-localpv

Источник

Согласно официальной документации на данный момент (v1.16) K8S поддерживает WriteMany на нескольких различных типах томов.

А именно это: cephfs, glusterfs и nfs

Как правило, при всем этом содержимое тома сохраняется, и том просто отключается при удалении модуля. Это означает, что том можно предварительно заполнить данными, и эти данные могут "передаваться" между модулями. Эти FS могут быть смонтированы несколькими авторами одновременно.

Среди этих FS glusterfs можно развернуть на каждом узле кластера kubernetes (требуется как минимум 3). Доступ к данным можно получить разными способами, одним из которых является NFS.

А persistentVolumeClaimVolume используется для монтирования PersistentVolume в Pod. PersistentVolumes - это способ, с помощью которого пользователи могут "потребовать" надежное хранилище (например, GCE PersistentDisk или том iSCSI), не зная подробностей конкретной облачной среды. ReadWriteMany поддерживается следующими типами томов: - AzureFile - CephFS - Glusterfs - Quobyte - NFS - PortworxVolume

но это не вариант без контроля базовой инфраструктуры.

В localПараметр тома представляет смонтированное локальное запоминающее устройство, такое как диск, раздел или каталог. Локальные тома можно использовать только как статически созданный PersistentVolume. Недостатком является то, что если узел становится неработоспособным, локальный том также становится недоступным, и использующий его под не сможет работать.

Так что на данный момент нет готового решения, удовлетворяющего всем требованиям.

Источник

Вы можете использовать OpenEBS Local PV, который может использовать весь диск для приложения, используя класс хранилища по умолчанию. openebs-device и вы можете использовать смонтированный диск для совместного использования нескольких приложений, используя класс хранилища по умолчанию openebs-hostpath. Более подробная информация представлена ​​в документации OpenEBS в разделеUser Guideраздел. Это не требует open-iscsi. Если вы используете прямое устройство, то при использовании OpenEBS Node Disk Manager диск будет автоматически обнаружен и использован. Для удовлетворения сценария использования RWM вы можете использовать этот подготовленный том, используя локальный PV, как нижний том для нескольких приложений с помощью средства обеспечения NFS. Реализация того же упоминается в документации OpenEBS в разделеStateful Application раздел.

Источник
Другие вопросы по тегам