Как мы разделили монолит на независимые операторы и сделали OperatorHUB в Nova
Раньше инфраструктурные модули в Nova устанавливали с помощью YAML-манифестов. Например, чтобы развернуть в Kubernetes-кластере систему хранения данных Longhorn, администратор находил нужный манифест в документации и копировал его в Nova Console. Затем менял параметры под свой кластер, указывал названия нод и при необходимости применял патчи. Если что-то не работало, шёл обратно в документацию и искал пропущенное или неправильно заполненное поле.
За развёртывание инфраструктурных модулей в Nova Container Platform отвечал Apps Operator. В нём были собраны семь манифестов (Custom Resource) для разных сервисов, а сам Apps Operator подтягивался вместе с кластером, даже если заказчику требовалась только часть компонентов.
Со временем такой монолит перестал подходить и пользователям, и команде. Версии инфраструктурных компонентов были привязаны к релизам платформы. Для обновления одного из них заказчику приходилось обновлять весь кластер, а изменение даже одного модуля влекло за собой полное регрессионное тестирование Apps Operator. Изначально он не выглядел будущим монолитом. Манифесты компонентов хранились отдельно в Git внутри кластера, а для их доставки использовали FluxCD. Сам оператор задумывался как лёгкая обёртка над GitOps-системой, но со временем разросся. Этот опыт показал, что хранение манифестов за пределами оператора само по себе не защищает его от превращения в монолит.
Привет, Хабр! Меня зовут Никита Лось, я — системный аналитик Nova Container Platform в компании Orion soft. В статье я расскажу, почему мы взяли за основу OperatorHUB из проекта Operator Framework, что пришлось изменить под Nova и как переносили работающие кластеры с монолитного Apps Operator на набор независимых операторов.
