使用Helm在K8s集群中部署MySQL 8.0高可用架构：一主两从实战指南

1. 为什么要在K8s里搞MySQL高可用？先聊聊我的踩坑史

说实话，最开始我也觉得在Kubernetes里跑有状态数据库，尤其是MySQL这种，有点“自找麻烦”。虚拟机或者物理机上部署，配置好主从复制，不是挺稳的吗？但真在容器化这条路上走久了，尤其是在做微服务改造和云原生迁移的项目里，我踩过几个大坑，才彻底转变了想法。

第一个坑是资源隔离和弹性伸缩。以前用虚拟机部署，给MySQL分配了固定的CPU和内存，业务高峰期扛不住，想临时扩容？得申请新机器、装系统、配环境、做数据同步，一套流程下来黄花菜都凉了。而业务低谷期，这些资源又白白浪费。K8s的Pod可以轻松定义资源请求和限制，配合HPA（Horizontal Pod Autoscaler）虽然对数据库这种有状态应用要谨慎，但至少给了我们更精细的管理手段。

第二个坑是运维的复杂度。手动部署一主两从，你得操心三台机器的系统配置、MySQL安装、参数调优、备份脚本、监控告警。每加一套新环境，就得从头再来一遍，容易出错，也难保证一致性。用Helm Chart部署，相当于把一整套最佳实践打包成了一个“应用包”，一次定义，到处部署。版本升级、回滚也变得像点个按钮一样简单，这体验是传统运维没法比的。

第三个坑，也是最重要的，高可用（HA）的自动化恢复。传统架构下，主库挂了，你得手动或者靠脚本去提升一个从库为主，还要改应用连接串，中间的服务中断时间不短。在K8s里，我们可以结合StatefulSet的稳定网络标识（Pod名固定）、Headless Service（无头服务）以及定制的探针，设计出更优雅的故障转移方案。虽然Bitnami这个Chart默认不包含自动主从切换（需要更复杂的Operator），但它为我们搭建好了复制架构的基础，后续集成第三方工具或者自己写控制器就方便多了。

所以，用Helm在K8s里部署MySQL高可用，核心价值不在于“能不能跑起来”，而在于标准化、可重复、以及为未来的自动化运维铺平道路。对于开发测试环境，你可以快速拉起一套和生产架构一样的数据库；对于生产环境，你获得了与无状态服务一致的部署、监控、生命周期管理体验。接下来，我就手把手带你，用最流行的Bitnami MySQL Helm Chart，在K8s集群里部署一套坚如磐石的MySQL 8.0一主两从集群。

2. 动手之前：把你的环境收拾利索

老话说，工欲善其事，必先利其器。部署之前，咱们得确保环境里该有的“家伙事儿”都齐备，并且版本对得上，能省去后面一大堆莫名其妙的报错。

2.1 核心组件版本对一对

我用的环境和你可能差不多，但版本一定要心里有数。这里列一下我这次实战经过验证的版本组合，你照着来，大概率一路绿灯。

• Kubernetes集群：我用的是1.22.15。这个版本比较稳定，社区资料也多。你的集群版本最好在1.19以上，因为我们要用的某些API和特性在更早的版本可能不支持。用 kubectl version 命令就能看到客户端和服务端的版本。
• 容器运行时：Docker 20.10.9 或者 Containerd 1.4+ 都行。确保运行时工作正常，能拉取镜像。
• Helm：必须是Helm 3。Helm 2已经彻底淘汰了，Tiller那套安全模型太复杂。用 helm version 看看，版本号是v3.x.x就对了。
• 网络与存储：这是两个重中之重。
  • 网络：集群的CNI插件（比如Calico、Flannel）要正常工作，Pod之间、Pod与Service之间要能互通。这关系到主从复制的数据同步。
  • 存储：这是有状态应用的生命线。你必须提前准备好StorageClass。我强烈推荐使用动态供给的存储，比如NFS-CSI、Ceph RBD、AWS EBS、Azure Disk等。我这次用的是事先部署好的 nfs-storageclass。你可以用 kubectl get storageclass 命令检查，必须有一个标记为 (default) 或者你明确知道名字的StorageClass可用。

2.2 给Helm配上Bitnami这个“软件仓库”

Helm就像一个包管理器，Chart就是软件包。Bitnami是官方认证的Chart仓库之一，里面的应用都经过良好测试和持续维护，质量很高。

添加仓库就一行命令：

helm repo add bitnami https://charts.bitnami.com/bitnami

加完之后，更新一下本地仓库的索引，确保能获取到最新的Chart信息：

helm repo update

现在，搜索一下MySQL相关的Chart看看：

helm search repo bitnami/mysq