Модуль csi-netapp: настройки

Сколько места тома резервируется под суперпользователя?

По умолчанию — нисколько: модуль просит Trident форматировать с -m0, весь объём тома доступен нагрузке.

Если классический 5-процентный резерв ext4 всё же нужен — например, чтобы привилегированный процесс мог писать в файловую систему после того, как нагрузка заняла её целиком, — задайте процент аннотацией на ресурсе NetappStorageConnection:

d8 k annotate netappstorageconnection <name> storage.deckhouse.io/ext4-reserved-percent=5

Обратите внимание на ресурс: в отличие от остальных модулей хранения, процент задаётся на подключение, а не на StorageClass. Trident хранит опции mkfs на бэкенде, поэтому значение действует на все StorageClass этого подключения.

Значение — целое число процентов от 0 до 50; при некорректном значении NetappStorageConnection остаётся с Ready=False и причиной в статусе, а не ломает создание томов позже.

Резерв применяется только к томам, созданным после установки аннотации: уже существующие файловые системы сохраняют тот резерв, с которым были созданы.

Откуда на узле берутся open-iscsi и multipath-tools?

Их ставит сам модуль. NodeGroupConfiguration никогда не обращается к пакетному менеджеру узла, поэтому узел в закрытой среде без доступа к репозиториям дистрибутива настраивается так же, как любой другой, и ни один запуск bashible не ждет этих репозиториев.

На каждом обслуживаемом узле — то есть на тех, где есть метка storage.deckhouse.io/csi-netapp-node, — bashible скачивает из реестра модуля образ-пакет iscsi-tools, распаковывает его и запускает скрипт установки. Стек состоит из двух пар — iscsiadm с iscsid и multipath с multipathd, — и скрипт решает по каждой паре отдельно:

• пара, которая на узле уже есть, остается узловой, а модуль только включает и настраивает юнит ее демона из дистрибутива;
• недостающая пара размещается в /var/lib/deckhouse/sds/csi-netapp, каждый ее бинарный файл запускается через собственный загрузчик со своим путем к библиотекам, а для демона поднимается юнит модуля.

Клиент и его демон всегда берутся из одного источника, поскольку iscsiadm одной версии не разговаривает с iscsid другой. Сами пары друг с другом не взаимодействуют, поэтому на узле вполне может работать узловой iscsid рядом с multipathd модуля.

Все остальное, что делает NodeGroupConfiguration, выполняется одинаково, откуда бы ни была взята каждая пара: переопределение find_multipaths no, блок устройства NetApp ONTAP, модули ядра и метка storage.deckhouse.io/csi-netapp-node-ready, которой дожидается узловой компонент CSI.

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

Trident обращается к хостовым iscsiadm, multipath и multipathd по имени, через nsenter, поэтому каждое имя разрешается по PATH контейнера, но уже в mount namespace хоста. Скрипт кладет в /usr/local/sbin обертку для каждой из этих утилит, взятой из модуля, и каждая обертка уступает дистрибутивному бинарному файлу, едва тот появится.

А multipathd из пакета читает конфигурацию по префиксу, с которым он собран, а не по /etc. Скрипт связывает multipath.conf и multipath из этого префикса с теми, что на узле. Без этой связи собственные предварительные проверки Trident видят find_multipaths: yes и вообще отказываются подключать том.

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

# демоны дистрибутива
systemctl is-active iscsid multipathd
# демоны и бинарные файлы модуля
systemctl is-active d8-csi-netapp-iscsid.service d8-csi-netapp-multipathd.service
ls /var/lib/deckhouse/sds/csi-netapp/bin
multipathd show config | grep find_multipaths

На самом узле стек модуля меняет немногое. Его библиотеки никогда не добавляются в хостовые /lib64 и /usr/lib. Единственные файлы вне собственного каталога — описанные выше обертки и ссылки и модули проверки путей multipath в /usr/lib/multipath, где их ищет multipathd; каждый из них появляется только там, где у узла нет своего файла, и убирается, как только у узла появляется своя пара, к которой он относится. И он не трогает /etc/iscsi/initiatorname.iscsi, если файл на узле уже есть: IQN — это идентификатор узла на массиве, под ним там зарегистрирован host-объект, и узел, вернувшийся под другим именем, для массива является незнакомым.

Требования

К версии Deckhouse Platform: 1.72 и выше.

Параметры

Версия схемы: 1

• settings

  объект
  • settings.logLevel

    строка

    Уровень детализации логирования модуля.

    По умолчанию: INFO

    Допустимые значения: ERROR, WARN, INFO, DEBUG, TRACE

  • settings.nodeSelector

    объект

    Определяет узлы, на которых может выполняться монтирование. Работает аналогично параметру spec.nodeSelector в подах Kubernetes. Если параметр не задан, монтирование NetApp доступно на любых узлах кластера под управлением операционной системы Linux.

    По умолчанию: { "kubernetes.io/os": "linux" }

  • settings.storageClassLabelIgnoredPrefixes

    массив строк

    Список префиксов ключей лейблов, которые НЕ должны пробрасываться (propagate — копироваться) с NetappStorageClass на управляемый StorageClass в Kubernetes.

    Контроллер объединяет этот список с системным (system — служебным, неизменяемым) списком и при формировании лейблов StorageClass отбрасывает любой лейбл NetappStorageClass, ключ которого начинается с одного из префиксов объединённого списка.

    Значения по умолчанию покрывают лейблы, которые обычно добавляют GitOps-инструменты (Argo CD, Flux, Rancher Fleet), чтобы их reconciler’ы не конкурировали с контроллером хранилища за лейблы управляемого StorageClass.

    По умолчанию: [ "argocd.argoproj.io/", "kustomize.toolkit.fluxcd.io/", "helm.toolkit.fluxcd.io/", "fleet.cattle.op/" ]