Хранилище и тома

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

Подробное справочное описание каждого поля см. в разделе Конфигурация → Конфигурация хранилища и в справочнике по API.

spec.dataVolumeClaimSpec — это стандартный Kubernetes PersistentVolumeClaimSpec. Оператор преобразует его в volumeClaimTemplate StatefulSet, поэтому контроллер StatefulSet создает и сохраняет по одному PersistentVolumeClaim для каждой реплики и монтирует его по пути к данным ClickHouse /var/lib/clickhouse.

apiVersion: clickhouse.com/v1alpha1
kind: ClickHouseCluster
metadata:
  name: my-cluster
spec:
  dataVolumeClaimSpec:
    storageClassName: fast-ssd   # optional; depends on the installed CSI driver
    resources:
      requests:
        storage: 100Gi

• Если accessModes не указан, оператор по умолчанию устанавливает значение ReadWriteOnce.
• PVC для каждой реплики сохраняется при удалении кластера, поэтому данные переживают удаление и повторное создание пользовательского ресурса. Для данных на зашифрованной политике это дополнительно требует сохранения ключа шифрования — см. примечание в этом разделе.
• Такое же поле есть у KeeperCluster и работает оно так же.

dataVolumeClaimSpec необязателен. Если не указать его и не смонтировать собственный том по пути к данным, ClickHouse будет записывать данные в эфемерную файловую систему контейнера, а вебхук допуска вернёт предупреждение о том, что данные могут быть потеряны при перезапуске кластера.

Этот вариант предназначен только для временных или тестовых кластеров. Чтобы использовать собственное хранилище вместо dataVolumeClaimSpec — например, emptyDir или заранее подготовленный том, — задайте его через spec.podTemplate.volumes и смонтируйте в /var/lib/clickhouse с помощью spec.containerTemplate.volumeMounts.

Чтобы увеличить том, повысьте значение resources.requests.storage и примените изменения. Оператор обновит существующие PVC на месте.

spec:
  dataVolumeClaimSpec:
    resources:
      requests:
        storage: 200Gi   # was 100Gi

spec.additionalVolumeClaimTemplates добавляет дополнительные диски к каждой реплике ClickHouse помимо основного dataVolumeClaimSpec. Каждая запись представляет собой именованный шаблон PVC — metadata.name и spec PVC — который обрабатывается точно так же, как основной диск данных, поэтому контроллер StatefulSet создает и сохраняет по одному PVC для каждой реплики с именем <name>-<statefulset>-0.

spec:
  dataVolumeClaimSpec:
    storageClassName: fast-ssd
    resources:
      requests:
        storage: 100Gi
  additionalVolumeClaimTemplates:
    - metadata:
        name: disk1
      spec:
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 100Gi
    - metadata:
        name: disk2
      spec:
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 100Gi

Оператор монтирует каждый дополнительный том в /var/lib/clickhouse/disks/<name> и генерирует storage_configuration ClickHouse за вас — вам не нужно задавать её вручную. Он регистрирует каждый дополнительный диск и добавляет его во встроенную политику хранения default.

Основной диск данных (default) и каждый дополнительный диск входят в один общий том политики default, поэтому ClickHouse распределяет новые части данных между ними по круговому алгоритму. Полезная ёмкость равна сумме всех дисков, и каждая таблица, которая не задаёт собственную storage_policy, — включая таблицы system.* — использует этот общий набор.

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

Описание полей политики см. в документации ClickHouse по хранилищу.

Параметр spec.settings.encryption включает шифрование данных таблиц при хранении. Оператор генерирует 16-байтный ключ AES — он хранится в Secret управляемого кластера или передаётся через externalSecret — а также отдельную политику хранения, которая оборачивает каждый диск с данными в тип диска ClickHouse encrypted.

spec:
  settings:
    encryption: {}   # enables the feature; the policy defaults to "encrypted"

Шифрование включается для каждой таблицы отдельно; политика хранения по умолчанию остаётся без шифрования. Выберите зашифрованную политику при создании таблицы:

CREATE TABLE secret_data (id UInt64) ENGINE = MergeTree ORDER BY id
SETTINGS storage_policy = 'encrypted';

Установите encryption.policyName, чтобы использовать другое имя политики.

Структура хранилища по большей части фиксируется после создания кластера. Вебхук допуска отклоняет обновления, которые привели бы к отвязке или повторной привязке PersistentVolumeClaims:

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

• Конфигурация — полный справочник по всем полям, включая extraConfig.
• Масштабирование кластеров — как добавлять и удалять реплики и сегменты.