SavePearlHarbor

Blockstor: Kubernetes-native альтернатива LINSTOR, которую мы готовим как отдельный CNCF-проект

—

от автора

admin

Всем привет. Мы в Æ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.

ссылка на оригинал статьи https://habr.com/ru/articles/1040388/