Deckhouse Standard Edition
Changes on Alpha
0.5.37·arrival time on the release channel unknown
0.5.37
Alpha- Dates
- released 01.10.2026 14:23 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.5.37
Upgrade notes 8
- Контроллер один раз пересоздаёт каждый существующий RBD StorageClass, чтобы добавить параметры секрета для отключения: в Kubernetes `parameters` у StorageClass неизменяемы. Существующие PersistentVolume и PVC не затрагиваются: секрет для отключения есть только у томов, созданных после обновления, а более старые RBD-тома по-прежнему отключаются через общую запись конфигурации ceph-csi.duplicate not checked
- После обновления проверьте условие `ClusterConfigConflict` в кластерах, где к одному кластеру Ceph ведут несколько `CephClusterConnection`. В FAQ приведена команда, которая выводит затронутые подключения, и описано, как дать перечисленным RBD-томам отключиться: выдать пользователю подключения, настройки которого хранит запись, доступ к их пулам.duplicate not checked
- Удаление `CephClusterConnection` теперь ждёт, пока не исчезнут PersistentVolume и `VolumeSnapshotContent`, которым нужен его Secret. Чтобы удаление завершилось, удалите их или `VolumeSnapshot` перечисленных объектов `VolumeSnapshotContent`. Для этого контроллер получает права на чтение PersistentVolume, `VolumeAttachment` и `VolumeSnapshotContent`.duplicate not checked
- В DKP 1.78 и новее роли ClusterRole `d8:manage:permission:module:csi-ceph:*` заменены на `d8:system-capability:csi-ceph:*`. Доступ, выданный через агрегацию ролей Deckhouse, продолжает работать; привязку, созданную вручную к одной из старых ролей, нужно перевести на новое имя.duplicate not checked
- The controller recreates every existing RBD StorageClass once to add the controller-publish secret parameters; `parameters` of a StorageClass are immutable in Kubernetes. Existing PersistentVolumes and PVCs are not affected: only volumes provisioned after the upgrade carry the detach Secret, and older RBD volumes keep detaching through the shared ceph-csi configuration entry.duplicate not checked
- After the upgrade, check `ClusterConfigConflict` on clusters with several `CephClusterConnection`s to the same Ceph cluster; the FAQ gives the command that lists the affected connections and explains how to let the listed RBD volumes detach by granting the user of the connection the entry holds access to their pools.duplicate not checked
- Deleting a `CephClusterConnection` now waits for the PersistentVolumes and `VolumeSnapshotContent`s that need its Secret. Delete them, or the `VolumeSnapshot`s of the listed contents, for the deletion to finish. The controller is granted read access to PersistentVolumes, `VolumeAttachment`s and `VolumeSnapshotContent`s for this.duplicate not checked
- On DKP 1.78 and later the `d8:manage:permission:module:csi-ceph:*` ClusterRoles are replaced by `d8:system-capability:csi-ceph:*`. Access granted through the Deckhouse role aggregation keeps working; a binding created by hand to one of the old role names has to be moved to the new name.duplicate not checked
Highlights 6
- RBD-тома отключаются с секретом своего `CephClusterConnection`. Раньше при двух подключениях к одному кластеру Ceph отключение могло выполняться от пользователя другого подключения, падать с `Operation not permitted` и оставлять `VolumeAttachment`, из-за чего следующее подключение тома блокировалось ошибкой `Multi-Attach`.duplicate not checked
- Удаляемый `CephClusterConnection` сохраняет свой Secret и финализатор (finalizer — метка, удерживающая объект от удаления), пока они нужны PersistentVolume или `VolumeSnapshotContent`, и сообщает об этом в условии `Ready` с причиной `PersistentVolumesExist` или `VolumeSnapshotContentsExist`.duplicate not checked
- Новое условие `ClusterConfigConflict` у `CephClusterConnection` перечисляет тома, которым нужен другой пользователь Ceph или другая группа подтомов CephFS, чем записаны в общей конфигурации ceph-csi для их кластера.duplicate not checked
- RBD volumes detach with the secret of their own `CephClusterConnection`. Before, with two connections to the same Ceph cluster, a detach could run as the user of the other connection, fail with `Operation not permitted` and leave the `VolumeAttachment` behind, blocking the next attach of the volume with `Multi-Attach`.duplicate not checked
- A `CephClusterConnection` being deleted keeps its Secret and finalizer while PersistentVolumes or `VolumeSnapshotContent`s still need them, and says so in its `Ready` condition with the reason `PersistentVolumesExist` or `VolumeSnapshotContentsExist`.duplicate not checked
- The new `ClusterConfigConflict` condition of `CephClusterConnection` names the volumes that need a Ceph user or a CephFS subvolume group other than the one the shared ceph-csi configuration of their cluster holds.duplicate not checked
Improvements 2
- Контроллер модуля больше не хранит `managedFields` объектов PersistentVolume и `VolumeAttachment` в своём кеше, где лежат объекты всех CSI-драйверов кластера, поэтому его потребление памяти меньше растёт с числом томов.duplicate not checked
- The module controller no longer keeps `managedFields` of PersistentVolumes and `VolumeAttachment`s in its cache, which holds those of every CSI driver in the cluster, so its memory use grows less with the number of volumes.duplicate not checked
Fixes 6
- Каждый RBD StorageClass теперь содержит параметры `csi.storage.k8s.io/controller-publish-secret-name` и `csi.storage.k8s.io/controller-publish-secret-namespace`, поэтому в каждом новом RBD PersistentVolume для отключения указан Secret его собственного `CephClusterConnection`. Раньше ceph-csi брал секрет для отключения из единственной записи конфигурации на кластер Ceph, которую контроллер перезаписывал данными подключения, обработанного последним. При двух подключениях к одному кластеру, например одном для RBD и другом для CephFS, у пользователя которого нет доступа к RBD-пулам, отключение завершалось ошибкой, и том нельзя было подключить на другом узле. Для RBD-томов, созданных до обновления и по-прежнему зависящих от этой записи, запись сохраняет подключение, от которого зависят тома, а удаление одного из подключений к кластеру больше не убирает запись, нужную остальным.duplicate not checked
- Удаление `CephClusterConnection` больше не оставляет его тома в нерабочем состоянии. Раньше его Secret удалялся сразу, и созданный через него том уже нельзя было отключить, расширить или удалить. Теперь подключение остаётся, пока его Secret нужен хотя бы одному PersistentVolume (подключённому к узлу, в фазе `Bound` или ещё не занятому, либо в фазе `Released`/`Failed` с политикой возврата `Delete`) и пока на него ссылается хотя бы один `VolumeSnapshotContent` с политикой удаления `Delete`. Его условие `Ready` равно `False` с причиной `PersistentVolumesExist` или, если остались только снимки, `VolumeSnapshotContentsExist`, а в сообщении названы до десяти таких объектов. PersistentVolume в фазе `Released` или `Failed` с политикой `Retain`, не подключённый ни к одному узлу, подключение не удерживает, поэтому такой том не блокирует удаление `ElasticCluster` в sds-elastic. Подключение удаляется сразу после исчезновения последнего тома или снимка.duplicate not checked
- Группа подтомов CephFS в общей записи конфигурации ceph-csi больше не переключается на группу другого `CephClusterConnection`, когда второе подключение к тому же кластеру создаёт свой первый том CephFS. Раньше созданные до этого тома CephFS после такого переключения уже нельзя было удалить или расширить. Теперь группа определяется по `subvolumePath` существующих томов, а мониторы в записи берутся из всех подключений к кластеру.duplicate not checked
- Every RBD StorageClass now carries the `csi.storage.k8s.io/controller-publish-secret-name` and `csi.storage.k8s.io/controller-publish-secret-namespace` parameters, so each new RBD PersistentVolume names the Secret of its own `CephClusterConnection` for detach. Before, ceph-csi took the detach Secret from the one configuration entry per Ceph cluster, which the controller overwrote with the connection reconciled last; with two connections to one cluster, for example one for RBD and one for CephFS whose user has no access to the RBD pools, detach failed and the volume could not be attached on another node. For RBD volumes provisioned before the upgrade, which still rely on that entry, the entry keeps the connection whose volumes depend on it, and deleting one connection of a cluster no longer drops the entry the others need.duplicate not checked
- Deleting a `CephClusterConnection` no longer leaves its volumes stuck. Before, its Secret was deleted at once, and a volume it had provisioned could then no longer be detached, expanded or deleted. The connection now stays until no PersistentVolume needs its Secret (attached to a node, `Bound` or not yet claimed, or `Released`/`Failed` with the `Delete` reclaim policy) and no `VolumeSnapshotContent` with the `Delete` deletion policy refers to it. Its `Ready` condition is `False` with the reason `PersistentVolumesExist` or, when only snapshots are left, `VolumeSnapshotContentsExist`, and the message names up to ten of them. A `Released` or `Failed` PersistentVolume with the `Retain` policy that is attached nowhere does not hold the connection, so an `ElasticCluster` teardown in sds-elastic is not blocked by such a volume. The connection goes as soon as its last volume or snapshot is gone.duplicate not checked
- The CephFS subvolume group of the shared ceph-csi configuration entry no longer moves to the group of another `CephClusterConnection` once a second connection to the same cluster creates its first CephFS volume. Before, the CephFS volumes created earlier could then no longer be deleted or expanded. The group now follows the `subvolumePath` of the existing volumes, and the monitors of the entry are those of all connections to the cluster.duplicate not checked
Documentation 2
- В FAQ описано, почему `CephClusterConnection` не удаляется и какие PersistentVolume и `VolumeSnapshotContent` его удерживают, а также что означает условие `ClusterConfigConflict`, как найти затронутые подключения и как дать перечисленным RBD-томам отключиться.duplicate not checked
- The FAQ explains why a `CephClusterConnection` is not deleted and which PersistentVolumes and `VolumeSnapshotContent`s hold it, and what the `ClusterConfigConflict` condition means, how to find the affected connections and how to let the listed RBD volumes detach.duplicate not checked
Other 14
- У `CephClusterConnection` появилось условие `ClusterConfigConflict`. ceph-csi хранит одну запись конфигурации на кластер Ceph: в ней пользователь одного подключения для RBD и группа подтомов одного подключения для CephFS. Условие равно `True` с причиной `VolumesNeedOtherSettings`, если томам, созданным через подключение, нужен другой пользователь или другая группа, чем в этой записи; в сообщении названы до десяти таких PersistentVolume и подключение, настройки которого хранит запись. В остальных случаях условие равно `False` с причиной `ServedByClusterConfig`. Условие выставляется на каждом подключении к общему кластеру и обновляется, когда перечисленные тома меняют фазу или удаляются. Затронуты RBD-тома, созданные до этого релиза, у подключения которых другой пользователь (их нельзя отключить от узла), и тома CephFS в другой группе подтомов (их можно смонтировать, но нельзя удалить, расширить или снять с них снимок).duplicate not checked
- В DKP 1.78 и новее модуль поставляет роли доступа в схеме RBACv2 capability/scope (возможность и область действия): `d8:system-capability:csi-ceph:view` и `d8:system-capability:csi-ceph:edit` для ресурсов `CephClusterConnection`, `CephClusterAuthentication`, `CephStorageClass` и `CephMetadataBackup`. В более ранних версиях DKP роли `d8:manage:permission:module:csi-ceph:view` и `d8:manage:permission:module:csi-ceph:edit` создаются без изменений.duplicate not checked
- `CephClusterConnection` has the `ClusterConfigConflict` condition. ceph-csi keeps one configuration entry per Ceph cluster with the user of one connection for RBD and the subvolume group of one connection for CephFS. The condition is `True` with the reason `VolumesNeedOtherSettings` when volumes created through the connection need another user or group than that entry holds, names up to ten such PersistentVolumes and the connection whose settings the entry holds, and is `False` with the reason `ServedByClusterConfig` otherwise. It is set on every connection that shares a Ceph cluster and is updated when the listed volumes change phase or are deleted. Affected are RBD volumes provisioned before this release whose connection has another user (they cannot detach) and CephFS volumes in another subvolume group (they can be mounted but not deleted, expanded or snapshotted).duplicate not checked
- On DKP 1.78 and later the module ships its access roles in the capability/scope RBACv2 scheme: `d8:system-capability:csi-ceph:view` and `d8:system-capability:csi-ceph:edit` for the `CephClusterConnection`, `CephClusterAuthentication`, `CephStorageClass` and `CephMetadataBackup` resources. On earlier DKP versions the `d8:manage:permission:module:csi-ceph:view` and `d8:manage:permission:module:csi-ceph:edit` roles are rendered unchanged.duplicate not checked
- Nothing has to be done by hand. A cluster that relied on the previous default verbosity should set `logLevel: DEBUG` in the module configuration explicitly, because the default is now `INFO`.duplicate not checked
- Руками делать ничего не нужно. Кластеру, который полагался на прежнюю подробность логов, следует явно задать `logLevel: DEBUG` в конфигурации модуля, поскольку значение по умолчанию теперь `INFO`.duplicate not checked
- The `golang.org/x/crypto` pin is raised from v0.53.0 to v0.57.0 in every component, which takes CVE-2026-56854, CVE-2026-56855 and CVE-2026-78662 out of scans of the module's hooks image. None of the three was reachable: the vulnerable `x/crypto/ssh` package is not compiled into any binary the module ships, so this clears the finding rather than an exposure.duplicate not checked
- Пин `golang.org/x/crypto` поднят с v0.53.0 до v0.57.0 во всех компонентах, что убирает CVE-2026-56854, CVE-2026-56855 и CVE-2026-78662 из результатов сканирования образа хуков модуля. Ни одна из трёх не была достижима: уязвимый пакет `x/crypto/ssh` не попадает ни в один поставляемый модулем бинарный файл, поэтому исправлена находка сканера, а не эксплуатируемая уязвимость.duplicate not checked
- The default `logLevel` is now `INFO` instead of `DEBUG`, which is what a cluster that never set it explicitly will get.duplicate not checked
- Значение `logLevel` по умолчанию теперь `INFO`, а не `DEBUG` — его получит кластер, в котором параметр не задан явно.duplicate not checked