Как мы разделили монолит на независимые операторы и сделали 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 на набор независимых операторов.

Один оператор отвечал сразу за всё

До появления OperatorHUB с каждым новым кластером по дефолту приезжал Apps Operator, который отвечал сразу за несколько инфраструктурных компонентов. Например, при установке одного из компонентов администратору достаточно указать количество реплик. Если реплика одна, оператор разворачивает компонент в одиночном режиме, если три — в кластерном и применяет настройки для высокой нагрузки.

Ручная настройка YAML создавала высокий порог вхождения. Она требовала строгого соблюдения синтаксиса и внимательной сверки параметров с документацией. Если при установке возникала ошибка, инженеры поддержки по шагам восстанавливали действия пользователя и искали расхождение с инструкцией. 

По мере развития Apps Operator становился сложнее. Все компоненты были собраны в одном Go-приложении и выпускались вместе. Из-за этого параллельную разработку приходилось синхронизировать с общим циклом выпуска.

С версиями действовало простое правило: хочешь получить новый Apps Operator — обновляй весь кластер Nova. Выбрать другую версию оператора или остаться на прежней при обновлении платформы было нельзя.

В какой-то момент Apps Operator настолько разросся, что дорабатывать его стало слишком долго. Тогда команда решила разделить монолит на самостоятельные операторы и собрать их в каталог.

Красивый интерфейс монолит не вылечит

Сначала команда хотела самостоятельно разработать в Nova Console интерфейс для выбора, установки и настройки инфраструктурных компонентов. Но вместо разработки с нуля решила использовать связку OperatorHUB и OLM. OperatorHUB отвечает за поиск и выбор операторов, а OLM устанавливает их, управляет подписками и обновляет по заданным путям. Большую часть этой логики взяли как есть.

При этом интерфейс адаптировали под Nova Console. Переделали карточки операторов и список установленных операторов, а формы построили по схеме CRD со значениями по умолчанию и подсказками для основных полей. Nova Console показывает ход установки через стандартные состояния и события Kubernetes. Если что-то идёт не так, администратор сразу видит ошибку и может дальше разбираться на уровне ресурсов кластера. Для нестандартной конфигурации и ручной настройки оставили возможно работать с YAML.

Ещё одно изменение коснулось сетевых политик. Мы отказались от встроенных в OLM NetworkPolicy в пользу централизованного управления сетевыми настройками через Cilium или Calico, доработав отдельный флаг, который отключает создание этих политик. Так все сетевые настройки остаются в одном месте. Если сетевые ограничения нужны, заказчик может настроить их самостоятельно по своим правилам.

В итоге готовую логику OperatorHUB и OLM сохранили, а формы, список установленных операторов, отображение статусов и управление сетевыми политиками адаптировали под Nova.

Независимые операторы вместо монолита

Для распиливания монолита сначала стандартизировали разработку платформенных операторов и создали внутренний фреймворк Operator Kit. В нём уже были реализованы базовые механизмы: цикл согласования ресурса, статусы и события, применение пользовательских кастомизаций и миграция ресурсов между версиями CRD. Дополнительную функциональность можно подключать в виде готовых модулей, например для работы с секретами. Разработчику нужно только описать CRD своего компонента и его бизнес-логику.

Когда администратор создаёт CR, оператор проверяет его и на основе заданных параметров формирует объекты Kustomization. FluxCD получает их, забирает необходимые артефакты и создает в кластере Deployment, Secret, ConfigMap, RBAC и другие ресурсы. Поэтому операторы различаются предметной областью, но работают по общим правилам.

Для них также унифицировали путь от сборки образа и bundle до публикации новой версии в каталоге. Каждому инфраструктурному компоненту сделали свой оператор с отдельным циклом выпуска. Теперь правка OpenSearch Operator не тянет за собой пересборку и тестирование Service Mesh Operator, а разные разработчики могут работать над ними параллельно.

В каталоге есть две группы операторов.

• Операторы Nova разрабатывает и поставляет команда платформы. В их числе операторы для OpenSearch, Service Mesh, Longhorn, Velero, NeuVector.

• Комьюнити-операторы создаёт и поддерживает сообщество. В текущий набор, например, входят Kyverno и MetalLB.

Разница не только в происхождении. Комьюнити-оператор обычно открывает пользователю почти все параметры продукта, поэтому его можно настроить от А до Я. Но вместо короткой формы пользователь получает большую портянку настроек, в которых ещё нужно разобраться.

В собственных операторах Nova мы заранее продумали типовой сценарий, задали стандартные значения и оставили в форме только параметры, которые зависят от конкретного кластера. Например, при установке OpenSearch пользователь указывает количество реплик. С одной репликой оператор запускает OpenSearch в одиночном режиме, а с тремя — в кластерном и с настройками для высокой нагрузки.

Один вариант не заменяет другой. Эти подходы решают разные задачи. Комьюнити-оператор подходит тем, кто хочет сразу работать со всеми доступными параметрами. А собственные операторы Nova оптимизированы под типовые сценарии, поэтому в форме показаны только основные поля. При этом возможности настройки не ограничены. Для более глубокой конфигурации предусмотрен блок патчей и кастомизации.

Удалить монолит оказалось недостаточно

Подключить OperatorHUB в новый кластер было проще, чем обновить уже работающие инсталляции Nova. В таких кластерах уже стоял монолитный Apps Operator, через который заказчик мог развернуть несколько инфраструктурных компонентов. Набор у каждого был свой, поэтому сценарий миграции состоял из пяти шагов: 

1. Определить, какие компоненты уже установлены через Apps Operator.

2. Удалить старый монолит.

3. Установить только соответствующие отдельные операторы.

4. Передать им управление существующими ресурсами.

5. Убедиться, что работающие компоненты не потеряли конфигурацию.

Иными словами, новые операторы приходили не в пустой кластер. После удаления Apps Operator управление уже развёрнутыми приложениями передавали отдельным операторам. Сами приложения оставались в кластере, а их спецификации и конфигурацию не нужно было создавать заново.

Установленные компоненты определяли по объектам Kustomization. Если весь набор объектов компонента присутствовал и находился в состоянии Ready, OLM устанавливал для него отдельный оператор. Ориентироваться только на CR было нельзя, поскольку в некоторых старых инсталляциях его могло и не быть.

Перед удалением Apps Operator с объектов Kustomization снимали старые ownerReferences, а у CR обнуляли финализаторы. Так разрывалась связь с монолитом, но FluxCD продолжал поддерживать приложения в прежнем состоянии. Затем ресурсам добавляли специальную аннотацию с именем нового оператора. По ней он принимал ресурсы под управление, переиспользовал существующие Kustomization и добавлял в их ownerReferences ссылку на новый CR.

У большинства компонентов существующий spec без изменений переносили в ресурс с apiVersion новой API-группы: скрипт миграции вычитывал существующий CR, пересоздавал ресурс в новой API-группе с сохранением всех пользовательских настроек и переносил владельцев. Если старого CR не было, параметры восстанавливали из фактической конфигурации кластера. Например, для NeuVector их получали из патчей FluxCD и переменных окружения, а для Velero использовали текущий BackupStorageLocation. У Longhorn API-группа не менялась, поэтому достаточно было передать ресурс новому владельцу.

После разделения сузился и набор привилегий. Вместо общей учётной записи и кластерной роли Apps Operator с 30 правилами для 21 API-группы каждый оператор получил собственную учётную запись и разрешения, описанные в его ClusterServiceVersion. OLM выдаёт ему только те права, которые нужны для управления конкретным компонентом.

Из чего состоит поставка оператора

Чтобы оператор появился в каталоге, одного его образа мало. Для каждой версии собирается bundle. Это контейнерный образ с манифестами и метаданными, включая ClusterServiceVersion, CRD и другие необходимые Kubernetes-объекты.

Поставка состоит из нескольких частей.

Работа над новой версией начинается с доработки логики оператора. Если она затрагивает параметры пользовательского ресурса, разработчик актуализирует CRD с допустимыми полями и правилами валидации, а затем включает её в bundle. Kubernetes использует эту схему при проверке ресурса.

После доработок собираются новые образы оператора и bundle, и пересобирается каталог. В него добавляется ссылка на новую версию, а прежние записи сохраняются. Поэтому в каталоге одновременно доступны несколько версий одного оператора. Далее образы оператора, bundle и каталога включаются в поставку Nova.

Та же схема работает в кластерах без доступа в интернет. В закрытый контур эти артефакты доставляет Nova Universe. Все необходимые данные остаются внутри инфраструктуры заказчика, поэтому OLM не обращается к внешним каталогам и реестрам. Вместо того чтобы пересобирать bundle под закрытое окружение с зашитыми адресами registry, как это предполагает OLM из коробки, мы изменили структуру репозитория в Universe и добавили зеркало на уровне CRI в платформе. Поэтому один и тот же bundle одинаково работает как в онлайн-установке, так и в закрытом окружении.

Путь обновления задаётся заранее

OLM умеет не только складывать версии в каталог, но и задавать путь между ними. Правила описываются в bundle. Граф может быть линейным или разветвлённым. В нём можно задать обновление через промежуточные версии либо разрешить пропустить одну версию или целый диапазон. Версии распределяются по каналам, поэтому для Stable и Fast можно настроить разные пути обновления. Например, в канале Stable держать проверенную последовательность обновлений, а в Fast раньше публиковать новые сборки.

Граф задаёт допустимые переходы между версиями, а совместимость с конкретным релизом Nova подтверждается отдельно. Сначала новую версию оператора проверяет инженер, затем собственные и комьюнити-операторы проходят предрелизное тестирование. Так перед публикацией команда убеждается, что обновление проходит корректно, а управляемый компонент работает во всём окружении кластера.

Если в новой версии CRD появилось обязательное поле, уже созданные пользовательские ресурсы тоже нужно обновить. Этим занимается сам оператор. После этого администратору остаётся выбрать канал и способ подтверждения обновлений. В автоматическом режиме новая разрешённая версия устанавливается без его участия. В ручном режиме OLM формирует InstallPlan, а администратор проверяет его и только затем подтверждает обновление.

Так заказчик может отложить переход на новую версию оператора, если пока не готов её применять. При этом платформа может обновляться отдельно. При переходе на новую версию оператор смотрит на фактическую конфигурацию развёрнутого приложения и подставляет недостающие значения исходя из неё. Администратору не приходится вписывать их вручную.

В новом кластере весь набор операторов по умолчанию не устанавливается. Администратор выбирает нужный компонент в OperatorHUB, указывает версию, канал обновления и пространство имён, а затем запускает установку через OLM. После этого можно создать экземпляр управляемого приложения через форму Nova Console или отредактировать YAML вручную.

Что изменилось

Мы начинали с идеи сделать каталог приложений. В итоге задача оказалась шире. Мы разделили монолит, отвязали жизненный цикл операторов от обновления всей платформы и сохранили совместимость с открытой экосистемой OLM.

Администратор теперь выбирает, устанавливает и обновляет операторы через Nova Console. Разработчики тоже больше не работают с одним Go-приложением. Операторы можно выпускать и тестировать отдельно, а общие шаблоны и модули переиспользовать в новых проектах.

Дальше в каталоге будут появляться комьюнити-операторы, в том числе по запросам заказчиков. В планах также дать заказчикам возможность собирать собственные каталоги по стандартным правилам OLM и подключать их к OperatorHUB без дополнительной адаптации.

Отдельным компонентом платформы станет Helm Hub, созданный с учётом опыта OperatorHUB. В Nova Console администратор сможет добавить Helm-репозиторий, выбрать чарт и версию, а установкой займётся уже работающий в кластере FluxCD. При этом чарты смогут устанавливать не только администраторы платформы, но и команды в своих пространствах имён. Источником правды станет отдельный ресурс с заявкой на установку, а платформа определит доступные репозитории, чарты и версии. Так команды смогут самостоятельно устанавливать прикладное ПО без доступа ко всему кластеру и продолжат работать в рамках GitOps-подхода.