Clickhouse Kubernetes Operator 实测：哪种方案更适合生产？本文对比了Kubernetes上

本文在 VKE Kubernetes v1.34.1-vke.4 上，对 KubeBlocks、Altinity Operator、ClickHouse 官方 Operator 三条自建路线做了真实集群测试。测试覆盖部署门槛、拓扑支持、Day-2 运维、TLS、备份恢复和监控等能力，适合正在评估 ClickHouse Kubernetes 自建方案的工程师参考。

ClickHouse Cloud 是托管服务路线，本文把它作为“自建还是托管”的参照，不参与三条 Operator 的功能排名。

一、为什么要做这次对比？

把 ClickHouse 跑在 Kubernetes 上，第一步通常并不难。真正拉开差距的，往往是部署之后的一系列工程问题：

standalone 和 keeper-backed cluster 分别能否稳定创建；
shard / replica 如何扩缩，扩完之后数据和状态能否收敛；
参数修改、重启、停止、启动等 Day-2 操作是否有清晰入口；
备份和恢复能否完成数据级闭环；
TLS、监控这些生产高频能力能否稳定落地。

这篇文章关心的不是“某个 YAML 能不能把 Pod 拉起来”，而是一个更实际的问题：如果团队要在 Kubernetes 上自建 ClickHouse，哪条路线更接近生产可用。

测试环境如下：

项目	说明
平台	VKE，Kubernetes `v1.34.1-vke.4`
节点	3 节点，单节点 `4c16G`
时间	2026 年 4 月
命名空间	`kb-system`、`clickhouse-lab`、`altinity-lab`、`ch-operator-lab`

实测对象如下：

方案	固定版本 / 路径	维护方	证据强度
KubeBlocks ClickHouse	`v1.0.2`	ApeCloud	高
Altinity Operator for ClickHouse	`0.25.6`	Altinity	中
ClickHouse 官方 Operator	`v0.0.4`	ClickHouse 官方	中

托管路线仅作参考：

方案	固定版本 / 路径	维护方	证据强度
ClickHouse Cloud	官网托管服务入口	ClickHouse 官方	文档和控制台观察

二、先说结论

KubeBlocks 的证据覆盖最完整；Altinity 和 ClickHouse 官方 Operator 都已经进入可用区间，但优势和短板并不相同。

方案	推荐判断	更适合谁	主要风险 / 保留
KubeBlocks	本轮测试范围内证据覆盖最完整	想要完整自建路线、统一 Day-2 接口、重视 backup / restore 闭环的团队	恢复相关资源命名需要控制长度
Altinity	keeper-backed 路线和 patch 风格 Day-2 运维已成立	ClickHouse 专项团队，接受以 `ClickHouseInstallation` 为中心的运维接口	本轮基于 `0.25.6` 验证，后续版本仍值得跟踪
官方 Operator	keeper-backed、TLS、metrics 方向已成立	更偏好上游语义、看重 TLS / metrics 的团队	项目发布时间短；standalone 当前 API 不支持

ClickHouse Cloud 更适合不想自建、希望直接使用托管能力的团队。它属于托管服务维度，不进入三条自建 Operator 的功能排名。

测试方法上，KubeBlocks、Altinity、官方 Operator 都以真实集群实测为准；ClickHouse Cloud 只做文档和控制台形态分析。每个功能点尽量保留输入动作、资源状态变化和 ClickHouse 侧验证结果。

三、部署体验：门槛差异很明显

先看安装阶段的整体结果。

方案	安装入口	结论
KubeBlocks	Helm 安装控制面 + 启用 ClickHouse addon	安装路径已验证
Altinity	官方 Helm chart `0.25.6`	Operator 与样本集群已验证
官方 Operator	官方 release asset `clickhouse-operator.yaml` + `cert-manager v1.19.2`	controller-manager 与样本集群已验证
ClickHouse Cloud	官网托管入口	控制台形态已查看，仅作托管路线参考

KubeBlocks：安装路径完整验证

helm repo add kubeblocks https://apecloud.github.io/helm-charts
helm install kubeblocks kubeblocks/kubeblocks \
  --namespace kb-system --create-namespace

kbcli addon enable clickhouse

本轮实际验证时，控制面和 addon 就绪后再创建测试命名空间与 ClickHouse 集群：

kubectl create namespace clickhouse-lab

kubectl -n kb-system get pod
kubectl get clusterdefinition clickhouse

# standalone 样本
kubectl apply -f kb-clickhouse-standalone.yaml
kubectl -n clickhouse-lab get cluster kb-clickhouse-standalone
kubectl -n clickhouse-lab get pod,pvc

# keeper-backed 样本
kubectl apply -f kb-clickhouse-ha.yaml
kubectl -n clickhouse-lab get cluster kb-clickhouse-ha-rqld
kubectl -n clickhouse-lab get pod -l app.kubernetes.io/instance=kb-clickhouse-ha-rqld

安装完成后，kubeblocks 主控制器、ClickHouse addon、kubeblocks-dataprotection、StorageProvider/minio、minio-cluster 和 minio-clickhouse-backuprepo 都进入可用状态。后续功能测试都基于这条路径展开。

Altinity：Operator 与样本集群已验证

Altinity Operator 固定使用 0.25.6。需要说明的是，release-0.26.0 已在 2026-02-20 发布；读者评估生产方案时，可以继续关注更新版本的变化。

实际安装与核验命令如下：

kubectl create namespace altinity-lab

helm repo add altinity https://helm.altinity.com
helm repo update
helm install altinity-clickhouse-operator \
  altinity/altinity-clickhouse-operator \
  --namespace altinity-lab \
  --version 0.25.6

kubectl -n altinity-lab get deploy,pod
kubectl -n altinity-lab get chi,clickhousekeeperinstallation

Operator 启动后开始 watch ClickHouseInstallation / ClickHouseKeeperInstallation。后续 keeper-backed cluster、登录、replicated 样本、scale-in 都验证通过。

ClickHouse 官方 Operator：项目很新，基础路径可用

ClickHouse 官方 Operator 固定使用官方 v0.0.4 release asset clickhouse-operator.yaml。这个项目的第一个 release v0.0.1 发布于 2026-01-29，v0.0.4 发布于 2026-04-17，整体仍处在很早期的产品阶段。因此，文中 Day-2 能力覆盖较少，更适合理解为项目阶段差异，而不是简单归因于设计缺陷。

本轮使用 release manifest 安装 controller，并用 CR 状态确认控制循环已经工作：

kubectl create namespace ch-operator-lab

kubectl apply -f clickhouse-operator.yaml
kubectl -n clickhouse-operator-system get deploy,pod

kubectl -n ch-operator-lab get keepercluster,clickhousecluster
kubectl -n ch-operator-lab get pod

安装完成后，clickhouse-operator-controller-manager 正常进入 ClickHouseCluster / KeeperCluster 控制循环。后续 keeper-backed cluster、登录、replicated 样本、scale-in 都验证通过。

ClickHouse Cloud：托管路线，不是另一种 Operator

把 ClickHouse Cloud 放进来，是为了给“自建还是托管”这个决策提供参照。控制台可以看到 SQL Console、Data sources、Dashboards、Backups、Monitoring 等入口，产品形态明显是 SaaS，而不是 Kubernetes Operator。

不过，ClickHouse Cloud 的产品形态、交付边界和运维责任都与自建 Operator 不同。它在本文中只作为托管路线补充，不参与自建路线排名。

四、功能实测结果

先看总览矩阵。这里写的是最终可落地结论，不展开所有中间排障过程。

功能	KubeBlocks	Altinity	官方 Operator
控制面安装	已验证	已验证	已验证
Standalone 创建	已验证	已验证	不支持
Keeper-backed 创建	已验证	已验证	已验证
登录验证	已验证	已验证	已验证
Replicated 样本	已验证	已验证	已验证
Restart / Stop / Start	已验证	已验证	无原生入口
Volume Expansion	已验证	已验证	已验证
TLS	已验证	已验证	已验证
Backup / Restore	已验证	已验证	暂未形成闭环
Prometheus 监控	已验证	已验证	已验证
Day-2 scale	已验证	已验证	已验证
HA switchover	已验证	不支持	不支持
Day-2 API 统一性	`OpsRequest`	patch 风格	patch 风格

4.1 拓扑支持

KubeBlocks 的 kb-clickhouse-standalone 和 kb-clickhouse 都完成了真实创建。Altinity 的 keeper-backed cluster 创建成功；最小 standalone 样本 altinity-proof-s1 也已 Completed，Pod 2/2 Running，并完成登录、TLS 和备份恢复验证。

拓扑验证不是只看 CR 创建成功，而是同时看 CR 状态、Pod 状态和 ClickHouse 内部查询：

# KubeBlocks
kubectl -n clickhouse-lab get cluster kb-clickhouse-standalone kb-clickhouse
kubectl -n clickhouse-lab get pod -l app.kubernetes.io/instance=kb-clickhouse

KB_CH_POD=$(kubectl -n clickhouse-lab get pod \
  -l app.kubernetes.io/instance=kb-clickhouse-ha-rqld \
  --no-headers | awk '/clickhouse/ {print $1; exit}')

kubectl -n clickhouse-lab exec -it "${KB_CH_POD}" \
  -c clickhouse -- clickhouse-client \
  --user admin --password password123 \
  --query "SELECT version(), currentUser()"

# Altinity
kubectl -n altinity-lab get chi
kubectl -n altinity-lab get clickhousekeeperinstallation
kubectl -n altinity-lab get pod -l clickhouse.altinity.com/chi

kubectl -n altinity-lab exec -it chi-altinity-proof-s1-standalone-0-0-0 \
  -c clickhouse -- clickhouse-client \
  --user user1 --password qwerty \
  --query "SELECT version(), currentUser()"

# ClickHouse 官方 Operator
kubectl -n ch-operator-lab get keepercluster,clickhousecluster
kubectl -n ch-operator-lab get pod

kubectl -n ch-operator-lab exec -it official-clickhouse-s1-clickhouse-0-0-0 \
  -- clickhouse-client \
  --query "SELECT version()"

官方 Operator 的 standalone 并非测试遗漏，而是当前 API 语义上不成立：ClickHouseCluster 校验要求 spec.keeperClusterRef，当前 release 无法表达无 keeper 的 standalone。官方文档和示例本身也按 no Keeper-less mode 设计，每个 ClickHouseCluster 都要绑定自己的 KeeperCluster。这更接近明确的产品边界，不是实现缺陷。

keeper-backed / replicated 路线方面，三条自建方案都拿到了可用样本。

4.2 Keeper / 高可用相关行为

当前 keeper HA 验证状态如下：

方案	keeper HA 当前证据	现阶段结论
KubeBlocks	已验证 3-keeper 基线、scale-out、指定候选 switchover 和配置优先级恢复	已验证
Altinity	keeper-backed 基线已验证	不支持 switchover
官方 Operator	keeper-backed 基线已验证	不支持 switchover

KubeBlocks 已验证 3-keeper 基线、scale-out 和 switchover。当前配置下，3-keeper 集群稳定 Running，HorizontalScaling 能收敛到 Succeed。在 kb-clickhouse-ha-rqld 上执行 OpsRequest/kb-clickhouse-ha-rqld-switchover 后，请求收敛到 Succeed，leader 切到指定候选实例，/keeper/config 中三条 server.* priority 也恢复为 1。

当时的 keeper 扩容和指定候选切主动作如下：

apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: kb-clickhouse-ha-rqld-keeper-scale-out
  namespace: clickhouse-lab
spec:
  clusterName: kb-clickhouse-ha-rqld
  type: HorizontalScaling
  horizontalScaling:
    - componentName: ch-keeper
      scaleOut:
        replicaChanges: 2

kubectl apply -f keeper-scale-out.yaml
kubectl -n clickhouse-lab get opsrequest kb-clickhouse-ha-rqld-keeper-scale-out -w
kubectl -n clickhouse-lab get pod -l apps.kubeblocks.io/component-name=ch-keeper

apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: kb-clickhouse-ha-rqld-switchover
  namespace: clickhouse-lab
spec:
  clusterName: kb-clickhouse-ha-rqld
  type: Switchover
  switchover:
    - componentName: ch-keeper
      instanceName: kb-clickhouse-ha-rqld-ch-keeper-0
      candidateName: kb-clickhouse-ha-rqld-ch-keeper-1

kubectl apply -f keeper-switchover.yaml
kubectl -n clickhouse-lab get opsrequest kb-clickhouse-ha-rqld-switchover -w
kubectl -n clickhouse-lab describe opsrequest kb-clickhouse-ha-rqld-switchover

Altinity 和官方 Operator 都归为“不支持 switchover”。

4.3 弹性扩缩容与 Day-2 动作

KubeBlocks 的 Day-2 scale 已验证完成。vertical scale、scale-out shard 和 scale-in shard 都实际验证通过，请求能够收敛，集群保持 Running。

Altinity 拿到了一组 patch 风格 Day-2 证据：keeper-backed CHI restart、stop/start、volume expansion、scale-in（2 -> 1）都已验证通过。官方 Operator 也拿到了 keeper-backed CHI scale-in（2 -> 1）和 volume expansion 证据，但 restart / stop / start 没有原生字段，因此归为“无原生入口”。

KubeBlocks 的 Day-2 操作都落在 OpsRequest 上。下面是 restart、volume expansion 和 shard scale-in 的实际写法：

apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: kb-clickhouse-restart
  namespace: clickhouse-lab
spec:
  clusterName: kb-clickhouse
  type: Restart
  restart:
    - componentName: clickhouse

apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: kb-clickhouse-volumeexpand
  namespace: clickhouse-lab
spec:
  clusterName: kb-clickhouse
  type: VolumeExpansion
  volumeExpansion:
    - componentName: clickhouse
      volumeClaimTemplates:
        - name: data
          storage: 30Gi

apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: kb-clickhouse-scale-in
  namespace: clickhouse-lab
spec:
  clusterName: kb-clickhouse
  type: HorizontalScaling
  horizontalScaling:
    - componentName: clickhouse
      shards: 1

提交后统一用同一组命令观察进度：

kubectl apply -f kb-clickhouse-restart.yaml
kubectl -n clickhouse-lab get opsrequest kb-clickhouse-restart -w

kubectl apply -f kb-clickhouse-volumeexpand.yaml
kubectl -n clickhouse-lab get opsrequest kb-clickhouse-volumeexpand -w
kubectl -n clickhouse-lab get pvc

kubectl apply -f kb-clickhouse-scale-in.yaml
kubectl -n clickhouse-lab get opsrequest kb-clickhouse-scale-in -w
kubectl -n clickhouse-lab get cluster kb-clickhouse
kubectl -n clickhouse-lab get pod

Altinity 的 Day-2 操作是直接 patch ClickHouseInstallation 字段：

# restart
kubectl -n altinity-lab patch chi altinity-proof \
  --type=merge \
  -p '{"spec":{"restart":"RollingUpdate"}}'

# stop / start
kubectl -n altinity-lab patch chi altinity-proof \
  --type=merge \
  -p '{"spec":{"stop":"1"}}'

kubectl -n altinity-lab patch chi altinity-proof \
  --type=merge \
  -p '{"spec":{"stop":"0"}}'

# scale-in: 2 -> 1
kubectl -n altinity-lab patch chi altinity-proof \
  --type=merge \
  -p '{"spec":{"configuration":{"clusters":[{"name":"s1","layout":{"replicasCount":1}}]}}}'

kubectl -n altinity-lab get chi altinity-proof -w
kubectl -n altinity-lab get pod

官方 Operator 的 scale-in 和 volume expansion 也通过 patch CR 完成：

# scale-in: 2 -> 1
kubectl -n ch-operator-lab patch clickhousecluster official-clickhouse-s1 \
  --type=merge \
  -p '{"spec":{"replicas":1}}'

# volume expansion
kubectl -n ch-operator-lab patch clickhousecluster official-clickhouse-s1 \
  --type=merge \
  -p '{"spec":{"dataVolumeClaimSpec":{"resources":{"requests":{"storage":"30Gi"}}}}}'

kubectl -n ch-operator-lab get clickhousecluster official-clickhouse-s1 -w
kubectl -n ch-operator-lab get pod,pvc

三条路线最显著的接口差异是：KubeBlocks 把 Day-2 入口集中到 OpsRequest；Altinity 主要通过 patch ClickHouseInstallation 自身字段完成运维动作；官方 Operator 以 patch ClickHouseCluster 为主，但原生字段暴露不如 Altinity 直接。

已有的 Day-2 耗时数据如下：

能力	KubeBlocks	Altinity	官方 Operator
水平 / 拓扑变更入口	`OpsRequest`	patch `ClickHouseInstallation`	patch `ClickHouseCluster`
重启入口	`OpsRequest`	patch `spec.restart=RollingUpdate`	无原生入口
Stop / Start 入口	`OpsRequest`	patch `spec.stop=1/0`	无原生入口
Restart 耗时	`~31s`	`~34s`	不适用
Stop 耗时	`~11s`	`~13s`	不适用
Start 耗时	`~31s`	`~52s`	不适用
Volume expansion 入口	`VolumeExpansion OpsRequest`	patch `spec.templates.volumeClaimTemplates[*].spec.resources.requests.storage`	patch `spec.dataVolumeClaimSpec.resources.requests.storage`
Volume expansion 耗时	`~28s`	`~62s`	`~41s`
Scale-in 入口	`HorizontalScaling OpsRequest`（`componentName=clickhouse, shards=1`）	patch `ClickHouseInstallation.replicasCount`	patch `ClickHouseCluster.replicas`
Scale-in 耗时	`~4s` 内 `OpsRequest` 收敛到 `Succeed`，额外 shard `clickhouse-qdm` 被移除，Cluster 保持 `Running`	`~6s` 内 CHI status 从 `hosts=2` 缩到 `hosts=1`；最终单副本收敛受 controller 恢复过程影响，不硬写单一总耗时	`~6s` 内只剩单个 ClickHouse pod，约 `46s` 回到 `Ready=True`
进度跟踪	`OpsRequest`	`ClickHouseInstallation.status` + controller 事件	`KeeperCluster` / `ClickHouseCluster.status` + controller 事件

4.4 参数配置

参数配置不进入本轮主结论矩阵。三条路线都可以通过各自 CR 或配置文件表达参数，但动态参数变更涉及在线生效范围、重启边界和回滚路径，单独展开会比这篇文章更长。因此，这里只把它作为后续深挖项，不作为本轮选型判断的决定性指标。

4.5 TLS

KubeBlocks 的 TLS 已验证通过。在 chs-tls-fix 上，用 user-provided 证书和 1Gi 内存重新验证后，集群持续 Running。Pod 内执行 clickhouse-client --host localhost --port 9440 --secure --user admin --password password123 登录成功，返回 25.9.7.56 / admin。

TLS 验证命令如下：

kubectl -n clickhouse-lab get cluster chs-tls-fix
kubectl -n clickhouse-lab get secret chs-tls-fix-clickhouse-tls-certs

TLS_POD=$(kubectl -n clickhouse-lab get pod \
  -l app.kubernetes.io/instance=chs-tls-fix \
  --no-headers | awk '/clickhouse/ {print $1; exit}')

kubectl -n clickhouse-lab exec -it "${TLS_POD}" \
  -c clickhouse -- clickhouse-client \
  --host localhost \
  --port 9440 \
  --secure \
  --user admin \
  --password password123 \
  --query "SELECT version(), currentUser()"

Altinity 的 TLS 也已验证通过。altinity-proof-s1 通过 configuration.files 挂载证书，并启用 tcp_port_secure: 9440 / https_port: 8443。Pod 内执行 clickhouse-client --secure --accept-invalid-certificate --port 9440 --user user1 --password qwerty 登录成功，返回 25.9.7.56 / user1。

kubectl -n altinity-lab get chi altinity-proof

kubectl -n altinity-lab exec -it chi-altinity-proof-s1-standalone-0-0-0 \
  -c clickhouse -- clickhouse-client \
  --secure \
  --accept-invalid-certificate \
  --port 9440 \
  --user user1 \
  --password qwerty \
  --query "SELECT version(), currentUser()"

官方 Operator 拿到了一组可用的 TLS 证据：在已稳定运行的 official-clickhouse-s1 上开启 TLS，复用 keeper identity 和 cluster secret，手工创建证书 Secret 后重新收敛到 Ready=True。Pod 内执行 clickhouse-client --secure --accept-invalid-certificate --port 9440 登录成功，返回 25.9.7.56。

kubectl -n ch-operator-lab get secret official-clickhouse-tls
kubectl -n ch-operator-lab get clickhousecluster official-clickhouse-s1

kubectl -n ch-operator-lab exec -it official-clickhouse-s1-clickhouse-0-0-0 \
  -- clickhouse-client \
  --secure \
  --accept-invalid-certificate \
  --port 9440 \
  --query "SELECT version()"

4.6 Backup / Restore

KubeBlocks 的 backup / restore 已完成数据级闭环验证。前提方面，VolumeSnapshot* CRD、snapshot-controller、默认 VolumeSnapshotClass、kubeblocks-dataprotection、对象存储 CSI、StorageProvider/minio、minio-cluster 和 minio-clickhouse-backuprepo 都已补齐。

standalone full backup kb-clickhouse-standalone-full-backup 已完成。数据恢复验证继续使用 kb-clickhouse-standalone 作为 source，在 restore_proof.rows_v1 中写入固定 5 行，再执行 full backup chs-proof-b1 并恢复到 chs-proof-r1。

测试数据写入和备份 CR 创建过程如下：

SRC_POD=$(kubectl -n clickhouse-lab get pod \
  -l app.kubernetes.io/instance=kb-clickhouse-standalone \
  --no-headers | awk '/clickhouse/ {print $1; exit}')

kubectl -n clickhouse-lab exec -it "${SRC_POD}" \
  -c clickhouse -- clickhouse-client \
  --user admin --password password123 \
  --multiquery --query "
    CREATE DATABASE IF NOT EXISTS restore_proof;
    DROP TABLE IF EXISTS restore_proof.rows_v1;
    CREATE TABLE restore_proof.rows_v1
    (
      id UInt64,
      value String
    )
    ENGINE = MergeTree
    ORDER BY id;
    INSERT INTO restore_proof.rows_v1 VALUES
      (1, 'a'), (2, 'b'), (3, 'c'), (4, 'd'), (5, 'e');
    SELECT count(), sum(id), groupArray((id, value)) FROM restore_proof.rows_v1;
  "

apiVersion: dataprotection.kubeblocks.io/v1alpha1
kind: Backup
metadata:
  name: chs-proof-b1
  namespace: clickhouse-lab
spec:
  backupMethod: full
  backupPolicyName: kb-clickhouse-standalone-clickhouse-backup-policy
  deletionPolicy: Delete

kubectl apply -f chs-proof-b1.yaml
kubectl -n clickhouse-lab get backup chs-proof-b1 -w
kubectl -n clickhouse-lab describe backup chs-proof-b1

恢复流程中的 preparedata 和 postready 都进入 Completed，restore cluster 进入 Running，admin 登录验证成功。source 和 restore 两边对 restore_proof.rows_v1 的校验结果完全一致：count()=5、sum(id)=15，groupArray((id, value)) 也完全相同。

恢复集群通过 restore annotation 创建：

apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:
  name: chs-proof-r1
  namespace: clickhouse-lab
  annotations:
    kubeblocks.io/restore-from-backup: '{"clickhouse":{"name":"chs-proof-b1","namespace":"clickhouse-lab","volumeRestorePolicy":"Parallel"}}'
spec:
  clusterDef: clickhouse
  topology: standalone
  terminationPolicy: Delete
  shardings:
    - name: clickhouse
      shards: 1
      template:
        name: clickhouse
        componentDef: clickhouse-1
        replicas: 1
        systemAccounts:
          - name: admin
            secretRef:
              name: chs-proof-r1-account
              namespace: clickhouse-lab
        resources:
          requests:
            cpu: "500m"
            memory: 1Gi
          limits:
            cpu: "500m"
            memory: 1Gi
        volumeClaimTemplates:
          - name: data
            spec:
              accessModes: [ReadWriteOnce]
              resources:
                requests:
                  storage: 20Gi
---
apiVersion: v1
kind: Secret
metadata:
  name: chs-proof-r1-account
  namespace: clickhouse-lab
type: Opaque
data:
  password: cGFzc3dvcmQxMjM=

kubectl apply -f chs-proof-r1.yaml
kubectl -n clickhouse-lab get restore -w
kubectl -n clickhouse-lab get cluster chs-proof-r1 -w

RESTORE_POD=$(kubectl -n clickhouse-lab get pod \
  -l app.kubernetes.io/instance=chs-proof-r1 \
  --no-headers | awk '/clickhouse/ {print $1; exit}')

kubectl -n clickhouse-lab exec -it "${RESTORE_POD}" \
  -c clickhouse -- clickhouse-client \
  --user admin --password password123 \
  --query "SELECT count(), sum(id), groupArray((id, value)) FROM restore_proof.rows_v1"

TLS 场景也做了同样的数据级闭环：TLS 源集群写入 tls_restore.rows_v1 后，full backup rtls-b3 完成，恢复到独立 TLS 目标集群 rtls-r。恢复端查询结果与源端一致：count()=5、sum(id)=15，5 行样本数据完全匹配。

kubectl -n clickhouse-lab get backup rtls-b3
kubectl -n clickhouse-lab get cluster rtls-r

kubectl -n clickhouse-lab exec -it rtls-r-clickhouse-phs-0 \
  -c clickhouse -- clickhouse-client \
  --secure \
  --accept-invalid-certificate \
  --host 127.0.0.1 \
  --port 9440 \
  --user admin \
  --password password123 \
  --query "SELECT count(), sum(id) FROM tls_restore.rows_v1"

需要保留的边界是：恢复流程会派生一些 Kubernetes 资源名和 label，集群名、备份名、恢复名过长时可能触发长度限制，需要通过命名规范来规避。就本轮结论而言，KubeBlocks 已经完成普通路径和 TLS 路径的数据级恢复闭环。

Altinity 也完成了数据级闭环验证。

altinity-proof-s1 对接同一套 MinIO 备份仓库，在 altinity_proof.rows_v1 写入 5 行固定数据后执行备份，远端备份列表显示 altinity-proof-b1 已上传，包含 all:10.54KiB,data:817B,arch:10.00KiB,meta:555B。

kubectl -n altinity-lab exec -it chi-altinity-proof-s1-standalone-0-0-0 \
  -c clickhouse -- clickhouse-client \
  --user user1 --password qwerty \
  --multiquery --query "
    CREATE DATABASE IF NOT EXISTS altinity_proof;
    DROP TABLE IF EXISTS altinity_proof.rows_v1;
    CREATE TABLE altinity_proof.rows_v1
    (
      id UInt64,
      value String
    )
    ENGINE = MergeTree
    ORDER BY id;
    INSERT INTO altinity_proof.rows_v1 VALUES
      (1, 'a'), (2, 'b'), (3, 'c'), (4, 'd'), (5, 'e');
    SELECT count(), sum(id) FROM altinity_proof.rows_v1;
  "

kubectl -n altinity-lab exec -it chi-altinity-proof-s1-standalone-0-0-0 \
  -c clickhouse-backup -- clickhouse-backup \
  create_remote -t altinity_proof.rows_v1 altinity-proof-b1

kubectl -n altinity-lab exec -it chi-altinity-proof-s1-standalone-0-0-0 \
  -c clickhouse-backup -- clickhouse-backup list remote

随后创建独立恢复集群 altinity-proof-r1，将 altinity-proof-b1 恢复到目标集群。最终恢复端查询结果与源端一致：count()=5、sum(id)=15，groupArray((id, value)) 也完全相同。

kubectl -n altinity-lab exec -it chi-altinity-proof-r1-standalone-0-0-0 \
  -c clickhouse-backup -- clickhouse-backup \
  download -t altinity_proof.rows_v1 altinity-proof-b1

kubectl -n altinity-lab exec -it chi-altinity-proof-r1-standalone-0-0-0 \
  -c clickhouse-backup -- clickhouse-backup \
  restore --schema --data --rm -t altinity_proof.rows_v1 altinity-proof-b1

kubectl -n altinity-lab exec -it chi-altinity-proof-r1-standalone-0-0-0 \
  -c clickhouse -- clickhouse-client \
  --user user1 --password qwerty \
  --query "SELECT count(), sum(id), groupArray((id, value)) FROM altinity_proof.rows_v1"

官方 Operator 在 v0.0.4 中暂未形成 backup / restore 数据级闭环。

4.7 Prometheus 监控

KubeBlocks 拿到了最小正向证据：集群原本没有 PodMonitor CRD，测试中从 Prometheus Operator 官方 v0.90.1 bundle 中提取并安装了 podmonitors.monitoring.coreos.com 这个 CRD，没有额外安装整套 Prometheus 栈。之后在 kb-clickhouse-standalone 上创建 PodMonitor，workload 的 http-metrics:8001/metrics 已成功返回 Prometheus 文本。

KubeBlocks workload metrics 的验证命令如下：

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: kb-clickhouse-pod-monitor
  namespace: clickhouse-lab
spec:
  podMetricsEndpoints:
    - path: /metrics
      port: http-metrics
      scheme: http
  namespaceSelector:
    matchNames:
      - clickhouse-lab
  selector:
    matchLabels:
      app.kubernetes.io/instance: kb-clickhouse-standalone

kubectl apply -f kb-clickhouse-pod-monitor.yaml
kubectl -n clickhouse-lab get podmonitor kb-clickhouse-pod-monitor

METRICS_POD=$(kubectl -n clickhouse-lab get pod \
  -l app.kubernetes.io/instance=kb-clickhouse-standalone \
  --no-headers | awk '/clickhouse/ {print $1; exit}')

kubectl -n clickhouse-lab port-forward "pod/${METRICS_POD}" 8001:8001
curl -s localhost:8001/metrics | head

Altinity 的 Prometheus 监控已验证。PodMonitor/altinity-operator-pod-monitor 创建成功，altinity-clickhouse-operator-metrics:9999/metrics 已返回 Prometheus 文本；上游 README 和文档也给出了 ClickHouse workload metrics 路线。

kubectl -n altinity-lab get podmonitor altinity-operator-pod-monitor
kubectl -n altinity-lab port-forward deploy/altinity-clickhouse-operator 9999:9999
curl -s localhost:9999/metrics | head

官方 Operator 也完成了 Prometheus 验证：PodMonitor/official-clickhouse-pod-monitor 创建成功，official-clickhouse-s1 workload 的 :9363/metrics 可抓，controller 自身的 clickhouse-operator-metrics-service:8080/metrics 也已返回 Prometheus 文本。

kubectl -n ch-operator-lab get podmonitor official-clickhouse-pod-monitor
kubectl -n ch-operator-lab port-forward pod/official-clickhouse-s1-clickhouse-0-0-0 9363:9363
curl -s localhost:9363/metrics | head

kubectl -n clickhouse-operator-system port-forward \
  service/clickhouse-operator-metrics-service 8080:8080
curl -s localhost:8080/metrics | head

五、综合对比

下表只比较三条自建路线。ClickHouse Cloud 是托管服务，不参与自建功能对比。

功能	KubeBlocks	Altinity	官方 Operator
控制面安装	已验证	已验证	已验证
Standalone 创建	已验证	已验证	不支持
Keeper-backed 创建	已验证	已验证	已验证
登录验证	已验证	已验证	已验证
Replicated 样本	已验证	已验证	已验证
Restart / Stop / Start	已验证	已验证	无原生入口
Volume expansion	已验证	已验证	已验证
TLS	已验证	已验证	已验证
Backup / Restore	已验证	已验证	暂未形成闭环
PodMonitor / Metrics	已验证	已验证	已验证
Day-2 scale	已验证	已验证	已验证
HA switchover	已验证	不支持	不支持

这张表看的是各方案在本轮评测中的最终结论，不表示三条路线在每一项上的证据强度完全一样。比如，KubeBlocks 和 Altinity 都完成了数据级恢复验证，但两者暴露给用户的入口和自动化程度并不完全相同。

方案	证据强度	关键词摘要	主要风险	最终判断
KubeBlocks	高	install、双拓扑、SQL、restart、stop/start、扩容、switchover、TLS、监控、backup / restore	恢复相关资源命名需要控制长度	本轮测试范围内证据覆盖最完整；backup / restore 已做数据级校验；keeper switchover 与 Day-2 scale 已验证
Altinity	中	install、standalone、keeper、replicated、scale-in、restart、stop/start、扩容、TLS、Prometheus、backup / restore	本轮基于 `0.25.6` 验证，后续版本仍值得跟踪	standalone 和 keeper-backed 使用路径都已成立；TLS 和 Prometheus 已验证通过；backup / restore 已做数据级校验
官方 Operator	中	install、keeper、replicated、scale-in、扩容、TLS、workload metrics	项目发布时间很短；当前 release 要求 `keeperClusterRef`	keeper-backed 使用路径已成立；TLS / metrics 已验证；standalone 在当前 API 下不成立

从现有证据看，三条路线的差异可以压缩成三句话：

KubeBlocks 的覆盖面最广，backup / restore 是平台侧 API 闭环。
Altinity 的 standalone 和 keeper-backed 路线都能真实工作，TLS 和备份恢复也已验证通过。
官方 Operator 拿到了 keeper-backed、TLS 和 metrics 的正向证据，但项目仍处在早期，Day-2 API 和 backup / restore 路线还不够完整。

六、什么场景选什么？

先看速查表：

你的情况	推荐优先评估
多数据库统一平台 + 需要平台侧 backup / restore API	KubeBlocks
ClickHouse 专项团队 + 接受 patch 风格运维	Altinity
偏好上游语义 + 看重 TLS / metrics	官方 Operator
不想自建，只关心托管	ClickHouse Cloud

如果你要的是一条覆盖面最完整、接口最统一、最像平台产品的自建路线，优先评估 KubeBlocks。它最大的优势不是“最早验证通过”，而是 backup / restore 已经通过平台侧 API 拿到数据级闭环，restart、stop/start、volume expansion、监控等能力也都完成了验证。

如果你是 ClickHouse 专项团队，接受以 ClickHouseInstallation 为中心的 CR 模型，并且更看重 patch 风格 Day-2 动作，Altinity 已经进入值得认真评估的区间。它的问题不在 keeper-backed 基线，也不在 TLS 或备份恢复能力；主要保留在统一平台入口和跨数据库运维抽象上。

如果你更偏好上游语义，同时看重 TLS / metrics 这两条线，官方 Operator 已经具备继续深挖的价值。当前需要注意的是：项目发布时间还很短，release 仍停在 v0.0.x，standalone 在当前 API 下不成立，整体能力还在快速补齐阶段。

ClickHouse Cloud 应该被看作托管路线，而不是“另一个更省事的 Operator”。更合适的比较方式，是把它放在“托管 vs 自建”的框架里单独分析，而不是放进这篇自建路线评测的同一套功能矩阵里。

七、结语

截至 2026 年 4 月，三条自建路线都拿到了真实业务层验证。本文不想把问题简化成“谁第一、谁第二”，更准确的结论是：每条路线都已经有可用部分，但证据强度、接口形态和生产覆盖面不同。

KubeBlocks 在本文测试范围内覆盖面最完整。双拓扑、SQL、restart、stop/start、扩容、switchover、监控和 backup / restore 都已拿到直接证据，其中 backup / restore 做到了数据级闭环，TLS 也已完成验证。

Altinity 和官方 Operator 不能简单归为“并列第二”。Altinity 的 patch 风格 Day-2 动作、TLS、Prometheus 和备份恢复都已经拿到正向证据；它的主要保留是统一平台入口和跨数据库运维抽象不如 KubeBlocks 完整。官方 Operator 已经验证 keeper-backed、TLS 和 metrics，但项目太新，standalone 也不在当前 API 边界内。

现在能成立的判断是：KubeBlocks 在本文场景里证据最完整；Altinity 和官方 Operator 都已经进入可用区间，但不能把“可用区间”直接写成同一强度的支持结论。backup / restore 仍然是三条路线差异最大的功能项，差异不只在能不能恢复数据，也在恢复入口、自动化程度和平台化程度。

测试时间：2026 年 4 月参考：KubeBlocks 文档 / Altinity Operator GitHub / ClickHouse 官方 Operator GitHub

开源仓库：github.com/apecloud/ku…

详细文档和快速开始指南：kubeblocks.com/addons/clic…