Skip to main content
В этом руководстве описано, как оператор подготавливает постоянное хранилище для ClickHouseCluster: основной том данных, подключение дополнительных дисков в многодисковой конфигурации (JBOD), расширение ёмкости и правила, определяющие, что можно и нельзя изменять после создания кластера. Подробное справочное описание каждого поля см. в разделе Конфигурация → Конфигурация хранилища и в справочнике по API.

​
Основной том данных

spec.dataVolumeClaimSpec — это стандартный Kubernetes PersistentVolumeClaimSpec. Оператор преобразует его в volumeClaimTemplate StatefulSet, поэтому контроллер StatefulSet создает и сохраняет по одному PersistentVolumeClaim для каждой реплики и монтирует его по пути к данным ClickHouse /var/lib/clickhouse.
  • Если accessModes не указан, оператор по умолчанию устанавливает значение ReadWriteOnce.
  • PVC для каждой реплики сохраняется при удалении кластера, поэтому данные переживают удаление и повторное создание custom resource.
  • Такое же поле есть у KeeperCluster и работает оно так же.

​
Запуск без постоянного тома данных

dataVolumeClaimSpec необязателен. Если не указать его и не смонтировать собственный том по пути к данным, ClickHouse будет записывать данные в эфемерную файловую систему контейнера, а вебхук допуска вернёт предупреждение о том, что данные могут быть потеряны при перезапуске кластера. Этот вариант предназначен только для временных или тестовых кластеров. Чтобы использовать собственное хранилище вместо dataVolumeClaimSpec — например, emptyDir или заранее подготовленный том, — задайте его через spec.podTemplate.volumes и смонтируйте в /var/lib/clickhouse с помощью spec.containerTemplate.volumeMounts.
dataVolumeClaimSpec и пользовательский том по пути к данным взаимоисключающи. Если задан dataVolumeClaimSpec, монтирование пользовательского тома в /var/lib/clickhouse будет отклонено. Зарезервированные имена томов clickhouse-storage-volume, clickhouse-server-tls-volume и clickhouse-server-custom-ca-volume нельзя использовать в podTemplate.volumes.

​
Расширение хранилища

Чтобы увеличить том, повысьте значение resources.requests.storage и примените изменения. Оператор обновит существующие PVC на месте.
Расширение работает только в том случае, если в нижележащем StorageClass задано allowVolumeExpansion: true. Kubernetes не поддерживает уменьшение PVC, поэтому новый размер должен быть больше или равен текущему.

​
Многодисковое (JBOD) хранилище

spec.additionalVolumeClaimTemplates добавляет дополнительные диски к каждой реплике ClickHouse помимо основного dataVolumeClaimSpec. Каждая запись представляет собой именованный шаблон PVC — metadata.name и spec PVC — который обрабатывается точно так же, как основной диск данных, поэтому контроллер StatefulSet создает и сохраняет по одному PVC для каждой реплики с именем <name>-<statefulset>-0.
Оператор монтирует каждый дополнительный том в /var/lib/clickhouse/disks/<name> и генерирует storage_configuration ClickHouse за вас — вам не нужно задавать её вручную. Он регистрирует каждый дополнительный диск и добавляет его во встроенную политику хранения default. Основной диск данных (default) и каждый дополнительный диск входят в один общий том политики default, поэтому ClickHouse распределяет новые части данных между ними по круговому алгоритму. Полезная ёмкость равна сумме всех дисков, и каждая таблица, которая не задаёт собственную storage_policy, — включая таблицы system.* — использует этот общий набор.
Путь монтирования сохраняет имя шаблона без изменений, но идентификатор диска внутри storage_configuration заменяет дефисы на символы подчёркивания. Шаблон с именем cold-disk монтируется в /var/lib/clickhouse/disks/cold-disk и отображается как cold_disk в сгенерированной конфигурации.

​
Пользовательские политики хранения

Для описанной выше структуры JBOD extraConfig не нужен — оператор автоматически создаёт политику default. Используйте spec.settings.extraConfig только в тех случаях, когда вам нужны политики хранения помимо автоматически сгенерированной по умолчанию, например многоуровневая политика hot/cold с move_factor и prefer_not_to_merge или диск на базе S3. Добавленная там конфигурация накладывается поверх сгенерированного storage_configuration. Описание полей политики см. в документации ClickHouse по хранилищу.

​
Что нельзя изменить после создания

Структура хранилища по большей части фиксируется после создания кластера. Вебхук допуска отклоняет обновления, которые привели бы к отвязке или повторной привязке PersistentVolumeClaims:
  • Наличие dataVolumeClaimSpec неизменно — вы не можете добавить том данных в кластер, созданный без него, и не можете удалить его из кластера, созданного с ним.
  • Набор additionalVolumeClaimTemplates фиксирован — вы не можете добавлять, удалять или переименовывать записи после создания.
  • Увеличение resources.requests.storage у существующей записи допускается (при условии поддержки со стороны StorageClass, см. Расширение хранилища).

​
Справочник по валидации

Последнее изменение 3 июля 2026 г.