Модуль 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?

Модуль установит их сам, из собственного образа.

На каждом обслуживаемом узле — то есть на тех, где есть метка storage.deckhouse.io/csi-netapp-node, — NodeGroupConfiguration сначала просит пакетный менеджер узла установить open-iscsi и multipath-tools (на RPM-дистрибутивах — iscsi-initiator-utils и device-mapper-multipath). Этот путь остается предпочтительным: вокруг собственного клиента и демона узла построено все остальное на этом узле, и пока они на месте, модуль в них не вмешивается.

Если установка не удалась — закрытая среда без доступа к репозиториям или дистрибутив, который этих пакетов не поставляет, — модуль разворачивает собственный образ-пакет iscsi-tools. bashible скачивает его из реестра модуля, распаковывает на узле и запускает скрипт установки. Полезная нагрузка размещается в /var/lib/deckhouse/sds/csi-netapp, каждый бинарный файл запускается через собственный загрузчик со своим путем к библиотекам, а для демонов поднимаются два юнита:

systemctl is-active d8-csi-netapp-iscsid.service d8-csi-netapp-multipathd.service

Все, что 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 и вообще отказываются подключать том.

Два пути никогда не смешиваются. Узел, у которого уже есть свой iscsiadm, сохраняет все свое, и скрипт установки там ничего не делает: клиент и демон всегда должны быть из одного источника, поскольку iscsiadm одной версии не разговаривает с iscsid другой.

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

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

Две вещи, которых откат намеренно не делает. Он ничего не добавляет в хостовые /lib64 и /usr/lib — полезная нагрузка самодостаточна. И он не трогает /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/" ]