Архитектура Doris Operator
Doris Operator следует стандартной модели Kubernetes Operator. Пользователи задают желаемое состояние через CRD, а Operator непрерывно отслеживает фактическое состояние и устраняет различия, создавая, обновляя или удаляя ресурсы Kubernetes.
В этом документе рассматривается общая архитектура. Определения полей и процедуры развёртывания приведены в соответствующих документах по установке и настройке.
Уровни архитектуры
Doris Operator можно представить в виде двух уровней: плоскости управления и плоскости данных.

Плоскость управления считывает пользовательские ресурсы Doris и выполняет процесс Reconcile. Плоскость данных состоит из штатных ресурсов Kubernetes, в которых непосредственно работают компоненты Doris.
Модель Reconcile
Цикл Reconcile лежит в основе Doris Operator. При создании или обновлении пользовательского ресурса Doris, а также при изменении состояния связанных ресурсов Operator заново определяет различия между желаемым и фактическим состоянием, а затем выполняет необходимые операции.
Типичная последовательность действий:
- Считать пользовательский ресурс Doris.
- Проверить, находится ли ресурс в процессе удаления.
- Разобрать настройки компонентов, хранения, аутентификации и доступа.
- Создать или обновить соответствующие
StatefulSet,Service, PVC и связанные ресурсы. - Собрать сведения о состоянии компонентов и записать их в поле
statusресурса CR. - Если кластер не готов, дождаться следующего цикла Reconcile.

Схема управления кластерами с совмещёнными вычислениями и хранением
DorisCluster используется для развёртываний с совмещёнными вычислениями и хранением. Один ресурс может включать настройки FE, BE, CN и Broker.

В этой схеме основной Reconciler отвечает за чтение CR, определение порядка действий с компонентами, удаление некорректных ресурсов и агрегацию состояния. Контроллеры компонентов создают и проверяют ресурсы своих компонентов.
Схема управления кластерами с разделёнными вычислениями и хранением
DorisDisaggregatedCluster используется для развёртываний с разделёнными вычислениями и хранением. Один ресурс содержит MetaService, FE и одну или несколько ComputeGroups.

По сравнению с режимом совмещённых вычислений и хранения эта схема включает больше действий на уровне метаданных Doris. Например, при уменьшении размера ComputeGroup может потребоваться, чтобы Operator сначала выполнил операции decommission или drop, а затем обновил ресурсы Kubernetes.
Webhook и валидация
В Doris Operator можно включить Webhook, чтобы применять значения по умолчанию и отклонять заведомо некорректные конфигурации до их передачи в процесс Reconcile.
Обычно проверяется следующее:
- Совместимы ли настройки реплик FE с настройками выборов.
- Соответствуют ли форматы полей ресурса ограничениям CRD.
- Соответствует ли конфигурация компонентов моделям, поддерживаемым Operator.
Использование Webhook зависит от способа развёртывания и среды. Даже без Webhook валидация по схеме CRD и обратная связь о состоянии из Reconcile обеспечивают базовый контроль.
Агрегация состояния
Operator не только создаёт ресурсы, но и записывает состояние компонентов в пользовательский ресурс Doris. С помощью kubectl get или kubectl describe можно узнать, доступны ли компоненты, масштабируются ли они, ожидают ли назначения на узел или находятся в состоянии сбоя.
Для кластеров с совмещёнными вычислениями и хранением состояние агрегируется по FE, BE, CN и Broker. Для кластеров с разделёнными вычислениями и хранением состояние агрегируется по MetaService, FE и ComputeGroups и дополняется общей сводкой о работоспособности.