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

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

v0.2.2

Дата релиза: 2026-10-01

Том, расширенный без остановки пода после перезапуска node plugin, снова отключается от узла и удаляется, а не остаётся смонтированным на нём навсегда.

Ключевые изменения

Изменения в этом релизе:

  • После перезапуска пода csi-node том, расширенный без остановки пода, отключается от узла при удалении пода и PersistentVolumeClaim — для volumeMode: Filesystem и volumeMode: Block.

Исправления

В этом релизе исправлено:

  • Расширение без остановки пода после перезапуска node plugin: node plugin хранит подключённые тома в памяти, и после перезапуска пода csi-node расширение восстанавливало том по пути, по которому он смонтирован в под, а не по пути staging (промежуточной точки монтирования тома на узле). Отключение тома после этого бесконечно завершалось ошибкой remove staging path ...: directory not empty: монтирование staging и подключение NBD оставались на узле, VolumeAttachment не снимался, PersistentVolume оставался в Released. Теперь расширение восстанавливает том по пути staging, а отключение не доверяет записи, сделанной для другого пути.

Рекомендации по обновлению

Перед обновлением учтите следующее:

  • Том, застрявший так в v0.2.1 или раньше, обновление не освобождает. На его узле нужно отмонтировать то, что осталось в пути staging: для тома с файловой системой — каталог globalmount из события kubelet remove staging path, для блочного тома — .../volumeDevices/staging/<имя PV>/device, который затем нужно удалить. Kubelet доделает отключение при следующей попытке, и PersistentVolume удалится.

Известные ограничения

Известные ограничения этого релиза:

  • Диски виртуальных машин на узлах с ядром Linux 6.6 и новее (на нашем стенде — Ubuntu 24.04 и RED OS 8.0) теряют соединение NBD в первую минуту после старта виртуальной машины (Double reply или Unexpected reply от драйвера nbd в журнале ядра): гостевая система остаётся без диска, а виртуальную машину нельзя остановить, пока устройство не отключено на узле командой ustor-nbd netlink-unmap /dev/nbdN. Узлы с ядром Linux 6.1 (Debian 12, Astra 1.8) не затронуты. Причины выясняются.

v0.2.1

Дата релиза: 2026-09-30

Блочные тома после перезапуска node plugin отключаются со своего устройства, а снимки создаются без указания VolumeSnapshotClass.

Ключевые изменения

Изменения в этом релизе:

  • После перезапуска пода csi-node отключение блочного тома (volumeMode: Block) больше не отключает том другого пода на /dev/nbd0 и не оставляет свой подключённым.
  • StorageClass модуля получают аннотацию storage.deckhouse.io/volumesnapshotclass: csi-mind-ustor, поэтому VolumeSnapshot без volumeSnapshotClassName создаётся.

Исправления

В этом релизе исправлено:

  • Блочные тома после перезапуска node plugin: node plugin хранит устройство подключённого тома в памяти, а после перезапуска пода csi-node брал устройство блочного тома из таблицы монтирований, где источником блочного тома указан udev. Отключение тома тогда отключало /dev/nbd0, чей бы том там ни был, а свой образ оставляло подключённым, и его PersistentVolume не удалялся (still used by client(s)). Теперь устройство берётся из записи таблицы монтирований о файле устройства и перед отключением проверяется, что на нём образ этого тома; если нет, ищется устройство, на котором этот образ подключён. Расширение блочного тома без остановки пода после перезапуска использует тот же поиск.
  • Снимки: StorageClass модуля получают аннотацию storage.deckhouse.io/volumesnapshotclass: csi-mind-ustor. Без неё snapshot-controller отклонял любой VolumeSnapshot тома модуля, storage-foundation не подставлял класс в VolumeSnapshot, где класс не указан, а сценарии storage-foundation, берущие класс из StorageClass, завершались ошибкой. Значение, уже заданное на StorageClass, сохраняется.

Рекомендации по обновлению

Перед обновлением учтите следующее:

  • Аннотация добавляется в StorageClass существующих MindUstorStorageClass на месте; руками ничего делать не нужно.
  • Блочный том, отключённый в v0.2.0 после перезапуска node plugin, остаётся подключённым на своём узле, а его PersistentVolume остаётся в Released. Найдите такие подключения командой ustor-nbd ls на узле, сверьте их с VolumeAttachment узла и отключите каждое по полному имени устройства: ustor-nbd netlink-unmap /dev/nbdN; после этого PersistentVolume удаляется. Под, у которого блочный том потерял устройство (ошибки ввода-вывода на устройстве), нужно пересоздать.

v0.2.0

Дата релиза: 2026-09-29

Снимки томов, блочные тома и живая миграция виртуальных машин на uStor, а также статистика томов, топология и проверка входа в uStor в драйвере.

Ключевые изменения

Изменения в этом релизе:

  • Снимки томов: модуль создаёт VolumeSnapshotClass csi-mind-ustor, а PersistentVolumeClaim можно восстановить из снимка, в том числе в claim больше снимка.
  • Блочные тома (volumeMode: Block) и блочные тома ReadWriteMany для виртуальных машин модуля virtualization, которые теперь можно мигрировать между узлами вживую.
  • MindUstorStorageConnection сообщает в новом условии Authenticated, принимает ли uStor вход его пользователя, поэтому заблокированный пользователь или истёкший пароль видны в подключении и его алерте.

Новый функционал

В этом релизе добавлено:

  • Снимки: если в кластере есть модуль, предоставляющий API snapshot.storage.k8s.io (например, storage-foundation), CSI-контроллер запускает snapshotter, а модуль создаёт VolumeSnapshotClass csi-mind-ustor. Восстановленный том — полная независимая копия снимка; он может быть больше снимка, и его файловая система увеличивается до запрошенного размера при монтировании.
  • Блочные тома: PersistentVolumeClaim с volumeMode: Block и режимом доступа ReadWriteOncePod получает том uStor как устройство, с расширением без остановки пода и снимками.
  • Блочные тома на нескольких узлах для виртуальных машин: драйвер принимает ReadWriteMany для volumeMode: Block. Вебхук pvc-validation разрешает создавать такой claim только сервисным аккаунтам модуля virtualization и отклоняет ReadWriteMany с volumeMode: Filesystem для всех.
  • StorageClass модуля несут аннотации virtualdisk.virtualization.deckhouse.io/volume-mode: Block и virtualdisk.virtualization.deckhouse.io/access-mode: ReadWriteMany, поэтому модуль virtualization создаёт на них свои VirtualDisk как блочные тома ReadWriteMany; уже заданное на StorageClass значение сохраняется.
  • Статистика томов: node plugin отвечает на NodeGetVolumeStats, поэтому kubelet отдаёт kubelet_volume_stats_* для томов uStor, и алерты и дашборды заполнения PersistentVolumeClaim работают для них.
  • Условие Authenticated у MindUstorStorageConnection: модуль входит в API управления uStor с учётными данными подключения раз в час и сразу после изменения Secret’а с ними. Причина (reason) называет причину отказа (UserLocked, PasswordExpired, TemporaryPassword, UserNotFound, LoginRejected, Unreachable), пока вход не удаётся, Ready равно False и срабатывает алерт D8CsiMindUstorStorageConnectionNotInUse. Ежечасный вход к тому же не даёт uStor заблокировать пользователя кластера, где долго не создаются тома.

Улучшения

В этом релизе улучшено:

  • Поды с томами uStor размещаются только на узлах, где работает node plugin: драйвер сообщает сегмент топологии topology.ustor-nbd.csi.mindsw.io/data-plane, новые PersistentVolume получают привязку к нему (node affinity), а StorageClass модуля выбирают его в allowedTopologies. WaitForFirstConsumer теперь работает так, как сказано в описании volumeBindingMode.
  • Node plugin запускается только на узлах с установленным клиентом uStor, которые модуль помечает меткой storage.deckhouse.io/csi-mind-ustor-client-ready=true; узел с неподдерживаемой ОС больше не регистрирует драйвер.
  • Клиент uStor ставится вместе со всеми нужными ему библиотеками из самого модуля, без пакетов из репозиториев узла, поэтому клиент получает и узел без доступа к репозиториям своего дистрибутива.
  • Ошибка отклонённого входа в uStor содержит причину, которую называет uStor, а не «invalid credentials» для любого случая, и отклонённый вход не повторяется с теми же учётными данными 5 минут, поэтому опечатка в пароле в Secret’е больше не блокирует пользователя uStor за секунды.
  • В Deckhouse 1.78 и новее модуль выдаёт доступ к своим ресурсам по модели capability/scope, наряду с ролями manage/use для более ранних версий.

Рекомендации по обновлению

Перед обновлением учтите следующее:

  • StorageClass существующих MindUstorStorageClass один раз пересоздаются, чтобы добавить allowedTopologies; уже созданные тома это не затрагивает. PersistentVolume, созданные до обновления, не привязаны к топологии и работают как раньше.
  • После обновления node plugin уходит с узла, пока bashible не применит там новую NodeGroupConfiguration и не поставит метку (обычно несколько минут). Смонтированные на узле тома всё это время работают; их отмонтирование и расширение ждут метки.
  • Руками ничего делать не нужно: новые аннотации StorageClass, VolumeSnapshotClass и вебхук создаёт модуль.

Известные ограничения

Известные ограничения этого релиза:

  • Клонировать том напрямую из другого PersistentVolumeClaim нельзя; создайте снимок и восстановите том из него.
  • Блочный том без ReadWriteMany обслуживается только с ReadWriteOncePod, а ReadWriteMany оставлен для дисков виртуальных машин модуля virtualization.
  • Живая миграция виртуальной машины между узлами с разными ОС может завершиться ошибкой QEMU на состоянии сетевого устройства virtio, когда диски на целевом узле уже подключены; миграция между узлами с одинаковой ОС работает.

Документация

Изменения в документации:

  • Документация разделена на обзор, руководство по использованию, настройки, описание ресурсов и FAQ. Руководство описывает пользователя uStor, который нужен CSI-контроллеру, и его политику паролей, смену его пароля, снимки и восстановление, блочные тома и блочные тома для виртуальных машин.

Зависимости

Обновления зависимостей:

  • uStor CSI driver: delivery 2026-08-25 → delivery 2026-09-28
    • Поставка вендора добавляет снимки и блочные тома; модуль накладывает поверх свои исправления (статистика томов, топология, причина отказа входа и пауза перед повтором, восстановление в том больше снимка, блочные тома на нескольких узлах).

v0.1.0

Дата релиза: 2026-09-25

Первый выпуск модуля: постоянные тома на uStor 1.6 по NBD, управляемые ресурсами MindUstorStorageConnection и MindUstorStorageClass.

Ключевые изменения

Изменения в этом релизе:

  • Кластер uStor описывается один раз, ресурсом MindUstorStorageConnection: API управления, Secret с пользователем uStor, адреса etcd и Secret с клиентскими сертификатами. Условие Ready показывает, используется ли подключение, а если нет — чего не хватает.
  • MindUstorStorageClass задаёт подключение, пул, файловую систему, политику освобождения и режим привязки, а модуль создаёт под него StorageClass. Вручную StorageClass для этого драйвера не создать и не изменить — им владеет модуль.
  • Узлы готовит сам модуль: клиент uStor (ustor-client, ustor-nbd) устанавливается на Astra Linux 1.8, РЕД ОС 8, Ubuntu 22.04 и 24.04 и Debian 12, а его конфигурация и сертификаты поддерживаются в соответствии с подключением.

Новый функционал

В этом релизе добавлено:

  • Жизненный цикл тома: создание, подключение и отключение, расширение на лету, переезд пода между узлами. Том переживает перезапуск node plugin (узлового плагина CSI).
  • Настройка модуля clusterID разделяет образы нескольких кластеров Kubernetes, которые обслуживает одна инсталляция uStor.
  • Алерты D8CsiMindUstorStorageConnectionNotInUse и D8CsiMindUstorStorageClassNotReady срабатывают, если подключение или StorageClass остаются в состоянии Failed дольше 15 минут.

Известные ограничения

Известные ограничения этого релиза:

  • Модуль обслуживает один кластер uStor: все MindUstorStorageConnection, кроме самого старого, получают статус Failed.
  • Снимки и блочные тома (raw block) не поддерживаются.
  • На узле с ОС не из списка поддерживаемых клиент uStor не устанавливается, и тома uStor на нём не монтируются.