Helm直接安装bitnami/mysql虽快，但连通性、数据持久化与可维护性取决于persistence、auth和architecture参数的合理组合：未配StorageClass会导致Pending，未设auth.rootPassword则密码不可知，禁用persistence会致重启丢数据，Service类型不匹配则无法访问。
直接用 helm install 装 bitnami/mysql 是最快路径，但“装上能连”和“能用、不丢数据、可维护”是两回事——关键在 persistence、auth 和 architecture 三个参数的组合是否合理。
为什么 helm install bitnami/mysql 后连不上或重启就丢数据
默认 chart 启用 persistence.enabled=true，但若集群没配 StorageClass 或 PV 不可用，StatefulSet 会卡在 Pending；更常见的是你没显式设 auth.rootPassword，导致 Helm 自动生成随机密码，而你根本不知道它藏在哪。
-
kubectl get secret mysqltest -o jsonpath='{.data.mysql-root-password}' | base64 -d才能拿到真实密码，不是 values.yaml 里写的那个 - 如果用
--set persistence.enabled=false测试，Pod 重启后整个数据库目录消失，mysqld启动失败并反复 CrashLoopBackOff - Bitnami 镜像默认禁用
skip-networking，但若 Service 类型仍是ClusterIP，外部根本访问不到，别急着查 Pod 日志，先看 Service 暴露方式
单实例 MySQL 必须配的 4 个参数
绕开复杂配置，一条命令跑通可连、可持久、有密码的单实例：
helm install mysql-test bitnami/mysql \ --set auth.rootPassword=MyP@ssw0rd \ --set primary.persistence.size=8Gi \ --set primary.service.type=NodePort \ --set primary.service.nodePort=32000
-
auth.rootPassword：必须设，且不能含特殊字符如$、@（会被 shell 解析），建议用字母+数字+下划线 -
primary.persistence.size：即使集群有默认 StorageClass，也得明确指定 size，否则部分 provisioner 会拒绝创建 PVC -
primary.service.type和nodePort：Kubernetes 默认不开放 NodePort 范围（30000–32767），设成32000更安全，避免冲突 - 不要碰
architecture参数——除非你真要主从，否则留默认standalone，设成replication却不配replica.replicaCount会导致副节点起不来
用 hostPath 做本地存储时最容易漏的三件事
开发或单节点集群常用 hostPath，但 Bitnami chart 默认不走这条路，需手动覆盖 volume 配置：
- 先在目标节点（比如
k8s-node1）执行：mkdir -p /data/mysql && chmod 755 /data/mysql，注意不能用777，MySQL 容器以非 root 用户（1001）运行，会拒绝写入全权限目录 - 在
values.yaml中关闭动态 PV：persistence.enabled=false，再加primary.extraVolumeMounts和primary.extraVolumes挂载宿主机路径 - 必须加
primary.containerSecurityContext.runAsUser=1001，否则容器启动报错chown: changing ownership of '/bitnami/mysql/data': Operation not permitted
真正麻烦的从来不是“怎么装”，而是“装完之后谁负责备份、谁监控慢查询、谁轮转 error log、谁验证 binlog 是否启用”——Helm 只管把 Pod 跑起来，剩下的得靠你补上 mysqld-exporter、backup cronjob 和 ConfigMap 里的 my.cnf 调优项。别让一个 helm install 给你制造出运维黑洞。
