Модуль csi-yadro-tatlin-unified: FAQ

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

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

kubectl -n d8-csi-yadro-tatlin-unified get pod -owide -w

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

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

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

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

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

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

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

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

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

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

Если установка не удалась — закрытая среда без доступа к репозиториям или дистрибутив, который этих пакетов не поставляет, — модуль разворачивает собственный образ-пакет. bashible скачивает его из реестра модуля, распаковывает на узле и запускает скрипт установки.

Таких образов два, и они намеренно независимы: дистрибутив, который не может дать open-iscsi, может при этом дать nvme-cli, и наоборот.

iscsi-tools размещается в /var/lib/deckhouse/sds/csi-yadro-tatlin-unified и поднимает два юнита:

systemctl is-active d8-csi-yadro-tatlin-unified-iscsid.service d8-csi-yadro-tatlin-unified-multipathd.service

nvme-tools размещается в /var/lib/deckhouse/sds/csi-yadro-tatlin-unified-nvme и несет только nvme — демона у него нет, а значит нет и версии, которую надо согласовывать. Хосту он нужен для собственной настройки, а не для вызовов драйвера: NodeGroupConfiguration выполняет nvme gen-hostnqn, чтобы дать узлу постоянное NVMe Qualified Name, которое драйвер затем регистрирует в группе доступа массива. Без него драйвер сообщает initiators is empty, и ни один том NVMe-TCP на этот узел опубликовать нельзя.

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

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

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

# стек дистрибутива
systemctl is-active iscsid multipathd
# собственный стек модуля
ls /var/lib/deckhouse/sds/csi-yadro-tatlin-unified/bin
ls /var/lib/deckhouse/sds/csi-yadro-tatlin-unified-nvme/bin
command -v iscsiadm nvme

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