Deckhouse Standard Edition
Changes on Beta
0.4.9·arrival time on the release channel unknown
0.4.9
BetaEarly AccessStable- Dates
- released 15.09.2026 15:58 detected 05.10.2026 01:20
- Requirements
- deckhouse ≥ 1.72
- Stage
- General Availability
- On release channels
- Beta — since unknown · Early Access — since unknown · Stable — since unknown
- Before
- never
What changed in 0.4.9
Upgrade notes 4
- Руками делать ничего не нужно. Таргет контроллера в Prometheus восстановится сам после выката обновлённого контроллера, а откат на пакет модуля затрагивает только узлы, где пакеты дистрибутива установить не удаётся.duplicate not checked
- Кластеру, который полагался на прежнюю подробность логов, следует явно задать `logLevel: DEBUG` в конфигурации модуля, поскольку значение по умолчанию теперь `INFO`.duplicate not checked
- Nothing has to be done by hand. The controller target in Prometheus recovers on its own once the updated controller is rolled out, and the NFSv3 fallback only touches nodes where the distribution packages cannot be installed.duplicate not checked
- 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
Highlights 4
- Там, где пакетный менеджер узла не может установить `rpcbind` и `nfs-common`/`nfs-utils`, модуль ставит оба демона из собственного образа `nfs-tools`. Без них под CSI-узла на таком узле вообще не стартует, а любое монтирование NFSv3 висит вечно.duplicate not checked
- `kube-rbac-proxy` перед метриками контроллера снова имеет право проверять запросы сбора: с тех пор как метрики ушли за него, каждый сбор отклонялся и таргет контроллера в Prometheus оставался недоступным.duplicate not checked
- Where a node's package manager cannot install `rpcbind` and `nfs-common`/`nfs-utils`, the module installs the two daemons from its own `nfs-tools` image. Without them the CSI node Pod never starts on that node and every NFSv3 mount waits forever.duplicate not checked
- The `kube-rbac-proxy` in front of the controller metrics is authorized to check scrapes again: since the metrics moved behind it, every scrape was refused and the controller target stayed down in Prometheus.duplicate not checked
Improvements 2
- Значение `logLevel` по умолчанию теперь `INFO`, а не `DEBUG` — его получит кластер, в котором параметр не задан явно.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
Fixes 4
- Prometheus не мог собирать метрики контроллера модуля: `kube-rbac-proxy` перед ними не имел права создавать `TokenReview` и `SubjectAccessReview`, которыми авторизуется каждый сбор, поэтому все сборы отклонялись и таргет оставался недоступным. Затронуты кластеры на v0.4.8, где метрики были переведены за прокси.duplicate not checked
- `rpc.statd` из собственного пакета модуля находит `sm-notify` и больше не стартует с пустым файлом состояния, поэтому перезагрузившийся узел оповещает о перезагрузке узлы, удерживающие на нём блокировки NFSv3.duplicate not checked
- Prometheus could not scrape the module controller: the `kube-rbac-proxy` in front of its metrics was not allowed to create the `TokenReview` and `SubjectAccessReview` that every scrape is authorized with, so all scrapes were refused and the target stayed down. Clusters running v0.4.8, where the metrics moved behind the proxy, are the ones affected.duplicate not checked
- `rpc.statd` from the module's own package can reach `sm-notify` and no longer starts on an empty state file, so a node that has rebooted announces the reboot to the peers holding NFSv3 locks on it.duplicate not checked
Other 4
- На узле, репозитории которого не могут предоставить `rpcbind` и `nfs-common`/`nfs-utils`, `NodeGroupConfiguration` откатывается на собственный пакетный образ модуля `nfs-tools`: содержимое распаковывается в `/var/lib/deckhouse/sds/csi-nfs`, демоны поднимаются юнитами `d8-csi-nfs-rpcbind.service` и `d8-csi-nfs-rpc-statd.service`. Пакеты дистрибутива остаются предпочтительным путём, узел со своим `rpcbind` остаётся нетронутым. Это касается только NFSv3, то есть кластеров с `v3support: true`; NFSv4 ни одного из этих демонов не требует. Кроме того, шаг установки теперь роняет шаг bashible, если сокет портмаппера не отвечает, — вместо сообщения об успехе и узла с зависающими монтированиями.duplicate not checked
- On a node whose repositories cannot provide `rpcbind` and `nfs-common`/`nfs-utils`, the `NodeGroupConfiguration` falls back to the module's own `nfs-tools` package image: the payload is unpacked under `/var/lib/deckhouse/sds/csi-nfs` and the daemons come up as `d8-csi-nfs-rpcbind.service` and `d8-csi-nfs-rpc-statd.service`. The distribution's packages stay the preferred path and a node that already has `rpcbind` of its own is left untouched. This concerns NFSv3 only, so it applies to clusters with `v3support: true`; NFSv4 needs neither daemon. The install step now also fails the bashible step when the portmapper socket does not answer, instead of reporting success and leaving the node with mounts that hang.duplicate not checked
- Updating base images, Go 1.26.5 and lib-helm to 1.72.10duplicate not checked
- Internal changes in module assembly and CI, added a set of e2e testsduplicate not checked