helm 本身不部署“mysql集群”，它只按 chart 定义部署资源；所谓“集群”效果，完全取决于你选的 chart 类型和 values 配置是否触发了主从/innodb cluster 等高可用逻辑。
直接说结论：Helm 本身不部署“MySQL集群”，它只按 Chart 定义部署资源；所谓“集群”效果，完全取决于你选的 Chart 类型和 values 配置是否触发了主从/InnoDB Cluster 等高可用逻辑。
用 bitnami/mysql Chart 部署一主多从，必须改这 4 个 values
Bitnami 的 mysql Chart 默认是单节点（architecture: standalone），哪怕你设了 replicaCount: 2，也只是起两个互不通信的 MySQL 实例。要真正启用主从复制，以下字段缺一不可：
-
architecture: replication—— 不是standalone，也不是留空（默认就是standalone） -
auth.replicationUser和auth.replicationPassword—— 必须显式设置，不能复用rootPassword；否则 initContainer 会跳过复制初始化 -
primary.persistence.enabled: true且secondary.persistence.enabled: true—— 主从都需持久化，否则 Pod 重启后 binlog position 丢失，复制中断
漏掉任意一项，kubectl get pods 看起来正常，但 show slave status\G 会显示 Slave_IO_Running: No，日志里反复报 Access denied for user 'replicator'@'%' (using password: YES)。
storageClass 配置错误会导致 mysql-secondary-0 卡在 Pending
常见现象不是 PVC 绑定失败报错，而是 mysql-secondary-0 一直 Pending，或者进容器后发现 /var/lib/mysql 是空目录，接着报 Can't start server : Bind on unix socket: Permission denied。这不是 UID 权限问题，而是 PVC 没绑定成功，MySQL 启动时试图在空盘上初始化，触发了容器内 root 用户与数据目录权限冲突。
必须确保：
- 集群已存在支持
ReadWriteOnce的StorageClass（如nfs-client、ceph-rbd）；hostPath或localPV 在多节点场景下不可靠 -
primary.persistence.storageClass和secondary.persistence.storageClass显式指定同一名称，不要留空（留空可能 fallback 到不存在的default） - 该
StorageClass的allowVolumeExpansion: true已启用——后续扩容 PVC 时必需，否则kubectl patch pvc会静默失败
想真高可用？别用 bitnami/mysql，改用 mysql-operator
bitnami/mysql 的主从是静态拓扑：主挂了不会自动切从，从节点扩缩容需手动干预，也没有组复制或故障自愈能力。如果你需要 InnoDB Cluster、自动故障转移、声明式扩缩容，必须换路径：
- 安装的是
mysql-operator（如 PressLabs 或 Bitnami 提供的mysql-operatorChart），不是mysqlChart - 执行
helm install mysql-operator presslabs/mysql-operator --namespace=mysql-operator，等控制器 Pod 进入Running状态 - 再通过
MysqlCluster自定义资源（CR）部署集群，例如：instances: 3、tlsUseSelfSigned: true、secretName: mycluster-secret
这时候 helm install 只是装了个“司机”，真正开车的是 Operator 控制器；没这层，你所有 values 配置都只是在搭积木，不是建集群。
helm install 后连不上 MySQL？先查这三处
部署完执行 mysql -h mysql-test.default.svc.cluster.local -uroot -p$MYSQL_ROOT_PASSWORD 报 Access denied 或连接超时，优先检查：
- Secret 名称是否匹配：Chart 默认生成的 Secret 名是 release 名（如
mysql-test），不是 Chart 名；kubectl get secret确认是否存在 - Service 类型：
primary.service.type若设为NodePort或LoadBalancer，需确认节点端口是否开放、云厂商安全组是否放行 - Pod 就绪探针失败：进
mysql-primary-0查日志，若出现mysqld is alive but not ready，大概率是primary.extraFlags覆盖了默认项，丢了--log-bin；Bitnami 默认加了，但你若写extraFlags: ["--max-connections=500"]就会清空全部默认参数
最易被忽略的是：Operator 场景下，helm install 成功 ≠ MySQL 集群就绪；得等 kubectl get innodbclusters 出现 Ready 状态，且对应 StatefulSet 的所有 Pod 都 Running 并 Ready，才算真正可用。
