Релизы

v0.2.25

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

Тома остаются смонтированными при перезапуске пода csi-node, потому что geesefs теперь работает как служба systemd узла, а удалённый S3StorageClass сохраняет учётные данные, пока не удалены его PersistentVolume.

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

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

• geesefs работает как временная служба systemd узла (geesefs-<volume>.service), а не внутри контейнера csi-node, поэтому перезапуск, вытеснение или обновление csi-node больше не оставляет тома на этом узле с ошибкой «Transport endpoint is not connected».
• При удалении S3StorageClass его StorageClass удаляется сразу, а Secret csi-s3-<name> в d8-csi-s3 и сам S3StorageClass сохраняются, пока не удалены все PersistentVolume, которые ссылаются на этот Secret. Эти тома по-прежнему монтируются, а их bucket (корзина S3) удаляется вместе с томом.

Улучшения

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

• В DKP 1.78 и новее роли доступа модуля следуют схеме RBACv2 с capability (возможность) и scope (область действия): d8:system-capability:csi-s3:view даёт доступ на чтение S3StorageClass, а d8:system-capability:csi-s3:edit — на создание, изменение и удаление. Там они заменяют d8:manage:permission:module:csi-s3:view и d8:manage:permission:module:csi-s3:edit и по-прежнему агрегируются в роли просмотра и управления хранилищем. В DKP ниже 1.78 прежние роли создаются без изменений.

Исправления

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

• geesefs запускался внутри контейнера csi-node и завершался вместе с ним при каждом перезапуске, вытеснении (включая обновление ресурсов через VPA без пересоздания пода) или обновлении пода. Все тома, смонтированные на этом узле, становились недоступны, пока их не отмонтируют. Теперь драйвер запускает geesefs через systemd узла, и процесс работает независимо от пода. Учётные данные S3 передаются службе в файле в /run/csi-s3, доступном только root, а не в свойстве Environment юнита (unit — описание службы в systemd), которое любой пользователь узла мог прочитать через systemctl show. Сертификаты из customCACertificates копируются на узел, чтобы geesefs по-прежнему им доверял, а адрес эндпоинта geesefs резолвит через DNS кластера, как под csi-node, поэтому endpointUrl в виде имени Service (https://<service>.<namespace>.svc) продолжает работать, хотя собственный резолвер узла не знает домен кластера. Мёртвая точка монтирования FUSE, оставшаяся на узле, отмонтируется в NodeStageVolume, NodePublishVolume и NodeUnstageVolume, а не приводит к ошибке операции.
• При удалении S3StorageClass Secret csi-s3-<name> удалялся, а финализатор снимался сразу, даже если у класса оставались PersistentVolume. external-provisioner берёт из этого Secret учётные данные для удаления, поэтому такие тома навсегда оставались в состоянии Released, а их bucket не удалялись. Теперь контроллер сразу удаляет StorageClass, чтобы новые тома не создавались, и сохраняет Secret и финализатор, пока на Secret ссылается хотя бы один PersistentVolume драйвера, независимо от его политики освобождения. В это время условие Ready имеет статус False с причиной Deleting, а в сообщении перечислены PersistentVolume, удаления которых ждёт контроллер. Контроллер получил право на чтение persistentvolumes.
• customCACertificates принимает каждый сертификат и текстом PEM, как написано в документации, и в виде PEM в кодировке Base64. Раньше работал только Base64: значение в PEM отклонял вебхук ModuleConfig, а в ModuleConfig, применённом до установки модуля, вместо сертификата в ConfigMap csi-s3-custom-ca попадал текст ошибки, и каждый запрос к эндпоинту падал с x509: certificate signed by unknown authority. Уже заданные в Base64 значения продолжают работать.

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

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

• Обновление модуля перезапускает поды csi-node. Тома, смонтированные до обновления, обслуживаются процессами geesefs внутри старых контейнеров и завершаются вместе с ними: на каждом узле поды, использующие тома csi-s3, получают ошибку «Transport endpoint is not connected», пока их не пересоздадут. Пересоздайте такие поды после обновления. Тогда их тома смонтируются через systemd узла, и последующие перезапуски csi-node на них уже не повлияют.
• В DKP 1.78 и новее ClusterRole d8:manage:permission:module:csi-s3:view и d8:manage:permission:module:csi-s3:edit заменены на d8:system-capability:csi-s3:view и d8:system-capability:csi-s3:edit. Доступ, выданный через роли просмотра и управления хранилищем, не меняется. RoleBinding или ClusterRoleBinding, которые ссылаются на старое имя напрямую, нужно перевести на новое.
• S3StorageClass, удалённый при наличии PersistentVolume, теперь остаётся в кластере с Ready=False и причиной Deleting, пока они не будут удалены. Удалите PVC перечисленных томов. PersistentVolume с политикой освобождения Retain автоматически не удаляется: удалите объект PersistentVolume вручную, данные останутся в bucket.

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

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

• В FAQ описано, почему удалённый S3StorageClass остаётся в кластере, как посмотреть список PersistentVolume, удаления которых он ждёт, и что делать с томами с политикой освобождения Retain.

Зависимости

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

• geesefs: 0.43.7 → 0.43.9 (changelog)
  • Обновлена файловая система FUSE geesefs, через которую монтируются тома. Патчи зависимостей объединены в один и по-прежнему поднимают grpc, x/crypto и OpenTelemetry до версий, закрывающих известные CVE.

v0.2.24

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

Обновление безопасности: CSI-драйвер, geesefs и хуки модуля пересобраны с исправленными grpc, x/crypto и OpenTelemetry.

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

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

• google.golang.org/grpc обновлён с v1.82.1 до v1.83.2 в CSI-драйвере (s3driver) и geesefs, что закрывает CVE-2026-84303, CVE-2026-84304 и CVE-2026-84445.

Обновления безопасности

Обновления безопасности в этом релизе:

• google.golang.org/grpc обновлён с v1.82.1 до v1.83.2 в CSI-драйвере (s3driver) и geesefs, что закрывает CVE-2026-84303, CVE-2026-84304 и CVE-2026-84445.
• golang.org/x/crypto обновлён с v0.53.0 до v0.57.0 в CSI-драйвере (s3driver), geesefs и хуках модуля (go-hooks), что закрывает CVE-2026-56854 (обход аутентификации по адресу источника в x/crypto/ssh), CVE-2026-56855 и CVE-2026-78662.
• Модули OpenTelemetry (go.opentelemetry.io/otel, metric, sdk, trace) обновлены с v1.44.0 до v1.45.0 в geesefs, что закрывает CVE-2026-81870.

v0.2.23

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

Модуль по умолчанию пишет логи на уровне INFO вместо DEBUG, поэтому установка, в которой уровень не выбирали, перестаёт получать отладочный вывод от контроллера.

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

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

• Значение logLevel по умолчанию теперь INFO, а не DEBUG. Там, где уровень не задавали в конфигурации модуля, контроллер и его валидирующий webhook после обновления становятся заметно тише; вернуть прежнюю подробность можно, указав logLevel: DEBUG.

Улучшения

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

• Значение logLevel в конфигурации модуля по умолчанию теперь INFO. Настройка доходит до контроллера и до валидирующего webhook, который живёт в том же поде, поэтому прежний умолчательный DEBUG означал, что каждая установка, где настройку не трогали, работала на отладочной подробности и платила за это объёмом логов. Явно указанный в ModuleConfig logLevel соблюдается ровно как раньше, каким бы он ни был.

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

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

• В конфигурации модуля делать ничего не нужно. Там, где logLevel не задан, компоненты поднимутся на уровне INFO по мере раскатки пода контроллера при обновлении; там, где задан, уровень останется прежним. Чтобы сохранить прежнее поведение, укажите logLevel: DEBUG явно.

v0.2.22

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

Метрики контроллера, объявленные в предыдущем релизе, наконец действительно собираются: стоявший перед ними kube-rbac-proxy не мог авторизовать ни один сбор.

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

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

• Prometheus собирает метрики контроллера — чего ни разу не получалось с момента их появления в предыдущем релизе. У стоящего перед ними kube-rbac-proxy не было прав создавать TokenReview и SubjectAccessReview, которыми авторизуется каждый сбор, поэтому он отклонял их все: up == 0 для задания csi-s3-controller и TargetDown, который никогда не гас.

Исправления

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

• Теперь kube-rbac-proxy перед метриками контроллера привязан к ClusterRole d8:rbac-proxy и может авторизовать сбор. Без этой привязки он отказывал в каждом сборе, и единственным симптомом была недоступная цель: до Prometheus не доходила ни одна метрика контроллера модуля — ни число и длительность реконсиляций, ни глубина очереди задач, ни задержки client-go, — а TargetDown горел всё время, пока модуль установлен.

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

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

• В конфигурации модуля делать ничего не нужно. Горящий TargetDown для задания csi-s3-controller погаснет сам, как только поднимется новый под контроллера и пройдёт первый сбор.

v0.2.21

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

Контроллер модуля отдаёт метрики Prometheus — через kube-rbac-proxy в своём же поде — и пишет структурированные логи; релиз модуля описывается разделами и на двух языках.

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

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

• Метрики контроллера собираются Prometheus без всякой настройки: ServiceMonitor в d8-monitoring снимает их под job csi-s3-controller, поэтому становятся видны число и длительность reconcile-циклов, глубина рабочей очереди (workqueue) и задержки обращений к API через client-go.
• Контроллер пишет структурированные логи — имя компонента и поля вида «ключ-значение» вместо префиксов в духе [main], — поэтому всё, что разбирает его строки лога, нужно поправить.
• Релиз описывается разделами — краткое описание, главное, новые возможности, улучшения, исправления — по-английски и по-русски, и консоль показывает описание на языке читателя.

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

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

• Контроллер теперь отдаёт метрики.

Улучшения

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

• Контроллер логирует через общий логгер storage-модулей: каждая строка несёт компонент, из которого она пришла, и свои поля как «ключ-значение». Настройка settings.logLevel работает точно как раньше (ERROR, WARN, INFO, DEBUG) — изменилась форма строки, а не уровень.
• Release notes пишутся по локалям в .release-notes/<тег>.yaml и <тег>.ru.yaml с разделами summary, highlights, new_features, improvements, fixes, security, breaking, upgrade_notes, known_issues, docs и dependencies. В кластер попадают обе локали; релизы, выпущенные до этого, остаются в прежнем плоском формате и отображаются на той же странице точно так же, как раньше.

Исправления

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

• Релизный тег без release notes публиковал пустой changelog.yaml, оставляя ModuleRelease.spec.changelog пустым при зелёной сборке. Теперь такой тег роняет сборку.

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

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

• В конфигурации модуля делать ничего не нужно.

v0.2.20

• Исправление: контроллеру выданы права patch на events вместо list — повторная запись события больше не отклоняется по правам
• Обновление базовых образов до v2.1.2, Go до 1.26.6 и lib-helm до 1.72.14

v0.2.19

• S3StorageClass публикует status.conditions и status.observedGeneration, добавлена колонка Ready. Поле status.phase сохраняет прежний набор значений, но теперь вычисляется из условия Ready
• Обновление базовых образов до v1.3.25, Go 1.26.5 и lib-helm до 1.72.13

v0.2.18

• Обновление базовых образов, Go 1.26.5 и lib-helm до 1.72.12
• Устранены уязвимости в сторонних зависимостях
• Внутренние изменения в сборке модуля и CI, добавлен набор e2e-тестов

v0.2.17

• Обновление базовых образов, Go 1.26.5 и lib-helm до 1.72.9
• Внутренние изменения в сборке модуля

v0.2.16

• Исправлено формирование секрета доступа к registry (deckhouse-registry): теперь в него попадают данные авторизации только активного источника образов
• Обновление базовых образов container-base до v1.1.8, Go 1.26.4 и lib-helm до 1.72.4

v0.2.15

• При пробросе меток из S3StorageClass в StorageClass теперь исключаются метки с заданными игнорируемыми префиксами
• Обновление базовых образов и lib-helm до 1.72.0

v0.2.14

• Метки из S3StorageClass теперь пробрасываются в управляемый StorageClass Kubernetes
• Обновление базовых образов, Go 1.25.10 и lib-helm 1.71.12

v0.2.13

• Добавлен параметр dataNodes.nodeSelector для управления размещением DaemonSet csi-node; пустой объект отклоняется валидирующим вебхуком
• Добавлен контроллер, синхронизирующий значение nodeSelector с DaemonSet csi-node

v0.2.12

• Внутренние изменения в структуре и сборке модуля

v0.2.11

• Обновление базовых образов, Go 1.25.10 и lib-helm 1.71.11
• Внутренние изменения в сборку модуля

v0.2.10

• Исправления в структуру модуля

v0.2.9

• Изменения в CI: DistroPackagesProxy и env прокси в werf, доработки CVE-сканов (role_name, checkout)
• Добавлены кластерные роли user-authz в шаблонах

v0.2.8

• Добавлены инфраструктура и недостающие точки монтирования для distroless-образов
• Обновление базовых образов, Go и lib-helm (фикс CVE)
• Документация по параметрам конфигурации модуля

v0.2.7

• Обновление базовых образов и версии golang
• Обновление хуков, работающих при удалении модуля
• Отключен запрос Capacity со стороны k8s (CSI не поддерживает выдачу Capacity)
• Обновление версии k8s-csi-s3 до 0.43.3

v0.2.6

• Переработка манифестов модуля

v0.2.5

• Обновлена версия базовых образов до v0.5.46
• Обновлена версия Go до 1.24.11
• Исправлены названия полей S3StorageClass в примерах документации
• Исправлены синтаксические ошибки YAML в примерах FAQ
• Объединены controller и webhooks в один deployment
• Добавлен режим HA для CSI контроллера

v0.2.4

• Обновлена версия базовых образов

v0.2.3

• Обновлена версия Go до 1.24.9
• Обновлена lib-helm до deckhouse_lib_helm-1.64.1

v0.2.2

• Добавлены файлы release notes

v0.2.1

• Добавлен readonlyRootFilesystem для большей безопасности модуля

v0.2.0

• Рефакторинг модуля
• Сервисный аккаунт изменен на “csi”

v0.1.5

• Небольшой фикс документации

v0.1.4

• Рефакторинг модуля без изменения функциональности для конечного пользователя
• Добавлены требования к версии Deckhouse (>= 1.67)

v0.1.3

• Добавлена поддержка пользовательских CA для сертификатов
• Обновлен GeeseFS до версии 0.43.0