ClickHouseInstallation
clickhouse.altinity.com / v1
apiVersion: clickhouse.altinity.com/v1
kind: ClickHouseInstallation
metadata:
name: example
apiVersion
string
APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
kind
string
Kind is a string value representing the REST resource this
object represents. Servers may infer this from the endpoint the client
submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
metadata
object
spec object required
Specification of the desired behavior of one or more ClickHouse clusters
More info: https://github.com/Altinity/clickhouse-operator/blob/master/docs/custom_resource_explained.md
configuration object
allows configure multiple aspects and behavior for `clickhouse-server` instance and also allows describe multiple `clickhouse-server` clusters inside one `chi` resource
clusters []object
describes clusters layout and allows change settings on cluster-level, shard-level and replica-level
every cluster is a set of StatefulSet, one StatefulSet contains only one Pod with `clickhouse-server`
all Pods will rendered in <remote_server> part of ClickHouse configs, mounted from ConfigMap as `/etc/clickhouse-server/config.d/chop-generated-remote_servers.xml`
Clusters will use for Distributed table engine, more details: https://clickhouse.tech/docs/en/engines/table-engines/special/distributed/
If `cluster` contains zookeeper settings (could be inherited from top `chi` level), when you can create *ReplicatedMergeTree tables
files
object
optional, allows define content of any setting file inside each `Pod` on current cluster during generate `ConfigMap` which will mount in `/etc/clickhouse-server/config.d/` or `/etc/clickhouse-server/conf.d/` or `/etc/clickhouse-server/users.d/`
override top-level `chi.spec.configuration.files`
insecure
object
optional, open insecure ports for cluster, defaults to "yes"
layout object
describe current cluster layout, how much shards in cluster, how much replica in shard
allows override settings on each shard and replica separatelly
replicas []object
optional, allows override top-level `chi.spec.configuration` and cluster-level `chi.spec.configuration.clusters` configuration for each replica and each shard relates to selected replica, use it only if you fully understand what you do
files
object
optional, allows define content of any setting file inside each `Pod` only in one replica during generate `ConfigMap` which will mount in `/etc/clickhouse-server/config.d/` or `/etc/clickhouse-server/conf.d/` or `/etc/clickhouse-server/users.d/`
override top-level `chi.spec.configuration.files` and cluster-level `chi.spec.configuration.clusters.files`, will ignore if `chi.spec.configuration.clusters.layout.shards` presents
name
string
optional, by default replica name is generated, but you can override it and setup custom name
pattern:
^[a-zA-Z0-9-]{0,15}$minLength:
1maxLength:
15
settings
object
optional, allows configure `clickhouse-server` settings inside <yandex>...</yandex> tag in `Pod` only in one replica during generate `ConfigMap` which will mount in `/etc/clickhouse-server/conf.d/`
override top-level `chi.spec.configuration.settings`, cluster-level `chi.spec.configuration.clusters.settings` and will ignore if shard-level `chi.spec.configuration.clusters.layout.shards` present
More details: https://clickhouse.tech/docs/en/operations/settings/settings/
shards []object
optional, list of shards related to current replica, will ignore if `chi.spec.configuration.clusters.layout.shards` presents
files
object
optional, allows define content of any setting file inside each `Pod` only in one shard related to current replica during generate `ConfigMap` which will mount in `/etc/clickhouse-server/config.d/` or `/etc/clickhouse-server/conf.d/` or `/etc/clickhouse-server/users.d/`
override top-level `chi.spec.configuration.files` and cluster-level `chi.spec.configuration.clusters.files`, will ignore if `chi.spec.configuration.clusters.layout.shards` presents
httpPort
integer
optional, setup `Pod.spec.containers.ports` with name `http` for selected shard, override `chi.spec.templates.hostTemplates.spec.httpPort`
allows connect to `clickhouse-server` via HTTP protocol via kubernetes `Service`
minimum:
1maximum:
65535
httpsPort
integer
minimum:
1maximum:
65535
insecure
object
optional, open insecure ports for cluster, defaults to "yes"
interserverHTTPPort
integer
optional, setup `Pod.spec.containers.ports` with name `interserver` for selected shard, override `chi.spec.templates.hostTemplates.spec.interserverHTTPPort`
allows connect between replicas inside same shard during fetch replicated data parts HTTP protocol
minimum:
1maximum:
65535
name
string
optional, by default shard name is generated, but you can override it and setup custom name
pattern:
^[a-zA-Z0-9-]{0,15}$minLength:
1maxLength:
15
secure
object
optional, open secure ports
settings
object
optional, allows configure `clickhouse-server` settings inside <yandex>...</yandex> tag in `Pod` only in one shard related to current replica during generate `ConfigMap` which will mount in `/etc/clickhouse-server/conf.d/`
override top-level `chi.spec.configuration.settings`, cluster-level `chi.spec.configuration.clusters.settings` and replica-level `chi.spec.configuration.clusters.layout.replicas.settings`
More details: https://clickhouse.tech/docs/en/operations/settings/settings/
tcpPort
integer
optional, setup `Pod.spec.containers.ports` with name `tcp` for selected shard, override `chi.spec.templates.hostTemplates.spec.tcpPort`
allows connect to `clickhouse-server` via TCP Native protocol via kubernetes `Service`
minimum:
1maximum:
65535templates object
optional, configuration of the templates names which will use for generate Kubernetes resources according to selected replica
override top-level `chi.spec.configuration.templates`, cluster-level `chi.spec.configuration.clusters.templates`, replica-level `chi.spec.configuration.clusters.layout.replicas.templates`
clusterServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each clickhouse cluster described in `chi.spec.configuration.clusters`
dataVolumeClaimTemplate
string
optional, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse data directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
hostTemplate
string
optional, template name from chi.spec.templates.hostTemplates, which will apply to configure every `clickhouse-server` instance during render ConfigMap resources which will mount into `Pod`
logVolumeClaimTemplate
string
optional, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse log directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
podTemplate
string
optional, template name from chi.spec.templates.podTemplates, allows customization each `Pod` resource during render and reconcile each StatefulSet.spec resource described in `chi.spec.configuration.clusters`
replicaServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each replica inside each shard inside each clickhouse cluster described in `chi.spec.configuration.clusters`
serviceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates. used for customization of the `Service` resource, created by `clickhouse-operator` to cover all clusters in whole `chi` resource
serviceTemplates
[]string
optional, template names from chi.spec.templates.serviceTemplates. used for customization of the `Service` resources, created by `clickhouse-operator` to cover all clusters in whole `chi` resource
shardServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each shard inside clickhouse cluster described in `chi.spec.configuration.clusters`
volumeClaimTemplate
string
optional, alias for dataVolumeClaimTemplate, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse data directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
tlsPort
integer
minimum:
1maximum:
65535
shardsCount
integer
optional, count of shards related to current replica, you can override each shard behavior on low-level `chi.spec.configuration.clusters.layout.replicas.shards`
minimum:
1templates object
optional, configuration of the templates names which will use for generate Kubernetes resources according to selected replica
override top-level `chi.spec.configuration.templates`, cluster-level `chi.spec.configuration.clusters.templates`
clusterServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each clickhouse cluster described in `chi.spec.configuration.clusters`
dataVolumeClaimTemplate
string
optional, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse data directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
hostTemplate
string
optional, template name from chi.spec.templates.hostTemplates, which will apply to configure every `clickhouse-server` instance during render ConfigMap resources which will mount into `Pod`
logVolumeClaimTemplate
string
optional, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse log directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
podTemplate
string
optional, template name from chi.spec.templates.podTemplates, allows customization each `Pod` resource during render and reconcile each StatefulSet.spec resource described in `chi.spec.configuration.clusters`
replicaServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each replica inside each shard inside each clickhouse cluster described in `chi.spec.configuration.clusters`
serviceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates. used for customization of the `Service` resource, created by `clickhouse-operator` to cover all clusters in whole `chi` resource
serviceTemplates
[]string
optional, template names from chi.spec.templates.serviceTemplates. used for customization of the `Service` resources, created by `clickhouse-operator` to cover all clusters in whole `chi` resource
shardServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each shard inside clickhouse cluster described in `chi.spec.configuration.clusters`
volumeClaimTemplate
string
optional, alias for dataVolumeClaimTemplate, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse data directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
replicasCount
integer
how much replicas in each shards for current cluster will run in Kubernetes,
each replica is a separate `StatefulSet` which contains only one `Pod` with `clickhouse-server` instance,
every shard contains 1 replica by default"
shards []object
optional, allows override top-level `chi.spec.configuration`, cluster-level
`chi.spec.configuration.clusters` settings for each shard separately,
use it only if you fully understand what you do"
definitionType
string
DEPRECATED - to be removed soon
files
object
optional, allows define content of any setting file inside each `Pod` only in one shard during generate `ConfigMap` which will mount in `/etc/clickhouse-server/config.d/` or `/etc/clickhouse-server/conf.d/` or `/etc/clickhouse-server/users.d/`
override top-level `chi.spec.configuration.files` and cluster-level `chi.spec.configuration.clusters.files`
internalReplication
object
optional, `true` by default when `chi.spec.configuration.clusters[].layout.ReplicaCount` > 1 and 0 otherwise
allows setup <internal_replication> setting which will use during insert into tables with `Distributed` engine for insert only in one live replica and other replicas will download inserted data during replication,
will apply in <remote_servers> inside ConfigMap which will mount in /etc/clickhouse-server/config.d/chop-generated-remote_servers.xml
More details: https://clickhouse.tech/docs/en/engines/table-engines/special/distributed/
name
string
optional, by default shard name is generated, but you can override it and setup custom name
pattern:
^[a-zA-Z0-9-]{0,15}$minLength:
1maxLength:
15replicas []object
optional, allows override behavior for selected replicas from cluster-level `chi.spec.configuration.clusters` and shard-level `chi.spec.configuration.clusters.layout.shards`
files
object
optional, allows define content of any setting file inside `Pod` only in one replica during generate `ConfigMap` which will mount in `/etc/clickhouse-server/config.d/` or `/etc/clickhouse-server/conf.d/` or `/etc/clickhouse-server/users.d/`
override top-level `chi.spec.configuration.files`, cluster-level `chi.spec.configuration.clusters.files` and shard-level `chi.spec.configuration.clusters.layout.shards.files`
httpPort
integer
optional, setup `Pod.spec.containers.ports` with name `http` for selected replica, override `chi.spec.templates.hostTemplates.spec.httpPort`
allows connect to `clickhouse-server` via HTTP protocol via kubernetes `Service`
minimum:
1maximum:
65535
httpsPort
integer
minimum:
1maximum:
65535
insecure
object
optional, open insecure ports for cluster, defaults to "yes"
interserverHTTPPort
integer
optional, setup `Pod.spec.containers.ports` with name `interserver` for selected replica, override `chi.spec.templates.hostTemplates.spec.interserverHTTPPort`
allows connect between replicas inside same shard during fetch replicated data parts HTTP protocol
minimum:
1maximum:
65535
name
string
optional, by default replica name is generated, but you can override it and setup custom name
pattern:
^[a-zA-Z0-9-]{0,15}$minLength:
1maxLength:
15
secure
object
optional, open secure ports
settings
object
optional, allows configure `clickhouse-server` settings inside <yandex>...</yandex> tag in `Pod` only in one replica during generate `ConfigMap` which will mount in `/etc/clickhouse-server/conf.d/`
override top-level `chi.spec.configuration.settings`, cluster-level `chi.spec.configuration.clusters.settings` and shard-level `chi.spec.configuration.clusters.layout.shards.settings`
More details: https://clickhouse.tech/docs/en/operations/settings/settings/
tcpPort
integer
optional, setup `Pod.spec.containers.ports` with name `tcp` for selected replica, override `chi.spec.templates.hostTemplates.spec.tcpPort`
allows connect to `clickhouse-server` via TCP Native protocol via kubernetes `Service`
minimum:
1maximum:
65535templates object
optional, configuration of the templates names which will use for generate Kubernetes resources according to selected replica
override top-level `chi.spec.configuration.templates`, cluster-level `chi.spec.configuration.clusters.templates` and shard-level `chi.spec.configuration.clusters.layout.shards.templates`
clusterServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each clickhouse cluster described in `chi.spec.configuration.clusters`
dataVolumeClaimTemplate
string
optional, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse data directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
hostTemplate
string
optional, template name from chi.spec.templates.hostTemplates, which will apply to configure every `clickhouse-server` instance during render ConfigMap resources which will mount into `Pod`
logVolumeClaimTemplate
string
optional, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse log directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
podTemplate
string
optional, template name from chi.spec.templates.podTemplates, allows customization each `Pod` resource during render and reconcile each StatefulSet.spec resource described in `chi.spec.configuration.clusters`
replicaServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each replica inside each shard inside each clickhouse cluster described in `chi.spec.configuration.clusters`
serviceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates. used for customization of the `Service` resource, created by `clickhouse-operator` to cover all clusters in whole `chi` resource
serviceTemplates
[]string
optional, template names from chi.spec.templates.serviceTemplates. used for customization of the `Service` resources, created by `clickhouse-operator` to cover all clusters in whole `chi` resource
shardServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each shard inside clickhouse cluster described in `chi.spec.configuration.clusters`
volumeClaimTemplate
string
optional, alias for dataVolumeClaimTemplate, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse data directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
tlsPort
integer
minimum:
1maximum:
65535
replicasCount
integer
optional, how much replicas in selected shard for selected ClickHouse cluster will run in Kubernetes, each replica is a separate `StatefulSet` which contains only one `Pod` with `clickhouse-server` instance,
shard contains 1 replica by default
override cluster-level `chi.spec.configuration.clusters.layout.replicasCount`
minimum:
1
settings
object
optional, allows configure `clickhouse-server` settings inside <yandex>...</yandex> tag in each `Pod` only in one shard during generate `ConfigMap` which will mount in `/etc/clickhouse-server/config.d/`
override top-level `chi.spec.configuration.settings` and cluster-level `chi.spec.configuration.clusters.settings`
More details: https://clickhouse.tech/docs/en/operations/settings/settings/
templates object
optional, configuration of the templates names which will use for generate Kubernetes resources according to selected shard
override top-level `chi.spec.configuration.templates` and cluster-level `chi.spec.configuration.clusters.templates`
clusterServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each clickhouse cluster described in `chi.spec.configuration.clusters`
dataVolumeClaimTemplate
string
optional, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse data directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
hostTemplate
string
optional, template name from chi.spec.templates.hostTemplates, which will apply to configure every `clickhouse-server` instance during render ConfigMap resources which will mount into `Pod`
logVolumeClaimTemplate
string
optional, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse log directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
podTemplate
string
optional, template name from chi.spec.templates.podTemplates, allows customization each `Pod` resource during render and reconcile each StatefulSet.spec resource described in `chi.spec.configuration.clusters`
replicaServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each replica inside each shard inside each clickhouse cluster described in `chi.spec.configuration.clusters`
serviceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates. used for customization of the `Service` resource, created by `clickhouse-operator` to cover all clusters in whole `chi` resource
serviceTemplates
[]string
optional, template names from chi.spec.templates.serviceTemplates. used for customization of the `Service` resources, created by `clickhouse-operator` to cover all clusters in whole `chi` resource
shardServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each shard inside clickhouse cluster described in `chi.spec.configuration.clusters`
volumeClaimTemplate
string
optional, alias for dataVolumeClaimTemplate, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse data directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
weight
integer
optional, 1 by default, allows setup shard <weight> setting which will use during insert into tables with `Distributed` engine,
will apply in <remote_servers> inside ConfigMap which will mount in /etc/clickhouse-server/config.d/chop-generated-remote_servers.xml
More details: https://clickhouse.tech/docs/en/engines/table-engines/special/distributed/
shardsCount
integer
how much shards for current ClickHouse cluster will run in Kubernetes,
each shard contains shared-nothing part of data and contains set of replicas,
cluster contains 1 shard by default"
name
string
cluster name, used to identify set of servers and wide used during generate names of related Kubernetes resources
pattern:
^[a-zA-Z0-9-]{0,15}$minLength:
1maxLength:
15
pdbManaged
object
Specifies whether the Pod Disruption Budget (PDB) should be managed.
During the next installation, if PDB management is enabled, the operator will
attempt to retrieve any existing PDB. If none is found, it will create a new one
and initiate a reconciliation loop. If PDB management is disabled, the existing PDB
will remain intact, and the reconciliation loop will not be executed. By default,
PDB management is enabled.
pdbMaxUnavailable
integer
Pod eviction is allowed if at most "pdbMaxUnavailable" pods are unavailable after the eviction,
i.e. even in absence of the evicted pod. For example, one can prevent all voluntary evictions
by specifying 0. This is a mutually exclusive setting with "minAvailable".
minimum:
0maximum:
65535reconcile object
allow tuning reconciling process
hooks object
cluster-level hooks to execute before and after cluster reconcile
post []object
actions to execute after cluster reconcile
events
[]string required
Cluster-scope reconcile lifecycle events. Required, non-empty.
Any - wildcard match: fires on every cluster reconcile pass
and the cluster delete sweep
ClusterCreate - all hosts in the cluster are new (no ancestor); fires
only on the first reconcile of a brand-new cluster
ClusterReconcile - ongoing reconcile pass over an existing cluster (at
least one host has prior state). Fires on every
operator reconcile cycle the upstream gates allow,
including taskID-only force-reconciles. NOT a "spec
changed" signal.
ClusterDelete - cluster is being removed (delete sweep — wiring follow-up)
minItems:
1
failurePolicy
string
Controls what happens when this hook returns an error.
Fail (default) propagates the error; Ignore logs a warning and continues.
enum:
Fail, fail, Ignore, ignorehttp object
method
string
url
string
shell object
command
[]string
container
string
sql object
queries
[]string
target
string
where to execute hook for cluster-level hooks: FirstHost (default), AllHosts, AllShards
enum:
, FirstHost, firsthost, AllHosts, allhosts, AllShards, allshardspre []object
actions to execute before cluster reconcile
events
[]string required
Cluster-scope reconcile lifecycle events. Required, non-empty.
Any - wildcard match: fires on every cluster reconcile pass
and the cluster delete sweep
ClusterCreate - all hosts in the cluster are new (no ancestor); fires
only on the first reconcile of a brand-new cluster
ClusterReconcile - ongoing reconcile pass over an existing cluster (at
least one host has prior state). Fires on every
operator reconcile cycle the upstream gates allow,
including taskID-only force-reconciles. NOT a "spec
changed" signal.
ClusterDelete - cluster is being removed (delete sweep — wiring follow-up)
minItems:
1
failurePolicy
string
Controls what happens when this hook returns an error.
Fail (default) propagates the error; Ignore logs a warning and continues.
enum:
Fail, fail, Ignore, ignorehttp object
method
string
url
string
shell object
command
[]string
container
string
sql object
queries
[]string
target
string
where to execute hook for cluster-level hooks: FirstHost (default), AllHosts, AllShards
enum:
, FirstHost, firsthost, AllHosts, allhosts, AllShards, allshardshost object
Whether the operator during reconcile procedure should wait for a ClickHouse host:
- to be excluded from a ClickHouse cluster
- to complete all running queries
- to be included into a ClickHouse cluster
respectfully before moving forward
drop object
replicas object
Whether the operator during reconcile procedure should drop replicas when replica is deleted or recreated
active
object
Whether the operator during reconcile procedure should drop active replicas when replica is deleted or recreated
onDelete
object
Whether the operator during reconcile procedure should drop replicas when replica is deleted
onLostVolume
object
Whether the operator during reconcile procedure should drop replicas when replica volume is lost
hooks object
hooks to execute before and after host reconcile
post []object
actions to execute after reconcile
events
[]string required
Reconcile lifecycle events that trigger this hook. Required, must be non-empty.
The hook is skipped on any reconcile whose classifier does not emit at least one
of the listed events. Supported values:
Any - wildcard match: fires on every hook-evaluation point,
including the pre-delete sweep on the dying host
HostCreate - first reconcile that creates a host (no ancestor); best
paired with POST hooks because PRE hooks on first creation
are skipped (no live pod yet)
HostUpdate - reconcile that has prior state for the host; catch-all
for ongoing reconciles
HostStart - host transitions from stopped to running
HostStop - host is being stopped (current spec marks it stopped)
HostConfigRestart - in-place software restart for a configuration change
HostRollout - pod-template change forces a StatefulSet rollout
HostShutdown - aggregate: fires whenever the pod is going down for any
reason (Stop, ConfigRestart, Rollout, or Delete)
HostDelete - host is being removed from the cluster (downsize); fires
on the dying host before tear-down. Always emitted
alongside HostShutdown.
minItems:
1
failurePolicy
string
Controls what happens when this hook returns an error.
Fail (default): error propagates — pre-hook aborts reconcile / host deletion.
Ignore: error is logged and the reconcile continues.
enum:
Fail, fail, Ignore, ignorehttp object
method
string
url
string
shell object
command
[]string
container
string
sql object
queries
[]string
target
string
where to execute hook for cluster-level hooks: FirstHost (default), AllHosts, AllShards
enum:
, FirstHost, firsthost, AllHosts, allhosts, AllShards, allshardspre []object
actions to execute before reconcile
events
[]string required
Reconcile lifecycle events that trigger this hook. Required, must be non-empty.
The hook is skipped on any reconcile whose classifier does not emit at least one
of the listed events. Supported values:
Any - wildcard match: fires on every hook-evaluation point,
including the pre-delete sweep on the dying host
HostCreate - first reconcile that creates a host (no ancestor); best
paired with POST hooks because PRE hooks on first creation
are skipped (no live pod yet)
HostUpdate - reconcile that has prior state for the host; catch-all
for ongoing reconciles
HostStart - host transitions from stopped to running
HostStop - host is being stopped (current spec marks it stopped)
HostConfigRestart - in-place software restart for a configuration change
HostRollout - pod-template change forces a StatefulSet rollout
HostShutdown - aggregate: fires whenever the pod is going down for any
reason (Stop, ConfigRestart, Rollout, or Delete)
HostDelete - host is being removed from the cluster (downsize); fires
on the dying host before tear-down. Always emitted
alongside HostShutdown.
minItems:
1
failurePolicy
string
Controls what happens when this hook returns an error.
Fail (default): error propagates — pre-hook aborts reconcile / host deletion.
Ignore: error is logged and the reconcile continues.
enum:
Fail, fail, Ignore, ignorehttp object
method
string
url
string
shell object
command
[]string
container
string
sql object
queries
[]string
target
string
where to execute hook for cluster-level hooks: FirstHost (default), AllHosts, AllShards
enum:
, FirstHost, firsthost, AllHosts, allhosts, AllShards, allshardswait object
exclude
object
Allows to stop all ClickHouse clusters defined in a CHI.
Works as the following:
- When `stop` is `1` operator sets `Replicas: 0` in each StatefulSet. Thie leads to having all `Pods` and `Service` deleted. All PVCs are kept intact.
- When `stop` is `0` operator sets `Replicas: 1` and `Pod`s and `Service`s will created again and all retained PVCs will be attached to `Pod`s.
include
object
Whether the operator during reconcile procedure should wait for a ClickHouse host to be included into a ClickHouse cluster
probes object
What probes the operator should wait during host launch procedure
readiness
object
Whether the operator during host launch procedure should wait for ready probe to succeed.
In case probe is unspecified wait is assumed to be completed successfully.
Default option value is to wait.
startup
object
Whether the operator during host launch procedure should wait for startup probe to succeed.
In case probe is unspecified wait is assumed to be completed successfully.
Default option value is to do not wait.
queries
object
Whether the operator during reconcile procedure should wait for a ClickHouse host to complete all running queries
replicas object
Whether the operator during reconcile procedure should wait for replicas to catch-up
all
object
Whether the operator during reconcile procedure should wait for all replicas to catch-up
delay
integer
replication max absolute delay to consider replica is not delayed
new
object
Whether the operator during reconcile procedure should wait for new replicas to catch-up
runtime object
runtime parameters for clickhouse-operator process which are used during reconcile cycle
reconcileShardsMaxConcurrencyPercent
integer
The maximum percentage of cluster shards that may be reconciled in parallel, 50 percent by default.
minimum:
0maximum:
100
reconcileShardsThreadsNumber
integer
The maximum number of cluster shards that may be reconciled in parallel, 1 by default
minimum:
1maximum:
65535schemaPolicy object
describes how schema is propagated within replicas and shards
replica
string
how schema is propagated within a replica
enum:
, None, All
shard
string
how schema is propagated between shards
enum:
, None, All, DistributedTablesOnlysecret object
optional, shared secret value to secure cluster communications
auto
object
Auto-generate shared secret value to secure cluster communications
value
string
Cluster shared secret value in plain text
valueFrom object
Cluster shared secret source
secretKeyRef object
Selects a key of a secret in the clickhouse installation namespace.
Should not be used if value is not empty.
key
string required
The key of the secret to select from. Must be a valid secret key.
name
string required
Name of the referent. More info:
https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
optional
boolean
Specify whether the Secret or its key must be defined
secure
object
optional, open secure ports for cluster
security
object
Per-cluster security toggles for outbound TLS connections the operator makes
to this cluster's ClickHouse and ZooKeeper / Keeper hosts. Nil fields fall
through to the operator-wide defaults in ClickHouseOperatorConfiguration.
See docs/security_hardening.md for details.
settings
object
optional, allows configure `clickhouse-server` settings inside <yandex>...</yandex> tag in each `Pod` only in one cluster during generate `ConfigMap` which will mount in `/etc/clickhouse-server/config.d/`
override top-level `chi.spec.configuration.settings`
More details: https://clickhouse.tech/docs/en/operations/settings/settings/
templates object
optional, configuration of the templates names which will use for generate Kubernetes resources according to selected cluster
override top-level `chi.spec.configuration.templates`
clusterServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each clickhouse cluster described in `chi.spec.configuration.clusters`
dataVolumeClaimTemplate
string
optional, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse data directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
hostTemplate
string
optional, template name from chi.spec.templates.hostTemplates, which will apply to configure every `clickhouse-server` instance during render ConfigMap resources which will mount into `Pod`
logVolumeClaimTemplate
string
optional, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse log directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
podTemplate
string
optional, template name from chi.spec.templates.podTemplates, allows customization each `Pod` resource during render and reconcile each StatefulSet.spec resource described in `chi.spec.configuration.clusters`
replicaServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each replica inside each shard inside each clickhouse cluster described in `chi.spec.configuration.clusters`
serviceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates. used for customization of the `Service` resource, created by `clickhouse-operator` to cover all clusters in whole `chi` resource
serviceTemplates
[]string
optional, template names from chi.spec.templates.serviceTemplates. used for customization of the `Service` resources, created by `clickhouse-operator` to cover all clusters in whole `chi` resource
shardServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each shard inside clickhouse cluster described in `chi.spec.configuration.clusters`
volumeClaimTemplate
string
optional, alias for dataVolumeClaimTemplate, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse data directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
zookeeper object
optional, allows configure <yandex><zookeeper>..</zookeeper></yandex> section in each `Pod` only in current ClickHouse cluster, during generate `ConfigMap` which will mounted in `/etc/clickhouse-server/config.d/`
override top-level `chi.spec.configuration.zookeeper` settings
identity
string
optional access credentials string with `user:password` format used when use digest authorization in Zookeeper
keeper object
reference to a ClickHouseKeeperInstallation (CHK) resource.
The operator resolves this to ZooKeeper node addresses automatically.
name
string
name of the ClickHouseKeeperInstallation custom resource
namespace
string
namespace of the CHK resource, defaults to the CHI namespace if omitted
serviceType
string
how to discover keeper endpoints:
replicas (default) — enumerate per-host services, one ZK node per keeper replica
service — use the CR-level headless service as a single ZK node entry
enum:
, Replicas, replicas, Service, servicenodes []object
describe every available zookeeper cluster node for interaction
availabilityZone
string
availability zone for Zookeeper node
host
string
dns name or ip address for Zookeeper node
port
integer
TCP port which used to connect to Zookeeper node
minimum:
0maximum:
65535
secure
object
if a secure connection to Zookeeper is required
operation_timeout_ms
integer
one operation timeout during Zookeeper transactions
root
string
optional root znode path inside zookeeper to store ClickHouse related data (replication queue or distributed DDL)
session_timeout_ms
integer
session timeout during connect to Zookeeper
use_compression
object
Enables compression in Keeper protocol if set to true
files
object
allows define content of any setting file inside each `Pod` during generate `ConfigMap` which will mount in `/etc/clickhouse-server/config.d/` or `/etc/clickhouse-server/conf.d/` or `/etc/clickhouse-server/users.d/`
every key in this object is the file name
every value in this object is the file content
you can use `!!binary |` and base64 for binary files, see details here https://yaml.org/type/binary.html
each key could contains prefix like {common}, {users}, {hosts} or config.d, users.d, conf.d, wrong prefixes will be ignored, subfolders also will be ignored
More details: https://github.com/Altinity/clickhouse-operator/blob/master/docs/chi-examples/05-settings-05-files-nested.yaml
any key could contains `valueFrom` with `secretKeyRef` which allow pass values from kubernetes secrets
secrets will mounted into pod as separate volume in /etc/clickhouse-server/secrets.d/
and will automatically update when update secret
it useful for pass SSL certificates from cert-manager or similar tool
look into https://github.com/Altinity/clickhouse-operator/blob/master/docs/chi-examples/05-settings-01-overview.yaml for examples
profiles
object
allows configure <yandex><profiles>..</profiles></yandex> section in each `Pod` during generate `ConfigMap` which will mount in `/etc/clickhouse-server/users.d/`
you can configure any aspect of settings profile
More details: https://clickhouse.tech/docs/en/operations/settings/settings-profiles/
Your yaml code will convert to XML, see examples https://github.com/Altinity/clickhouse-operator/blob/master/docs/custom_resource_explained.md#specconfigurationprofiles
quotas
object
allows configure <yandex><quotas>..</quotas></yandex> section in each `Pod` during generate `ConfigMap` which will mount in `/etc/clickhouse-server/users.d/`
you can configure any aspect of resource quotas
More details: https://clickhouse.tech/docs/en/operations/quotas/
Your yaml code will convert to XML, see examples https://github.com/Altinity/clickhouse-operator/blob/master/docs/custom_resource_explained.md#specconfigurationquotas
settings
object
allows configure `clickhouse-server` settings inside <yandex>...</yandex> tag in each `Pod` during generate `ConfigMap` which will mount in `/etc/clickhouse-server/config.d/`
More details: https://clickhouse.tech/docs/en/operations/settings/settings/
Your yaml code will convert to XML, see examples https://github.com/Altinity/clickhouse-operator/blob/master/docs/custom_resource_explained.md#specconfigurationsettings
any key could contains `valueFrom` with `secretKeyRef` which allow pass password from kubernetes secrets
look into https://github.com/Altinity/clickhouse-operator/blob/master/docs/chi-examples/05-settings-01-overview.yaml for examples
secret value will pass in `pod.spec.env`, and generate with from_env=XXX in XML in /etc/clickhouse-server/config.d/chop-generated-settings.xml
it not allow automatically updates when updates `secret`, change spec.taskID for manually trigger reconcile cycle
users
object
allows configure <yandex><users>..</users></yandex> section in each `Pod` during generate `ConfigMap` which will mount in `/etc/clickhouse-server/users.d/`
you can configure password hashed, authorization restrictions, database level security row filters etc.
More details: https://clickhouse.tech/docs/en/operations/settings/settings-users/
Your yaml code will convert to XML, see examples https://github.com/Altinity/clickhouse-operator/blob/master/docs/custom_resource_explained.md#specconfigurationusers
any key could contains `valueFrom` with `secretKeyRef` which allow pass password from kubernetes secrets
secret value will pass in `pod.spec.containers.evn`, and generate with from_env=XXX in XML in /etc/clickhouse-server/users.d/chop-generated-users.xml
it not allow automatically updates when updates `secret`, change spec.taskID for manually trigger reconcile cycle
look into https://github.com/Altinity/clickhouse-operator/blob/master/docs/chi-examples/05-settings-01-overview.yaml for examples
any key with prefix `k8s_secret_` shall has value with format namespace/secret/key or secret/key
in this case value from secret will write directly into XML tag during render *-usersd ConfigMap
any key with prefix `k8s_secret_env` shall has value with format namespace/secret/key or secret/key
in this case value from secret will write into environment variable and write to XML tag via from_env=XXX
look into https://github.com/Altinity/clickhouse-operator/blob/master/docs/chi-examples/05-settings-01-overview.yaml for examples
zookeeper object
allows configure <yandex><zookeeper>..</zookeeper></yandex> section in each `Pod` during generate `ConfigMap` which will mounted in `/etc/clickhouse-server/config.d/`
`clickhouse-operator` itself doesn't manage Zookeeper, please install Zookeeper separatelly look examples on https://github.com/Altinity/clickhouse-operator/tree/master/deploy/zookeeper/
currently, zookeeper (or clickhouse-keeper replacement) used for *ReplicatedMergeTree table engines and for `distributed_ddl`
More details: https://clickhouse.tech/docs/en/operations/server-configuration-parameters/settings/#server-settings_zookeeper
identity
string
optional access credentials string with `user:password` format used when use digest authorization in Zookeeper
keeper object
reference to a ClickHouseKeeperInstallation (CHK) resource.
The operator resolves this to ZooKeeper node addresses automatically.
name
string
name of the ClickHouseKeeperInstallation custom resource
namespace
string
namespace of the CHK resource, defaults to the CHI namespace if omitted
serviceType
string
how to discover keeper endpoints:
replicas (default) — enumerate per-host services, one ZK node per keeper replica
service — use the CR-level headless service as a single ZK node entry
enum:
, Replicas, replicas, Service, servicenodes []object
describe every available zookeeper cluster node for interaction
availabilityZone
string
availability zone for Zookeeper node
host
string
dns name or ip address for Zookeeper node
port
integer
TCP port which used to connect to Zookeeper node
minimum:
0maximum:
65535
secure
object
if a secure connection to Zookeeper is required
operation_timeout_ms
integer
one operation timeout during Zookeeper transactions
root
string
optional root znode path inside zookeeper to store ClickHouse related data (replication queue or distributed DDL)
session_timeout_ms
integer
session timeout during connect to Zookeeper
use_compression
object
Enables compression in Keeper protocol if set to true
defaults object
define default behavior for whole ClickHouseInstallation, some behavior can be re-define on cluster, shard and replica level
More info: https://github.com/Altinity/clickhouse-operator/blob/master/docs/custom_resource_explained.md#specdefaults
distributedDDL object
allows change `<yandex><distributed_ddl></distributed_ddl></yandex>` settings
More info: https://clickhouse.tech/docs/en/operations/server-configuration-parameters/settings/#server-settings-distributed_ddl
profile
string
Settings from this profile will be used to execute DDL queries
replicasUseFQDN
object
define should replicas be specified by FQDN in `<host></host>`.
In case of "no" will use short hostname and clickhouse-server will use kubernetes default suffixes for DNS lookup
"no" by default
storageManagement object
default storage management options
provisioner
string
defines `PVC` provisioner - be it StatefulSet or the Operator
enum:
, StatefulSet, Operator
reclaimPolicy
string
defines behavior of `PVC` deletion.
`Delete` by default, if `Retain` specified then `PVC` will be kept when deleting StatefulSet
enum:
, Retain, Deletetemplates object
optional, configuration of the templates names which will use for generate Kubernetes resources according to one or more ClickHouse clusters described in current ClickHouseInstallation (chi) resource
clusterServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each clickhouse cluster described in `chi.spec.configuration.clusters`
dataVolumeClaimTemplate
string
optional, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse data directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
hostTemplate
string
optional, template name from chi.spec.templates.hostTemplates, which will apply to configure every `clickhouse-server` instance during render ConfigMap resources which will mount into `Pod`
logVolumeClaimTemplate
string
optional, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse log directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
podTemplate
string
optional, template name from chi.spec.templates.podTemplates, allows customization each `Pod` resource during render and reconcile each StatefulSet.spec resource described in `chi.spec.configuration.clusters`
replicaServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each replica inside each shard inside each clickhouse cluster described in `chi.spec.configuration.clusters`
serviceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates. used for customization of the `Service` resource, created by `clickhouse-operator` to cover all clusters in whole `chi` resource
serviceTemplates
[]string
optional, template names from chi.spec.templates.serviceTemplates. used for customization of the `Service` resources, created by `clickhouse-operator` to cover all clusters in whole `chi` resource
shardServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each shard inside clickhouse cluster described in `chi.spec.configuration.clusters`
volumeClaimTemplate
string
optional, alias for dataVolumeClaimTemplate, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse data directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
namespaceDomainPattern
string
Custom domain pattern which will be used for DNS names of `Service` or `Pod`.
Typical use scenario - custom cluster domain in Kubernetes cluster
Example: %s.svc.my.test
reconcile object
Optional, allows tuning reconciling cycle for ClickhouseInstallation from clickhouse-operator side
cleanup object
Optional, defines behavior for cleanup Kubernetes resources during reconcile cycle
reconcileFailedObjects object
Describes what clickhouse-operator should do with Kubernetes resources which are failed during reconcile.
Default behavior is `Retain`"
configMap
string
Behavior policy for failed ConfigMap, `Retain` by default
enum:
, Retain, Delete
pvc
string
Behavior policy for failed PVC, `Retain` by default
enum:
, Retain, Delete
service
string
Behavior policy for failed Service, `Retain` by default
enum:
, Retain, Delete
statefulSet
string
Behavior policy for failed StatefulSet, `Retain` by default
enum:
, Retain, DeleteunknownObjects object
Describes what clickhouse-operator should do with found Kubernetes resources which should be managed by clickhouse-operator,
but do not have `ownerReference` to any currently managed `ClickHouseInstallation` resource.
Default behavior is `Delete`"
configMap
string
Behavior policy for unknown ConfigMap, `Delete` by default
enum:
, Retain, Delete
pvc
string
Behavior policy for unknown PVC, `Delete` by default
enum:
, Retain, Delete
service
string
Behavior policy for unknown Service, `Delete` by default
enum:
, Retain, Delete
statefulSet
string
Behavior policy for unknown StatefulSet, `Delete` by default
enum:
, Retain, Deletecluster object
CHI-level cluster reconcile defaults inherited by every cluster's
spec.configuration.clusters[N].reconcile section. Use this as a single
place to define cluster-level hooks that should apply to all clusters
in this CHI; per-cluster hooks (under clusters[N].reconcile.hooks)
are appended to (and dedup'd against) the inherited set.
hooks object
cluster-level hooks inherited by every cluster
post []object
actions to execute after each cluster reconcile
events
[]string required
Cluster-scope reconcile lifecycle events. Required, non-empty.
Any - wildcard match: fires on every cluster reconcile pass
and the cluster delete sweep
ClusterCreate - all hosts in the cluster are new (no ancestor); fires
only on the first reconcile of a brand-new cluster
ClusterReconcile - ongoing reconcile pass over an existing cluster (at
least one host has prior state). Fires on every
operator reconcile cycle the upstream gates allow,
including taskID-only force-reconciles. NOT a "spec
changed" signal.
ClusterDelete - cluster is being removed (delete sweep — wiring follow-up)
minItems:
1
failurePolicy
string
Controls what happens when this hook returns an error.
Fail (default) propagates the error; Ignore logs a warning and continues.
enum:
Fail, fail, Ignore, ignorehttp object
method
string
url
string
shell object
command
[]string
container
string
sql object
queries
[]string
target
string
where to execute hook for cluster-level hooks: FirstHost (default), AllHosts, AllShards
enum:
, FirstHost, firsthost, AllHosts, allhosts, AllShards, allshardspre []object
actions to execute before each cluster reconcile
events
[]string required
Cluster-scope reconcile lifecycle events. Required, non-empty.
Any - wildcard match: fires on every cluster reconcile pass
and the cluster delete sweep
ClusterCreate - all hosts in the cluster are new (no ancestor); fires
only on the first reconcile of a brand-new cluster
ClusterReconcile - ongoing reconcile pass over an existing cluster (at
least one host has prior state). Fires on every
operator reconcile cycle the upstream gates allow,
including taskID-only force-reconciles. NOT a "spec
changed" signal.
ClusterDelete - cluster is being removed (delete sweep — wiring follow-up)
minItems:
1
failurePolicy
string
Controls what happens when this hook returns an error.
Fail (default) propagates the error; Ignore logs a warning and continues.
enum:
Fail, fail, Ignore, ignorehttp object
method
string
url
string
shell object
command
[]string
container
string
sql object
queries
[]string
target
string
where to execute hook for cluster-level hooks: FirstHost (default), AllHosts, AllShards
enum:
, FirstHost, firsthost, AllHosts, allhosts, AllShards, allshards
configMapPropagationTimeout
integer
Timeout in seconds for `clickhouse-operator` to wait for modified `ConfigMap` to propagate into the `Pod`
More details: https://kubernetes.io/docs/concepts/configuration/configmap/#mounted-configmaps-are-updated-automatically
minimum:
0maximum:
3600host object
Whether the operator during reconcile procedure should wait for a ClickHouse host:
- to be excluded from a ClickHouse cluster
- to complete all running queries
- to be included into a ClickHouse cluster
respectfully before moving forward
drop object
replicas object
Whether the operator during reconcile procedure should drop replicas when replica is deleted or recreated
active
object
Whether the operator during reconcile procedure should drop active replicas when replica is deleted or recreated
onDelete
object
Whether the operator during reconcile procedure should drop replicas when replica is deleted
onLostVolume
object
Whether the operator during reconcile procedure should drop replicas when replica volume is lost
hooks object
hooks to execute before and after host reconcile
post []object
actions to execute after reconcile
events
[]string required
Reconcile lifecycle events that trigger this hook. Required, must be non-empty.
The hook is skipped on any reconcile whose classifier does not emit at least one
of the listed events. Supported values:
Any - wildcard match: fires on every hook-evaluation point,
including the pre-delete sweep on the dying host
HostCreate - first reconcile that creates a host (no ancestor); best
paired with POST hooks because PRE hooks on first creation
are skipped (no live pod yet)
HostUpdate - reconcile that has prior state for the host; catch-all
for ongoing reconciles
HostStart - host transitions from stopped to running
HostStop - host is being stopped (current spec marks it stopped)
HostConfigRestart - in-place software restart for a configuration change
HostRollout - pod-template change forces a StatefulSet rollout
HostShutdown - aggregate: fires whenever the pod is going down for any
reason (Stop, ConfigRestart, Rollout, or Delete)
HostDelete - host is being removed from the cluster (downsize); fires
on the dying host before tear-down. Always emitted
alongside HostShutdown.
minItems:
1
failurePolicy
string
Controls what happens when this hook returns an error.
Fail (default): error propagates — pre-hook aborts reconcile / host deletion.
Ignore: error is logged and the reconcile continues.
enum:
Fail, fail, Ignore, ignorehttp object
method
string
url
string
shell object
command
[]string
container
string
sql object
queries
[]string
target
string
where to execute hook for cluster-level hooks: FirstHost (default), AllHosts, AllShards
enum:
, FirstHost, firsthost, AllHosts, allhosts, AllShards, allshardspre []object
actions to execute before reconcile
events
[]string required
Reconcile lifecycle events that trigger this hook. Required, must be non-empty.
The hook is skipped on any reconcile whose classifier does not emit at least one
of the listed events. Supported values:
Any - wildcard match: fires on every hook-evaluation point,
including the pre-delete sweep on the dying host
HostCreate - first reconcile that creates a host (no ancestor); best
paired with POST hooks because PRE hooks on first creation
are skipped (no live pod yet)
HostUpdate - reconcile that has prior state for the host; catch-all
for ongoing reconciles
HostStart - host transitions from stopped to running
HostStop - host is being stopped (current spec marks it stopped)
HostConfigRestart - in-place software restart for a configuration change
HostRollout - pod-template change forces a StatefulSet rollout
HostShutdown - aggregate: fires whenever the pod is going down for any
reason (Stop, ConfigRestart, Rollout, or Delete)
HostDelete - host is being removed from the cluster (downsize); fires
on the dying host before tear-down. Always emitted
alongside HostShutdown.
minItems:
1
failurePolicy
string
Controls what happens when this hook returns an error.
Fail (default): error propagates — pre-hook aborts reconcile / host deletion.
Ignore: error is logged and the reconcile continues.
enum:
Fail, fail, Ignore, ignorehttp object
method
string
url
string
shell object
command
[]string
container
string
sql object
queries
[]string
target
string
where to execute hook for cluster-level hooks: FirstHost (default), AllHosts, AllShards
enum:
, FirstHost, firsthost, AllHosts, allhosts, AllShards, allshardswait object
exclude
object
Allows to stop all ClickHouse clusters defined in a CHI.
Works as the following:
- When `stop` is `1` operator sets `Replicas: 0` in each StatefulSet. Thie leads to having all `Pods` and `Service` deleted. All PVCs are kept intact.
- When `stop` is `0` operator sets `Replicas: 1` and `Pod`s and `Service`s will created again and all retained PVCs will be attached to `Pod`s.
include
object
Whether the operator during reconcile procedure should wait for a ClickHouse host to be included into a ClickHouse cluster
probes object
What probes the operator should wait during host launch procedure
readiness
object
Whether the operator during host launch procedure should wait for ready probe to succeed.
In case probe is unspecified wait is assumed to be completed successfully.
Default option value is to wait.
startup
object
Whether the operator during host launch procedure should wait for startup probe to succeed.
In case probe is unspecified wait is assumed to be completed successfully.
Default option value is to do not wait.
queries
object
Whether the operator during reconcile procedure should wait for a ClickHouse host to complete all running queries
replicas object
Whether the operator during reconcile procedure should wait for replicas to catch-up
all
object
Whether the operator during reconcile procedure should wait for all replicas to catch-up
delay
integer
replication max absolute delay to consider replica is not delayed
new
object
Whether the operator during reconcile procedure should wait for new replicas to catch-up
macros object
macros parameters
sections object
sections behaviour for macros
files object
sections behaviour for macros on files
enabled
object
enabled or not
profiles object
sections behaviour for macros on profiles
enabled
object
enabled or not
quotas object
sections behaviour for macros on quotas
enabled
object
enabled or not
settings object
sections behaviour for macros on settings
enabled
object
enabled or not
users object
sections behaviour for macros on users
enabled
object
enabled or not
policy
string
DISCUSSED TO BE DEPRECATED
Syntax sugar
Overrides all three 'reconcile.host.wait.{exclude, queries, include}' values from the operator's config
Possible values:
- wait - should wait to exclude host, complete queries and include host back into the cluster
- nowait - should NOT wait to exclude host, complete queries and include host back into the cluster
enum:
, wait, nowaitruntime object
runtime parameters for clickhouse-operator process which are used during reconcile cycle
reconcileShardsMaxConcurrencyPercent
integer
The maximum percentage of cluster shards that may be reconciled in parallel, 50 percent by default.
minimum:
0maximum:
100
reconcileShardsThreadsNumber
integer
The maximum number of cluster shards that may be reconciled in parallel, 1 by default
minimum:
1maximum:
65535statefulSet object
Optional, StatefulSet reconcile behavior tuning
create object
Behavior during create StatefulSet
onFailure
string
What to do in case created StatefulSet is not in 'Ready' after `reconcile.statefulSet.update.timeout` seconds.
Possible options:
1. abort - abort the process, do nothing with the problematic StatefulSet, leave it as it is.
2. delete - delete newly created problematic StatefulSet and follow 'abort' path afterwards.
3. ignore - ignore an error, pretend nothing happened, continue reconcile and move on to the next StatefulSet.
enum:
, abort, delete, ignorerecreate object
Behavior during recreate StatefulSet
onDataLoss
string
What to do in case operator needs to recreate StatefulSet due to PVC data loss or missing volumes.
Possible options:
1. abort - abort the process, do nothing with the problematic StatefulSet.
2. recreate - proceed and recreate StatefulSet.
enum:
, abort, recreate
onUpdateFailure
string
What to do in case operator needs to recreate StatefulSet due to update failure or StatefulSet not ready.
Possible options:
1. abort - abort the process, do nothing with the problematic StatefulSet.
2. recreate - proceed and recreate StatefulSet.
enum:
, abort, recreateupdate object
Behavior during update StatefulSet
onFailure
string
What to do in case updated StatefulSet is not in 'Ready' after `reconcile.statefulSet.update.timeout` seconds.
Possible options:
1. abort - abort the process, do nothing with the problematic StatefulSet, leave it as it is.
2. rollback - delete Pod and rollback StatefulSet to previous Generation. Follow 'abort' path afterwards.
3. ignore - ignore an error, pretend nothing happened, continue reconcile and move on to the next StatefulSet.
enum:
, abort, rollback, ignore
pollInterval
integer
How many seconds to wait between checks for StatefulSet status during update
minimum:
1maximum:
600
timeout
integer
How many seconds to wait for StatefulSet to be 'Ready' during update
minimum:
0maximum:
3600reconciling object
[OBSOLETED] Optional, allows tuning reconciling cycle for ClickhouseInstallation from clickhouse-operator side
cleanup object
Optional, defines behavior for cleanup Kubernetes resources during reconcile cycle
reconcileFailedObjects object
Describes what clickhouse-operator should do with Kubernetes resources which are failed during reconcile.
Default behavior is `Retain`"
configMap
string
Behavior policy for failed ConfigMap, `Retain` by default
enum:
, Retain, Delete
pvc
string
Behavior policy for failed PVC, `Retain` by default
enum:
, Retain, Delete
service
string
Behavior policy for failed Service, `Retain` by default
enum:
, Retain, Delete
statefulSet
string
Behavior policy for failed StatefulSet, `Retain` by default
enum:
, Retain, DeleteunknownObjects object
Describes what clickhouse-operator should do with found Kubernetes resources which should be managed by clickhouse-operator,
but do not have `ownerReference` to any currently managed `ClickHouseInstallation` resource.
Default behavior is `Delete`"
configMap
string
Behavior policy for unknown ConfigMap, `Delete` by default
enum:
, Retain, Delete
pvc
string
Behavior policy for unknown PVC, `Delete` by default
enum:
, Retain, Delete
service
string
Behavior policy for unknown Service, `Delete` by default
enum:
, Retain, Delete
statefulSet
string
Behavior policy for unknown StatefulSet, `Delete` by default
enum:
, Retain, Deletecluster object
CHI-level cluster reconcile defaults inherited by every cluster's
spec.configuration.clusters[N].reconcile section. Use this as a single
place to define cluster-level hooks that should apply to all clusters
in this CHI; per-cluster hooks (under clusters[N].reconcile.hooks)
are appended to (and dedup'd against) the inherited set.
hooks object
cluster-level hooks inherited by every cluster
post []object
actions to execute after each cluster reconcile
events
[]string required
Cluster-scope reconcile lifecycle events. Required, non-empty.
Any - wildcard match: fires on every cluster reconcile pass
and the cluster delete sweep
ClusterCreate - all hosts in the cluster are new (no ancestor); fires
only on the first reconcile of a brand-new cluster
ClusterReconcile - ongoing reconcile pass over an existing cluster (at
least one host has prior state). Fires on every
operator reconcile cycle the upstream gates allow,
including taskID-only force-reconciles. NOT a "spec
changed" signal.
ClusterDelete - cluster is being removed (delete sweep — wiring follow-up)
minItems:
1
failurePolicy
string
Controls what happens when this hook returns an error.
Fail (default) propagates the error; Ignore logs a warning and continues.
enum:
Fail, fail, Ignore, ignorehttp object
method
string
url
string
shell object
command
[]string
container
string
sql object
queries
[]string
target
string
where to execute hook for cluster-level hooks: FirstHost (default), AllHosts, AllShards
enum:
, FirstHost, firsthost, AllHosts, allhosts, AllShards, allshardspre []object
actions to execute before each cluster reconcile
events
[]string required
Cluster-scope reconcile lifecycle events. Required, non-empty.
Any - wildcard match: fires on every cluster reconcile pass
and the cluster delete sweep
ClusterCreate - all hosts in the cluster are new (no ancestor); fires
only on the first reconcile of a brand-new cluster
ClusterReconcile - ongoing reconcile pass over an existing cluster (at
least one host has prior state). Fires on every
operator reconcile cycle the upstream gates allow,
including taskID-only force-reconciles. NOT a "spec
changed" signal.
ClusterDelete - cluster is being removed (delete sweep — wiring follow-up)
minItems:
1
failurePolicy
string
Controls what happens when this hook returns an error.
Fail (default) propagates the error; Ignore logs a warning and continues.
enum:
Fail, fail, Ignore, ignorehttp object
method
string
url
string
shell object
command
[]string
container
string
sql object
queries
[]string
target
string
where to execute hook for cluster-level hooks: FirstHost (default), AllHosts, AllShards
enum:
, FirstHost, firsthost, AllHosts, allhosts, AllShards, allshards
configMapPropagationTimeout
integer
Timeout in seconds for `clickhouse-operator` to wait for modified `ConfigMap` to propagate into the `Pod`
More details: https://kubernetes.io/docs/concepts/configuration/configmap/#mounted-configmaps-are-updated-automatically
minimum:
0maximum:
3600host object
Whether the operator during reconcile procedure should wait for a ClickHouse host:
- to be excluded from a ClickHouse cluster
- to complete all running queries
- to be included into a ClickHouse cluster
respectfully before moving forward
drop object
replicas object
Whether the operator during reconcile procedure should drop replicas when replica is deleted or recreated
active
object
Whether the operator during reconcile procedure should drop active replicas when replica is deleted or recreated
onDelete
object
Whether the operator during reconcile procedure should drop replicas when replica is deleted
onLostVolume
object
Whether the operator during reconcile procedure should drop replicas when replica volume is lost
hooks object
hooks to execute before and after host reconcile
post []object
actions to execute after reconcile
events
[]string required
Reconcile lifecycle events that trigger this hook. Required, must be non-empty.
The hook is skipped on any reconcile whose classifier does not emit at least one
of the listed events. Supported values:
Any - wildcard match: fires on every hook-evaluation point,
including the pre-delete sweep on the dying host
HostCreate - first reconcile that creates a host (no ancestor); best
paired with POST hooks because PRE hooks on first creation
are skipped (no live pod yet)
HostUpdate - reconcile that has prior state for the host; catch-all
for ongoing reconciles
HostStart - host transitions from stopped to running
HostStop - host is being stopped (current spec marks it stopped)
HostConfigRestart - in-place software restart for a configuration change
HostRollout - pod-template change forces a StatefulSet rollout
HostShutdown - aggregate: fires whenever the pod is going down for any
reason (Stop, ConfigRestart, Rollout, or Delete)
HostDelete - host is being removed from the cluster (downsize); fires
on the dying host before tear-down. Always emitted
alongside HostShutdown.
minItems:
1
failurePolicy
string
Controls what happens when this hook returns an error.
Fail (default): error propagates — pre-hook aborts reconcile / host deletion.
Ignore: error is logged and the reconcile continues.
enum:
Fail, fail, Ignore, ignorehttp object
method
string
url
string
shell object
command
[]string
container
string
sql object
queries
[]string
target
string
where to execute hook for cluster-level hooks: FirstHost (default), AllHosts, AllShards
enum:
, FirstHost, firsthost, AllHosts, allhosts, AllShards, allshardspre []object
actions to execute before reconcile
events
[]string required
Reconcile lifecycle events that trigger this hook. Required, must be non-empty.
The hook is skipped on any reconcile whose classifier does not emit at least one
of the listed events. Supported values:
Any - wildcard match: fires on every hook-evaluation point,
including the pre-delete sweep on the dying host
HostCreate - first reconcile that creates a host (no ancestor); best
paired with POST hooks because PRE hooks on first creation
are skipped (no live pod yet)
HostUpdate - reconcile that has prior state for the host; catch-all
for ongoing reconciles
HostStart - host transitions from stopped to running
HostStop - host is being stopped (current spec marks it stopped)
HostConfigRestart - in-place software restart for a configuration change
HostRollout - pod-template change forces a StatefulSet rollout
HostShutdown - aggregate: fires whenever the pod is going down for any
reason (Stop, ConfigRestart, Rollout, or Delete)
HostDelete - host is being removed from the cluster (downsize); fires
on the dying host before tear-down. Always emitted
alongside HostShutdown.
minItems:
1
failurePolicy
string
Controls what happens when this hook returns an error.
Fail (default): error propagates — pre-hook aborts reconcile / host deletion.
Ignore: error is logged and the reconcile continues.
enum:
Fail, fail, Ignore, ignorehttp object
method
string
url
string
shell object
command
[]string
container
string
sql object
queries
[]string
target
string
where to execute hook for cluster-level hooks: FirstHost (default), AllHosts, AllShards
enum:
, FirstHost, firsthost, AllHosts, allhosts, AllShards, allshardswait object
exclude
object
Allows to stop all ClickHouse clusters defined in a CHI.
Works as the following:
- When `stop` is `1` operator sets `Replicas: 0` in each StatefulSet. Thie leads to having all `Pods` and `Service` deleted. All PVCs are kept intact.
- When `stop` is `0` operator sets `Replicas: 1` and `Pod`s and `Service`s will created again and all retained PVCs will be attached to `Pod`s.
include
object
Whether the operator during reconcile procedure should wait for a ClickHouse host to be included into a ClickHouse cluster
probes object
What probes the operator should wait during host launch procedure
readiness
object
Whether the operator during host launch procedure should wait for ready probe to succeed.
In case probe is unspecified wait is assumed to be completed successfully.
Default option value is to wait.
startup
object
Whether the operator during host launch procedure should wait for startup probe to succeed.
In case probe is unspecified wait is assumed to be completed successfully.
Default option value is to do not wait.
queries
object
Whether the operator during reconcile procedure should wait for a ClickHouse host to complete all running queries
replicas object
Whether the operator during reconcile procedure should wait for replicas to catch-up
all
object
Whether the operator during reconcile procedure should wait for all replicas to catch-up
delay
integer
replication max absolute delay to consider replica is not delayed
new
object
Whether the operator during reconcile procedure should wait for new replicas to catch-up
macros object
macros parameters
sections object
sections behaviour for macros
files object
sections behaviour for macros on files
enabled
object
enabled or not
profiles object
sections behaviour for macros on profiles
enabled
object
enabled or not
quotas object
sections behaviour for macros on quotas
enabled
object
enabled or not
settings object
sections behaviour for macros on settings
enabled
object
enabled or not
users object
sections behaviour for macros on users
enabled
object
enabled or not
policy
string
DISCUSSED TO BE DEPRECATED
Syntax sugar
Overrides all three 'reconcile.host.wait.{exclude, queries, include}' values from the operator's config
Possible values:
- wait - should wait to exclude host, complete queries and include host back into the cluster
- nowait - should NOT wait to exclude host, complete queries and include host back into the cluster
enum:
, wait, nowaitruntime object
runtime parameters for clickhouse-operator process which are used during reconcile cycle
reconcileShardsMaxConcurrencyPercent
integer
The maximum percentage of cluster shards that may be reconciled in parallel, 50 percent by default.
minimum:
0maximum:
100
reconcileShardsThreadsNumber
integer
The maximum number of cluster shards that may be reconciled in parallel, 1 by default
minimum:
1maximum:
65535statefulSet object
Optional, StatefulSet reconcile behavior tuning
create object
Behavior during create StatefulSet
onFailure
string
What to do in case created StatefulSet is not in 'Ready' after `reconcile.statefulSet.update.timeout` seconds.
Possible options:
1. abort - abort the process, do nothing with the problematic StatefulSet, leave it as it is.
2. delete - delete newly created problematic StatefulSet and follow 'abort' path afterwards.
3. ignore - ignore an error, pretend nothing happened, continue reconcile and move on to the next StatefulSet.
enum:
, abort, delete, ignorerecreate object
Behavior during recreate StatefulSet
onDataLoss
string
What to do in case operator needs to recreate StatefulSet due to PVC data loss or missing volumes.
Possible options:
1. abort - abort the process, do nothing with the problematic StatefulSet.
2. recreate - proceed and recreate StatefulSet.
enum:
, abort, recreate
onUpdateFailure
string
What to do in case operator needs to recreate StatefulSet due to update failure or StatefulSet not ready.
Possible options:
1. abort - abort the process, do nothing with the problematic StatefulSet.
2. recreate - proceed and recreate StatefulSet.
enum:
, abort, recreateupdate object
Behavior during update StatefulSet
onFailure
string
What to do in case updated StatefulSet is not in 'Ready' after `reconcile.statefulSet.update.timeout` seconds.
Possible options:
1. abort - abort the process, do nothing with the problematic StatefulSet, leave it as it is.
2. rollback - delete Pod and rollback StatefulSet to previous Generation. Follow 'abort' path afterwards.
3. ignore - ignore an error, pretend nothing happened, continue reconcile and move on to the next StatefulSet.
enum:
, abort, rollback, ignore
pollInterval
integer
How many seconds to wait between checks for StatefulSet status during update
minimum:
1maximum:
600
timeout
integer
How many seconds to wait for StatefulSet to be 'Ready' during update
minimum:
0maximum:
3600
restart
string
In case 'RollingUpdate' specified, the operator will always restart ClickHouse pods during reconcile.
This options is used in rare cases when force restart is required and is typically removed after the use in order to avoid unneeded restarts.
enum:
, RollingUpdate
security
object
CHI-level security defaults, applied to every cluster that does not override
them. Each cluster can shadow these via spec.configuration.clusters[].security.
See docs/security_hardening.md for details.
stop
object
Allows to stop all ClickHouse clusters defined in a CHI.
Works as the following:
- When `stop` is `1` operator sets `Replicas: 0` in each StatefulSet. Thie leads to having all `Pods` and `Service` deleted. All PVCs are kept intact.
- When `stop` is `0` operator sets `Replicas: 1` and `Pod`s and `Service`s will created again and all retained PVCs will be attached to `Pod`s.
suspend
object
Suspend reconciliation of resources managed by a ClickHouse Installation.
Works as the following:
- When `suspend` is `true` operator stops reconciling all resources.
- When `suspend` is `false` or not set, operator reconciles all resources.
taskID
string
Allows to define custom taskID for CHI update and watch status of this update execution.
Displayed in all .status.taskID* fields.
By default (if not filled) every update of CHI manifest will generate random taskID
templates object
allows define templates which will use for render Kubernetes resources like StatefulSet, ConfigMap, Service, PVC, by default, clickhouse-operator have own templates, but you can override it
hostTemplates []object
hostTemplate will use during apply to generate `clickhose-server` config files
name
string
template name, could use to link inside top-level `chi.spec.defaults.templates.hostTemplate`, cluster-level `chi.spec.configuration.clusters.templates.hostTemplate`, shard-level `chi.spec.configuration.clusters.layout.shards.temlates.hostTemplate`, replica-level `chi.spec.configuration.clusters.layout.replicas.templates.hostTemplate`
portDistribution []object
define how will distribute numeric values of named ports in `Pod.spec.containers.ports` and clickhouse-server configs
type
string
type of distribution, when `Unspecified` (default value) then all listen ports on clickhouse-server configuration in all Pods will have the same value, when `ClusterScopeIndex` then ports will increment to offset from base value depends on shard and replica index inside cluster with combination of `chi.spec.templates.podTemlates.spec.HostNetwork` it allows setup ClickHouse cluster inside Kubernetes and provide access via external network bypass Kubernetes internal network
enum:
, Unspecified, ClusterScopeIndexspec object
files
object
optional, allows define content of any setting file inside each `Pod` where this template will apply during generate `ConfigMap` which will mount in `/etc/clickhouse-server/config.d/` or `/etc/clickhouse-server/conf.d/` or `/etc/clickhouse-server/users.d/`
httpPort
integer
optional, setup `http_port` inside `clickhouse-server` settings for each Pod where current template will apply
if specified, should have equal value with `chi.spec.templates.podTemplates.spec.containers.ports[name=http]`
More info: https://clickhouse.tech/docs/en/interfaces/http/
minimum:
1maximum:
65535
httpsPort
integer
minimum:
1maximum:
65535
insecure
object
optional, open insecure ports for cluster, defaults to "yes"
interserverHTTPPort
integer
optional, setup `interserver_http_port` inside `clickhouse-server` settings for each Pod where current template will apply
if specified, should have equal value with `chi.spec.templates.podTemplates.spec.containers.ports[name=interserver]`
More info: https://clickhouse.tech/docs/en/operations/server-configuration-parameters/settings/#interserver-http-port
minimum:
1maximum:
65535
name
string
by default, hostname will generate, but this allows define custom name for each `clickhouse-server`
pattern:
^[a-zA-Z0-9-]{0,15}$minLength:
1maxLength:
15
secure
object
optional, open secure ports
settings
object
optional, allows configure `clickhouse-server` settings inside <yandex>...</yandex> tag in each `Pod` where this template will apply during generate `ConfigMap` which will mount in `/etc/clickhouse-server/conf.d/`
More details: https://clickhouse.tech/docs/en/operations/settings/settings/
tcpPort
integer
optional, setup `tcp_port` inside `clickhouse-server` settings for each Pod where current template will apply
if specified, should have equal value with `chi.spec.templates.podTemplates.spec.containers.ports[name=tcp]`
More info: https://clickhouse.tech/docs/en/interfaces/tcp/
minimum:
1maximum:
65535templates object
be careful, this part of CRD allows override template inside template, don't use it if you don't understand what you do
clusterServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each clickhouse cluster described in `chi.spec.configuration.clusters`
dataVolumeClaimTemplate
string
optional, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse data directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
hostTemplate
string
optional, template name from chi.spec.templates.hostTemplates, which will apply to configure every `clickhouse-server` instance during render ConfigMap resources which will mount into `Pod`
logVolumeClaimTemplate
string
optional, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse log directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
podTemplate
string
optional, template name from chi.spec.templates.podTemplates, allows customization each `Pod` resource during render and reconcile each StatefulSet.spec resource described in `chi.spec.configuration.clusters`
replicaServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each replica inside each shard inside each clickhouse cluster described in `chi.spec.configuration.clusters`
serviceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates. used for customization of the `Service` resource, created by `clickhouse-operator` to cover all clusters in whole `chi` resource
serviceTemplates
[]string
optional, template names from chi.spec.templates.serviceTemplates. used for customization of the `Service` resources, created by `clickhouse-operator` to cover all clusters in whole `chi` resource
shardServiceTemplate
string
optional, template name from chi.spec.templates.serviceTemplates, allows customization for each `Service` resource which will created by `clickhouse-operator` which cover each shard inside clickhouse cluster described in `chi.spec.configuration.clusters`
volumeClaimTemplate
string
optional, alias for dataVolumeClaimTemplate, template name from chi.spec.templates.volumeClaimTemplates, allows customization each `PVC` which will mount for clickhouse data directory in each `Pod` during render and reconcile every StatefulSet.spec resource described in `chi.spec.configuration.clusters`
tlsPort
integer
minimum:
1maximum:
65535podTemplates []object
podTemplate will use during render `Pod` inside `StatefulSet.spec` and allows define rendered `Pod.spec`, pod scheduling distribution and pod zone
More information: https://github.com/Altinity/clickhouse-operator/blob/master/docs/custom_resource_explained.md#spectemplatespodtemplates
distribution
string
DEPRECATED, shortcut for `chi.spec.templates.podTemplates.spec.affinity.podAntiAffinity`
enum:
, Unspecified, OnePerHost
generateName
string
allows define format for generated `Pod` name, look to https://github.com/Altinity/clickhouse-operator/blob/master/docs/custom_resource_explained.md#spectemplatesservicetemplates for details about available template variables
metadata
object
allows pass standard object's metadata from template to Pod
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
name
string
template name, could use to link inside top-level `chi.spec.defaults.templates.podTemplate`, cluster-level `chi.spec.configuration.clusters.templates.podTemplate`, shard-level `chi.spec.configuration.clusters.layout.shards.temlates.podTemplate`, replica-level `chi.spec.configuration.clusters.layout.replicas.templates.podTemplate`
podDistribution []object
define ClickHouse Pod distribution policy between Kubernetes Nodes inside Shard, Replica, Namespace, CHI, another ClickHouse cluster
number
integer
define, how much ClickHouse Pods could be inside selected scope with selected distribution type
minimum:
0maximum:
65535
scope
string
scope for apply each podDistribution
enum:
, Unspecified, Shard, Replica, Cluster, ClickHouseInstallation, Namespace
topologyKey
string
use for inter-pod affinity look to `pod.spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.topologyKey`,
more info: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity"
type
string
you can define multiple affinity policy types
enum:
enum: , Unspecified, ClickHouseAntiAffinity, ShardAntiAffinity, ReplicaAntiAffinity, AnotherNamespaceAntiAffinity, AnotherClic...
, Unspecified, ClickHouseAntiAffinity, ShardAntiAffinity, ReplicaAntiAffinity, AnotherNamespaceAntiAffinity, AnotherClickHouseInstallationAntiAffinity, AnotherClusterAntiAffinity, MaxNumberPerNode, NamespaceAffinity, ClickHouseInstallationAffinity, ClusterAffinity, ShardAffinity, ReplicaAffinity, PreviousTailAffinity, CircularReplication
spec
object
allows define whole Pod.spec inside StaefulSet.spec, look to https://kubernetes.io/docs/concepts/workloads/pods/#pod-templates for details
zone object
allows define custom zone name and will separate ClickHouse `Pods` between nodes, shortcut for `chi.spec.templates.podTemplates.spec.affinity.podAntiAffinity`
key
string
optional, if defined, allows select kubernetes nodes by label with `name` equal `key`
values
[]string
optional, if defined, allows select kubernetes nodes by label with `value` in `values`
serviceTemplates []object
allows define template for rendering `Service` which would get endpoint from Pods which scoped chi-wide, cluster-wide, shard-wide, replica-wide level
generateName
string
allows define format for generated `Service` name,
look to https://github.com/Altinity/clickhouse-operator/blob/master/docs/custom_resource_explained.md#spectemplatesservicetemplates
for details about available template variables"
metadata
object
allows pass standard object's metadata from template to Service
Could be use for define specificly for Cloud Provider metadata which impact to behavior of service
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
name
string
template name, could use to link inside
chi-level `chi.spec.defaults.templates.serviceTemplate`
cluster-level `chi.spec.configuration.clusters.templates.clusterServiceTemplate`
shard-level `chi.spec.configuration.clusters.layout.shards.temlates.shardServiceTemplate`
replica-level `chi.spec.configuration.clusters.layout.replicas.templates.replicaServiceTemplate` or `chi.spec.configuration.clusters.layout.shards.replicas.replicaServiceTemplate`
spec
object
describe behavior of generated Service
More info: https://kubernetes.io/docs/concepts/services-networking/service/
volumeClaimTemplates []object
allows define template for rendering `PVC` kubernetes resource, which would use inside `Pod` for mount clickhouse `data`, clickhouse `logs` or something else
metadata
object
allows to pass standard object's metadata from template to PVC
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
name
string
template name, could use to link inside
top-level `chi.spec.defaults.templates.dataVolumeClaimTemplate` or `chi.spec.defaults.templates.logVolumeClaimTemplate`,
cluster-level `chi.spec.configuration.clusters.templates.dataVolumeClaimTemplate` or `chi.spec.configuration.clusters.templates.logVolumeClaimTemplate`,
shard-level `chi.spec.configuration.clusters.layout.shards.temlates.dataVolumeClaimTemplate` or `chi.spec.configuration.clusters.layout.shards.temlates.logVolumeClaimTemplate`
replica-level `chi.spec.configuration.clusters.layout.replicas.templates.dataVolumeClaimTemplate` or `chi.spec.configuration.clusters.layout.replicas.templates.logVolumeClaimTemplate`
provisioner
string
defines `PVC` provisioner - be it StatefulSet or the Operator
enum:
, StatefulSet, Operator
reclaimPolicy
string
defines behavior of `PVC` deletion.
`Delete` by default, if `Retain` specified then `PVC` will be kept when deleting StatefulSet
enum:
, Retain, Delete
spec
object
allows define all aspects of `PVC` resource
More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims
templating object
Optional, applicable inside ClickHouseInstallationTemplate only.
Defines current ClickHouseInstallationTemplate application options to target ClickHouseInstallation(s)."
chiSelector
object
Optional, defines selector for ClickHouseInstallation(s) to be templated with ClickhouseInstallationTemplate
policy
string
When defined as `auto` inside ClickhouseInstallationTemplate, this ClickhouseInstallationTemplate
will be auto-added into ClickHouseInstallation, selectable by `chiSelector`.
Default value is `manual`, meaning ClickHouseInstallation should request this ClickhouseInstallationTemplate explicitly.
enum:
, auto, manual
troubleshoot
object
Allows to troubleshoot Pods during CrashLoopBack state.
This may happen when wrong configuration applied, in this case `clickhouse-server` wouldn't start.
Command within ClickHouse container is modified with `sleep` in order to avoid quick restarts
and give time to troubleshoot via CLI.
Liveness and Readiness probes are disabled as well.
useTemplates []object
list of `ClickHouseInstallationTemplate` (chit) resource names which will merge with current `CHI`
manifest during render Kubernetes resources to create related ClickHouse clusters"
name
string
name of `ClickHouseInstallationTemplate` (chit) resource
namespace
string
Kubernetes namespace where need search `chit` resource, depending on `watchNamespaces` settings in `clickhouse-operator`
useType
string
optional, current strategy is only merge, and current `chi` settings have more priority than merged template `chit`
enum:
, mergestatus object
Status contains many fields like a normalized configuration, clickhouse-operator version, current action and all applied action list, current taskID and all applied taskIDs and other
action
string
Action
actionPlan
object
Action Plan
actions
[]string
Actions
chop-commit
string
Operator git commit SHA
chop-date
string
Operator build date
chop-ip
string
IP address of the operator's pod which managed this resource
chop-version
string
Operator version
clusters
integer
Clusters count
minimum:
0
endpoint
string
Endpoint
endpoints
[]string
All endpoints
error
string
Last error
errors
[]string
Errors
fqdns
[]string
Pods FQDNs
generation
integer
Generation
minimum:
0
hosts
integer
Hosts count
minimum:
0
hostsAdded
integer
Added Hosts count
minimum:
0
hostsCompleted
integer
Completed Hosts count
minimum:
0
hostsDelete
integer
About to delete Hosts count
minimum:
0
hostsDeleted
integer
Deleted Hosts count
minimum:
0
hostsUnchanged
integer
Unchanged Hosts count
minimum:
0
hostsUpdated
integer
Updated Hosts count
minimum:
0
hostsWithReplicaCaughtUp
[]string
List of hosts with replica caught up
hostsWithTablesCreated
[]string
List of hosts with tables created by the operator
normalized
object
Normalized resource requested
normalizedCompleted
object
Normalized resource completed
pod-ips
[]string
Pod IPs
pods
[]string
Pods
replicas
integer
Replicas count
minimum:
0
shards
integer
Shards count
minimum:
0
status
string
Status
taskID
string
Current task id
taskIDsCompleted
[]string
Completed task ids
taskIDsStarted
[]string
Started task ids
usedTemplates
[]object
List of templates used to build this CHI
No matches. Try .spec.configuration for an exact path