Стадия жизненного цикла модуля: Общедоступная версия

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

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

Для этого необходимо проверить состояние подов в 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 никогда не обращается к пакетному менеджеру узла, поэтому узел в закрытой среде без доступа к репозиториям дистрибутива настраивается так же, как любой другой, и ни один запуск bashible не ждет этих репозиториев.

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

iscsi-tools несет две пары — iscsiadm с iscsid и multipath с multipathd, — и скрипт установки решает по каждой паре отдельно:

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

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

nvme-tools несет только nvme — демона у него нет, а значит нет и версии, которую надо согласовывать, — и размещается в /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, который прописывает модуль.

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

# демоны дистрибутива
systemctl is-active iscsid multipathd
# демоны и бинарные файлы модуля
systemctl is-active d8-csi-yadro-tatlin-unified-iscsid.service d8-csi-yadro-tatlin-unified-multipathd.service
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; единственные файлы вне собственных каталогов — обертки /usr/local/sbin/iscsiadm и /usr/local/sbin/nvme, описанные выше ссылки multipath и модули проверки путей multipath в /usr/lib/multipath, где их ищет multipathd, — каждый только для той части, которую пакет размещает, и ни один там, где у узла уже есть свой файл. И они не трогают /etc/iscsi/initiatorname.iscsi и /etc/nvme/hostnqn, если они на узле уже есть: эти имена — идентификаторы узла на массиве, под ними он там зарегистрирован, и узел, вернувшийся под другим именем, для массива является незнакомым.