实测对比：哪款开源 Kubernetes MySQL Operator 最值得用？（2026 深度评测）

本文基于作者在 AWS EKS 上对四款 MySQL Operator 的真实部署与测试，覆盖集群搭建、高可用切换、弹性扩缩容、动态参数、TLS 等维度，适合正在评估 MySQL Kubernetes 方案的工程师参考。

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

过去两年，越来越多的团队开始将 MySQL 从虚拟机迁移到 Kubernetes。驱动力很直接：统一的基础设施管控、更快的弹性扩容、以及 GitOps 风格的声明式运维。

但随之而来的问题是：MySQL Operator 怎么选？

我们决定不依赖文档和宣传材料，而是直接在 AWS EKS 上把四款 Operator 都装起来跑一遍，看看实际表现如何。整个测试过程没有提前准备 runbook——我们用 Claude Code 直接检索各 Operator 的官方文档和 GitHub README，让它帮助理解 CRD 结构和部署步骤，然后在集群上实际执行。这种方式最接近一个新团队"第一次上手"的真实体验，也更容易暴露文档缺失和 API 设计问题。

测试环境：

• 平台：AWS EKS，Kubernetes v1.31.14
• 节点：3 个 m5.xlarge（4 vCPU / 16 GiB RAM）
• 时间：2026 年 4 月

测试对象：

测试维度包括了SRE/DBA 常用的 17 项功能矩阵，包括：拓扑支持、高可用 RTO、弹性扩缩容、动态参数、TLS、Prometheus 监控等。

二、部署实录：门槛差异明显

我们的测试方式是：用 Claude Code 实时检索各 Operator 的官方文档和 GitHub README，读懂 CRD 结构后直接在集群上操作，遇到报错就地排查。这样的测试更接近一个新团队"第一次上手"的真实体验。以下是各 Operator 完整的部署实录。

KubeBlocks（总耗时：约 5 分钟）

KubeBlocks 通过 Helm 安装控制平面，MySQL addon 单独启用：

1helm repo add kubeblocks https://apecloud.github.io/helm-charts
2helm install kubeblocks kubeblocks/kubeblocks \
3  --namespace kb-system --create-namespace
4
5kbcli addon enable mysql
6

创建集群使用统一的 Cluster CRD：

1apiVersion: apps.kubeblocks.io/v1
2kind: Cluster
3metadata:
4  name: kb-mysql
5  namespace: kb-mysql-test
6spec:
7  terminationPolicy: WipeOut
8  componentSpecs:
9    - name: mysql
10      componentDef: "mysql-8.0"   # 半同步主从；MGR 改为 "mysql-mgr-8.0"
11      serviceVersion: "8.0.35"
12      replicas: 3
13      resources:
14        limits:
15          cpu: "500m"
16          memory: "1Gi"
17        requests:
18          cpu: "500m"
19          memory: "1Gi"
20      volumeClaimTemplates:
21        - name: data
22          spec:
23            accessModes: [ReadWriteOnce]
24            resources:
25              requests:
26                storage: 20Gi
27

实测体验：集群 3 分钟内就绪，所有密钥自动生成，连接信息通过 Secret 获取：

1kubectl get secret kb-mysql-mysql-account-root -n kb-mysql-test \
2  -o jsonpath='{.data.password}' | base64 -d
3

Percona ps-operator（总耗时：约 90 分钟，含多次重装）

第一波：Helm Chart 版本找不到

Claude Code 根据文档最初尝试：

1helm install percona-op percona/ps-operator --version 0.9.0
2

报错：Error: chart "ps-operator" matching 0.9.0 not found。文档版本和实际 Chart 版本对不上。检索后发现正确的 Chart 是 percona/ps-operator（不带版本号，最新稳定版 1.0.0），另外数据库实例需要用单独的 percona/ps-db Chart，operator 和实例是分开安装的。

第二波：MGR 副本数校验失败 + orchestrator 必填字段

第一次尝试部署了 2 副本：

1helm install percona-db percona/ps-db \
2  --set mysql.clusterType=group-replication \
3  --set mysql.size=2
4

CRD webhook 直接拒绝：

1The PerconaServerMySQL "percona-db" is invalid:
2spec.mysql.size: Invalid value: 2: must be >= 3 for group-replication
3

MGR 模式要求至少 3 个节点（奇数）。改成 size=3 后重试，operator 又报：

1orchestrator.size is required when orchestrator.enabled=true
2

文档里 orchestrator 部分写的是可选，但实际 v1.0.0 版本的 CRD 校验把它列为必填。补上 --set orchestrator.enabled=true --set orchestrator.size=1 后通过校验。

第三波：OOMKill 导致 datadir 损坏，被迫重装

Pod 起来后 MySQL 容器反复 OOMKill：

1Last State: Terminated  Reason: OOMKilled
2

依次尝试了 512Mi → 1Gi，都 OOMKill。根本原因：MySQL 8.4 + MGR 协议的内存开销显著高于普通主从，实测至少需要 2Gi 才能稳定启动。

但升到 2Gi 后发现 StatefulSet 的 resource limit 没更新（Helm upgrade 没有触发 Pod 重建），需要手动 force-delete：

1kubectl delete pod percona-db-ps-db-mysql-0 -n percona-test --force
2

此时又发现之前 OOMKill 发生在 MySQL 初始化阶段，导致 datadir 写了一半，Pod 重建后进入 crash loop。必须彻底清除数据：

1helm uninstall percona-db -n percona-test
2kubectl delete pvc --all -n percona-test
3

从零重装，指定 2Gi 内存，约 8 分钟后三个 Pod 全部 2/2 Running，MGR 成员状态正常：

1MEMBER_HOST                                           MEMBER_STATE  MEMBER_ROLE
2percona-db-ps-db-mysql-0.percona-db-ps-db-mysql...   ONLINE        PRIMARY
3percona-db-ps-db-mysql-1.percona-db-ps-db-mysql...   ONLINE        SECONDARY
4percona-db-ps-db-mysql-2.percona-db-ps-db-mysql...   ONLINE        SECONDARY
5

最终可用的安装命令：

1helm repo add percona https://percona.github.io/percona-helm-charts
2helm install percona-op percona/ps-operator -n percona-test --create-namespace
3
4helm install percona-db percona/ps-db \
5  --set mysql.clusterType=group-replication \
6  --set mysql.size=3 \
7  --set mysql.resources.limits.memory=2Gi \
8  --set mysql.resources.requests.memory=2Gi \
9  --set orchestrator.enabled=true \
10  --set orchestrator.size=1 \
11  -n percona-test
12

Oracle 官方 Operator（总耗时：约 40 分钟）

安装分两步：operator 和 InnoDBCluster 实例。

1helm repo add mysql-operator https://mysql.github.io/mysql-operator/
2helm install mysql-op mysql-operator/mysql-operator -n oracle-test --create-namespace
3
4# 先创建 root 密码 Secret
5kubectl create secret generic oracle-mysql-secret \
6  --from-literal=rootPassword="MyP@ssw0rd" \
7  -n oracle-test
8
9kubectl apply -f - <<EOF
10apiVersion: mysql.oracle.com/v2
11kind: InnoDBCluster
12metadata:
13  name: oracle-mysql
14  namespace: oracle-test
15spec:
16  secretName: oracle-mysql-secret
17  tlsUseSelfSigned: true
18  instances: 3
19  router:
20    instances: 1
21  version: "9.6.0"
22EOF
23

遇到的问题：Router Pod 风暴

InnoDBCluster 创建后，Router Deployment 进入快速 crash/restart 循环。原因是 MySQL 实例还在初始化，Router 无法连接，每次失败后 Kubernetes 快速重启，加上 Router 镜像本身较大，节点磁盘被多个并发拉取的镜像塞满，触发 DiskPressure，进而把其他 Pod 驱逐出去。高峰时 oracle-test namespace 下出现了 25 个 Router Pod 同时存在（大部分处于 Failed/Evicted 状态）。

手动清理失败的 Pod：

1kubectl delete pods -n oracle-test \
2  --field-selector=status.phase=Failed
3

清理后等待 MySQL 实例初始化完成（约 15 分钟），Router 自然稳定在 1 个。整个集群就绪大约需要 25 分钟。

文档体验：Oracle 官方文档比较完整，CRD 字段清晰，Claude Code 能直接读懂并生成正确的 YAML，没有遇到字段校验类的报错。

Bitpoke MySQL Operator（总耗时：约 8 分钟）

Bitpoke的部署比较顺利：

1helm repo add bitpoke https://helm-charts.bitpoke.io
2helm install bitpoke-op bitpoke/mysql-operator -n bitpoke-test --create-namespace
3
4# 先创建 root 密码 Secret
5kubectl create secret generic bitpoke-mysql-secret \
6  --from-literal=ROOT_PASSWORD="Test@1234!" \
7  -n bitpoke-test
8
9kubectl apply -f - <<EOF
10apiVersion: mysql.presslabs.org/v1alpha1
11kind: MysqlCluster
12metadata:
13  name: bitpoke-mysql
14  namespace: bitpoke-test
15spec:
16  replicas: 3
17  secretName: bitpoke-mysql-secret
18  mysqlVersion: "8.0"
19  podSpec:
20    resources:
21      limits:
22        cpu: "500m"
23        memory: "512Mi"
24EOF
25

约 5 分钟，3 个 Pod（每个 4 容器：mysql、sidecar、metrics-exporter、pt-heartbeat）全部就绪。512Mi 内存完全够用（无 MGR 协议开销）。

遇到的问题：无明显报错。唯一注意点是 Bitpoke 的 Secret 字段名是 ROOT_PASSWORD（全大写），和其他 Operator 的 rootPassword 不同，文档里有说明。

文档体验：GitHub README 比较简洁，核心字段一目了然。不过部分高级功能（如 Orchestrator 参数调优）没有详细说明，需要看源码。

三、功能实测结果

3.1 拓扑支持

这一项最重要的结论在于 Percona ps-operator 和 Oracle 的拓扑选择是锁死的，不是我们事先预期的。

Percona ps-operator v1.0 只支持 MGR（clusterType=group-replication），传统半同步主从根本没有入口——我们尝试用 clusterType=semisync 创建，CRD webhook 直接拒绝。值得注意的是，Percona 其实有两款 MySQL Operator：ps-operator（对应 Percona Server）和 pxc-operator（对应 Percona XtraDB Cluster），两者功能差异很大，文档里容易混淆，选型前一定要确认自己用的是哪一款。Oracle 同理，InnoDB Cluster 和 MGR 是绑定的，没有其他选择。

Bitpoke 则相反，只有异步/半同步主从 + Orchestrator，MGR 完全不在支持范围内。

KubeBlocks 是四款里唯一能在同一套 CRD 下切换拓扑的——componentDef 填 mysql-8.0 是半同步，填 mysql-mgr-8.0 就是 MGR，API 不变，只改一个字段。

3.2 高可用切换 RTO（实测）

测试方法统一：写入测试数据后 kubectl delete pod <primary> 强制删除主节点，脚本轮询其他节点角色，记录从指令发出到新主可写的时间。每款测了 2 次，取平均值。

KubeBlocks 和 Percona 并列最快，主要得益于共识机制内置，选举和高可用切换不依赖外部组件。Oracle 慢 3 秒是因为 MySQL Router 在 MGR 选出新主后还需要额外时间刷新路由表，从客户端视角看延迟更长。

Bitpoke 的 13 秒则是 Orchestrator 架构的固有成本：Orchestrator 需要等心跳超时才能确认主节点宕机，这个窗口默认是几秒到十几秒。Bitpoke 文档里对这个延迟没有特别说明，实际生产中要根据业务对 RPO/RTO 的要求仔细评估。

3.3 弹性扩缩容

KubeBlocks 用 OpsRequest 声明式触发，apply 后可以 watch OpsRequest 的 status 跟进进度：

1apiVersion: operations.kubeblocks.io/v1alpha1
2kind: OpsRequest
3metadata:
4  name: mysql-scale-out
5  namespace: kb-mysql-test
6spec:
7  clusterName: kb-mysql
8  type: HorizontalScaling
9  horizontalScaling:
10    - componentName: mysql
11      scaleOut:
12        replicaChanges: 1
13

1$ kubectl apply -f scale-out.yaml
2$ kubectl get opsrequest mysql-scale-out -n kb-mysql-test -w
3NAME             TYPE                STATUS     AGE
4mysql-scale-out  HorizontalScaling   Running    8s
5mysql-scale-out  HorizontalScaling   Succeed    42s
6
7$ kubectl get pods -n kb-mysql-test
8kb-mysql-mysql-0   3/3   Running   0   85m
9kb-mysql-mysql-1   3/3   Running   0   3m
10kb-mysql-mysql-2   3/3   Running   0   80m
11kb-mysql-mysql-3   3/3   Running   0   38s   # 新副本
12

Oracle 直接 patch spec.instances，operator 自动处理 MGR 成员加入：

1$ kubectl patch innodbcluster oracle-mysql -n oracle-test \
2    --type=merge -p '{"spec":{"instances":4}}'
3
4$ kubectl get innodbcluster oracle-mysql -n oracle-test
5NAME           STATUS   ONLINE   INSTANCES
6oracle-mysql   ONLINE   4        4          # 约 3 分钟后 4 节点全部 ONLINE
7

Bitpoke 同样 patch CRD 即可，无需额外操作。

Percona 实测有问题：patch mysql.size=4 后命令无响应（no change），MGR 状态始终维持在 3 节点。可能与 MGR 成员管理机制有关，operator 在某些状态下会拒绝变更，但没有明确的错误提示，排查体验较差。

3.4 动态参数调整

我们用修改 max_connections 作为标准测试用例。OpsRequest 在 12 秒内返回 Succeed，配置写入了 /etc/mysql/conf.d/my.cnf。

1apiVersion: operations.kubeblocks.io/v1alpha1
2kind: OpsRequest
3metadata:
4  name: kb-mysql-reconfig
5  namespace: kb-mysql-test
6spec:
7  clusterName: kb-mysql
8  type: Reconfiguring
9  reconfigures:
10    - componentName: mysql
11      parameters:
12        - key: max_connections
13          value: "600"
14

1$ kubectl get opsrequest kb-mysql-reconfig -n kb-mysql-test
2NAME              TYPE            STATUS    AGE
3kb-mysql-reconfig Reconfiguring   Succeed   12s
4

Bitpoke 通过 spec.mysqlConf 写入。

1$ kubectl patch mysqlcluster bitpoke-mysql -n bitpoke-test \
2    --type=merge -p '{"spec":{"mysqlConf":{"max_connections":"600"}}}'
3
4# 等待滚动重启完成后验证
5$ mysql -e "SHOW VARIABLES LIKE 'max_connections';"
6max_connections  600   # ✅ 生效
7

Percona 将 my.cnf 片段写入 spec.mysql.configuration，需要 Pod 滚动重启才生效。Oracle 支持在 spec.mycnf 写入配置，同样需要重启，且无进度跟踪。

3.5 TLS 支持

四款 Operator 均内置 TLS，进 MySQL 验证：

1# 以 KubeBlocks 为例
2$ kubectl exec -n kb-mysql-test kb-mysql-mysql-0 -c mysql -- \
3    mysql -uroot -p"$PW" -e "SHOW VARIABLES LIKE 'have_ssl';"
4Variable_name  Value
5have_ssl       YES
6
7# Percona 的证书挂载路径
8$ mysql -e "SHOW VARIABLES LIKE 'ssl_ca';"
9Variable_name  Value
10ssl_ca         /etc/mysql/mysql-tls-secret/ca.crt
11

Oracle 在 InnoDBCluster spec 里指定 tlsUseSelfSigned: true，自动颁发自签名证书，无需手动管理 Secret。四款均通过 TLS 验证。

3.6 备份与 PITR

备份能力通过查文档 + 验证 CRD 和容器配置完成（未逐一触发完整备份流程）。

Oracle 官方 Operator 是这里最明显的短板：不支持 XtraBackup，也没有 Binlog 流式归档，PITR 完全缺失。如果发生误删数据，只能恢复到最近一次全量备份时间点，RPO 取决于备份频率。其余三款均支持 XtraBackup 物理备份 + Binlog 归档 + 对象存储，PITR 能力完整。

3.7 Prometheus 监控

查各 Pod 的容器列表是最直接的方式：

1# KubeBlocks：mysql-exporter 自动注入
2$ kubectl get pod kb-mysql-mysql-0 -n kb-mysql-test \
3    -o jsonpath='{.spec.containers[*].name}'
4mysql  mysql-exporter  kbagent
5
6# Bitpoke：metrics-exporter 内置
7$ kubectl get pod bitpoke-mysql-mysql-0 -n bitpoke-test \
8    -o jsonpath='{.spec.containers[*].name}'
9mysql  sidecar  metrics-exporter  pt-heartbeat
10
11# Oracle：无 exporter sidecar
12$ kubectl get pod oracle-mysql-0 -n oracle-test \
13    -o jsonpath='{.spec.containers[*].name}'
14mysql  sidecar    # 没有 metrics 容器
15

Oracle 需要用户自行在 Pod 旁边部署 mysqld_exporter 并配置 ServiceMonitor，对于习惯开箱即用 Prometheus 集成的团队来说是额外工作。

3.8 Day-2 运维接口统一性

测完所有功能，感受最深的是各 Operator 操作界面的碎片化程度。

Percona 扩容改 spec.mysql.size，改参数改 spec.mysql.configuration，这两个动作 API 路径不一样，没有统一的状态跟踪。Oracle 的扩容和参数变更同样分散在不同字段。Bitpoke 情况类似。每个 Operator 都有自己的一套"方言"。

KubeBlocks 的 OpsRequest 是唯一一个把所有 Day-2 操作统一抽象的设计：

1# 水平扩容
2kubectl apply -f ops-hscale.yaml    # type: HorizontalScaling
3
4# 参数变更
5kubectl apply -f ops-reconfig.yaml  # type: Reconfiguring
6
7# 垂直扩容
8kubectl apply -f ops-vscale.yaml    # type: VerticalScaling
9
10# 统一查进度
11kubectl get opsrequest -n kb-mysql-test
12NAME              TYPE               STATUS    AGE
13mysql-scale-out   HorizontalScaling  Succeed   5m
14kb-mysql-reconfig Reconfiguring      Succeed   2m
15

所有操作都有明确的 STATUS 字段（Pending / Running / Succeed / Failed），可以在 CI/CD 流水线里直接 watch，不需要自己写轮询逻辑。而且同一套 OpsRequest 接口对所有数据库引擎都成立——MySQL 怎么扩容，PostgreSQL、Redis 就怎么扩容，API 格式完全一致。

四、综合对比

五、选型建议

选 Percona ps-operator，如果：

• 仅部署 MySQL，且确定使用 MGR 拓扑
• 团队深度依赖 Percona 技术栈（XtraBackup、PMM）
• 需要与 Percona 官方商业支持绑定

选 Oracle 官方 Operator，如果：

• 场景相对简单，只需 InnoDB Cluster（MGR）
• 希望使用 Oracle 官方支持的技术栈
• 不依赖 XtraBackup / PITR / Prometheus 等能力

选 Bitpoke，如果：

• 已有 Orchestrator 运维经验
• 不需要 MGR，只需传统异步主从
• 注意：2024 年后社区更新明显放缓

选 KubeBlocks，如果：

• 集群同时运行 MySQL、PostgreSQL、Redis 等多种数据库，希望统一运维接口
• 需要灵活切换拓扑（半同步、MGR、Orchestrator）
• 希望通过 OpsRequest 标准化 CI/CD 流水线中的数据库变更
• 团队规模不大，希望降低多数据库的学习和维护成本

六、总结与推荐

测完四款 Operator，我们的整体结论是：如果你只能选一款，选 KubeBlocks。

理由很直接：

1. 拓扑最全。 半同步主从、MGR、Orchestrator 三种拓扑通过同一套 Cluster CRD 覆盖，其他三款都各有缺失——Percona ps-operator 只有 MGR，Oracle 只有 InnoDB Cluster，Bitpoke 没有 MGR。

2. HA 切换最快。 实测 RTO ~4s，与 Percona 并列最短，比 Oracle（7s）和 Bitpoke（13s）都快。

3. Day-2 运维体验最好。 扩缩容、参数变更、备份恢复全部通过 OpsRequest 这一个 CRD 完成，接口统一、可审计、天然适合 GitOps。其他 Operator 要么靠 patch CRD 字段，要么靠 annotation，没有统一的操作层。

4. 备份能力最完整。 XtraBackup 物理备份 + WAL-G binlog 流式归档 + S3/OSS 对象存储，PITR 开箱即用。Oracle 官方 Operator 完全不支持 XtraBackup 和 PITR，这一项直接出局。

5. 多数据库统一管理。 这是 KubeBlocks 相对其他三款最本质的差异。如果你的集群同时跑 MySQL、PostgreSQL、Redis，学会 KubeBlocks 操作 MySQL，其他数据库的运维接口完全一致，不需要再学三套 CRD。

当然，每款 Operator 都有其适用场景：

• 只跑 MySQL，且确定用 MGR：Percona ps-operator 是成熟选择，但要做好 2Gi+ 内存规划和部署踩坑的准备
• 追求零部署门槛：Bitpoke 最容易上手，适合规模小、需求简单的团队，但社区活跃度已明显下降
• Oracle 官方 Operator：除非有特殊的合规或支持要求，否则备份能力的短板让它很难在生产环境中推荐

对于大多数在 Kubernetes 上认真运维数据库的团队，KubeBlocks 是目前综合能力最强、运维成本最低的选择。

详细文档和快速开始指南：kubeblocks.io/mysql-opera…

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

《实测对比：哪款开源 Kubernetes MySQL Operator 最值得用？（2026 深度评测）》 是转载文章，点击查看原文。