#ClickHouseInstallations

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 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

ObjectMeta is metadata that all persisted resources must have, which includes all objects users must create.

Current ClickHouseInstallation manifest 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

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

ClickHouse operator version

ClickHouse operator git commit SHA

ClickHouse operator build date

IP address of the operator's pod which managed this CHI

Clusters count

Shards count

Replicas count

Hosts count

Status

Current task id

Started task ids

Completed task ids

Action

Actions

Last error

Errors

Updated Hosts count

Added Hosts count

Deleted Hosts count

About to delete Hosts count

Pods

Pod IPs

Pods FQDNs

Endpoint

Generation

Normalized CHI requested

Normalized CHI completed

Allows to define custom taskID for named update operation and watch status of this update execution in .status.taskIDs field. By default every update of chi manifest will generate random taskID

Allow stop all ClickHouse clusters described in current chi. Stop mechanism works as follows:

• When stop is 1 then setup Replicas: 0 in each related to current chi StatefulSet resource, all Pods and Service resources will desctroy, but PVCs still live
• When stop is 0 then Pods will created again and will attach retained PVCs and Service also will created again

This is a 'soft restart' button. When set to 'RollingUpdate' operator will restart ClickHouse pods in a graceful way. Remove it after the use in order to avoid unneeded restarts

allows troubleshoot Pods during CrashLoopBack state, when you apply wrong configuration, clickhouse-server wouldn't startup

custom domain suffix which will add to end of Service or Pod name, use it when you use custom cluster domain in your Kubernetes cluster

optional, define policy for auto applying ClickHouseInstallationTemplate inside ClickHouseInstallation

optional, allows tuning reconciling cycle for ClickhouseInstallation from clickhouse-operator side

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

allows configure multiple aspects and behavior for clickhouse-server instance and also allows describe multiple clickhouse-server clusters inside one chi resource

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

list of ClickHouseInstallationTemplate (chit) resource names which will merge with current Chi manifest during render Kubernetes resources to create related ClickHouse clusters

when defined as auto inside ClickhouseInstallationTemplate, it will auto add into all ClickHouseInstallation, manual value is default

DEPRECATED

timeout in seconds when clickhouse-operator will wait when applied ConfigMap during reconcile ClickhouseInstallation pods will updated from cache see details: https://kubernetes.io/docs/concepts/configuration/configmap/#mounted-configmaps-are-updated-automatically

optional, define behavior for cleanup Kubernetes resources during reconcile cycle

what clickhouse-operator shall do when found Kubernetes resources which should be managed with clickhouse-operator, but not have ownerReference to any currently managed ClickHouseInstallation resource, default behavior is Delete

what clickhouse-operator shall do when reconciling Kubernetes resources are failed, default behavior is Retain

behavior policy for unknown StatefulSet, Delete by default

behavior policy for unknown PVC, Delete by default

behavior policy for unknown ConfigMap, Delete by default

behavior policy for unknown Service, Delete by default

behavior policy for failed StatefulSet reconciling, Retain by default

behavior policy for failed PVC reconciling, Retain by default

behavior policy for failed ConfigMap reconciling, Retain by default

behavior policy for failed Service reconciling, Retain by default

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 "yes" by default

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

default storage management options

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

Settings from this profile will be used to execute DDL queries

defines PVC provisioner - be it StatefulSet or the Operator

defines behavior of PVC deletion. Delete by default, if Retain specified then PVC will be kept when deleting StatefulSet

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

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

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

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

optional, template name from chi.spec.templates.serviceTemplates, allows customization for one Service resource which will created by clickhouse-operator which cover all clusters in whole chi resource

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

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

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

DEPRECATED! VolumeClaimTemplate is deprecated in favor of DataVolumeClaimTemplate and LogVolumeClaimTemplate

allows configure .. 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

allows configure .. 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

allows configure .. 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

allows configure .. 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

allows configure clickhouse-server settings inside ... 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

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 USERS, COMMON, HOST or config.d, users.d, cond.d, wrong prefixes will ignored, subfolders also will ignored More details: https://github.com/Altinity/clickhouse-operator/blob/master/docs/chi-examples/05-settings-05-files-nested.yaml

describes ClickHouse 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

describe every available zookeeper cluster node for interaction

session timeout during connect to Zookeeper

one operation timeout during Zookeeper transactions

optional root znode path inside zookeeper to store ClickHouse related data (replication queue or distributed DDL)

optional access credentials string with user:password format used when use digest authorization in Zookeeper

dns name or ip address for Zookeeper node

TCP port which used to connect to Zookeeper node

cluster name, used to identify set of ClickHouse servers and wide used during generate names of related Kubernetes resources

optional, allows configure .. 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

optional, allows configure clickhouse-server settings inside ... 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/

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

optional, configuration of the templates names which will use for generate Kubernetes resources according to selected cluster override top-level chi.spec.configuration.templates

describes how schema is propagated within replicas and shards

optional, shared secret value to secure cluster communications

describe current cluster layout, how much shards in cluster, how much replica in shard allows override settings on each shard and replica separatelly

describe every available zookeeper cluster node for interaction

session timeout during connect to Zookeeper

one operation timeout during Zookeeper transactions

optional root znode path inside zookeeper to store ClickHouse related data (replication queue or distributed DDL)

optional access credentials string with user:password format used when use digest authorization in Zookeeper

dns name or ip address for Zookeeper node

TCP port which used to connect to Zookeeper node

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

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

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

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

optional, template name from chi.spec.templates.serviceTemplates, allows customization for one Service resource which will created by clickhouse-operator which cover all clusters in whole chi resource

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

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

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

DEPRECATED! VolumeClaimTemplate is deprecated in favor of DataVolumeClaimTemplate and LogVolumeClaimTemplate

how schema is propagated within a replica

how schema is propagated between shards

Auto-generate shared secret value to secure cluster communications

Cluster shared secret value in plain text

Cluster shared secret source

Selects a key of a secret in the clickhouse installation namespace. Should not be used if value is not empty.

Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

The key of the secret to select from. Must be a valid secret key.

Specify whether the Secret or its key must be defined

DEPRECATED - to be removed soon

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

how much replicas in each shards for current ClickHouse 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

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

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

optional, by default shard name is generated, but you can override it and setup custom name

DEPRECATED - to be removed soon

optional, 1 by default, allows setup shard 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/

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/

optional, allows configure clickhouse-server settings inside ... 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/

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

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

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

optional, allows override behavior for selected replicas from cluster-level chi.spec.configuration.clusters and shard-level chi.spec.configuration.clusters.layout.shards

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

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

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

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

optional, template name from chi.spec.templates.serviceTemplates, allows customization for one Service resource which will created by clickhouse-operator which cover all clusters in whole chi resource

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

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

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

DEPRECATED! VolumeClaimTemplate is deprecated in favor of DataVolumeClaimTemplate and LogVolumeClaimTemplate

optional, by default replica name is generated, but you can override it and setup custom name

optional, setup secure inside clickhouse-server settings for each Pod where current template will apply if specified

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

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

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

optional, allows configure clickhouse-server settings inside ... 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/

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

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

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

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

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

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

optional, template name from chi.spec.templates.serviceTemplates, allows customization for one Service resource which will created by clickhouse-operator which cover all clusters in whole chi resource

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

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

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

DEPRECATED! VolumeClaimTemplate is deprecated in favor of DataVolumeClaimTemplate and LogVolumeClaimTemplate

optional, by default replica name is generated, but you can override it and setup custom name

optional, allows configure clickhouse-server settings inside ... 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/

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

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

optional, count of shards related to current replica, you can override each shard behavior on low-level chi.spec.configuration.clusters.layout.replicas.shards

optional, list of shards related to current replica, will ignore if chi.spec.configuration.clusters.layout.shards presents

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

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

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

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

optional, template name from chi.spec.templates.serviceTemplates, allows customization for one Service resource which will created by clickhouse-operator which cover all clusters in whole chi resource

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

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

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

DEPRECATED! VolumeClaimTemplate is deprecated in favor of DataVolumeClaimTemplate and LogVolumeClaimTemplate

optional, by default shard name is generated, but you can override it and setup custom name

optional, setup secure inside clickhouse-server settings for each Pod where current template will apply if specified

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

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

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

optional, allows configure clickhouse-server settings inside ... 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/

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

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

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

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

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

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

optional, template name from chi.spec.templates.serviceTemplates, allows customization for one Service resource which will created by clickhouse-operator which cover all clusters in whole chi resource

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

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

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

DEPRECATED! VolumeClaimTemplate is deprecated in favor of DataVolumeClaimTemplate and LogVolumeClaimTemplate

hostTemplate will use during apply to generate clickhose-server config files

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

allows define template for rendering PVC kubernetes resource, which would use inside Pod for mount clickhouse data, clickhouse logs or something else

allows define template for rendering Service which would get endpoint from Pods which scoped chi-wide, cluster-wide, shard-wide, replica-wide level

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

define how will distribute numeric values of named ports in Pod.spec.containers.ports and clickhouse-server configs

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

by default, hostname will generate, but this allows define custom name for each clickhuse-server

optional, setup secure inside clickhouse-server settings for each Pod where current template will apply if specified

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/

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/

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

optional, allows configure clickhouse-server settings inside ... 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/

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/

be careful, this part of CRD allows override template inside template, don't use it if you don't understand what you do

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

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

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

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

optional, template name from chi.spec.templates.serviceTemplates, allows customization for one Service resource which will created by clickhouse-operator which cover all clusters in whole chi resource

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

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

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

DEPRECATED! VolumeClaimTemplate is deprecated in favor of DataVolumeClaimTemplate and LogVolumeClaimTemplate

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

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 aviailable template variables

allows define custom zone name and will separate ClickHouse Pods between nodes, shortcut for chi.spec.templates.podTemplates.spec.affinity.podAntiAffinity

DEPRECATED, shortcut for chi.spec.templates.podTemplates.spec.affinity.podAntiAffinity

define ClickHouse Pod distibution policy between Kubernetes Nodes inside Shard, Replica, Namespace, CHI, another ClickHouse cluster

allows define whole Pod.spec inside StaefulSet.spec, look to https://kubernetes.io/docs/concepts/workloads/pods/#pod-templates for details

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

optional, if defined, allows select kubernetes nodes by label with name equal key

optional, if defined, allows select kubernetes nodes by label with value in values

you can define multiple affinity policy types

scope for apply each podDistribution

define, how much ClickHouse Pods could be inside selected scope with selected distribution type

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

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

defines PVC provisioner - be it StatefulSet or the Operator

defines behavior of PVC deletion. Delete by default, if Retain specified then PVC will be kept when deleting StatefulSet

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

allows define all aspects of PVC resource More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims

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

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 aviailable template variables

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://kubernetes.io/docs/concepts/services-networking/service/

describe behavior of generated Service More info: https://kubernetes.io/docs/concepts/services-networking/service/

name of ClickHouseInstallationTemplate (chit) resource

Kubernetes namespace where need search chit resource, depending on watchNamespaces settings in clichouse-operator

optional, current strategy is only merge, and current chi settings have more priority than merged template chit