Доступен первый выпуск Blockstor - открытой системы управления распределённым блочным хранилищем для Kubernetes, обеспечивающей репликацию данных поверх DRBD. Blockstor совместим по REST API с LINSTOR и способен без изменений работать с существующей экосистемой клиентов, включая командную утилиту linstor, CSI-драйвер, оператор Piraeus, ha-controller и библиотеку golinstor. Проект представляет собой полностью самостоятельную (clean-room) реализацию на языке Go, не использующую исходный код оригинала. Код распространяется под лицензией Apache 2.0 и развивается в рамках платформы Cozystack (проект CNCF Sandbox).

Автор проекта - Андрей Квапил (@kvaps), основатель Cozystack и участник некоммерческой организации Piraeus, в рамках которой развиваются оператор и CSI-драйвер LINSTOR для Kubernetes. Автор известен в Kubernetes-сообществе как популяризатор LINSTOR и неоднократно выступал с техническими докладами по теме. Изначально разработка задумывалась как небольшая "пятничная" инициатива, однако в итоге превратилась примерно в 20 дней непрерывной работы. На текущий момент проект развивается как исследовательский, однако в перспективе рассматривается как возможная замена LINSTOR в роли системы хранения по умолчанию в Cozystack.

В качестве причин создания нового проекта упоминаются сложности с сопровождением оригинального проекта и передачей изменений в основной проект, а также архитектурные ограничения LINSTOR. Оригинальный проект использует "request-based" модель обработки запросов в реальном времени, который показывает проблемы на масштабах, тогда как декларативный reconciliation-подход Kubernetes и framework controller-runtime, по мнению автора, значительно лучше подходит для построения распределённых систем.

В отличие от LINSTOR, архитектура Blockstor полностью основана на подходе Kubernetes controller-runtime. Конфигурация и текущее состояние системы представлены в виде Kubernetes CRD-объектов, а сама система не рассчитана на работу вне Kubernetes-кластера.

Среди основных возможностей Blockstor:

• Реплицируемые поверх DRBD тома на базе LVM, LVM-thin, ZFS, ZFS-thin и файловых бэкендов.
• Автоматическое размещение реплик с учётом зон, свойств узлов и правил "replicas-on-different".
• Поддержка TieBreaker, quorum и изменения размера томов без остановки работы.
• Возможность работы без DRBD в режиме локального (single-replica diskful) или бездискового хранилища.
• Шифрование томов через LUKS.
• Поддержка снапшотов: создание, откат, клонирование и восстановление в виде нового ресурса.
• Перенос снапшотов внутри кластера через zfs send/recv и thin-send-recv.
• Создание storage pool’ов из физических дисков.
• Собранные для разных архитектур контейнерные образы (linux/amd64 и linux/arm64), опубликованные в GHCR.

Особенностью проекта стало активное использование AI-инструментов при разработке. Практически весь код был подготовлен с помощью Claude Code (модель Opus 4.7) компании Anthropic. Разработка велась почти круглосуточно в течение примерно 20 дней. В отдельные моменты одновременно работало до 60 AI-агентов, а общий диалог разработки составил около 1320 запросов со стороны автора и порядка 36 тысяч ответов модели в рамках одной непрерывной сессии. На выходе получилось 1500 коммитов, в которых 83 тысячи строк кода заняла реализация и ещё 137 тысяч строк кода тесты. По предварительной оценке, суммарно было израсходовано около 18.9 млрд токенов, а эквивалентная стоимость такого объёма при использовании API-тарифов составила бы около 40 тысяч долларов.

Автор первоначально рассчитывал на почти полностью автономную разработку силами AI-модели, однако сложная логика DRBD потребовала постоянного участия человека. Наиболее сложными оказались сценарии схождения DRBD-состояний, работа с Generation Identifier (GI), пропуска изначальной синхронизации и обработка split-brain сценариев. Поскольку оригинальный LINSTOR распространяется под лицензией GPL, использовать его код напрямую было нельзя. Основная часть реализации создавалась на основе анализа API-контрактов, поведения утилит, Python-клиента LINSTOR, а также совместимых по лицензии проектов, включая piraeus-operator и CSI-драйвер.

В наиболее сложных случаях применялась схема с разделением ролей AI-агентов: один агент анализировал исходный код LINSTOR и формировал текстовую спецификацию поведения, после чего другой агент реализовывал функциональность исключительно по этой спецификации без прямого копирования исходного кода. Из-за отсутствия открытых тестов у оригинального проекта тестовую базу пришлось формировать самостоятельно.