Перейти к основному содержанию
В этом руководстве рассказывается, как настроить кластеры ClickHouse и Keeper с помощью оператора.

Конфигурация ClickHouseCluster

Базовая конфигурация

Реплики и сегменты

  • Реплики: Количество экземпляров ClickHouse в каждом сегменте (для высокой доступности)
  • Сегменты: Количество горизонтальных сегментов (для масштабирования)
Кластер с replicas: 3 и shards: 2 создаст всего 6 подов ClickHouse.

Интеграция с Keeper

Для координации в каждом кластере ClickHouse должен быть указан KeeperCluster:
Когда задан keeperClusterRef.namespace, оператор должен отслеживать оба пространства имен. Если настроена переменная WATCH_NAMESPACE, включите в этот список пространства имен ClickHouse и Keeper.

Конфигурация KeeperCluster

Конфигурация хранилища

Настройте постоянное хранилище:
Оператор может изменять существующий PVC, только если используемый класс хранилища поддерживает расширение томов.

Настройка пода

Автоматическое топологическое распределение и аффинность

Распределите поды по зонам доступности:
Убедитесь, что в вашем кластере Kubernetes достаточно узлов в разных зонах, чтобы выполнить требования к распределению.

Ручная конфигурация

Можно указать произвольные правила affinity/anti-affinity для подов и ограничения на распределение по топологии.

Все поддерживаемые параметры шаблона пода см. в справочнике по API.

Бюджеты сбоев подов

Оператор создает PodDisruptionBudget (PDB) для каждого кластера, чтобы плановые нарушения работы — дренирование узлов, поэтапные обновления, вытеснение автоскейлером — не могли вывести из строя достаточно подов, чтобы потерять кворум или нарушить доступность. Для кластеров ClickHouse с более чем одним сегментом создается один PDB на каждый сегмент, чтобы сбой в одном сегменте не учитывался в другом.

Значения по умолчанию

Оператор выбирает безопасные значения по умолчанию с учётом размера кластера, чтобы уже после первого apply защитить его от случайной потери кворума. Для ClickHouseCluster с 3 сегментами и replicas: 3 оператор создаёт три PDB — по одному на каждый сегмент, каждый с minAvailable: 1.

Переопределение значений по умолчанию

Используйте spec.podDisruptionBudget, чтобы переопределить либо minAvailable, либо maxUnavailable (ровно одно из них):
Или вариант maxUnavailable с указанием в процентах:
Одновременная установка minAvailable и maxUnavailable отклоняется валидирующим вебхуком. Выберите что-то одно — сам Kubernetes тоже не разрешает задавать оба параметра одновременно.
Вы также можете передать поле unhealthyPodEvictionPolicy в сгенерированный PDB — это полезно, если нужно разрешить вытеснение подов, которые всё ещё находятся в состоянии NotReady:

Политики

spec.podDisruptionBudget.policy позволяет выбрать, насколько активно оператор управляет PDB: Пример — полностью отключить управление PDB в кластере разработки:
Пример — оставьте созданный вручную PDB рядом с кластером и не позволяйте оператору его затрагивать:

Отключение на уровне всего кластера

Управление PDB также можно отключить на уровне всего кластера через переменную окружения оператора ENABLE_PDB. При ENABLE_PDB=false оператор пропускает шаг сверки PDB для всех ClickHouseCluster и KeeperCluster независимо от их spec.podDisruptionBudget.policy и вообще не отслеживает ресурсы PodDisruptionBudget. Поэтому ServiceAccount оператора не нужны разрешения RBAC на poddisruptionbudgets.policy/v1, что полезно, если оператор запускается с ограниченным ServiceAccount, в котором эти разрешения намеренно отсутствуют.
Это предназначено для сред, где используются собственные политики disruption (например, через Gatekeeper / Kyverno) и где оператор должен быть полностью исключён из процесса.

Настройка контейнера

Собственный образ

Используйте конкретный образ ClickHouse:

Ресурсы контейнеров

Настройте CPU и память для контейнеров ClickHouse:

Переменные окружения

Добавьте пользовательские переменные окружения:

Подключение томов

Добавьте дополнительные точки монтирования томов:
Допускается указывать несколько подключений томов к одному и тому же mountPath. Оператор создаст projected volume со всеми указанными подключениями.

Все поддерживаемые параметры шаблона контейнера см. в справочнике по API.

Настройка TLS/SSL

Настройка защищённых конечных точек

Укажите ссылку на Secret Kubernetes с TLS-сертификатами, чтобы включить защищённые конечные точки

Формат Secret с SSL-сертификатом

Предполагается, что Secret содержит следующие ключи:
  • tls.crt - серверный сертификат в PEM-формате
  • tls.key - приватный ключ в PEM-формате
  • ca.crt - цепочка CA‑сертификатов в PEM-формате
Этот формат совместим с сертификатами, созданными cert-manager.

Взаимодействие ClickHouse-Keeper по TLS

Если в KeeperCluster включен TLS, ClickHouseCluster будет автоматически использовать защищенное соединение с узлами Keeper. ClickHouseCluster должен иметь возможность проверять сертификаты узлов Keeper. Если в ClickHouseCluster включен TLS, для проверки используется комплект ca.crt. В противном случае используется комплект CA по умолчанию. Пользователь может указать ссылку на пользовательский комплект CA:

Настройки ClickHouse

Пароль пользователя по умолчанию

Задайте пароль пользователя по умолчанию:
Не рекомендуется использовать ConfigMap для хранения паролей в открытом виде.
Создайте secret:

Использование ConfigMap для паролей пользователей

Вы также можете использовать ConfigMap для паролей по умолчанию, не содержащих конфиденциальных данных:

Дополнительные пользователи в конфигурации

Настройте дополнительных пользователей в файлах конфигурации. Создайте ConfigMap и Secret для пользователя:
Добавьте пользовательскую конфигурацию в ClickHouseCluster:

Синхронизация базы данных

Включите автоматическую синхронизацию базы данных для новых реплик:
Когда эта настройка включена, оператор синхронизирует таблицы Replicated и интеграционные таблицы на новые реплики.

Пользовательская конфигурация

Встроенная дополнительная конфигурация

Вместо подключения пользовательских файлов конфигурации можно напрямую указать дополнительные параметры конфигурации ClickHouse. Добавьте пользовательскую конфигурацию ClickHouse с помощью extraConfig:

Встроенная конфигурация дополнительных пользователей

Вы также можете указать дополнительную конфигурацию пользователей ClickHouse с помощью extraUsersConfig. Это удобно, если нужно определить пользователей, профили, квоты и привилегии прямо в спецификации кластера.
extraUsersConfig хранится в объекте ConfigMap в k8s. Не храните там секретные данные в открытом виде.

См. документацию с полным перечнем поддерживаемых параметров конфигурации пользователей ClickHouse.

Пример конфигурации

Полный пример конфигурации:
Последнее изменение 12 июня 2026 г.