Skip to main content

ClickHouse Operator configuration guide

This guide covers how to configure ClickHouse and Keeper clusters using the operator.

ClickHouseCluster configuration

Basic configuration

Replicas and shards

  • Replicas: Number of ClickHouse instances per shard (for high availability)
  • Shards: Number of horizontal partitions (for scaling)
A cluster with replicas: 3 and shards: 2 will create 6 ClickHouse pods total.

Keeper integration

Every ClickHouse cluster must reference a KeeperCluster for coordination:
When keeperClusterRef.namespace is set, the operator must watch both namespaces. If WATCH_NAMESPACE is configured, include the ClickHouse and Keeper namespaces in that list.

KeeperCluster configuration

Storage configuration

Configure persistent storage:
Operator can modify existing PVC only if the underlying storage class supports volume expansion.

Pod configuration

Automatic topology spread and affinity

Distribute pods across availability zones:
Ensure your Kubernetes cluster has enough nodes in different zones to satisfy the spread constraints.

Manual configuration

Arbitrary pod affinity/anti-affinity rules and topology spread constraints can be specified.

See API Reference for all supported Pod template options.

Container configuration

Custom image

Use a specific ClickHouse image:

Container resources

Configure CPU and memory for ClickHouse containers:

Environment variables

Add custom environment variables:

Volume mounts

Add additional volume mounts:
It is allowed to specify multiple volume mounts to the same mountPath. Operator will create projected volume with all specified mounts.

See API Reference for all supported Container template options.

TLS/SSL configuration

Configure secure endpoints

Pass a reference to a Kubernetes Secret containing TLS certificates to enable secure endpoints

SSL certificate secret format

It is expected that the Secret contains the following keys:
  • tls.crt - PEM encoded server certificate
  • tls.key - PEM encoded private key
  • ca.crt - PEM encoded CA certificate chain
This format is compatible with cert-manager generated certificates.

ClickHouse-Keeper communication over TLS

If KeeperCluster has TLS enabled, ClickHouseCluster would use secure connection to Keeper nodes automatically. ClickHouseCluster should be able to verify Keeper nodes certificates. If ClickHouseCluster has TLS enabled, is uses ca.crt bundle for verification. Otherwise, default CA bundle is used. User may provide a custom CA bundle reference:

ClickHouse settings

Default user password

Set the default user password:
It isn’t recommended to use ConfigMap to store plain text passwords.
Create the secret:

Using ConfigMap for user passwords

You can also use ConfigMap for non-sensitive default passwords:

Custom users in configuration

Configure additional users in configuration files. Create a ConfigMap and Secret for user:
Add custom configuration to ClickHouseCluster:

Database sync

Enable automatic database synchronization for new replicas:
When enabled, the operator synchronizes Replicated and integration tables to new replicas.

Custom configuration

Embedded extra configuration

Instead of mounting custom configuration files, you can directly specify additional ClickHouse configuration options. Add custom ClickHouse configuration using extraConfig:

Embedded extra users configuration

You can also specify additional ClickHouse users configuration using extraUsersConfig. This is useful for defining users, profiles, quotas, and grants directly in the cluster specification.
The extraUsersConfig is stored in k8s ConfigMap object. Avoid plain text secrets there.

See documentation for all supported ClickHouse users configuration options.

Configuration example

Complete configuration example: