Модуль csi-hpe: FAQ

Какие требования предъявляются к модулю csi-hpe?

Модуль csi-hpe требует:

• Наличие развернутой и настроенной СХД HPE.
• Уникальные iqn в /etc/iscsi/initiatorname.iscsi на каждой из Kubernetes Nodes
• Модуль snapshot-controller должен быть включен в кластере (требуется для функциональности снапшотов томов).

Как проверить работоспособность модуля?

Для этого необходимо проверить состояние подов в namespace d8-csi-hpe. Все поды должны быть в состоянии Running или Completed и запущены на всех узлах.

kubectl -n d8-csi-hpe get pod -owide -w

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

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

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

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

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

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

Изменение аннотации приводит к пересозданию StorageClass контроллером, поскольку поле parameters у существующего StorageClass в Kubernetes иммутабельно. На уже созданные тома и PVC это не влияет.

Что произойдет, если репозитории узла не могут предоставить open-iscsi и multipath-tools?

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

На каждом обслуживаемом узле NodeGroupConfiguration сначала просит пакетный менеджер узла установить open-iscsi и multipath-tools. Этот путь остается предпочтительным: вокруг собственного клиента и демона узла построено все остальное на этом узле, и пока они на месте, модуль в них не вмешивается.

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

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

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

Драйвер обращается к хостовому iscsiadm через контейнерный /bin/iscsiadm — это встроенный бинарный файл host-iscsiadm: он делает chroot в /host и ищет клиента уже там, по собственному PATH. Скрипт кладет обертку в /usr/local/sbin/iscsiadm, который этот PATH просматривает раньше дистрибутивных каталогов, и обертка уступает дистрибутивному iscsiadm, едва тот появится.

А multipathd из пакета читает конфигурацию по префиксу, с которым он собран, а не по /etc. Скрипт связывает multipath.conf и multipath из этого префикса с теми, что на узле. Здесь это важнее, чем где-либо: драйвер находит застейдженный LUN исключительно по его карте device-mapper, поэтому find_multipaths no, который модуль пишет в /etc/multipath/conf.d, и есть разница между работающим подключением и ошибкой device not found with serial <wwn>.

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

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

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

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

sg3-utils запрашивается у дистрибутива, но в откате его нет, и ничего от этого не теряется: единственным обращением драйвера к нему был rescan-scsi-bus.sh, и патчи модуля заменили его прямыми записями в sysfs.