Блог

У меня есть приложение, запущенное в Kubernetes, которому необходимо получить доступ к общим ресурсам SMB, которые настраиваются динамически (хост, учетные данные и т. Д.) В указанном приложении. Я изо всех сил пытаюсь добиться этого (чисто) с помощью Kubernetes.

Я сталкиваюсь с несколькими трудностями:

• Мне не нужно хранилище «a», мне нужны явно указанные общие ресурсы SMB
• Эти общие ресурсы динамически определяются в приложении и заранее неизвестны
• У меня переменное количество общих ресурсов, и один модуль должен иметь доступ ко всем из них

В настоящее время у нас есть решение, в котором на каждом рабочем узле kubernetes все общие ресурсы подключаются к точкам монтирования в общей папке. Затем эта папка присваивается в качестве HostPath тома контейнерам, которым требуется доступ к этим хранилищам. Наконец, у каждого из этих контейнеров есть логика для доступа к подпапкам, соответствующим хранилищам, которые ему нужны.

Недостатком и причиной, по которой я ищу более чистую альтернативу, является:

• HostPath тома представляют угрозу безопасности
• Для этого решения мне нужно что-то вне Kubernetes, которое автоматически монтирует общие ресурсы SMB на каждом узле Kubernetes

Есть ли лучшее решение, которого мне не хватает?

Объект Kubernetes, который, по-видимому, наиболее точно соответствует этому подходу, — это проектируемый том, поскольку он «отображает существующие источники томов в один и тот же каталог». Однако он не поддерживает тип источника тома, который мне нужен, и я не думаю, что можно динамически добавлять / удалять источники тома без перезапуска модулей, которые используют этот прогнозируемый объем.

Наверняка ваше текущее решение, использующее hostPath на узлах, не является гибким, небезопасным, поэтому это не очень хорошая практика.

Я думаю, вам следует рассмотреть возможность использования одного из пользовательских драйверов для ваших общих ресурсов SMB:

• Плагин CIFS FlexVolume — более старое решение, не поддерживается
• Драйвер CSI SMB — активно разрабатывается (рекомендуется)

Плагин CIFS FlexVolume:

Это более старое решение, и оно заменено драйвером CSI. Преимущество по сравнению с CSI заключается в том, что вы можете указать общие ресурсы SMB непосредственно из определения pod (включая учетные данные как секрет Kubernetes) по своему усмотрению.

Здесь вы можете найти инструкции по установке этого плагина в свой кластер.

Драйвер CSI SMB:

Этот драйвер автоматически позаботится о подключении общих ресурсов SMB на всех узлах с помощью DaemonSet.

Вы можете установить драйвер SMB CSI либо с помощью bash-скрипта, либо с помощью helm-диаграммы.

Предполагая, что ваш SMB-сервер готов, вы можете использовать одно из следующих решений для доступа к нему из своего модуля:

• Класс хранилища
• PV / PVC

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

В вашем случае для каждого общего ресурса SMB вы должны создать класс хранилища / PV и подключить его к pod.

Преимущество драйвера CSI в том, что это более новое, поддерживаемое в настоящее время решение, и оно заменило FlexVolume.

Ниже приведена схема, представляющая, как работает плагин CSI:

Также проверьте:

• Эволюция плагинов для томов Kubernetes от FlexVolume до CSI
• Представляем альфа-интерфейс контейнерного хранилища (CSI) для Kubernetes