企业官网建设流程全解析

从 CHANGELOG 读懂 Altinity ClickHouse Operator：核心机制、关键能力与版本演进全解析

【免费下载链接】clickhouse-operatorAltinity Kubernetes Operator for ClickHouse creates, configures and manages ClickHouse® clusters running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/cl/clickhouse-operator

导读

CHANGELOG.md 记录了 Altinity ClickHouse Operator（一个在 Kubernetes 上创建、配置并管理 ClickHouse 集群的 Operator）从 0.15.0 到 0.23.4 的核心演进脉络。本文以该变更记录为骨架，结合仓库源码（pkg/、config/、docs/、deploy/）逐条印证每个重要特性的实现位置与工作原理，帮助读者系统理解：Operator 如何决定一次配置变更是否需要重启 ClickHouse、如何通过 Kubernetes Secret 注入密码与配置、如何并发调和大规模分片集群、如何度量自身运行状态，以及升级到新版本时需要注意哪些兼容性红线。读完本文，你将能把"某个版本改了什么"与"底层代码如何实现"一一对应起来，从而更安全地规划自己的升级与排障路径。

一、CHANGELOG 的组织方式与版本节奏

该文件遵循 Keep a Changelog 规范、采用语义化版本（Semantic Versioning），按"Added / Changed / Fixed"三类归并每个版本的行为变更。从版本号跨度（0.15.0 → 0.23.4）可以看出，这是一个持续高频迭代的项目，每个小版本通常包含数个到数十个 PR 的合并成果。

值得注意的版本节奏特点：

• 0.x 阶段：主版本号仍为 0，意味着 0.21.0、0.23.0 这类次版本号跃迁往往携带行为级变化（例如 0.21.0 重写了设置应用方式、0.23.0 引入 Kubernetes Secret 支持与实验性 Keeper 支持），升级时务必阅读对应小节。
• 部分版本带升级提示：例如 0.16.1 明确标注"CRD needs to be updated with this release"，0.19.3 提示 ClickHouseInstallation 自定义资源类型发生变化，"make sure you deploy full installation manifest when upgrading"。
• 仓库中 deploy/operatorhub/ 目录按 0.18.1 起逐版本存放 CSV 与 CRD 清单，CHANGELOG.md 中记录的许多变更都能在其中找到对应的发布产物。

下文按主题（而非按版本顺序）重组这些变更，让每个机制都能讲透"是什么、为什么、源码在哪"。

二、配置重启决策引擎：configurationRestartPolicy

2.1 问题背景：设置变更 ≠ 必须重启

在 0.21.0 之前，Operator 应用 ClickHouse 设置的唯一方式是"通过重建 StatefulSet 触发重启"——任何 settings 变更都会导致所有 Pod 滚动重启，代价高昂。0.21.0 彻底改变了这一行为：不再重建 StatefulSet，而是维护一套决策逻辑，判断 ClickHouse 是否需要重启才能让某条设置生效；需要重启时，采用"将 StatefulSet 缩容再扩容"（scale down and up）的方式执行。

这套逻辑由configurationRestartPolicy配置项控制，其默认规则集在 config/config.yaml 与 CHANGELOG 中均有记录：

configurationRestartPolicy: rules: - version: "*" rules: - settings/*: "yes" - settings/dictionaries_config: "no" - settings/logger: "no" - settings/macros/*: "no" - settings/max_server_memory_*: "no" - settings/max_*_to_drop: "no" - settings/max_concurrent_queries: "no" - settings/models_config: "no" - settings/user_defined_executable_functions_config: "no" - zookeeper/*: "yes" - files/config.d/*.xml: "yes" - files/config.d/*dict*.xml: "no" - profiles/default/background_*_pool_size: "yes" - profiles/default/max_*_for_server: "yes" - version: "21.*" rules: - settings/logger: "yes"

规则语义：按版本匹配（version支持通配，"*"作为兜底默认版本），对每个配置路径前缀给出"yes"（需重启）或"no"（热生效即可）的结论；同一路径命中多条规则时取最后一条匹配。

2.2 源码实现：谁在执行这条决策

• 决策入口在 pkg/model/chop_config.go 的IsConfigurationChangeRequiresReboot(host)，它分别对 ZooKeeper、全局 Profiles、全局 Quotas、Settings、Files 等区块逐一调用isSettingsChangeRequiresReboot判断。
• 路径前缀常量定义于同一文件：configurationRestartPolicyRulesSectionProfiles/Quotas/Settings/Files/Zookeeper，对应配置文件中profiles/*、settings/*、files/*、zookeeper/*等前缀。
• 注释中特别强调了一个工程细节（pkg/model/chop_config.go）："*"默认版本必须满足所有 ClickHouse 版本，且当 ClickHouse 版本未知（例如 host 因配置错误而无法启动时）也会回退到该默认规则。

2.3 结构化设置的特殊处理（0.23.4）

0.23.4 修复了logger/*这类结构化设置的重启规则：此前修改它们会错误地触发 Pod 重启，现在已修正。这正体现了该决策引擎的价值——把"能否热加载"的判断精确到路径级别，避免无谓的集群抖动。与此相关的配套默认配置可见 config/chi/config.d/01-clickhouse-02-logger.xml 等文件，Operator 正是通过生成这类配置片段来管理 ClickHouse 的日志、查询日志与 trace 日志。

三、Kubernetes Secret 集成：密码、设置与文件的注入

3.1 三种标准注入位置（0.23.0 起）

0.23.0 是 Secret 支持的重要里程碑：CHI 中用户密码、配置设置项、配置文件三类内容都可以用 Kubernetes 标准语法从 Secret 取值：

users: user1/password: valueFrom: secretKeyRef: name: clickhouse_secret key: pwduser1 settings: s3/my_bucket/access_key: valueFrom: secretKeyRef: name: s3-credentials key: AWS_ACCESS_KEY_ID files: server.key: valueFrom: secretKeyRef: name: clickhouse-certs key: server.key

• users：用户密码可从 Secret 注入（如上面的user1/password），避免明文写在 CHI 中。
• settings：配置设置项的值可引用 Secret，典型场景是 S3 存储的access_key/secret_key等凭据。
• files：完整文件内容可来自 Secret，典型场景是 TLS 证书server.key。

仓库中完整的实战示例包括 docs/chi-examples/05-settings-01-overview.yaml（用户/设置/文件综合示例）、docs/chi-examples/22-secure-ssl-02-files-secret-ref.yaml（SSL 文件引用 Secret）、docs/chi-examples/22-secure-ssl-03-files-multi-secrets-ref.yaml（多 Secret 引用），详见 docs/security_hardening.md 的 "Securing ClickHouse server settings" 一节。

3.2 更早的铺垫与源码落点

Secret 能力并非一蹴而就：

• 0.16.0 就为settings区块增加了"通过 Kubernetes Secret 提供 ClickHouse 用户/密码"的能力。
• 0.18.0 允许在定义用户时指定access_management，并支持在用户密码中引用 k8s secret。
• 0.20.0 起 Operator 与 ClickHouse 之间使用的clickhouse_operator凭据默认也来自 Secret（见 config/secret.yaml 的生成模板思路）。

源码层面，Secret 引用的数据结构定义在 pkg/apis/clickhouse.altinity.com/v1/type_cluster_secret.go，Secret 值在配置模板中的替换逻辑在 pkg/model/common/normalizer/subst/settings.go 中完成；CHI 的规范器（normalizer）在 pkg/model/chi/normalizer/normalizer.go 中处理这些引用。相关的单元测试见 pkg/controller/chi/worker-reconciler-chi_test.go。

3.3 相关修复与配套能力

• 0.23.2：修复了某些情况下 Secret 相关环境变量生成可能偏离预期的问题（issue #1344），并升级到 Go 1.20 以关闭依赖库中的 CVE。
• 0.23.1：修复了在某些场景下用户（users）生成可能出错的问题（issue #1324、#1332），以及 metrics-exporter 在部分情况下无法导出指标的问题（issue #1336）。
• 0.20.1：修复了 Secret 相关的 RBAC 权限（issue #1051），Operator 需要具备读取 Secret 的权限才能在运行时解析这些引用。

四、调和（Reconcile）机制：并发控制、等待策略与状态可见性

4.1 分片级并发调和（0.21.1 → 0.22.0 定型）

0.21.1 引入可配置的分片级并发调和（PR #1124），0.22.0 将参数正式化为reconcile.runtime区块。从 config/config.yaml 可以看到当前完整默认配置：

reconcile: runtime: # Max number of concurrent CHI reconciles in progress reconcileCHIsThreadsNumber: 10 # The operator reconciles shards concurrently in each CHI with the following limitations: # 1. Number of shards being reconciled (and thus having hosts down) in each CHI concurrently # can not be greater than 'reconcileShardsThreadsNumber'. # 2. Percentage of shards being reconciled (and thus having hosts down) in each CHI concurrently # can not be greater than 'reconcileShardsMaxConcurrencyPercent'. # 3. The first shard is always reconciled alone. Concurrency starts from the second shard and onward. # Max number of concurrent shard reconciles within one CHI in progress reconcileShardsThreadsNumber: 5 # Max percentage of concurrent shard reconciles within one CHI in progress reconcileShardsMaxConcurrencyPercent: 50

设计要点（注释中已写明，并能在代码常量中得到印证）：

• reconcileShardsThreadsNumber与reconcileShardsMaxConcurrencyPercent同时约束并行分片数——数量上限与百分比上限取更严格者。
• 第一个分片总是单独调和，并发从第二个分片才开始，避免"首片尚未就绪就滚动后续分片"。
• 代码层面的默认值定义在 pkg/apis/clickhouse.altinity.com/v1/type_configuration_chop.go：defaultReconcileCHIsThreadsNumber = 1、defaultReconcileShardsThreadsNumber = 1（1 表示严格串行）、defaultReconcileShardsMaxConcurrencyPercent = 50。也就是说，CHANGELOG 与 config.yaml 中的示例值（10/5/50）是生产调优推荐值，而非代码内建默认值，未配置时 Operator 会按串行方式安全运行。

0.22.0 还提到：当变更应用到分片很多的集群时，先在第一个节点上探针式验证，成功后推广到 50% 分片——这一"先验证后推广"的节奏同样是保护大规模集群稳定性的关键设计。

4.2 等待策略：等待查询结束与"nowait"

0.22.0 新增"关闭等待运行中查询完成"的能力，可在 Operator 配置中全局设置：

spec: reconcile: host: wait: queries: "false"

也可在 CHI 中按集群覆盖：

spec: reconciling: policy: nowait

这延续了 0.16.0 引入的"Pod 维护期间等待查询完成（最长 5 分钟）"的思路，把"是否等待"变成用户可调的策略。

4.3 状态可见性演进

CHI.status的演进贯穿多个版本：

• 0.20.2 / 0.20.1：引入hostsCompleted（status.hostsCompleted），用于跟踪调和进度。
• 0.21.3：新增.status.useTemplates，反映 CHI 中实际使用（手动或自动）的所有模板。
• 0.22.1：新增Aborted状态——当 Operator 中止一次调和时，CHI 被标记为Aborted，而不是停留在中间状态。
• 0.23.3：在 CHI status 中引入"未变化 host 数量"（number of unchanged hosts），并修复了调和中途重启时hosts-completed可能误报的问题。
• 状态字段的开合可在 config/config.yaml 的status.fields区块控制（如error: true、errors: true默认开启）。

4.4 自动恢复（Aborted 后的处理）

config/config.yaml 中还记录了与 Aborted 状态配套的自动恢复配置：

reconcile: recovery: from: aborted: onPodReady: retry # retry (default) — re-enqueue the CHI for reconcile # none — do nothing, CHI stays Aborted

即默认情况下，当被中止的 CHI 的某个 Pod 变为 Ready 时，Operator 会重新入队调和；也可改为none保持 Aborted。对应的clickhouse_operator_chi_auto_recoveries_triggered指标在 pkg/controller/chi/metrics/metrics.go 中登记（后续 4.5 节详述）。

4.5 Operator 自身指标：从 0.22.0 到 0.23.4

0.22.0 起 Operator 暴露一批自监控指标，0.23.4 又补充了clickhouse_operator_chi_reconciles_aborted。CHANGELOG 中列出的完整指标清单（在 pkg/controller/chi/metrics/metrics.go 中可逐条对应到 OTel Meter 的注册代码）：

clickhouse_operator_chi_reconciles_started clickhouse_operator_chi_reconciles_completed clickhouse_operator_chi_reconciles_timings clickhouse_operator_host_reconciles_started clickhouse_operator_host_reconciles_completed clickhouse_operator_host_reconciles_restarts clickhouse_operator_host_reconciles_errors clickhouse_operator_host_reconciles_timings clickhouse_operator_pod_add_events clickhouse_operator_pod_update_events clickhouse_operator_pod_delete_events

此外 0.23.4 新增的clickhouse_operator_chi_reconciles_aborted（统计被显式中止的调和次数）在源码中也有明确注释：它不包含因外部原因（如 Operator 重启）而未完成的调和，语义非常精确。0.23.0 还让 CHI 的 labels 随指标一并导出，方便在 Prometheus 中按集群维度聚合；config/config.yaml 的metrics.labels.exclude可控制是否排除部分 label。

指标收集与抓取的另一半是 metrics-exporter（入口在 cmd/metrics_exporter），0.22.0 起它并行采集所有 host 与查询；0.23.1 修复了其偶发无法导出指标的问题；0.21.0 起支持采集system.errors，并允许通过配置禁用 metrics exporter。

五、实验性 ClickHouse Keeper 支持（0.23.0）

0.23.0 通过 PR #1218 引入了实验性的 ClickHouse Keeper 支持，CRD 类型为ClickHouseKeeperInstallation：

kind: ClickHouseKeeperInstallation

CHANGELOG 明确列出了尚未完成的两件事，如实呈现了该功能的实验性质：

1. 动态重配置——这是支持动态增删 Keeper 副本的前提；
2. 与 ClickHouseInstallation 的集成——理想情况下 CHI 应通过引用（reference）而非服务名来关联 Keeper。

同时 0.23.4 提到 Keeper 相关代码有大量内部重构但无功能变化，功能增强留待下一大版本。CHANGELOG 还注明：如果集群中不存在ClickHouseKeeperInstallation资源类型，Operator 也不会因此失败（0.23.4），这为混合环境提供了兼容性保障。

仓库中可找到的配套产物：

• 示例清单：配置与部署示例集中在 docs/chk-examples/（含 1 节点、3 节点、test-only、私有镜像 Secret 等场景），部署目录见 deploy/clickhouse-keeper/。
• 默认 Keeper 配置：Operator 生成 Keeper 配置时使用的模板在 config/chk/keeper_config.d/（如 01-keeper-01-default-config.xml、02-keeper-readiness.xml）。
• 调谐逻辑：pkg/controller/chk/目录（34 个 Go 文件）对应 CHK 的控制器实现，模型层在 pkg/model/chk/。

六、存储与数据安全：卷重供应、PV 管理与数据恢复

6.1 卷重供应（0.22.0）

0.22.0 支持卷重供应（volume re-provisioning）：当卷损坏、PVC 判定其丢失（lost）时，Operator 会重新供应卷。这对自管存储（Local PV 等）场景尤为重要——损坏的卷不应导致集群永久不可用。

6.2 Operator 托管的 PV 供应（0.20.0）

0.20.0 引入 Operator 管理的 PV provisioning（受 PR #947 启发），允许无停机调整卷大小。启用方式是在 CHI 中设置：

defaults: storageManagement: provisioner: Operator

启用后，卷的创建与扩容由 Operator 接管，从而避免"调整 PVC 大小必须重建 Pod"的经典约束。仓库中与之配套的卷管理示例见 docs/chi-examples/03-persistent-volume-05-resizeable-volume-1.yaml 与 03-persistent-volume-07-multiple-resizable-volumes-1.yaml，存储设计文档见 docs/storage.md。

6.3 数据恢复与误删保护

• 0.23.0：修复了用户删除 PVC 后的数据恢复问题（issue #1310）。
• 0.18.0：删除 CRD 时 Operator 保留所有依赖对象（StatefulSet、卷），防止误删导致整个集群数据丢失。
• 0.16.1 / 0.16.0：修复了 PVC 在 Operator 外部被修改后调和时被重建的 bug（issue #730），以及缩容时副本未从 ZooKeeper 删除的问题（issue #735）。

6.4 对象存储指标修正（0.23.3）

0.23.3 将对象存储磁盘（S3 等）从DiskTotal/Free指标中移除——对对象存储而言"总容量/剩余容量"没有实际意义，保留只会误导监控。

七、安全加固演进：网络、用户、TLS

安全相关的变更贯穿多个版本，核心脉络如下：

• 0.19.0：clickhouse_operator用户被限制为只能从 Operator Pod 的 IP 访问；default用户除了hostRegexp外还被限制为仅接受 CHI Pod 的 IP（修复 GKE 下分片间连接问题）；interserver_http_host设为服务名并与remote_servers匹配（可通过replicasUseFQDN改为全限定名）；支持为 Operator 到 ClickHouse 的连接添加自定义 CA。
• 0.20.0：支持 ClickHouse 实例之间安全通信，配套示例见 docs/chi-examples/21-secure-cluster-secret-01-auto.yaml（自动生成 Secret）、21-secure-cluster-secret-02-plaintext.yaml（明文 Secret）、21-secure-cluster-secret-03-secret-ref.yaml（引用 K8s Secret）。
• 0.20.2：集群级别新增secure标志，用于启用分布式查询的 TLS；注意其数据类型从 boolean 改为 String（接受'true'、'yes'、'1'等），升级时需留意写法。
• 0.21.0：ZooKeeper 连接新增secure选项；新增insecure标志可关闭不安全的 TCP/HTTP ClickHouse 端口（详见 docs/security_hardening.md 的 "Disabling insecure connections"）。
• 0.21.2：Operator 与 metrics-exporter 会根据集群配置自动选择 http 或 https连接，无需手工指定。
• 基础镜像层面：0.16.0 切到 RedHat UBI，0.20.3 又改为 alpine 基础镜像；多个版本（0.18.4/0.18.5/0.20.2/0.20.1/0.23.2）持续处理依赖库 CVE。

八、网络与服务治理：Service 类型、PDB 与健康检查

8.1 Service 类型变更与重建（0.23.4 / 0.23.0）

• 0.23.4：默认 Service 类型从LoadBalancer改为ClusterIP——对多数内部使用场景，ClusterIP更符合最小暴露原则，需要对外暴露时再显式指定LoadBalancer。
• 0.23.0：当 ServiceType 被修改时，Service 会被重建，以规避 Kubernetes 的已知问题（kubernetes/kubernetes#24040，Service 类型变更后负载均衡器不生效）。
• 0.20.2：调整 LB Service 的创建顺序，避免出现"Service 已存在但没有可用 endpoints"的窗口期。
• 0.19.1：为副本 Service 增加clickhouse.altinity.com/ready: yes|no注解，供外部负载均衡器判断就绪状态。

8.2 PodDisruptionBudget（0.16.0 → 0.20.1）

• 0.16.0 起自动配置 PDB，防止 k8s 同时关闭多个 Pod。
• 0.20.1 将 cluster 加入 PDB selector（issue #996），注意：该特性要求 Kubernetes 1.21 及以上。
• 0.21.0 修复了 PDB 可能被误删的 bug（issue #1139）。
• 0.19.1 更新了 PDB 的 API 版本。

8.3 健康检查与探针

• 0.18.4：健康检查支持 HTTPS（PR #912）。
• 0.23.0：检查节点是否在线时，Operator 会等待 ClickHouse Service 的 endpoints 响应，避免"Pod 在但服务不可达"的误判。
• 0.15.0：引入troubleshooting 模式（spec.troubleshoot），ClickHouse 启动失败时允许 Pod 照常启动、移除 liveness 检查并注入额外 sleep，便于现场排障。

九、模板与元数据管理

• 0.21.3：CHITemplate 支持selector——可以定义"只应用于特定 CHI"的模板，示例见 docs/chi-examples/50-CHIT-04-auto-template-volume-with-selector.yaml；同时新增.status.useTemplates反映实际使用的模板。
• 0.23.0：CHI 模板（CHITemplate）改为自动热加载——此前只在 Operator 启动时加载，现在模板变更后只需触发一次 CHI 更新即可生效；0.21.3 已为 CHITemplate 本身实现免重启重载。
• 0.17.0：自动模板的 labels/annotations 得到支持；宏（macros）可用于 service annotations（与 generateName 用法一致）。
• 0.23.4：Helm chart 支持在 chart 中直接添加 Pod labels（PR #1369），满足通过 Helm 安装时统一打标的诉求，对应 deploy/helm/clickhouse-operator/values.yaml。

十、Schema 传播、迁移与分布式表

• 0.19.0：schema 传播策略由两个集群级设置控制（CRD 定义见 deploy/operator/parts/crd.yaml）：

schemaPolicy: replica: None | All (default) shard: None | All (default) | DistributedTablesOnly

此前新增分片时只创建分布式表及依赖对象（即DistributedTablesOnly），现在可配置为全量传播。

• 0.17.0 / 0.19.1：修复 Atomic 数据库、{uuid}宏、materialized view 在 ClickHouse 22.6+ 的迁移问题；0.18.0 从 schema 传播中移除 INFORMATION_SCHEMA。
• 0.21.2：新增分片/副本时支持SQL UDF 的复制（issue #1174）。
• 0.23.0 / 0.23.3：修复 ClickHouse 23.11+ 新副本的 schema 传播；0.23.3 起支持参数化数据库传播到分片与副本（ClickHouse 22.12+），包括 Replicated 与 MySQL 数据库引擎（issue #1076）。
• 0.22.0：修复了新节点启动过慢时 schema 无法创建的问题。
• 0.16.0：DDL 操作超时提高到 60 秒，缓解慢集群上的 schema 管理问题。

十一、升级与兼容性检查清单

综合 CHANGELOG 中所有带标注的注意点，升级时建议逐项核对：

1. CRD 必须同步更新：0.16.1（Status CRD 定义修改）、0.19.3（ClickHouseInstallation 资源类型变化）都明确要求部署完整安装清单。0.22.1 起允许 CRD status 及部分字段为空，方便"先升 Operator、后升 CRD"的过渡迁移（issue #842、#890）。
2. 默认值变化可能引发重启：0.16.0 将terminationGracePeriod提到 60 秒，0.16.1 又改回 30 秒并移入 Operator 配置（见 config/config.yaml 的pod.terminationGracePeriod）。0.15.0 → 0.16.x 的升级会触发 ClickHouse 重启，0.16.0 → 0.16.1 如需保留 60 秒需在 Operator 配置中显式设置。
3. Service 类型默认值：0.23.4 起默认ClusterIP，依赖LoadBalancer的环境需显式配置。
4. 类型语义变化：0.20.2 中secure标志从 boolean 改为 String；0.18.0 起 Operator 配置文件格式调整（旧格式仍向后兼容），新格式参见 config/config.yaml 与 docs/chi-examples/70-chop-config.yaml。
5. 行为变化：0.23.0 起 Operator 配置无法解析时直接崩溃而非回退到默认值——这要求配置必须经过校验（可用 docs/operator_configuration.md 核对全部可选项）；0.21.2 起 StatefulSet 更新失败会中止更新以保护集群其余部分。
6. 故障容忍：0.18.0 起删除 CRD 不再级联删除 StatefulSet 与卷，避免误删；0.19.2/0.19.3 修复了重启时 remote-servers.xml 被重建导致分布式查询异常的问题。
7. 调度与亲和：0.16.0 使topologyKey可配置（issue #772）；0.15.0 引入spec.reconciling.configMapPropagationTimeout（默认 90 秒）消除 ConfigMap 更新与 StatefulSet 重启之间的竞态。

十二、总结

把 CHANGELOG.md 与源码对照阅读，可以得到几条清晰的演进主线：

1. 从"无脑重启"到"智能决策"：configurationRestartPolicy让设置变更的重启决策精确到路径级，是 0.21.0 以来最值得关注的架构改进；
2. 从"明文配置"到"Secret 优先"：用户密码、设置项、文件三路 Secret 注入，配合secure/insecure/TLS 选项，构成了完整的安全闭环；
3. 从"串行调和"到"受控并发"：reconcile.runtime的线程数与百分比双约束、首分片单独调和、探针式推广，让大规模多分片集群的滚动更新既快又稳；
4. 从"黑盒运行"到"可观测"：CHI/host 两个层级的 reconcile 指标族与Aborted状态、自动恢复机制，使 Operator 自身的健康与进度可监控、可恢复。

对于计划升级或正在排障的用户，建议以本文第二章（重启策略）、第四章（调和与指标）、第十一章（兼容性清单）作为优先阅读章节，并将 config/config.yaml 作为核对配置的权威基准。

【免费下载链接】clickhouse-operatorAltinity Kubernetes Operator for ClickHouse creates, configures and manages ClickHouse® clusters running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/cl/clickhouse-operator