Всем привет. Мы в Ænix давно занимаемся Kubernetes-платформами, bare metal-инфраструктурой и Cozystack, поэтому тема блочного хранилища для Kubernetes у нас не теоретическая. Это та часть стека, где красивых абстракций быстро становится мало: надо переживать падения нод, понимать топологию, реплицировать данные, не ломать PVC, дружить с CSI и при этом оставаться предсказуемыми для операторов.

Сегодня хотим показать первый публичный результат этой работы — Blockstor 0.1.0.

Blockstor — это открытая система управления распределенным блочным хранилищем для Kubernetes. Она использует DRBD для репликации данных, совместима с REST API LINSTOR и написана на Go как самостоятельная clean-room реализация. Код распространяется под Apache 2.0.

Зачем мы это сделали

Сначала важный дисклеймер: LINSTOR решил реальную и сложную задачу. Он много лет помогает строить реплицируемое блочное хранилище поверх Linux-примитивов вроде LVM, ZFS, LUKS и DRBD. Мы сами хорошо знаем этот стек, использовали его, рассказывали о нем и понимаем, почему вокруг него выросла экосистема. Но если смотреть на Kubernetes-платформы сегодняшнего дня, у нас накопилось несколько практических проблем.

Во-первых, Kubernetes-мир живет декларативной моделью: есть желаемое состояние, есть фактическое состояние, есть reconciliation loop, который постоянно сводит одно к другому. Для распределенных систем это очень естественная модель. Оригинальный LINSTOR устроен иначе: он исторически вырос как отдельная система управления хранилищем и обрабатывает запросы в request-based стиле.

Во-вторых, нам хотелось Go-native control plane, который ощущается как обычный Kubernetes-controller: CRD, controller-runtime, reconciliation, статусы ресурсов, события, привычная интеграция с Kubernetes-инструментами. LINSTOR же написан на Java.

В-третьих, нам важна открытая и понятная governance-модель. Blockstor не должен быть просто заменой LINSTOR внутри Cozystack или закрытым компонентом Ænix. Мы хотим, чтобы он существовал как самостоятельный cloud-native проект в рамках CNCF.

Что такое Blockstor

Если коротко, Blockstor — это Kubernetes-native block storage control plane для платформ, которым нужно реплицируемое блочное хранилище на bare metal, edge и private cloud-инфраструктуре. Технически это не форк LINSTOR и не обертка вокруг него. Это самостоятельная реализация на Go, которая повторяет совместимые API-контракты там, где это нужно для существующей экосистемы. В то же время у него и есть собственные архитектурные особенности и фичи.

На практике это означает, что Blockstor может работать с уже привычными клиентами и компонентами:

• CLI linstor;

• LINSTOR CSI driver;

• Piraeus Operator;

• ha-controller;

• библиотекой golinstor;

• другими инструментами, которые общаются через совместимый REST API.

При этом внутри Blockstor устроен по-kubernetes’овски: конфигурация и текущее состояние представлены через Kubernetes CRD, а логика управления построена на controller-runtime.

Важное отличие: мы не пытаемся сделать универсальную систему управления хранилищем вне Kubernetes. Blockstor изначально ориентирован именно на Kubernetes-кластеры. Это сознательное ограничение, которое сильно упрощает модель и делает ее ближе к тому, как реально эксплуатируются современные платформы.

Что уже есть в 0.1.0

Первый релиз — это еще ранняя версия, но в нем уже есть основная функциональность, без которой проект нельзя было бы показывать сообществу.

Blockstor умеет:

• создавать реплицируемые поверх DRBD тома;

• работать с LVM, LVM-thin, ZFS, ZFS-thin и файловыми backend’ами;

• автоматически размещать реплики с учетом зон, свойств узлов и правила replicas-on-different;

• поддерживать TieBreaker, quorum и resize томов без остановки работы;

• работать без DRBD в режиме локального single-replica diskful или diskless-хранилища;

• шифровать тома через LUKS;

• создавать снапшоты, откатываться к ним, клонировать их и восстанавливать в новый ресурс;

• переносить снапшоты внутри кластера через zfs send/recv и thin-send-recv;

• создавать storage pool’ы из физических дисков;

• собирать multi-arch контейнерные образы для linux/amd64 и linux/arm64.

Для версии 0.1.0 это уже довольно большой объем. Но мы специально называем релиз ранним: на таком уровне стека зрелость определяется не количеством фич, а тем, как система ведет себя в плохих сценариях.

Нас интересуют не только happy path и красивые демо. Нам нужны проверки на падение нод, потерю сети, split-brain, recovery, миграции, ошибки оператора, рестарты контроллеров и странные состояния DRBD.

Почему clean-room

Оригинальный LINSTOR распространяется под GPL, поэтому мы не могли просто взять его код и переписать кусками на Go. Это было бы неправильно и юридически, и инженерно. Blockstor делался как clean-room реализация. Мы смотрели на публичные API-контракты, поведение утилит, совместимые по лицензии проекты, Python-клиент LINSTOR, Piraeus Operator, CSI-драйвер и собственный опыт эксплуатации DRBD.

В самых сложных местах мы использовали такой процесс:

1. Один участник/агент анализировал поведение оригинальной системы и формировал текстовую спецификацию.

2. Другой участник/агент реализовывал функциональность по этой спецификации, без прямого копирования исходного кода.

Такой подход медленнее, чем “посмотреть как сделано и переписать”, но для open source storage-проекта это единственный нормальный путь. Особенно если мы хотим, чтобы проект жил независимо, под Apache 2.0 в рамках CNCF и с понятной историей происхождения кода.

Где было сложно

Самая сложная часть ожидаемо оказалась не в Kubernetes API и не в CRUD-операциях. Сложность началась там, где начинается DRBD.

Нужно корректно сходить состояния ресурсов, понимать Generation Identifier, обрабатывать пропуск начальной синхронизации, учитывать quorum, не превращать нестандартные ситуации в split-brain и уметь безопасно восстанавливаться после отказов.

Это именно та область, где нельзя “почти угадать”. Ошибка в control plane для storage может стоить данных, поэтому мы сразу вкладывались в тесты и сценарии отказов.

Отдельная проблема — у оригинального проекта нет открытой тестовой базы, которую можно было бы просто взять и прогнать на нашем проекте. Поэтому значительную часть тестов мы собирали сами: из опыта эксплуатации, из реальных отладочных историй, из обсуждений в сообществе DRBD и из технических докладов.

Сейчас в репозитории уже получился большой объем тестового кода. По текущим оценкам, на реализацию приходится около 83 тысяч строк, а на тесты — около 137 тысяч строк. Это не метрика качества сама по себе, но хороший индикатор того, что проект изначально строился не как демка на один вечер.

Да, здесь много AI

Blockstor — один из тех проектов, где AI-инструменты реально повлияли на скорость разработки. Практически весь код готовился при активном использовании Claude Code. Разработка шла почти круглосуточно около 20 дней. В отдельные периоды параллельно работали десятки AI-агентов; в сумме получилось около 1500 коммитов и очень длинная непрерывная сессия разработки. Но важный вывод здесь не в том, что “AI написал storage”. Это было бы неправильным упрощением.

AI действительно помогал:

• быстро писать типовой Go-код;

• раскладывать API-контракты на структуры и reconcile-логику;

• генерировать тесты;

• искать несостыковки;

• параллелить рутинные задачи.

Но сложная логика DRBD все равно требовала постоянного человеческого контроля. Модель может предложить правдоподобное решение, но в storage правдоподобности недостаточно. Нужно понимать, какие состояния допустимы, какие опасны, где можно повторить операцию, а где нужна жесткая остановка.

Поэтому для нас Blockstor — это не история про “заменили инженеров моделью”. Скорее наоборот: это пример того, как опытный инженер может резко увеличить throughput, если умеет правильно ставить задачи, проверять результат и не отдавать модели финальное решение там, где цена ошибки слишком высокая.

Как это связано с Cozystack и Ænix

Blockstor появился из практических задач Cozystack и нашей работы в Ænix. Cozystack — это CNCF Sandbox проект, и нам важно, чтобы его базовые компоненты развивались максимально открыто. Но мы не хотим, чтобы Blockstor воспринимался только как “внутренний storage backend для Cozystack”.

Правильная для нас цель шире: Blockstor должен стать самостоятельным Kubernetes storage-control-plane проектом. Cozystack в такой модели будет первым крупным adopter и reference implementation, а не единственным смыслом существования проекта.

Это важное различие. Если проект живет только внутри одной платформы, внешним пользователям сложно влиять на roadmap. Если проект развивается отдельно, с прозрачной governance, публичными issue, roadmap, maintainer model и понятным release process, вокруг него может появиться нормальное сообщество.

Планы по CNCF

Отдельно проговорим статус и планы. Сейчас код уже находится не в приватном контуре Ænix: он опубликован в GitHub-организации CNCF-проекта Cozystack. То есть инфраструктурно Blockstor уже фактически живет в CNCF-экосистеме, но организационно это еще не означает, что Blockstor принят как отдельный CNCF-проект.

Следующий шаг — довести Blockstor до состояния, в котором его можно честно подавать в CNCF как самостоятельный проект.

Для этого нам нужно:

• оформить независимую governance-модель;

• описать maintainer process и contributor ladder;

• подготовить отдельную документацию и архитектурные документы;

• сделать vanilla Kubernetes examples, не завязанные на Cozystack;

• вести публичный roadmap и проектный board;

• собрать больше обратной связи от пользователей вне нашей команды;

• расширить destructive/conformance-тестирование;

• показать понятную область ответственности проекта: block storage orchestration, CSI-интеграция, replication topology, node/disk/pool management, volume lifecycle, recovery и observability.

Мы хотим, чтобы Blockstor был не “кодом, который когда-то написала команда Ænix”, а нейтральным open source проектом, где есть место другим компаниям, независимым мейнтейнерам и пользователям.

Что дальше

Ближайший этап — проверять Blockstor в тестовых кластерах, ловить несовместимости, закрывать проблемы с edge cases и стабилизировать поведение в отказах.

Нам особенно интересны сценарии:

• bare metal Kubernetes;

• edge-кластеры;

• private cloud;

• KubeVirt workloads;

• кластеры с несколькими зонами;

• DRBD-сценарии с отказами сети и нод;

• совместимость с существующим LINSTOR/Piraeus tooling.

Если вы уже используете LINSTOR, Piraeus, DRBD или строите свою Kubernetes-платформу на bare metal, нам очень нужна ваша обратная связь.

Поставьте Blockstor в тестовый кластер. Попробуйте существующие клиенты. Прогоните свои storage-сценарии. Откройте issue, если что-то не работает или работает не так, как вы ожидаете. Если хочется помочь кодом, тестами, документацией, примерами или архитектурной ревизией — приходите контрибьютить.

Репозиторий проекта: https://github.com/cozystack/blockstor

Обсудить можно в чатах по Cozystack: https://t.me/cozystack, https://t.me/cozystack_ru

Мы будем рады баг-репортам, pull request’ам, вопросам, критике и реальным историям эксплуатации. Сейчас как раз тот момент, когда вклад сообщества может повлиять не только на отдельные фичи, но и на форму проекта: его governance, roadmap и путь в CNCF.