Deckhouse Standard Edition
Changes on Alpha
0.8.0·arrival time on the release channel unknown
0.8.0
Alpha- Dates
- released 24.09.2026 15:29 detected 05.10.2026 01:20
- Requirements
- deckhouse ≥ 1.72
- Stage
- General Availability
- On release channels
- Alpha — since unknown
- Before
- never
What changed in 0.8.0
Upgrade notes 4
- Руками делать ничего не нужно. После перезапуска пода агента на узле следующий прогон bashible удаляет файлы, которые модуль раньше устанавливал в `/opt/deckhouse/sds`; файлы других модулей и файлы-подложки там остаются на месте. Скрипты, которые запускали `/opt/deckhouse/sds/bin/lvm` или `dmsetup`, должны перейти на `/var/lib/deckhouse/sds/bin/`.duplicate not checked
- Поле `spec.fileDevices[].directory` неизменяемое, поэтому записи, созданные со старым значением по умолчанию `/opt/deckhouse/sds/file-devices`, продолжают на него указывать, и агент продолжает его принимать. Не переносите их файлы-подложки руками: как перевести запись в новый каталог без остановки, описано в FAQ. Новые записи создавайте в новом каталоге по умолчанию. Значение `fileDevicesDirectory`, явно заданное в настройках модуля, остаётся как есть.duplicate not checked
- Nothing has to be done by hand. Once the agent Pod has restarted on a node, the next bashible run removes the files the module used to install under `/opt/deckhouse/sds`; files of other modules and backing files there are left in place. Scripts that ran `/opt/deckhouse/sds/bin/lvm` or `dmsetup` have to switch to `/var/lib/deckhouse/sds/bin/`.duplicate not checked
- `spec.fileDevices[].directory` is immutable, so entries created with the old default `/opt/deckhouse/sds/file-devices` keep naming it, and the agent keeps accepting it. Do not move their backing files by hand; the FAQ describes how to move an entry to the new directory online. Create new entries under the new default. A `fileDevicesDirectory` set explicitly in the module config is kept as is.duplicate not checked
Breaking changes 2
- Модуль больше не устанавливает `lvm` и `dmsetup` в `/opt/deckhouse/sds/bin` и удаляет старые копии с узлов. Скрипты вне модуля, которые запускали их оттуда, должны перейти на `/var/lib/deckhouse/sds/bin/`.duplicate not checked
- The module no longer installs `lvm` and `dmsetup` under `/opt/deckhouse/sds/bin`, and removes the old copies from nodes. Scripts outside the module that run them from there have to use `/var/lib/deckhouse/sds/bin/`.duplicate not checked
Highlights 6
- Дерево модуля на узле переезжает в `/var/lib/deckhouse/sds`, куда можно писать и на узлах, где `/opt` доступен только для чтения, а значение `fileDevicesDirectory` по умолчанию становится `/var/lib/deckhouse/sds/file-devices`. Существующие записи `spec.fileDevices` в старом каталоге продолжают работать там же.duplicate not checked
- На узле с виртуальными машинами группы томов, которые вложенный кластер создаёт на своих дисках, больше не превращаются в ресурсы `LVMVolumeGroup` и `BlockDevice` кластера-хозяина.duplicate not checked
- `LVMLogicalVolumeSnapshot`, восстановление из VolumeSnapshot и клоны тонких томов работают на узлах без модуля ядра `dm_snapshot`.duplicate not checked
- The module's node tree moves to `/var/lib/deckhouse/sds`, which stays writable on nodes whose `/opt` is read-only, and the `fileDevicesDirectory` default becomes `/var/lib/deckhouse/sds/file-devices`. Existing `spec.fileDevices` entries under the old directory keep working where they are.duplicate not checked
- On a node that runs virtual machines, the Volume Groups a nested cluster builds on its disks no longer turn into `LVMVolumeGroup` and `BlockDevice` resources of the host cluster.duplicate not checked
- `LVMLogicalVolumeSnapshot`, restores from a VolumeSnapshot and clones of thin volumes work on nodes without the `dm_snapshot` kernel module.duplicate not checked
Improvements 2
- Новые метрики: `sds_node_configurator_published_block_devices` и `sds_node_configurator_published_devices_directory_present` показывают, сколько устройств на узле агент не пускает в LVM и нашёл ли он там каталог kubelet с опубликованными блочными томами, а `sds_node_configurator_legacy_file_devices_directory_lvgs` считает ресурсы `LVMVolumeGroup`, у которых `spec.fileDevices` всё ещё указывает на `/opt/deckhouse/sds/file-devices`; их имена выводятся в лог модуля.duplicate not checked
- New metrics: `sds_node_configurator_published_block_devices` and `sds_node_configurator_published_devices_directory_present` show how many devices the agent keeps out of LVM on each node and whether it found kubelet's directory of published block volumes there, and `sds_node_configurator_legacy_file_devices_directory_lvgs` counts the `LVMVolumeGroup` resources whose `spec.fileDevices` still name `/opt/deckhouse/sds/file-devices`; the module log lists their names.duplicate not checked
Fixes 8
- На узле с виртуальными машинами (DVP) агент читал LVM внутри дисков ВМ: группы томов гостевого кластера появлялись как ресурсы `LVMVolumeGroup`, а его диски — как ресурсы `BlockDevice` кластера-хозяина. Теперь команды `lvm` агента отвергают каждое устройство, которое kubelet опубликовал в под как блочный том, вместе с его разделами и всем, что построено поверх, для любого CSI-драйвера. Ресурсы, созданные так до обновления, выходят из `Ready`, и их можно удалить; группа томов внутри ВМ при этом не затрагивается.duplicate not checked
- Группа томов с тегом `storage.deckhouse.io/lvmVolumeGroupName=<name>`, указывающим на `LVMVolumeGroup`, которого в этом кластере нет, импортировалась как новый ресурс, хотя такой тег пишет только модуль в другом кластере (например, внутри виртуальной машины). Теперь она не импортируется: агент один раз пишет отказ в лог и учитывает его в `sds_node_configurator_lvm_volume_group_import_refused_total`. Группа томов, переданная модулю тегом `storage.deckhouse.io/enabled=true` без тега с именем, импортируется как прежде, как и группа на файлах-подложках.duplicate not checked
- Создание `LVMLogicalVolumeSnapshot`, восстановление из VolumeSnapshot и клонирование тонкого `LVMLogicalVolume` падали на узлах без загруженного модуля ядра `dm_snapshot` с ошибкой `snapshot: Required device-mapper target(s) not detected in your kernel`. Теперь тонкие снимки создаются без этого модуля. Агент по-прежнему загружает `dm_snapshot` на каждом узле с тонким выделением, а узел, где его нет, больше не мешает агенту запуститься.duplicate not checked
- Встроенный `lvm` не мог сам загрузить недостающий модуль ядра device-mapper и вместо этого сообщал, что цель не найдена. Теперь он вызывает `/sbin/modprobe` узла.duplicate not checked
- On a node that runs virtual machines (DVP), the agent read LVM inside VM disks: a guest cluster's Volume Groups appeared as `LVMVolumeGroup` resources and its disks as `BlockDevice` resources of the host cluster. The agent's `lvm` commands now reject every device kubelet has published to a Pod as a block volume, with its partitions and whatever is stacked on it, for any CSI driver. Resources created this way before the update leave `Ready` and can be deleted; the Volume Group inside the VM is not touched.duplicate not checked
- A Volume Group tagged `storage.deckhouse.io/lvmVolumeGroupName=<name>` for an `LVMVolumeGroup` that does not exist in this cluster was imported as a new resource, although only the module in another cluster (for example, inside a virtual machine) writes that tag. It is no longer imported: the agent logs the refusal once and counts it in `sds_node_configurator_lvm_volume_group_import_refused_total`. A Volume Group handed over with `storage.deckhouse.io/enabled=true` and no name tag is imported as before, and so is a file-backed one.duplicate not checked
- Creating an `LVMLogicalVolumeSnapshot`, restoring from a VolumeSnapshot and cloning a thin `LVMLogicalVolume` failed on nodes without the `dm_snapshot` kernel module loaded, with `snapshot: Required device-mapper target(s) not detected in your kernel`. Thin snapshots are now created without that module. The agent still loads `dm_snapshot` on every node with thin provisioning, and a node where it is missing no longer keeps the agent from starting.duplicate not checked
- The bundled `lvm` could not load a missing device-mapper kernel module by itself and reported the target as not detected instead. It now calls the node's `/sbin/modprobe`.duplicate not checked
Documentation 2
- FAQ: раздел о файлах-подложках, созданных до переноса базового каталога, с порядком перевода записи в новый каталог через `pvmove`.duplicate not checked
- FAQ: a section on backing files created before the base directory moved, with a procedure that moves an entry to the new directory using `pvmove`.duplicate not checked