kubeasz 实战基于 Helm Chart 在 Kubernetes 中部署 MariaDB 主从复制集群【免费下载链接】kubeasz使用Ansible脚本安装K8S集群介绍组件交互原理方便直接不受国内网络环境影响项目地址: https://gitcode.com/GitHub_Trending/ku/kubeasz本文以 kubeasz 仓库中docs/deprecated/practice/mariadb_cluster.md的实践方案为主线完整演示如何在已由 kubeasz 部署好的 K8s 集群上通过 Helm 以 Bitnami MariaDB Chart 一键部署一主一从的 MariaDB 复制集群涵盖 values 配置修改、NodePort 外部访问、NFS 持久化存储、root/业务库/复制账号三套密码体系以及基于 StatefulSet 与 ConfigMap 的底层实现原理。读完本文你将能够在自己的 kubeasz 集群中复现一套可直接连接、具备主从复制与持久化能力的 MariaDB 集群并理解其每个配置项背后的模板机制。背景与适用场景MariaDB 是从 MySQL 衍生出来的开源关系型数据库目前兼容 MySQL 5.7 版本它同样非常流行拥有 Google、Facebook 等重要企业用户。在 Kubernetes 中部署数据库集群最常见的做法是利用官方维护的 Helm Chart 快速拉起主从架构避免手工编排 StatefulSet、Service、Secret、ConfigMap 等一长串 YAML。本实践方案使用Bitnami MariaDB Chartchart 版本 5.5.0appVersion 10.1.37该 Chart 自带主从复制master/slave编排能力仓库中已将其完整下载到本地因此不受国内网络环境影响、可离线安装。这一点与 kubeasz 项目方便直接不受国内网络环境影响的整体设计一致。需要注意的是本文对应的文档位于 docs/deprecated/practice/mariadb_cluster.md属于仓库中标记为 deprecated 的实践章节仅供实践交流使用。前提条件开始之前请确保你的环境满足以下三个条件条件说明参考文档已部署 K8s 集群kubeasz 已完成集群初始化与节点就绪快速开始已部署 Helm集群内可用 helm 命令执行安装Helm 安装指南集群提供持久性存储数据库数据目录需要挂载 PV/PVC集群持久化存储其中第三条是数据库上云的硬性要求MariaDB 的数据必须落到持久卷上Pod 重建后数据才能保留。本文后续配置中的storageClass: nfs-db即对应你预先在集群中创建好的 NFS StorageClass创建方法可参考 08-cluster-storage.md 中的 NFS 章节。Chart 目录结构解析仓库中该方案所需的 Chart 与自定义配置全部位于manifests/deprecated/mariadb-cluster/目录下manifests/deprecated/mariadb-cluster/ ├── my-values.yaml # 本次实践的自定义 values核心修改文件 └── mariadb/ # Bitnami MariaDB Chart 本体 ├── Chart.yaml # chart 元数据name: mariadb, version: 5.5.0 ├── values.yaml # Chart 默认配置 ├── values-production.yaml ├── README.md # Chart 官方参数说明文档 ├── files/docker-entrypoint-initdb.d/ # 首次启动初始化脚本挂载目录 └── templates/ # 渲染出 K8s 资源的 Go 模板 ├── NOTES.txt ├── _helpers.tpl ├── secrets.yaml # 密码 Secret ├── master-configmap.yaml # 主库 my.cnf ├── master-statefulset.yaml # 主库 StatefulSet ├── master-svc.yaml # 主库 Service ├── slave-configmap.yaml # 从库 my.cnf ├── slave-statefulset.yaml # 从库 StatefulSet ├── slave-svc.yaml # 从库 Service ├── initialization-configmap.yaml # 首次初始化脚本 ConfigMap ├── test-runner.yaml └── tests.yaml从模板清单可以直观看出该 Chart 的部署模型主库与从库各是一个独立 StatefulSet各自配套独立 Service密码统一存放在一个 Opaque Secret 中主从两端通过secretKeyRef引用同一份密码my.cnf 通过 ConfigMap 注入容器。这正是后续所有配置项的落点。修改自定义 values 配置按照惯例直接把 Chart 下载到本地然后把配置复制 values.yaml 出来进行修改这样方便以后整体更新 Chart。安装实际使用需要修改配置文件$ cd /etc/kubeasz/manifests/mariadb-cluster # 编辑 my-values.yaml 修改以下部分注在仓库中该目录的完整相对路径为 manifests/deprecated/mariadb-cluster/my-values.yaml即 my-values.yaml它是基于 Chart 自带 values.yaml 复制并精简出的自定义配置。下面逐段说明本次实践修改的关键配置1. Service以 NodePort 对外暴露service: type: NodePort # 方便集群外部访问 port: 3306 nodePort: master: 33306 # 设置主库的 nodePort slave: 33307 # 设置从库的 nodePorttype: NodePort将数据库服务以节点端口方式暴露到集群外部便于测试期直接通过任意节点 IP:33306/33307访问省去额外部署 Ingress 或 LoadBalancerport: 3306Service 的 ClusterIP 端口也是容器内 MariaDB 监听端口nodePort.master/slave分别指定主、从两个 Service 映射到宿主机上的端口。从模板 master-svc.yaml 可以看到只有service.type为NodePort且显式设置nodePort.master时模板才会渲染nodePort字段。2. rootUser设置 root 密码rootUser: # 设置 root 密码 password: test.c0m forcePassword: trueforcePassword: true表示强制要求用户显式指定密码。根据 secrets.yaml 模板的逻辑若password为空且未开启forcePasswordChart 会自动生成 10 位随机字母数字密码一旦开启forcePassword密码必须显式给出否则模板渲染会直接报错required A MariaDB Root Password is required!。推荐生产环境始终开启 forcePassword这也是保证后续helm upgrade能正常工作的前提。3. db创建初始业务库与账号db: # 设置初始测试数据库 user: hello password: hello name: hello forcePassword: true首次启动时Bitnami 镜像会根据MARIADB_USER/MARIADB_PASSWORD/MARIADB_DATABASE三个环境变量自动创建业务用户与同名数据库对应hello库、hello用户从 master-statefulset.yaml 可见db.user存在时模板才会渲染MARIADB_USER与MARIADB_PASSWORD两个环境变量而MARIADB_DATABASE始终以db.name注入。4. replication开启主从复制replication: # 设置主从复制 enabled: true user: replicator password: R4%forep11CAT0r forcePassword: trueenabled: true是主从架构的总开关。从 slave-statefulset.yaml 的第一行{{- if .Values.replication.enabled }}可以看出只有开启 replication从库 StatefulSet 才会被渲染关闭后集群退化为仅主库的单实例user/password指定主库上专门用于复制的账号replicator从库会用它连接主库拉取 binlog主库容器通过MARIADB_REPLICATION_MODEmaster环境变量启动复制源从库容器则通过MARIADB_REPLICATION_MODEslave、MARIADB_MASTER_HOSTrelease 名、MARIADB_MASTER_PORT_NUMBER3306、MARIADB_MASTER_ROOT_PASSWORD等环境变量自动完成主从配置——也就是说主从关系的建立完全由镜像启动脚本自动完成无需手工执行 CHANGE MASTER 语句这正是该 Chart 的核心价值。5. master持久化与调度策略master: affinity: {} antiAffinity: soft tolerations: [] persistence: enabled: true # 启用持久化存储 mountPath: /bitnami/mariadb storageClass: nfs-db # 设置使用 nfs-db 存储类 annotations: {} accessModes: - ReadWriteOnce size: 5Gi # 设置存储容量persistence.enabled: true主库数据必须持久化。启用后模板会渲染volumeClaimTemplates见 master-statefulset.yaml由 StatefulSet 自动为每个副本创建 PVCmountPath: /bitnami/mariadbBitnami 镜像的数据目录固定为此路径模板将 PVC 挂载到该目录storageClass: nfs-db显式指定使用预先创建的 NFS 存储类做动态供给。模板中若该值为-则渲染空storageClassName禁用动态供给若留空则使用集群默认存储类accessModes: [ReadWriteOnce]单节点读写符合 NFS 场景下的数据库挂载惯例size: 5Gi本次实践按测试规模申请 5Gi生产可按数据量调整antiAffinity: soft软反亲和尽量将主从 Pod 调度到不同节点preferredDuringSchedulingIgnoredDuringExecutiontopologyKey 为kubernetes.io/hostname提升可用性改为hard则变成强制不共节点。6. slave从库副本数与存储策略slave: replicas: 1 affinity: {} antiAffinity: soft tolerations: [] persistence: enabled: false # 从库这里没有启用持久性存储replicas: 1从库副本数为 1与主库构成一主一从persistence.enabled: false本实践中从库刻意不启用持久化作为练习/测试验证主从复制链路。从 slave-statefulset.yaml 可见关闭持久化后数据卷退化为emptyDirPod 一旦重建从库数据即丢失但会从主库重新全量同步生产环境建议将从库也开启持久化避免全量重同步的 IO 开销。7. my.cnf主从共用的性能优化参数在 Chart 自带的 values.yaml 中master.config与slave.config各内置了一段针对 Bitnami 镜像路径定制的 my.cnf主从两端内容基本一致核心优化点包括[mysqld] skip-name-resolve explicit_defaults_for_timestamp basedir/opt/bitnami/mariadb port3306 socket/opt/bitnami/mariadb/tmp/mysql.sock tmpdir/opt/bitnami/mariadb/tmp bind-address0.0.0.0 pid-file/opt/bitnami/mariadb/tmp/mysqld.pid log-error/opt/bitnami/mariadb/logs/mysqld.log character-set-serverUTF8 collation-serverutf8_general_ci # optimize max_allowed_packet 1024M table_open_cache 512 sort_buffer_size 2M read_buffer_size 2M read_rnd_buffer_size 8M thread_cache_size 8 query_cache_size 32M max_heap_table_size1024M tmp_table_size1024M max_connections65535 max_connect_errors65535 wait_timeout172800 interactive_timeout172800 connect_timeout30 # log settings expire_logs_days3要点说明所有路径均指向 Bitnami 镜像内部的/opt/bitnami/mariadb前缀直接套用官方 MySQL 路径会导致实例无法启动字符集统一为 UTF8character-set-serverUTF8collation-serverutf8_general_ci业务侧务必与之一致连接数调至max_connections65535大包限制放宽至max_allowed_packet1024M适用于传输较大数据块的场景二进制日志保留 3 天expire_logs_days3兼顾主从复制与磁盘占用该配置通过 master-configmap.yaml / slave 对应的 ConfigMap 模板渲染成my.cnf再以subPath方式挂载到容器内/opt/bitnami/mariadb/conf/my.cnf。使用 helm 安装配置完成后执行安装注意仓库文档中的命令基于 Helm 2 语法$ cd /etc/kubeasz/manifests/mariadb-cluster $ helm install --name mariadb --namespace default -f my-values.yaml ./mariadb命令含义--name mariadbRelease 名为mariadb它同时决定了主从 Service 的 hostname从库通过MARIADB_MASTER_HOSTmariadb找到主库--namespace default安装到 default 命名空间-f my-values.yaml用前面修改好的自定义 values 覆盖 Chart 默认值./mariadb本地 Chart 目录这正是不受国内网络环境影响的关键——整个 Chart 已随仓库分发到本地无需从远端 Chart 仓库拉取。安装过程中Helm 会依次渲染并提交 Secret、ConfigMap、StatefulSet、Service 等资源。释放release的密码信息会在 NOTES 中给出建议用helm list确认 release 状态。验证集群状态安装完成后验证 Pod 与 Service$ kubectl get pod,svc | grep mariadb pod/mariadb-mariadb-master-0 1/1 Running 0 27m pod/mariadb-mariadb-slave-0 1/1 Running 0 29m service/mariadb NodePort 10.68.170.168 none 3306:33306/TCP 29m service/mariadb-mariadb-slave NodePort 10.68.151.95 none 3306:33307/TCP 29m判断要点两个 Pod 名称分别为mariadb-mariadb-master-0与mariadb-mariadb-slave-0序号-0是 StatefulSet 有序命名特征说明主从各由一个单副本 StatefulSet 管理主库 Servicemariadb将 3306 映射到节点端口 33306从库 Servicemariadb-mariadb-slave映射到 33307与 values 配置一一对应集群外部可通过任意节点IP:33306连主库、任意节点IP:33307连从库。验证主从复制是否生效可在主库写入测试数据再到从库查询验证复制链路# 连接主库任选一台节点 IP $ mysql -h node-ip -P 33306 -uhello -phello hello # 主库写入 MariaDB [hello] CREATE TABLE t1 (id INT PRIMARY KEY, name VARCHAR(50)); MariaDB [hello] INSERT INTO t1 VALUES (1, kubeasz); # 连接从库 $ mysql -h node-ip -P 33307 -uhello -phello hello # 从库查询若能读到 t1 与数据说明主从复制正常 MariaDB [hello] SELECT * FROM t1; ------------- | id | name | ------------- | 1 | kubeasz | -------------也可以使用SHOW SLAVE STATUS\G查看从库的Slave_IO_Running与Slave_SQL_Running是否均为Yes。上述一主一从、读写分离验证完成后即可将业务连接串指向主库写与从库读。深入原理模板如何生成这套集群理解模板有助于你日后按需扩展以下均为仓库内可查证的实现细节1. 密码即 Secret。所有密码root、业务库、复制账号由 secrets.yaml 统一渲染为一个 Opaque Secretrelease 名为mariadb键名分别为mariadb-root-password、mariadb-password、mariadb-replication-password。主从 StatefulSet 全部通过secretKeyRef引用避免密码明文出现在 Pod 定义中若配置了existingSecret则 Chart 不再生成 Secret而是直接引用你预先创建的 Secret此时三组密码均以 Secret 内容为准。2. 主从角色靠环境变量区分。主库容器注入MARIADB_REPLICATION_MODEmaster从库容器注入MARIADB_REPLICATION_MODEslave与MARIADB_MASTER_HOST值即 release 名mariadbBitnami 镜像的启动脚本据此自动完成复制初始化。3. 探针使用 mysqladmin。主从的存活探针与就绪探针均通过exec mysqladmin status -uroot -p$MARIADB_ROOT_PASSWORD实现从库用$MARIADB_MASTER_ROOT_PASSWORD主库 liveness 初始延迟 120 秒首次初始化数据库耗时较长从库 readiness 初始延迟更长均为避免数据库初始化期间被误判为故障。4. 首次初始化可注入自定义脚本。Chart 支持三类方式详见 initialization-configmap.yaml 与 Chart 自带 README.md将.sh/.sql/.sql.gz脚本放入files/docker-entrypoint-initdb.d/目录或通过initdbScripts以字典形式声明或通过initdbScriptsConfigMap引用外部 ConfigMap优先级最高会覆盖前两者。这些脚本仅在数据库首次启动时执行常用于建表、初始化字典数据。5. 可选的监控边车。metrics.enabled: true时主从 Pod 会各挂载一个prom/mysqld-exporter边车容器端口 9104Service 上自动开放metrics端口并打上prometheus.io/scrape: true注解可直接接入集群内的 Prometheuskubeasz 的监控方案见 Prometheus 指南。后续运维与升级注意事项卸载helm delete mariadb会删除该 release 下的所有资源若需同时清理 PVC需手动删除 StatefulSet 遗留的 PVC 与 NFS 上的数据卷。升级Chart 官方要求升级时显式传入rootUser.password否则探针将因拿不到正确密码而持续失败例如$ helm upgrade mariadb ./mariadb -f my-values.yaml --set rootUser.passwordtest.c0m版本说明本方案对应 Chart 版本 5.5.0、MariaDB 镜像版本 10.1.37见 Chart.yaml 与 my-values.yaml 中的image.tag该版本栈兼容 MySQL 5.7 协议业务侧迁移成本较低从库启用持久化、NodePort 改为 LoadBalancer/ClusterIP Ingress 等生产化调整均可直接在上文 values 基础上增量修改。目录位置说明kubeasz 在服务器上的实际安装目录通常为/etc/kubeasz仓库内对应的源文件位于 manifests/deprecated/mariadb-cluster/部署时以服务器上的实际路径为准。通过本文你已经掌握了从集群就绪到MariaDB 一主一从落地的完整链路修改 values → helm 安装 → kubectl 验证 → 主从读写验证并理解了密码管理、持久化、探针与复制机制在 Chart 模板中的实现方式。这套本地 Chart 自定义 values的实践思路同样适用于 kubeasz 仓库中其他 Chart 类应用如 Redis 集群、MySQL 集群等可作为你在 k8s 上部署有状态服务的通用参考。【免费下载链接】kubeasz使用Ansible脚本安装K8S集群介绍组件交互原理方便直接不受国内网络环境影响项目地址: https://gitcode.com/GitHub_Trending/ku/kubeasz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
kubeasz 实战基于 Helm Chart 在 Kubernetes 中部署 MariaDB 主从复制集群【免费下载链接】kubeasz使用Ansible脚本安装K8S集群介绍组件交互原理方便直接不受国内网络环境影响项目地址: https://gitcode.com/GitHub_Trending/ku/kubeasz本文以 kubeasz 仓库中docs/deprecated/practice/mariadb_cluster.md的实践方案为主线完整演示如何在已由 kubeasz 部署好的 K8s 集群上通过 Helm 以 Bitnami MariaDB Chart 一键部署一主一从的 MariaDB 复制集群涵盖 values 配置修改、NodePort 外部访问、NFS 持久化存储、root/业务库/复制账号三套密码体系以及基于 StatefulSet 与 ConfigMap 的底层实现原理。读完本文你将能够在自己的 kubeasz 集群中复现一套可直接连接、具备主从复制与持久化能力的 MariaDB 集群并理解其每个配置项背后的模板机制。背景与适用场景MariaDB 是从 MySQL 衍生出来的开源关系型数据库目前兼容 MySQL 5.7 版本它同样非常流行拥有 Google、Facebook 等重要企业用户。在 Kubernetes 中部署数据库集群最常见的做法是利用官方维护的 Helm Chart 快速拉起主从架构避免手工编排 StatefulSet、Service、Secret、ConfigMap 等一长串 YAML。本实践方案使用Bitnami MariaDB Chartchart 版本 5.5.0appVersion 10.1.37该 Chart 自带主从复制master/slave编排能力仓库中已将其完整下载到本地因此不受国内网络环境影响、可离线安装。这一点与 kubeasz 项目方便直接不受国内网络环境影响的整体设计一致。需要注意的是本文对应的文档位于 docs/deprecated/practice/mariadb_cluster.md属于仓库中标记为 deprecated 的实践章节仅供实践交流使用。前提条件开始之前请确保你的环境满足以下三个条件条件说明参考文档已部署 K8s 集群kubeasz 已完成集群初始化与节点就绪快速开始已部署 Helm集群内可用 helm 命令执行安装Helm 安装指南集群提供持久性存储数据库数据目录需要挂载 PV/PVC集群持久化存储其中第三条是数据库上云的硬性要求MariaDB 的数据必须落到持久卷上Pod 重建后数据才能保留。本文后续配置中的storageClass: nfs-db即对应你预先在集群中创建好的 NFS StorageClass创建方法可参考 08-cluster-storage.md 中的 NFS 章节。Chart 目录结构解析仓库中该方案所需的 Chart 与自定义配置全部位于manifests/deprecated/mariadb-cluster/目录下manifests/deprecated/mariadb-cluster/ ├── my-values.yaml # 本次实践的自定义 values核心修改文件 └── mariadb/ # Bitnami MariaDB Chart 本体 ├── Chart.yaml # chart 元数据name: mariadb, version: 5.5.0 ├── values.yaml # Chart 默认配置 ├── values-production.yaml ├── README.md # Chart 官方参数说明文档 ├── files/docker-entrypoint-initdb.d/ # 首次启动初始化脚本挂载目录 └── templates/ # 渲染出 K8s 资源的 Go 模板 ├── NOTES.txt ├── _helpers.tpl ├── secrets.yaml # 密码 Secret ├── master-configmap.yaml # 主库 my.cnf ├── master-statefulset.yaml # 主库 StatefulSet ├── master-svc.yaml # 主库 Service ├── slave-configmap.yaml # 从库 my.cnf ├── slave-statefulset.yaml # 从库 StatefulSet ├── slave-svc.yaml # 从库 Service ├── initialization-configmap.yaml # 首次初始化脚本 ConfigMap ├── test-runner.yaml └── tests.yaml从模板清单可以直观看出该 Chart 的部署模型主库与从库各是一个独立 StatefulSet各自配套独立 Service密码统一存放在一个 Opaque Secret 中主从两端通过secretKeyRef引用同一份密码my.cnf 通过 ConfigMap 注入容器。这正是后续所有配置项的落点。修改自定义 values 配置按照惯例直接把 Chart 下载到本地然后把配置复制 values.yaml 出来进行修改这样方便以后整体更新 Chart。安装实际使用需要修改配置文件$ cd /etc/kubeasz/manifests/mariadb-cluster # 编辑 my-values.yaml 修改以下部分注在仓库中该目录的完整相对路径为 manifests/deprecated/mariadb-cluster/my-values.yaml即 my-values.yaml它是基于 Chart 自带 values.yaml 复制并精简出的自定义配置。下面逐段说明本次实践修改的关键配置1. Service以 NodePort 对外暴露service: type: NodePort # 方便集群外部访问 port: 3306 nodePort: master: 33306 # 设置主库的 nodePort slave: 33307 # 设置从库的 nodePorttype: NodePort将数据库服务以节点端口方式暴露到集群外部便于测试期直接通过任意节点 IP:33306/33307访问省去额外部署 Ingress 或 LoadBalancerport: 3306Service 的 ClusterIP 端口也是容器内 MariaDB 监听端口nodePort.master/slave分别指定主、从两个 Service 映射到宿主机上的端口。从模板 master-svc.yaml 可以看到只有service.type为NodePort且显式设置nodePort.master时模板才会渲染nodePort字段。2. rootUser设置 root 密码rootUser: # 设置 root 密码 password: test.c0m forcePassword: trueforcePassword: true表示强制要求用户显式指定密码。根据 secrets.yaml 模板的逻辑若password为空且未开启forcePasswordChart 会自动生成 10 位随机字母数字密码一旦开启forcePassword密码必须显式给出否则模板渲染会直接报错required A MariaDB Root Password is required!。推荐生产环境始终开启 forcePassword这也是保证后续helm upgrade能正常工作的前提。3. db创建初始业务库与账号db: # 设置初始测试数据库 user: hello password: hello name: hello forcePassword: true首次启动时Bitnami 镜像会根据MARIADB_USER/MARIADB_PASSWORD/MARIADB_DATABASE三个环境变量自动创建业务用户与同名数据库对应hello库、hello用户从 master-statefulset.yaml 可见db.user存在时模板才会渲染MARIADB_USER与MARIADB_PASSWORD两个环境变量而MARIADB_DATABASE始终以db.name注入。4. replication开启主从复制replication: # 设置主从复制 enabled: true user: replicator password: R4%forep11CAT0r forcePassword: trueenabled: true是主从架构的总开关。从 slave-statefulset.yaml 的第一行{{- if .Values.replication.enabled }}可以看出只有开启 replication从库 StatefulSet 才会被渲染关闭后集群退化为仅主库的单实例user/password指定主库上专门用于复制的账号replicator从库会用它连接主库拉取 binlog主库容器通过MARIADB_REPLICATION_MODEmaster环境变量启动复制源从库容器则通过MARIADB_REPLICATION_MODEslave、MARIADB_MASTER_HOSTrelease 名、MARIADB_MASTER_PORT_NUMBER3306、MARIADB_MASTER_ROOT_PASSWORD等环境变量自动完成主从配置——也就是说主从关系的建立完全由镜像启动脚本自动完成无需手工执行 CHANGE MASTER 语句这正是该 Chart 的核心价值。5. master持久化与调度策略master: affinity: {} antiAffinity: soft tolerations: [] persistence: enabled: true # 启用持久化存储 mountPath: /bitnami/mariadb storageClass: nfs-db # 设置使用 nfs-db 存储类 annotations: {} accessModes: - ReadWriteOnce size: 5Gi # 设置存储容量persistence.enabled: true主库数据必须持久化。启用后模板会渲染volumeClaimTemplates见 master-statefulset.yaml由 StatefulSet 自动为每个副本创建 PVCmountPath: /bitnami/mariadbBitnami 镜像的数据目录固定为此路径模板将 PVC 挂载到该目录storageClass: nfs-db显式指定使用预先创建的 NFS 存储类做动态供给。模板中若该值为-则渲染空storageClassName禁用动态供给若留空则使用集群默认存储类accessModes: [ReadWriteOnce]单节点读写符合 NFS 场景下的数据库挂载惯例size: 5Gi本次实践按测试规模申请 5Gi生产可按数据量调整antiAffinity: soft软反亲和尽量将主从 Pod 调度到不同节点preferredDuringSchedulingIgnoredDuringExecutiontopologyKey 为kubernetes.io/hostname提升可用性改为hard则变成强制不共节点。6. slave从库副本数与存储策略slave: replicas: 1 affinity: {} antiAffinity: soft tolerations: [] persistence: enabled: false # 从库这里没有启用持久性存储replicas: 1从库副本数为 1与主库构成一主一从persistence.enabled: false本实践中从库刻意不启用持久化作为练习/测试验证主从复制链路。从 slave-statefulset.yaml 可见关闭持久化后数据卷退化为emptyDirPod 一旦重建从库数据即丢失但会从主库重新全量同步生产环境建议将从库也开启持久化避免全量重同步的 IO 开销。7. my.cnf主从共用的性能优化参数在 Chart 自带的 values.yaml 中master.config与slave.config各内置了一段针对 Bitnami 镜像路径定制的 my.cnf主从两端内容基本一致核心优化点包括[mysqld] skip-name-resolve explicit_defaults_for_timestamp basedir/opt/bitnami/mariadb port3306 socket/opt/bitnami/mariadb/tmp/mysql.sock tmpdir/opt/bitnami/mariadb/tmp bind-address0.0.0.0 pid-file/opt/bitnami/mariadb/tmp/mysqld.pid log-error/opt/bitnami/mariadb/logs/mysqld.log character-set-serverUTF8 collation-serverutf8_general_ci # optimize max_allowed_packet 1024M table_open_cache 512 sort_buffer_size 2M read_buffer_size 2M read_rnd_buffer_size 8M thread_cache_size 8 query_cache_size 32M max_heap_table_size1024M tmp_table_size1024M max_connections65535 max_connect_errors65535 wait_timeout172800 interactive_timeout172800 connect_timeout30 # log settings expire_logs_days3要点说明所有路径均指向 Bitnami 镜像内部的/opt/bitnami/mariadb前缀直接套用官方 MySQL 路径会导致实例无法启动字符集统一为 UTF8character-set-serverUTF8collation-serverutf8_general_ci业务侧务必与之一致连接数调至max_connections65535大包限制放宽至max_allowed_packet1024M适用于传输较大数据块的场景二进制日志保留 3 天expire_logs_days3兼顾主从复制与磁盘占用该配置通过 master-configmap.yaml / slave 对应的 ConfigMap 模板渲染成my.cnf再以subPath方式挂载到容器内/opt/bitnami/mariadb/conf/my.cnf。使用 helm 安装配置完成后执行安装注意仓库文档中的命令基于 Helm 2 语法$ cd /etc/kubeasz/manifests/mariadb-cluster $ helm install --name mariadb --namespace default -f my-values.yaml ./mariadb命令含义--name mariadbRelease 名为mariadb它同时决定了主从 Service 的 hostname从库通过MARIADB_MASTER_HOSTmariadb找到主库--namespace default安装到 default 命名空间-f my-values.yaml用前面修改好的自定义 values 覆盖 Chart 默认值./mariadb本地 Chart 目录这正是不受国内网络环境影响的关键——整个 Chart 已随仓库分发到本地无需从远端 Chart 仓库拉取。安装过程中Helm 会依次渲染并提交 Secret、ConfigMap、StatefulSet、Service 等资源。释放release的密码信息会在 NOTES 中给出建议用helm list确认 release 状态。验证集群状态安装完成后验证 Pod 与 Service$ kubectl get pod,svc | grep mariadb pod/mariadb-mariadb-master-0 1/1 Running 0 27m pod/mariadb-mariadb-slave-0 1/1 Running 0 29m service/mariadb NodePort 10.68.170.168 none 3306:33306/TCP 29m service/mariadb-mariadb-slave NodePort 10.68.151.95 none 3306:33307/TCP 29m判断要点两个 Pod 名称分别为mariadb-mariadb-master-0与mariadb-mariadb-slave-0序号-0是 StatefulSet 有序命名特征说明主从各由一个单副本 StatefulSet 管理主库 Servicemariadb将 3306 映射到节点端口 33306从库 Servicemariadb-mariadb-slave映射到 33307与 values 配置一一对应集群外部可通过任意节点IP:33306连主库、任意节点IP:33307连从库。验证主从复制是否生效可在主库写入测试数据再到从库查询验证复制链路# 连接主库任选一台节点 IP $ mysql -h node-ip -P 33306 -uhello -phello hello # 主库写入 MariaDB [hello] CREATE TABLE t1 (id INT PRIMARY KEY, name VARCHAR(50)); MariaDB [hello] INSERT INTO t1 VALUES (1, kubeasz); # 连接从库 $ mysql -h node-ip -P 33307 -uhello -phello hello # 从库查询若能读到 t1 与数据说明主从复制正常 MariaDB [hello] SELECT * FROM t1; ------------- | id | name | ------------- | 1 | kubeasz | -------------也可以使用SHOW SLAVE STATUS\G查看从库的Slave_IO_Running与Slave_SQL_Running是否均为Yes。上述一主一从、读写分离验证完成后即可将业务连接串指向主库写与从库读。深入原理模板如何生成这套集群理解模板有助于你日后按需扩展以下均为仓库内可查证的实现细节1. 密码即 Secret。所有密码root、业务库、复制账号由 secrets.yaml 统一渲染为一个 Opaque Secretrelease 名为mariadb键名分别为mariadb-root-password、mariadb-password、mariadb-replication-password。主从 StatefulSet 全部通过secretKeyRef引用避免密码明文出现在 Pod 定义中若配置了existingSecret则 Chart 不再生成 Secret而是直接引用你预先创建的 Secret此时三组密码均以 Secret 内容为准。2. 主从角色靠环境变量区分。主库容器注入MARIADB_REPLICATION_MODEmaster从库容器注入MARIADB_REPLICATION_MODEslave与MARIADB_MASTER_HOST值即 release 名mariadbBitnami 镜像的启动脚本据此自动完成复制初始化。3. 探针使用 mysqladmin。主从的存活探针与就绪探针均通过exec mysqladmin status -uroot -p$MARIADB_ROOT_PASSWORD实现从库用$MARIADB_MASTER_ROOT_PASSWORD主库 liveness 初始延迟 120 秒首次初始化数据库耗时较长从库 readiness 初始延迟更长均为避免数据库初始化期间被误判为故障。4. 首次初始化可注入自定义脚本。Chart 支持三类方式详见 initialization-configmap.yaml 与 Chart 自带 README.md将.sh/.sql/.sql.gz脚本放入files/docker-entrypoint-initdb.d/目录或通过initdbScripts以字典形式声明或通过initdbScriptsConfigMap引用外部 ConfigMap优先级最高会覆盖前两者。这些脚本仅在数据库首次启动时执行常用于建表、初始化字典数据。5. 可选的监控边车。metrics.enabled: true时主从 Pod 会各挂载一个prom/mysqld-exporter边车容器端口 9104Service 上自动开放metrics端口并打上prometheus.io/scrape: true注解可直接接入集群内的 Prometheuskubeasz 的监控方案见 Prometheus 指南。后续运维与升级注意事项卸载helm delete mariadb会删除该 release 下的所有资源若需同时清理 PVC需手动删除 StatefulSet 遗留的 PVC 与 NFS 上的数据卷。升级Chart 官方要求升级时显式传入rootUser.password否则探针将因拿不到正确密码而持续失败例如$ helm upgrade mariadb ./mariadb -f my-values.yaml --set rootUser.passwordtest.c0m版本说明本方案对应 Chart 版本 5.5.0、MariaDB 镜像版本 10.1.37见 Chart.yaml 与 my-values.yaml 中的image.tag该版本栈兼容 MySQL 5.7 协议业务侧迁移成本较低从库启用持久化、NodePort 改为 LoadBalancer/ClusterIP Ingress 等生产化调整均可直接在上文 values 基础上增量修改。目录位置说明kubeasz 在服务器上的实际安装目录通常为/etc/kubeasz仓库内对应的源文件位于 manifests/deprecated/mariadb-cluster/部署时以服务器上的实际路径为准。通过本文你已经掌握了从集群就绪到MariaDB 一主一从落地的完整链路修改 values → helm 安装 → kubectl 验证 → 主从读写验证并理解了密码管理、持久化、探针与复制机制在 Chart 模板中的实现方式。这套本地 Chart 自定义 values的实践思路同样适用于 kubeasz 仓库中其他 Chart 类应用如 Redis 集群、MySQL 集群等可作为你在 k8s 上部署有状态服务的通用参考。【免费下载链接】kubeasz使用Ansible脚本安装K8S集群介绍组件交互原理方便直接不受国内网络环境影响项目地址: https://gitcode.com/GitHub_Trending/ku/kubeasz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
