OpenKruise 不是 MySQL 高可用部署的适用工具，它专为无状态或弱状态工作负载设计，核心能力聚焦于增强型 Workload（如 CloneSet、AdvancedStatefulSet）、原地升级、批量发布等，不提供数据库集群编排、故障自动转移、组复制管理等功能。
OpenKruise 不是 MySQL 高可用部署的适用工具。
它专为无状态或弱状态工作负载设计，核心能力集中在增强型 CloneSet、AdvancedStatefulSet、原地升级、批量发布等场景，不提供数据库集群编排、故障自动转移、组复制管理、GTID 同步校验或备份生命周期控制等功能。
如果你在搜索“OpenKruise + MySQL”，大概率是混淆了两个事实：
-
OpenKruise是阿里开源的 Kubernetes 增强套件，解决的是通用 Pod 编排效率问题； - MySQL 在 Kubernetes 中实现高可用，依赖的是有状态协调逻辑——这必须由数据库专属控制器完成，比如
mysql-operator（PressLabs/Bitnami）或percona-server-operator。
为什么不能用 OpenKruise 替代 MySQL Operator？
-
AdvancedStatefulSet虽然支持有序发布、分区灰度、原地升级，但它不感知 MySQL 协议、不监听 binlog 位点、不介入 MGR/Group Replication 状态机、不执行STOP SLAVE/RESET MASTER等语句； - 它无法判断哪个 Pod 是 PRIMARY，也不能在主节点宕机后触发
SELECT GROUP_REPLICATION_SET_AS_PRIMARY()； - 所有基于
OpenKruise的 YAML 部署，最终只是多个独立运行的 MySQL 实例，彼此无拓扑关系，不构成集群，也不具备故障自愈能力。
如果你已经用了 OpenKruise，还能否部署高可用 MySQL？
可以，但必须分层协作：
- 用
AdvancedStatefulSet管理 Pod 生命周期（如滚动重启、节点亲和调度）； -
仍需单独部署
mysql-operator并创建MysqlClusterCR； -
mysql-operator负责注入 sidecar、初始化复制、监听group_replication_member_state、触发故障转移； -
AdvancedStatefulSet只负责“让 Pod 活着、按序启停”，不碰数据库逻辑。
此时你看到的 Pod 标签里会有：
-
app.kubernetes.io/managed-by: mysql-operator（表明数据库行为由 operator 控制） - 同时可能带
controller-revision-hash和pod-template-generation（来自AdvancedStatefulSet）
两者共存可行，但职责绝不能越界。
最容易被忽略的关键点
- Operator 必须运行在与
MysqlCluster相同 namespace 或已配置 RBAC 跨 ns 权限，否则 CR 创建后静默无 Pod； -
mysql-operator的 Pod 必须处于Running状态，且日志中出现Starting EventSource和Starting Controller，才代表它真正开始监听 CR； - 所有 MySQL Pod 的
server-id必须全局唯一且不可复用（Operator 通常通过 Pod 序号 + 偏移量生成），手动用CloneSet扩容会跳过该逻辑，导致复制中断； - 备份地址（如
s3://bucket/）必须提前验证 operator 有写权限，否则backupSchedule会失败且无明显报错。
别把调度器当数据库管家。MySQL 的高可用不在 Pod 数量，而在状态协同。
