Skip to content
ClickHouse Docs
ClickHouse DocsClickHouse Docs

ClickHouse Operator 配置指南

本指南介绍如何使用该 Operator 配置 ClickHouse 和 Keeper 集群。

ClickHouseCluster 配置

基本配置

apiVersion: clickhouse.com/v1alpha1
kind: ClickHouseCluster
metadata:
  name: my-cluster
spec:
  replicas: 3           # 每个分片的副本数
  shards: 2             # 分片数量
  keeperClusterRef:
    name: my-keeper     # 引用 KeeperCluster
  dataVolumeClaimSpec:
    resources:
      requests:
        storage: 10Gi

副本和分片

  • 副本:每个分片中的 ClickHouse 实例数 (用于高可用)
  • 分片:水平分片的数量 (用于扩缩容)
spec:
  replicas: 3  # 默认值:3
  shards: 2    # 默认值:1

一个配置为 replicas: 3shards: 2 的集群将总共创建 6 个 ClickHouse pod (容器组) 。

Keeper 集成

每个 ClickHouse 集群都必须引用一个 KeeperCluster,以进行协调:

spec:
  keeperClusterRef:
    name: my-keeper
    # namespace: keeper-system  # 可选,默认为 ClickHouseCluster 的命名空间

当设置了 keeperClusterRef.namespace 时,operator 必须同时监听这两个命名空间。如果配置了 WATCH_NAMESPACE,请将 ClickHouse 和 Keeper 所在的命名空间都包含在该列表中。

KeeperCluster 配置

apiVersion: clickhouse.com/v1alpha1
kind: KeeperCluster
metadata:
  name: my-keeper
spec:
  replicas: 3  # 必须为奇数:1、3、5、7、9、11、13 或 15
  dataVolumeClaimSpec:
    resources:
      requests:
        storage: 5Gi

存储配置

使用 dataVolumeClaimSpec (标准 Kubernetes PersistentVolumeClaimSpec) 配置持久化存储。Operator 会将其转换为每个副本对应的 PersistentVolumeClaim, 并将其挂载到数据路径 /var/lib/clickhouse

spec:
  dataVolumeClaimSpec:
    storageClassName: fast-ssd  # Optional: consider your storage class based on the installed CSI
    resources:
      requests:
        storage: 100Gi

关于在多磁盘 (JBOD) 布局中挂载额外磁盘、在没有持久卷的情况下运行、扩展容量、自定义存储策略、静态数据加密,以及创建后哪些内容不能更改的规则,请参阅专门的 存储和卷指南

集群域

spec.clusterDomain 用于设置 operator 在构建并写入 ClickHouse server 配置的 pod (容器组) 完全限定主机名时所使用的 Kubernetes DNS 后缀。默认值为 cluster.local,并且在 ClickHouseClusterKeeperCluster 中都可用。

spec:
  clusterDomain: cluster.local   # default; override only for a custom domain

对于 ClickHouse 副本,operator 会创建一个负责处理客户端流量的主无头 Service <cluster-name>-clickhouse-headless。 并为每个副本创建 Service <cluster-name>-clickhouse-internal-<shard>-<index>,用于暴露尚未就绪的 Pod (容器组) ,以处理内部流量 以及来自 operator 的管理请求。如果副本自身无法就绪,这可用于副本恢复。

Keeper 节点会通过其无头 Service 使用 pod 名称:<pod>.<headless-service>.<namespace>.svc.<clusterDomain>

pod (容器组) 配置

自动拓扑分散与亲和性

将 Pod (容器组) 分散到各可用区:

spec:
  podTemplate:
    topologyZoneKey: topology.kubernetes.io/zone
    nodeHostnameKey: kubernetes.io/hostname

手动配置

可以指定任意的 pod (容器组) 亲和性/反亲和性规则以及拓扑分布约束条件。

spec:
  podTemplate:
    affinity:
      <your-affinity-rules-here>
    topologySpreadConstraints:
      <your-topology-spread-constraints-here>

所有受支持的 pod (容器组) 模板选项,请参见 API 参考文档

pod (容器组) 中断预算

Operator 会为每个集群创建一个 PodDisruptionBudget (PDB) ,以确保自愿中断 (如节点排空、滚动升级、自动扩缩容驱逐) 不会导致过多 pod (容器组) 下线,从而失去仲裁或影响可用性。

对于拥有多个分片的 ClickHouse 集群,每个分片都会创建一个 PDB,这样一个分片中的中断就不会计入另一个分片。

默认值

operator 会根据集群规模选择安全的默认值,因此即使首次执行 apply,也能避免意外丢失仲裁。

资源 拓扑 默认 PDB
ClickHouseCluster replicas: 1 (单副本分片) maxUnavailable: 1 — 对于单节点集群,允许中断,这样不会阻塞节点排空
ClickHouseCluster replicas: 2+ (多副本分片) minAvailable: 1 — 每个分片至少必须保持 1 个副本在线
KeeperCluster replicas: 1 maxUnavailable: 1 — 对于单节点集群,允许中断,这样不会阻塞节点排空
KeeperCluster replicas: 3+ maxUnavailable: replicas/2 — 为 2F+1 集群保留 RAFT 仲裁 (3 个副本可容忍 1 个宕机,5 个副本可容忍 2 个宕机)

对于一个包含 3 个分片且 replicas: 3 的 ClickHouseCluster,operator 会创建 3 个 PDB,每个分片 1 个,且每个都设置为 minAvailable: 1

覆盖默认设置

使用 spec.podDisruptionBudget 覆盖 minAvailable maxUnavailable (两者只能指定一个) :

spec:
  replicas: 3
  shards: 2
  podDisruptionBudget:
    minAvailable: 2   # 中断期间,每个分片中至少保持 3 个副本中的 2 个正常运行

或者使用按百分比设置的 maxUnavailable 形式:

spec:
  replicas: 5
  podDisruptionBudget:
    maxUnavailable: 40%

你也可以将 unhealthyPodEvictionPolicy 字段传递到生成的 PDB 中——当你需要允许仍处于 NotReady 状态的 pod (容器组) 被驱逐时,这会很有用:

spec:
  podDisruptionBudget:
    minAvailable: 2
    unhealthyPodEvictionPolicy: AlwaysAllow

策略

spec.podDisruptionBudget.policy 允许你选择 operator 以多大力度管理 PDB:

Policy Behavior
Enabled (default) operator 会在每次 reconcile 时创建并更新 PDB。这是适用于生产环境的安全默认设置。
Disabled operator 不会创建 PDB,并会删除所有带有匹配标签的现有 PDB。这适用于开发集群,因为这类集群通常应允许所有自愿中断。
Ignored operator 既不创建也不删除 PDB。现有 PDB 会保持不变。当 PDB 管理由其他系统 (例如策略准入、GitOps 工具) 接管时,请使用此选项。

示例——在开发集群上完全禁用 PDB 管理:

spec:
  podDisruptionBudget:
    policy: Disabled

示例 — 将你手动编写的 PDB 与集群放在一起,并阻止 operator 触碰它:

spec:
  podDisruptionBudget:
    policy: Ignored

集群范围内停用

也可以通过 operator 的 ENABLE_PDB 环境变量,在整个集群范围内停用 PDB 管理。设置 ENABLE_PDB=false 后,无论 spec.podDisruptionBudget.policy 如何,operator 都会跳过 所有 ClickHouseCluster 和 KeeperCluster 的 PDB reconcile 步骤,并且完全不监视 PodDisruptionBudget 资源。因此,operator 的 ServiceAccount 无需具备 poddisruptionbudgets.policy/v1 的 RBAC 权限;当 operator 以受限的 ServiceAccount 运行,且该账户刻意不包含这些权限时,这一点尤其有用。

# 在 operator 的 Deployment 规格中
env:
- name: ENABLE_PDB
  value: "false"

这适用于自行实施中断策略 (例如通过 Gatekeeper / Kyverno) 的环境,并希望将 operator 完全排除在外。

容器配置

自定义镜像

使用指定的 ClickHouse 镜像:

spec:
  containerTemplate:
    image:
      repository: clickhouse/clickhouse-server
      tag: "25.12"
    imagePullPolicy: IfNotPresent

容器资源

为 ClickHouse 容器配置 CPU 和内存:

# default values
spec:
  containerTemplate:
    resources:
      requests:
        cpu: "250m"
        memory: "512Mi"
      limits:
        cpu: "1"
        memory: "512Mi"

环境变量

添加自定义的环境变量:

spec:
  containerTemplate:
    env:
    - name: CUSTOM_ENV_VAR
      value: "1"

卷挂载

添加更多卷挂载:

spec:
  containerTemplate:
    volumeMounts:
    - name: custom-config
      mountPath: /etc/clickhouse-server/config.d/custom.xml
      subPath: custom.xml

有关所有受支持的容器模板选项,请参见 API 参考文档

TLS/SSL 配置

配置安全端点

引用包含 TLS 证书的 Kubernetes Secret,以启用安全端点

spec:
  settings:
    tls:
      enabled: true
      required: true # 设置此项后,非安全端口将被禁用
      serverCertSecret:
        name: <certificate-secret-name>

SSL 证书 Secret 格式

该 Secret 应包含服务器密钥对:

  • tls.crt - PEM 编码的服务器证书
  • tls.key - PEM 编码的私钥

通过 TLS 进行 ClickHouse-Keeper 通信

如果 KeeperCluster 启用了 TLS,ClickHouseCluster 会自动使用与 Keeper 节点的安全连接。

ClickHouseCluster 会根据系统信任存储以及你配置的任何 caBundle 来验证 Keeper 节点证书。

要信任私有 CA (例如自签名 CA 或内部 CA) ,请提供自定义 CA 证书包引用:

spec:
    settings:
        tls:
          caBundle:
            name: <ca-certificate-secret-name>
            key: <ca-certificate-key>

外部 Secret

默认情况下,operator 会创建并管理一个 Secret,其中包含集群的内部凭据 (interserver 密码、管理密码、Keeper 身份、集群 secret、named-collections 密钥) 。该 Secret 以集群名称命名,并位于集群所在的命名空间中。

如果你想自行管理这些凭据——例如从 HashiCorp Vault、AWS Secrets Manager 或 External Secrets Operator 获取——可以使用 spec.externalSecret 将 operator 指向一个预先创建的 Secret:

apiVersion: clickhouse.com/v1alpha1
kind: ClickHouseCluster
metadata:
  name: sample
spec:
  replicas: 2
  keeperClusterRef:
    name: sample
  dataVolumeClaimSpec:
    resources:
      requests:
        storage: 10Gi
  externalSecret:
    name: my-clickhouse-credentials
    policy: Observe

必需的键

Secret 必须包含以下键:

Key Format When required
interserver-password 明文密码 始终需要
management-password 明文密码 始终需要
keeper-identity clickhouse:<password> 始终需要
cluster-secret 明文密码 始终需要
named-collections-key 以十六进制编码的 16 字节 AES 密钥 (32 个十六进制字符) 仅适用于 ClickHouse >= 25.12
disk-encryption-key 以十六进制编码的 16 字节 AES 密钥 (32 个十六进制字符) 仅当设置了 settings.encryption

一个完整的 Secret 如下所示:

apiVersion: v1
kind: Secret
metadata:
  name: my-clickhouse-credentials
  namespace: sample
type: Opaque
stringData:
  interserver-password: "a-strong-random-password"
  management-password: "another-strong-password"
  keeper-identity: "clickhouse:keeper-auth-password"
  cluster-secret: "cluster-internal-secret"
  named-collections-key: "0123456789abcdef0123456789abcdef"   # 32 hex chars = 16 bytes
  disk-encryption-key: "00112233445566778899aabbccddeeff"     # only when settings.encryption is set

策略:Observe 与 Manage

spec.externalSecret.policy 用于控制 Operator 如何处理缺失的必需键:

Policy 键缺失时的行为
Observe (默认) 在所有必需键都存在之前,协调会被阻塞。Operator 会通过 ExternalSecretValid 条件 (reason 为 ExternalSecretInvalid) 和一个 Warning 事件,报告每个缺失的键及其对应的格式提示。
Manage Operator 会生成所有缺失的必需键,并将它们写回同一个 Secret。适用于引导场景:先创建一个空 Secret,让 Operator 将其补齐,然后再按需收紧访问权限。Operator 仍然绝不会删除该 Secret。

当外部系统 (Vault、ESO、sealed-secrets、GitOps) 是事实来源,且你希望 Operator 在配置错误时明确报错时,请选择 Observe。当你希望实现自给自足的引导,同时仍保留对 Secret 对象本身的所有权 (例如为了备份) 时,请选择 Manage

状态条件和故障排查

Operator 会在 ClickHouseCluster.status.conditions 中暴露 ExternalSecretValid 条件。协调过程看起来卡住时,请检查它:

# Plain kubectl — works out of the box
kubectl describe clickhousecluster sample | sed -n '/Conditions:/,$p'

# Same data as YAML
kubectl get clickhousecluster sample -o yaml | sed -n '/conditions:/,/^[^ ]/p'

# Pretty-printed JSON (requires jq)
kubectl get clickhousecluster sample -o jsonpath='{.status.conditions}' | jq

可能的原因:

reason 含义 处理方式
ExternalSecretNotFound 被引用的 Secret 在该命名空间中不存在。 创建该 Secret,或修正 spec.externalSecret.name
ExternalSecretInvalid Secret 存在,但缺少必需的键 (仅在使用 Observe 时) 。消息会列出每个缺失的键及其预期格式。 添加缺失的键,或切换为 policy: Manage
ExternalSecretValid 所有必需的键都已存在,并且 operator 正在使用该 Secret。

当 Secret 无效时,operator 会将协调重新入队,因此一旦补齐缺失的键,下一次协调就会自动生效——无需重启 Pod (容器组) 。

附加端口

该 Operator 会在每个 ClickHouse pod (容器组) 及其公网无头 Service 上暴露一组固定端口:8123 HTTP、9000 native、9009 interserver、9001/9002 management、9363 Prometheus 指标,以及启用 TLS 时对应的 8443/9440 TLS 端口变体。interserver 和 management 端口还会通过每个副本的内部 Service 暴露,以便副本和 operator 能够在副本就绪前进行通信。若要让 ClickHouse 监听更多协议 (如 MySQL、PostgreSQL、gRPC 或其他自定义端口) ,请在 spec.additionalPorts 中声明:

spec:
  additionalPorts:
    - name: mysql
      port: 9004
    - name: postgres
      port: 9005
    - name: grpc
      port: 9100

operator 会将这些端口添加到 Pod 的 containerPorts 和公网无头 Service 中。 完整示例见 examples/custom_protocols.yaml

端到端示例:MySQL wire 协议

要通过 MySQL wire 协议在端口 9004 上对外暴露 ClickHouse:

apiVersion: clickhouse.com/v1alpha1
kind: ClickHouseCluster
metadata:
  name: sample
spec:
  replicas: 1
  keeperClusterRef:
    name: sample
  dataVolumeClaimSpec:
    resources:
      requests:
        storage: 2Gi

  # 1) Open the port on the Pod and the public headless Service.
  additionalPorts:
    - name: mysql
      port: 9004

  # 2) Tell ClickHouse server to actually listen on it.
  settings:
    extraConfig:
      protocols:
        mysql:
          type: mysql
          port: 9004
          description: "MySQL wire protocol"

应用完成后,在集群内部验证:

kubectl exec sample-clickhouse-0-0-0 -- \
  clickhouse-client --port 9004 --query "SELECT 1"

字段约束

字段 规则
name 必须匹配 DNS_LABEL 模式 ^[a-z]([-a-z0-9]*[a-z0-9])?$,最长 63 个字符。CRD 会将其作为 list-map 键来强制保证唯一性。
port [1, 65535] 范围内的整数。webhook 会拒绝列表中重复的端口号。

保留端口和名称

validating webhook 会拒绝与 operator 自身绑定端口发生冲突的 additionalPorts 条目。所有与 TLS 相关的端口都会被无条件保留,以确保后续切换 spec.settings.tls.enabled 时,不会破坏原本有效的集群。

Port 保留用途
8123 HTTP
8443 HTTPS
9000 native TCP
9440 native TLS
9009 interserver
9001 management
9363 Prometheus 指标

以下名称也会被拒绝——它们是 operator 的内部协议类型标识符 (而非便于人工阅读的别名) :

Name
http
http-secure
tcp
tcp-secure
interserver
management
prometheus

被拒绝的请求会产生如下错误:

spec.additionalPorts[0].port: 8123 is reserved for the operator-managed HTTP port
spec.additionalPorts[0].name: "http" is reserved by the operator

版本探测与升级通道

operator 会针对 cluster 版本执行两项彼此独立的操作:

  1. 版本报告 — 对于 ClickHouseCluster,一个 Kubernetes Job 会将容器镜像运行一次,以检测当前运行的 ClickHouse 版本;对于 KeeperCluster,operator 会从正在运行的副本中读取由 server 上报的版本。检测到的版本会记录到 .status.version 中,并用于其他协调步骤 (例如,名为 外部 Secret 的 named-collections key 仅在 ClickHouse 25.12 及以上版本中才需要) 。
  2. 升级通道 — 定期检查公开的 ClickHouse 发布源 (https://clickhouse.com/data/version_date.tsv) 。operator 会通过 VersionUpgraded status condition 报告是否有新版本可用。它绝不会自行升级 cluster——镜像标签始终由用户控制。

选择发布渠道

spec.upgradeChannel 用于指定 operator 要对照比较的上游发行版集合。ClickHouseClusterKeeperCluster 都有这个相同的字段。

spec:
  upgradeChannel: lts   # or "stable", or "25.8", or omitted

允许的值 (由 CRD 按模式 ^(lts|stable|\d+\.\d+)?$ 验证) :

Value Behavior
empty (default) Operator 只会在当前运行的 major.minor 版本线上提示 次版本 更新。运行 25.8.3.1 的集群会收到 25.8.4.x 的更新提示,但不会收到 25.9.x
stable 跟踪上游 stable 通道——即 ClickHouse Inc. 在主发行线上标记为稳定版本的最新 release。与 lts 通道相比,它会更早接收 major 升级。
lts 跟踪上游 lts 通道——即长期支持发行版。接收 major 升级的频率较低,但支持周期更长。
25.8 (or any <major>.<minor>) 将通道固定在特定的 major.minor 版本线上。即使上游已有更新版本,也不会提示超出该版本线的 major 升级。

对于生产环境,通常更建议将通道固定为明确的 <major>.<minor> (例如 25.8) 。这样可以把集群锁定在预期的 major 发行线上,并且当某个副本因某种原因漂移到其他 major 版本时,Operator 会显示 WrongReleaseChannel 警告——这一点在镜像通过摘要 (@sha256:...) 而不是便于人类阅读的标签引用时尤其重要。对于不担心 major 版本跳变的开发集群,默认的空值也完全适用。

状态条件

两个 conditions 会体现探测和升级检查的结果:

Condition Reason Meaning
VersionInSync VersionMatch 所有副本报告的版本都相同
VersionInSync VersionMismatch 各副本运行的版本不同。在计划内的滚动升级期间,此原因会被抑制。通常这会在可变镜像标签被固定时出现 (例如 latest 或仅指定主次版本的 26.3) ,且底层 registry 在多次拉取之间发生了变化,导致不同副本最终落在同一标签对应的不同补丁版本上。
VersionInSync VersionPending 版本探测 Job 尚未完成,或者尚未观察到 Keeper 副本版本
VersionInSync VersionProbeFailed ClickHouse 探测 Job 失败;operator 无法确定当前运行的版本
VersionUpgraded UpToDate 该集群使用的是所选通道中当前可用的最新版本
VersionUpgraded MinorUpdateAvailable 同一 major.minor 系列中有更新的补丁版本可用
VersionUpgraded MajorUpdateAvailable 所选通道中有更新的 major.minor 版本可用
VersionUpgraded VersionOutdated 当前运行的版本已过时,不会再从所选通道接收修复——通常是因为该主版本系列已被上游从 ltsstable 中移除
VersionUpgraded WrongReleaseChannel 当前运行的镜像不属于所选的 upgradeChannel。例如:某个运行 26.5 且设置了 upgradeChannel: lts 的集群,因为 26.5 不属于上游 lts 系列。
VersionUpgraded UpgradeCheckFailed operator 无法访问上游发布源

可使用以下方式检查它们:

kubectl get clickhousecluster sample -o yaml | sed -n '/conditions:/,/^[^ ]/p'

覆盖版本探测 Job

这仅适用于 ClickHouseClusterKeeperCluster 不再运行版本探测 Job——它的版本会直接从正在运行的 Keeper 副本中读取——因此 spec.versionProbeTemplate 已弃用,在那里不会产生任何效果。

该探测是通过一个常规的 Kubernetes Job 实现的。如果你的集群设置了准入策略,要求指定的 Tolerations、节点选择器或安全上下文,或者你想限制已完成的探测 Job 保留的时间,可以通过 spec.versionProbeTemplate 覆盖该模板:

spec:
  versionProbeTemplate:
    spec:
      ttlSecondsAfterFinished: 600   # delete completed probe Jobs 10 minutes after completion
      template:
        spec:
          nodeSelector:
            kubernetes.io/arch: amd64
          tolerations:
            - key: dedicated
              operator: Equal
              value: clickhouse
              effect: NoSchedule
          containers:
            - name: version-probe
              resources:
                requests:
                  cpu: 50m
                  memory: 64Mi

容器名称 version-probe 是 operator 的默认名称——containers: 下对应的条目会按名称与其匹配,因此 operator 会在默认配置的基础上,将用户提供的字段深度合并进去。

Operator 级别的控制

Operator 管理器上的两个标志可在全局范围内控制升级检查循环:

Flag Default Effect
--version-update-interval 24h Operator 重新拉取上游版本列表的频率
--disable-version-update-checks false 完全禁用升级检查器。不会设置 VersionUpgraded 条件,也不会产生任何发往 clickhouse.com 的出站 HTTP 流量

在隔离网络环境中,或者不允许访问 clickhouse.com 出站流量时,请设置 --disable-version-update-checks=true

ClickHouse 设置

默认用户密码

spec.settings.defaultUserPassword 用于为内置 default 用户设置密码。请提供你创建的 Secret (推荐) 或 ConfigMap 中某个键的值, 而不要直接将密码内联写在 CR 中:

spec:
  settings:
    defaultUserPassword:
      passwordType: password   # default; see "Password types" below
      secret:                  # exactly one of secret or configMap
        name: clickhouse-password   # name of the Secret/ConfigMap
        key: password               # the key inside it, not the password value

只能提供 secretconfigMap 其中之一,并且两者都必须同时包含 name (对象) 和 key (保存密码的条目) 。

密码类型

passwordType 用于告知 ClickHouse 如何解析该值。其默认值为 password (明文) ;其他可选项为哈希形式,例如 password_sha256_hexpassword_double_sha1_hex。建议优先使用哈希类型,以避免 存储 明文。完整列表请参见 ClickHouse user settings

使用 Secret 的完整示例

先创建 Secret,再引用其中的键:

kubectl create secret generic clickhouse-password \
  --from-literal=password='your-secure-password'
apiVersion: clickhouse.com/v1alpha1
kind: ClickHouseCluster
metadata:
  name: my-cluster
spec:
  settings:
    defaultUserPassword:
      passwordType: password
      secret:
        name: clickhouse-password
        key: password

对于哈希密码,请存储哈希值而非明文:

echo -n 'your-secure-password' | sha256sum   # use the hex digest as the value
kubectl create secret generic clickhouse-password \
  --from-literal=password='<sha256-hex-digest>'
spec:
  settings:
    defaultUserPassword:
      passwordType: password_sha256_hex
      secret:
        name: clickhouse-password
        key: password

使用 ConfigMap

ConfigMap 的作用方式与 Secret 相同,但其内容不像 Secret 那样受到保护。 仅应用于非敏感或已哈希的值,例如 password_sha256_hex 摘要:

spec:
  settings:
    defaultUserPassword:
      passwordType: password_sha256_hex
      configMap:
        name: clickhouse-config
        key: default_password

配置中的自定义用户

在配置文件中添加其他用户。

为该用户创建 ConfigMap 和 Secret:

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-config
data:
  reader.yaml: |
    users:
      reader:
        password:
          - '@from_env': READER_PASSWORD
        profile: default
        grants:
          query:
            - "GRANT SELECT ON *.*"
---
apiVersion: v1
kind: Secret
metadata:
  name: reader-password
data:
  password: "c2VjcmV0LXBhc3N3b3Jk"  # base64("secret-password")

向 ClickHouseCluster 添加自定义配置:

spec:
  podTemplate:
    volumes:
      - name: reader-user
        configMap:
          name: user-config
  containerTemplate:
    env:
      - name: READER_PASSWORD
        valueFrom:
          secretKeyRef:
            name: reader-password
            key: password
    volumeMounts:
      - mountPath: /etc/clickhouse-server/users.d/
        name: reader-user
        readOnly: true

数据库同步

为新副本启用数据库自动同步:

spec:
  settings:
    enableDatabaseSync: true  # Default: true

启用后,该 Operator 会将 Replicated 表和集成表同步到新副本。

每个副本 pod (容器组) 都带有 clickhouse.com/ReplicaInitialized 就绪门控,因此只有在 Operator 完成初始化后,新副本才会通过公网无头 Service 对外发布:default 数据库会转换为 Replicated 引擎,并同步 schema。在此之前,Operator 和其他副本会通过其内部 Service 访问该副本。使用 enableDatabaseSync: false 时,Operator 会立即将副本标记为已初始化,因此就绪状态仅取决于容器探针。

Operator 绝不会删除已填充数据的非 Replicated default 数据库。此类副本在完成 schema 准备后仍会开始处理客户端流量,但在您自行解决该数据库的问题之前,集群会报告 SchemaInSync=False,原因为 DefaultDatabaseNotReplicated

在缩容移除副本之前,Operator 会先将客户端流量从该副本卸载,等待其停止对外发布,将其剩余数据复制到存活副本,然后才将其删除。

服务器日志

通过 spec.settings.logger 配置 ClickHouse 服务器日志。每个字段都是可选的,并且都有安全的默认值,因此即使你从未改动过,集群也会默认以 trace 级别同时将日志输出到容器控制台和磁盘上的轮转文件。

spec:
  settings:
    logger:
      logToFile: true   # Default: true. Set false to log only to the console
      jsonLogs: false   # Default: false. Set true for structured JSON log lines
      level: trace      # Default: trace
      size: 1000M       # Default: 1000M. Rotate a log file once it reaches this size
      count: 50         # Default: 50. Number of rotated files to keep
字段 默认值 描述
logToFile true 当为 false 时,operator 会移除文件输出目标,server 只向容器控制台输出日志。
jsonLogs false 当为 true 时,operator 会添加 formatting.type: json,使每一行都成为一个 JSON 对象。
level trace 日志详细级别。可选值包括 testtracedebuginformationnoticewarningerrorcriticalfatal
size 1000M 单个日志文件在轮转前的最大大小。
count 50 server 保留的轮转后日志文件数量。

operator 始终会保持控制台日志开启,以确保 kubectl logs 可用;当 logToFiletrue 时,还会额外启用文件日志。使用默认值的集群会生成如下 logger 块:

logger:
  console: true
  level: trace
  log: /var/log/clickhouse-server/clickhouse-server.log
  errorlog: /var/log/clickhouse-server/clickhouse-server.err.log
  size: 1000M
  count: 50

同样的 spec.settings.logger 块也适用于 KeeperCluster;不过,operator 会改为将日志文件写入 /var/log/clickhouse-keeper/

自定义配置

内嵌额外配置

无需挂载自定义配置文件,也可以直接指定额外的 ClickHouse 配置选项。

使用 extraConfig 添加自定义的 ClickHouse 配置:

spec:
  settings:
    extraConfig:
      background_pool_size: 20

嵌入式附加用户配置

你也可以使用 extraUsersConfig 指定额外的 ClickHouse 用户配置。这对于直接在集群规范中定义用户、profile、配额和授权非常有用。

spec:
  settings:
    extraUsersConfig:
      users:
        analyst:
          password:
            - '@from_env': ANALYST_PASSWORD
          profile: "readonly"
          quota: "default"
      profiles:
        readonly:
          readonly: 1
          max_memory_usage: 10000000000
      quotas:
        default:
          interval:
            duration: 3600
            queries: 1000
            errors: 100

有关所有受支持的 ClickHouse 用户配置选项,请参阅文档

配置示例

完整配置示例:

apiVersion: clickhouse.com/v1alpha1
kind: KeeperCluster
metadata:
  name: sample
spec:
  replicas: 3
  dataVolumeClaimSpec:
    storageClassName: <storage-class-name>
    resources:
      requests:
        storage: 10Gi
  podTemplate:
    topologyZoneKey: topology.kubernetes.io/zone
    nodeHostnameKey: kubernetes.io/hostname
  containerTemplate:
    resources:
      requests:
        cpu: "2"
        memory: "4Gi"
      limits:
        cpu: "4"
        memory: "8Gi"
  settings:
    tls:
      enabled: true
      required: true
      serverCertSecret:
        name: <keeper-certificate-secret>
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: default-user-password
data:
  # 密钥密码
  password: "..." # 密码的 sha256 十六进制值
---
apiVersion: clickhouse.com/v1alpha1
kind: ClickHouseCluster
metadata:
  name: sample
spec:
  replicas: 2
  dataVolumeClaimSpec:
    storageClassName: <storage-class-name>
    resources:
      requests:
        storage: 200Gi
  keeperClusterRef:
    name: sample
  podTemplate:
    topologyZoneKey: topology.kubernetes.io/zone
    nodeHostnameKey: kubernetes.io/hostname
  settings:
    tls:
      enabled: true
      required: true
      serverCertSecret:
        name: clickhouse-cert
    defaultUserPassword:
      passwordType: password_sha256_hex
      configMap:
        key: password
        name: default-password
Navigation