Перейти к основному содержимому
Перейти к основному содержимому

Введение в оператор ClickHouse

В этом документе представлен обзор ключевых концепций и сценариев использования оператора ClickHouse.

Что такое ClickHouse Operator​

ClickHouse Operator — это Kubernetes-оператор, который автоматизирует развертывание и управление кластерами ClickHouse в Kubernetes. Реализованный по паттерну Operator, он расширяет Kubernetes API пользовательскими типами ресурсов, которые представляют кластеры ClickHouse и их зависимости.

Оператор отвечает за:

  • Управление жизненным циклом кластера (создание, обновление, масштабирование, удаление)
  • Координацию кластера ClickHouse Keeper
  • Автоматическую генерацию конфигурации
  • Синхронизацию схемы базы данных
  • Поэтапные (rolling) обновления и обновления версий
  • Выделение хранилища

Пользовательские ресурсы​

Оператор предоставляет два основных определения пользовательских ресурсов (CRD):

ClickHouseCluster​

Представляет кластер базы данных ClickHouse с настраиваемыми репликами и сегментами.

apiVersion: clickhouse.com/v1alpha1
kind: ClickHouseCluster
metadata:
  name: sample-cluster
spec:
  replicas: 3
  shards: 2
  keeperClusterRef:
    name: sample-keeper
  dataVolumeClaimSpec:
    resources:
      requests:
        storage: 100Gi

KeeperCluster​

Представляет собой кластер ClickHouse Keeper для распределённой координации (заменяет ZooKeeper).

apiVersion: clickhouse.com/v1alpha1
kind: KeeperCluster
metadata:
  name: sample-keeper
spec:
  replicas: 3
  dataVolumeClaimSpec:
    resources:
      requests:
        storage: 10Gi

Координация​

ClickHouse Keeper необходим​

Каждый ClickHouseCluster требует кластера ClickHouse Keeper для распределённой координации. Кластер Keeper должен быть указан в спецификации ClickHouseCluster через keeperClusterRef.

Отношение «один-к-одному» с Keeper​

Каждый ClickHouseCluster должен иметь собственный выделенный KeeperCluster. Нельзя использовать один KeeperCluster для нескольких ClickHouseCluster.

Почему? Оператор автоматически генерирует уникальный ключ аутентификации для каждого ClickHouseCluster для доступа к его Keeper. Этот ключ хранится в Secret и не может быть общим.

Последствия:

  • Несколько ClickHouseCluster не могут ссылаться на один и тот же KeeperCluster
  • Повторное создание ClickHouseCluster требует повторного создания соответствующего KeeperCluster
Примечание

Тома PersistentVolume не удаляются автоматически при удалении ресурсов ClickHouseCluster или KeeperCluster.

При повторном создании кластера:

  1. Удалите ресурс ClickHouseCluster
  2. Удалите ресурс KeeperCluster
  3. Дождитесь завершения работы всех подов
  4. При необходимости удалите PersistentVolumeClaim, если хотите начать с нуля
  5. Создайте KeeperCluster и ClickHouseCluster заново одновременно

Чтобы избежать ошибок аутентификации, либо удалите тома PersistentVolume вручную, либо пересоздайте оба кластера одновременно с новым хранилищем данных.

Репликация схемы​

Оператор ClickHouse автоматически реплицирует определения баз данных между всеми репликами в кластере.

Что реплицируется​

Оператор синхронизирует:

  • определения баз данных Replicated
  • движки интеграции с базами данных (PostgreSQL, MySQL и т. д.)

Оператор не синхронизирует:

  • нереплицируемые базы данных (Atomic, Ordinary и т. д.)
  • локальные таблицы в нереплицируемых базах данных
  • данные таблиц (ими управляет репликация ClickHouse)
Рекомендуемая практика

Всегда используйте движок базы данных Replicated для продакшн-развёртываний.

Преимущества:

  • Автоматическая репликация схемы на всех узлах
  • Упрощённое управление таблицами
  • Оператор может синхронизировать новые реплики
  • Единая согласованная схема во всём кластере

Создавайте базы данных с помощью распределённого DDL:

CREATE DATABASE my_database ON CLUSTER 'default' ENGINE = Replicated;

Избегайте нереплицируемых движков​

Нереплицируемые движки баз данных (Atomic, Lazy, SQLite, Ordinary) требуют ручного управления схемой:

  • Таблицы должны создаваться отдельно на каждой реплике
  • Между узлами может происходить расхождение схемы
  • Оператор не может автоматически синхронизировать новые реплики

Отключение репликации схемы​

Чтобы отключить автоматическую репликацию схемы, установите параметр spec.settings.enableDatabaseSync в значение false в ресурсе ClickHouseCluster.

Управление хранилищем​

Оператор управляет хранилищем с использованием Kubernetes PersistentVolumeClaim (PVC).

Настройка тома данных​

Укажите требования к хранилищу в dataVolumeClaimSpec:

spec:
  dataVolumeClaimSpec:
    storageClassName: fast-ssd
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 500Gi

Жизненный цикл хранилища​

  • Создание: объекты PVC создаются автоматически вместе с кластером
  • Расширение: поддерживается, если StorageClass допускает расширение томов
  • Сохранение: PVC не удаляются автоматически при удалении кластера
  • Повторное использование: существующие PVC могут быть повторно использованы, если кластер воссоздан с тем же именем

Чтобы полностью удалить хранилище:

# Delete cluster
kubectl delete clickhousecluster my-cluster

# Wait for pods to terminate
kubectl wait --for=delete pod -l app.kubernetes.io/instance=my-cluster

# Delete PVCs
kubectl delete pvc -l app.kubernetes.io/instance=sample-cluster

Основные особенности конфигурации по умолчанию​

  • Преднастроенный кластер: кластер с именем default, содержащий все узлы ClickHouse.
  • Макросы по умолчанию: некоторые полезные макросы заранее определены:
    • {cluster}: имя кластера (default)
    • {shard}: номер сегмента
    • {replica}: номер реплики
  • Реплицируемое хранилище для объектов Role Based Access Control (RBAC)
  • Реплицируемое хранилище для User Defined Functions (UDF)

Следующие шаги​