最稳妥方案是用 batch/v1 CronJob + mysqldump 容器化执行；禁用 v1beta1，显式设 concurrencyPolicy=Forbid、timeZone=Asia/Shanghai；密码通过只读 Secret 挂载 ~/.my.cnf；备份存至 PVC 绑定的共享存储；脚本末尾清理 7 天前文件并校验 dump 文件有效性。
直接用 batch/v1 CronJob + mysqldump 容器化执行，是最稳妥、可落地的方案；别再用已弃用的 batch/v1beta1，也别把密码硬编码进 YAML。
用 batch/v1 创建 CronJob，而不是 v1beta1
Kubernetes 1.21 起 batch/v1beta1 就被标记为弃用，1.25+ 已完全移除。现在必须用 batch/v1，否则 kubectl apply 会报错：error: unable to recognize "cronjob.yaml": no matches for kind "CronJob" in version "batch/v1beta1"。
- API 版本必须写成
apiVersion: batch/v1 -
spec.concurrencyPolicy默认是Allow，但生产环境建议显式设为Forbid，避免上一次备份没结束就触发下一轮，导致并发写冲突或磁盘打满 - 加
timeZone: Asia/Shanghai（尤其集群节点时区不统一时），否则 cron 表达式按 UTC 解析，容易“准时但不对时”
备份脚本不能裸奔，得封装进容器并安全传参
直接在 CronJob YAML 里写 args: ["mysqldump", "-h", "mysql", "-uroot", "-p123456"] 是高危操作：密码会出现在 kubectl get cronjob -o yaml 和 Pod 启动参数中，且可能被 ps aux 看到。
- 改用
~/.my.cnf配置文件方式：挂载一个只读 Secret，内容为：
[client] host=mysql user=root password=your_actual_password
- 在容器内挂载路径设为
/root/.my.cnf，并chmod 600 /root/.my.cnf（可在 entrypoint 脚本里做） - 命令简化为：
mysqldump --all-databases > /backup/mysql-$(date +%Y%m%d-%H%M%S).sql
备份存储必须用持久卷，不能依赖 emptyDir 或宿主机路径
用 hostPath 看似简单，但存在严重问题：Pod 调度到不同节点时，备份文件就丢了；节点重启或磁盘故障，备份全毁；多副本备份还会互相覆盖。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 必须声明
PersistentVolumeClaim（PVC），绑定到 NFS、Ceph、云厂商 NAS（如阿里云 CPFS、AWS EFS）等共享存储 - CronJob 的
volumeMounts挂载点要和脚本里的BACKUP_DIR严格一致，比如都设为/backup - 加清理逻辑：脚本末尾用
find /backup -name "mysql-*.sql" -mtime +7 -delete，避免备份无限堆积
验证备份有效性比“跑起来”更重要
很多团队只检查 CronJob 是否创建了 Job、Pod 是否 ExitCode 0，却从不验证 SQL 文件能否还原——结果某天真要恢复时发现全是空文件或权限错误。
- 每次备份后，追加一行校验：
head -n 20 "$BACKUP_FILE" | grep -q "MySQL dump" || { echo "Invalid dump file"; exit 1; } - 每周抽一个备份文件，用
mysql -h test-mysql -u root 做轻量级还原测试（可另起临时 Pod） - 在 Prometheus + Alertmanager 中监控
job_status{job="mysql-backup"} == 0，失败立即告警
真正难的不是写完 YAML，而是让每一次备份都可验证、可追溯、可恢复。时区、权限、存储路径、密码隔离、历史清理、结果校验——漏掉任意一环，都可能让“自动化”变成“自动失效”。
