CFN Cloud
2025-10-14

用 Helm 在 Kubernetes 部署 MySQL 集群：上手与权衡

通过 Helm 快速部署 MySQL 集群，同时理解 Chart 默认值、持久化、网络与生产环境中的关键权衡。

Helm 的价值，在于把一大坨状态化 YAML 收拢成一个相对可控的安装入口。对 MySQL 主从这类系统来说，这能显著降低上手门槛。但 Helm 只是帮你把部署过程打包了，并不会替你理解底层的存储、服务、复制拓扑和恢复风险。

Helm 在这里到底帮了什么

  • 把一组复杂资源打成一个可复用 Chart
  • 给你一个统一管理的 values.yaml
  • 让升级和回滚更有结构
  • 少写很多重复 YAML

但它并不会自动替你做出正确的状态化运维决策。

预备条件

  • 集群里有可用 StorageClass
  • 本地装好 helm 和 kubectl
  • 有足够资源承载一主一从或更多副本

如果底层存储本身就不健康，Chart 不会救你，它只是会更整齐地失败。

创建命名空间

kubectl create namespace db

安装一个复制型 Chart

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

helm install mysql bitnami/mysql \
  --namespace db \
  --set architecture=replication \
  --set auth.rootPassword='ChangeMe123!' \
  --set primary.persistence.size=10Gi \
  --set secondary.replicaCount=1

这适合快速起步，但更长期的好习惯仍然是把参数写进版本化的 values.yaml。

用一个小的 values 文件会更稳

architecture: replication

auth:
  rootPassword: "ChangeMe123!"
  username: "app"
  password: "AppPassword123!"
  database: "appdb"

primary:
  persistence:
    size: 10Gi

secondary:
  replicaCount: 1

应用：

helm install mysql bitnami/mysql -n db -f values.yaml

这篇为什么要和前面几篇连着看

即使用了 Chart，底层逻辑仍然没变：

  • 持久化还是依赖 PVC 和 StorageClass
  • 稳定身份还是依赖 StatefulSet 风格行为
  • 读写流量还是依赖 Service
  • 复制和恢复仍然依赖运维纪律

所以这篇天然和下面几篇是一组：

  • kubernetes-quickstart-mysql-database.md
  • kubernetes-quickstart-mysql-replication.md
  • kubernetes-quickstart-stateful-apps.md

先确认 Helm 到底创建了什么

kubectl get pods -n db
kubectl get svc -n db
helm status mysql -n db
helm get values mysql -n db

这一步非常重要。Helm 帮你减少了手工 YAML，但如果你完全不看底层对象，排障时就很容易失去上下文。

读写访问模式

大多数 MySQL Chart 会分别暴露主库写入口和从库读入口。

典型做法：

  • MYSQL_WRITE_HOST=mysql-primary.db.svc.cluster.local
  • MYSQL_READ_HOST=mysql-secondary.db.svc.cluster.local

如果应用还没准备好分流读写，先都走主库更稳，等业务逻辑确认稳定后再逐步把只读流量挪到从库。

资源和存储仍然要自己判断

Chart 帮你把默认值写好了，不代表默认值就是适合你的：

  • CPU / 内存 requests 合不合理
  • 卷容量够不够
  • IO 性能够不够
  • 复制延迟是否可接受
  • 备份策略有没有落地

Chart 只是降低了部署复杂度，并没有替你决定最适合的状态化运维姿势。

常用 Helm 生命周期命令

helm list -n db
helm status mysql -n db
helm get values mysql -n db
helm upgrade mysql -n db -f values.yaml
helm rollback mysql -n db 1

这些命令是 Helm 真正吸引人的地方：发布、回滚、版本追踪都比散落的手工 YAML 更容易管理。

本地访问时还是优先用 port-forward

如果只是临时调试，先走 port-forward：

kubectl port-forward -n db svc/mysql-primary 3306:3306

这和 kubernetes-quickstart-port-forward.md 是直接关联的。别一上来就把数据库对外暴露。

FAQ

Q: 用了 Helm，是不是就不用再理解 StatefulSet 和 PVC 了？ A: 不是。Helm 隐藏的是重复 YAML，不是底层架构。状态化系统的本质你还是得懂。

Q: 用 Helm 部数据库最容易犯什么错？ A: 把 Chart 默认值直接当生产可用方案，而没有认真评估资源、存储、备份和切主风险。

Q: 参数直接写在 helm install --set 里就够了吗？ A: 对一次性测试来说可以，但长期看，版本化的 values.yaml 更利于 review、diff 和回滚。

下一步阅读

  • 接着读 kubernetes-quickstart-mysql-replication.md，补齐主从和故障切换视角
  • 如果你对存储还有疑问，回头读 kubernetes-quickstart-storageclass.md
  • 再读 kubernetes-quickstart-stateful-apps.md，从更高层理解状态化运维思路

收个尾

Helm 最大的价值，是把复杂部署变成一个更可管理的发布单元。但对数据库来说，真正重要的仍然不是“能不能装上”，而是你到底知不知道这些值背后在影响什么。

参考链接

查看原文