Cloud Native LVM изначально разрабатывался как часть платформы Deckhouse, с упором на self-service для пользователей Kubernetes. Вся логика — от обнаружения дисков до создания PV — прозрачно управляется через Kubernetes API. Плюс мы развиваем решение исходя из реальных запросов пользователей Deckhouse. Если по существу, то на момент начала разработки мы смотрели в сторону TopoLVM, но он нам не подошёл: тогда в нём не было автоматического создания Volume Group и не хватало оперативного обновления информации о свободном месте в VG. OpenEBS (LocalPV LVM), насколько я видел по документации, тоже исходит из того, что Volume Group заранее создаётся вручную на всех узлах — для нас это было критично, потому что хотелось максимально убрать ручные операции администраторов.
Для реплицированных томов мы выбрали LINSTOR, но следующий этап развития нашего SDS — как раз отказ от него как control-plane и переход на подход, который описан в статье. От LINSTOR мы уходим, потому что он добавляет дополнительный уровень сложности и поддерживает сценарии, которые нам не нужны. Чуть подробнее о проблемах с ним мой коллега рассказывал в докладе, а про замену LINSTOR мы отдельно расскажем на Deckhouse Conf 9 апреля 2026 года.
Cloud Native LVM изначально разрабатывался как часть платформы Deckhouse, с упором на self-service для пользователей Kubernetes. Вся логика — от обнаружения дисков до создания PV — прозрачно управляется через Kubernetes API. Плюс мы развиваем решение исходя из реальных запросов пользователей Deckhouse. Если по существу, то на момент начала разработки мы смотрели в сторону TopoLVM, но он нам не подошёл: тогда в нём не было автоматического создания Volume Group и не хватало оперативного обновления информации о свободном месте в VG. OpenEBS (LocalPV LVM), насколько я видел по документации, тоже исходит из того, что Volume Group заранее создаётся вручную на всех узлах — для нас это было критично, потому что хотелось максимально убрать ручные операции администраторов.
Для реплицированных томов мы выбрали LINSTOR, но следующий этап развития нашего SDS — как раз отказ от него как control-plane и переход на подход, который описан в статье. От LINSTOR мы уходим, потому что он добавляет дополнительный уровень сложности и поддерживает сценарии, которые нам не нужны. Чуть подробнее о проблемах с ним мой коллега рассказывал в докладе, а про замену LINSTOR мы отдельно расскажем на Deckhouse Conf 9 апреля 2026 года.