必须通过values.yaml传参配置Bitnami MySQL Chart，硬编码或patch已部署资源无效；关键项包括architecture: replication、auth.replicationUser/Password，且storageClass、accessModes、size单位等需严格匹配集群实际配置。
能直接改，但必须在 install 或 upgrade 时传入自定义 values，硬编码进 chart 源码或改 release 后的资源都没用。
values.yaml 是唯一有效的参数入口
Bitnami 的 bitnami/mysql chart 所有可配项都收口在 values.yaml，包括镜像版本、密码、存储、Service 类型、字符集等。它不是“配置文件”，而是 Helm 渲染模板时的输入源 —— 改了它，deployment、service、secret 等所有生成资源都会随之变化。
- 不要手动编辑已部署的
Secret或ConfigMap：改了也不会生效，下次helm upgrade就被覆盖 - 不要直接 patch
StatefulSet：容器启动参数、环境变量、挂载路径等由 Helm 模板生成，patch 后和 values 不一致，升级必崩 - 拉取 chart 后必须解压才能改
values.yaml：helm pull bitnami/mysql --untar比--version X.Y.Z+tar更可靠
改 root 密码和数据库名必须用 existingSecret 或 auth 字段
直接在 values.yaml 里写 auth.rootPassword: "xxx" 最简单，但注意两点：
- 如果设了
auth.existingSecret: "mysql-secret"，auth.rootPassword就会被忽略 —— 这个字段优先级更高，且 secret 必须提前用kubectl create secret generic创建好 -
auth.database只在auth.createDatabase: true时生效；若为 false，chart 不会建库，你得自己连进去执行CREATE DATABASE - 密码含特殊字符（如
@、/、:）必须用单引号包裹：rootPassword: 'p@ss/w0rd'，否则 YAML 解析失败
StorageClass 和持久化配置容易错三处
MySQL 对存储敏感，persistence 块改错会导致 Pod 卡在 ContainerCreating 或反复 CrashLoopBackOff。
-
storageClass值必须和集群中实际存在的 StorageClass 名字**完全一致**（区分大小写），运行kubectl get sc确认，别写成nfs-sc而实际是nfs-client -
accessModes必须匹配底层存储能力：NFS 通常只支持ReadWriteMany，但 MySQL 主从架构里，从库 StatefulSet 的 PVC 默认是ReadWriteOnce，强行设成ReadWriteMany会绑定失败 -
size单位必须带后缀："10Gi"✅，10G❌，10❌ —— Kubernetes 不认裸数字，PV 绑定会 Pending
Service 类型改 NodePort 后端口不生效？检查这三点
把 service.type 改成 NodePort 很常见，但外部访问不通往往不是配置问题，而是网络链路断点。
-
service.nodePort必须在 kube-apiserver 的--service-node-port-range范围内（默认30000-32767），设成3306或8080会静默 fallback 到随机端口 - 云厂商（如阿里云、腾讯云）的安全组/网络 ACL 必须放行你指定的
nodePort，不只是容器端口3306 - 如果是本地测试用
minikube，得额外跑minikube service mysql才能拿到可访问地址，kubectl get svc显示的NodePort在宿主机上并不直接可连
最常被忽略的是：MySQL 8 默认启用密码强度插件 validate_password，如果你设的 rootPassword 太短或不含大小写字母+数字+符号，init 容器会失败退出，Pod 卡在 Init:0/1。要么关掉插件（加 extraInitArgs: ["--skip-validate-password"]），要么按规则设密码。
