bitnami的mysql chart是目前最稳妥、适配最广、文档最全的生产级mysql helm部署方案，但必须关闭默认persistence.enabled=false，且不可跳过auth.rootpassword和存储类配置；stable/mysql已于2023年被helm官方归档弃用，镜像陈旧、缺乏tls等生产必需能力，而bitnami/mysql持续更新，支持mysql 8.0+、非root运行、initcontainer校验及architecture=replication主从自动部署。
直接说结论：用 Bitnami 的 mysql Chart 是目前最稳妥、适配最广、文档最全的生产级 MySQL Helm 部署方案，但必须关掉默认的 persistence.enabled=false，且不能跳过 auth.rootPassword 和存储类配置。
为什么不用 stable/mysql 而选 bitnami/mysql
stable/mysql 已在 Helm 3 中被官方归档弃用（2023 年起），其镜像基于老旧 Debian 9 + MySQL 5.7，缺乏 TLS、资源限制、就绪探针等生产必需能力。bitnami/mysql 则持续更新，支持 MySQL 8.0+、非 root 用户运行、initContainer 初始化校验、自动主从切换（architecture=replication）和 InnoDB Cluster 模式（需搭配 mysql-innodbcluster Chart）。关键差异包括：
-
stable/mysql的image默认拉取mysql:5.7，无安全加固；bitnami/mysql默认用docker.io/bitnami/mysql:8.4.x-debian-12-r0，启用mysql_native_password兼容旧客户端 -
bitnami/mysql的primary.service.type支持LoadBalancer+loadBalancerIP，而 stable 不支持显式 IP 绑定 - 当设置
architecture=replication时，bitnami 会自动生成primary和secondary两个子 chart，分别控制主从 Pod 的livenessProbe和readinessProbe行为
必须显式覆盖的 4 个关键 values
不改这 4 项，部署出来的 MySQL 基本不可用于生产：
-
auth.rootPassword：必须设强密码（如"K8sMysql@2026!"），否则 Helm 会自动生成随机 base64 字符串，导致后续无法登录；注意：该值不会明文写入 Secret，而是由 Helm 渲染进 Secret 对象 -
primary.persistence.storageClass：必须指定已存在的 StorageClass 名（如nfs-client或alicloud-disk-efficiency），不能留空或用默认值；若集群无动态供给器，需提前创建 PV/PVC 并设primary.persistence.existingClaim -
primary.service.type：默认ClusterIP，外部无法访问；生产环境应设为NodePort（测试）或LoadBalancer（云厂商） -
primary.resources：必须限制 CPU/Memory，例如{limits: {cpu: "1", memory: "2Gi"}, requests: {cpu: "500m", memory: "1Gi"}}；否则 MySQL Pod 可能因 OOM 被 K8s 杀死
主从部署时最容易踩的坑
用 architecture=replication 启动一主多从后，以下问题高频出现：
-
secondaryPod 卡在Init:0/1：大概率是主节点primary尚未 Ready，secondary 的 initContainer 会反复尝试连接mysql-primary:3306；检查kubectl get pods -l app.kubernetes.io/component=primary是否 Running - 从库同步中断，日志报
Got fatal error 1236 from master：说明 binlog 文件被主库清理，需确认primary.persistence.size是否足够（建议 ≥20Gi），并检查主库my.cnf中是否设置了expire_logs_days=7（bitnami 默认开启） - 应用连上
mysql-readService 却写入失败：因为mysql-read是轮询所有 Pod 的 ClusterIP Service，会把写请求路由到只读从库；必须严格区分连接地址：mysql-primary（读写）、mysql-read（只读） - Pod 重启后从库无法自动重连主库：bitnami 的 replication 模式依赖
MYSQL_MASTER_HOST环境变量，该变量由 StatefulSet 的 headless service DNS 自动生成（如mysql-primary-0.mysql-primary），若 DNS 解析慢或 CoreDNS 配置异常，会导致初始化失败
备份与监控不能靠 Helm 自动完成
Helm Chart 本身不提供定时备份或 Prometheus 监控集成，这两块必须手动补全：
- 备份：bitnami/mysql 提供了
extraEnvVars注入MYSQLDUMP_USER/MYSQLDUMP_PASSWORD，但 dump 脚本需自己写 CronJob，挂载backup-pvc并调用mysqldump --all-databases；推荐用 Velero + restic 做 PVC 级快照 - 监控：Chart 内置了
metrics.enabled=true，会启动mysqld_exporter，但需额外部署 ServiceMonitor（Prometheus Operator）或配置 Prometheus static_configs 抓取primary.metrics.service.port（默认 9104） - 告警：MySQL 连接数 > 90%、复制延迟 > 30s、InnoDB buffer pool 命中率
真正麻烦的从来不是“能不能部署”，而是“部署完能不能稳住、出事能不能快速定位”。Bitnami Chart 缩短了初始部署时间，但备份策略、监控阈值、故障切换演练、SSL 证书轮换——这些才是压在 DBA 头上的真石头。
