Skip to search

ClickHouseInstallationTemplate

clickhouse.altinity.com / v1

apiVersion: clickhouse.altinity.com/v1 kind: ClickHouseInstallationTemplate metadata: name: example
View raw schema
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: 1
maxLength: 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: 1
maximum: 65535
httpsPort integer
minimum: 1
maximum: 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: 1
maximum: 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: 1
maxLength: 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: 1
maximum: 65535
templates 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: 1
maximum: 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: 1
templates 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: 1
maxLength: 15
replicas []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: 1
maximum: 65535
httpsPort integer
minimum: 1
maximum: 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: 1
maximum: 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: 1
maxLength: 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: 1
maximum: 65535
templates 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: 1
maximum: 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: 1
maxLength: 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: 0
maximum: 65535
reconcile 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, ignore
http 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
pre []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, ignore
http 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
host 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, ignore
http 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
pre []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, ignore
http 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
wait 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: 0
maximum: 100
reconcileShardsThreadsNumber integer
The maximum number of cluster shards that may be reconciled in parallel, 1 by default
minimum: 1
maximum: 65535
schemaPolicy 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, DistributedTablesOnly
secret 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, service
nodes []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: 0
maximum: 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, service
nodes []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: 0
maximum: 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, Delete
templates 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, Delete
unknownObjects 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, Delete
cluster 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, ignore
http 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
pre []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, ignore
http 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: 0
maximum: 3600
host 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, ignore
http 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
pre []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, ignore
http 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
wait 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, nowait
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: 0
maximum: 100
reconcileShardsThreadsNumber integer
The maximum number of cluster shards that may be reconciled in parallel, 1 by default
minimum: 1
maximum: 65535
statefulSet 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, ignore
recreate 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, recreate
update 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: 1
maximum: 600
timeout integer
How many seconds to wait for StatefulSet to be 'Ready' during update
minimum: 0
maximum: 3600
reconciling 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, Delete
unknownObjects 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, Delete
cluster 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, ignore
http 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
pre []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, ignore
http 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: 0
maximum: 3600
host 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, ignore
http 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
pre []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, ignore
http 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
wait 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, nowait
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: 0
maximum: 100
reconcileShardsThreadsNumber integer
The maximum number of cluster shards that may be reconciled in parallel, 1 by default
minimum: 1
maximum: 65535
statefulSet 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, ignore
recreate 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, recreate
update 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: 1
maximum: 600
timeout integer
How many seconds to wait for StatefulSet to be 'Ready' during update
minimum: 0
maximum: 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, ClusterScopeIndex
spec 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: 1
maximum: 65535
httpsPort integer
minimum: 1
maximum: 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: 1
maximum: 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: 1
maxLength: 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: 1
maximum: 65535
templates 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: 1
maximum: 65535
podTemplates []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: 0
maximum: 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: , 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: , merge
status 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