k8s 部署 mysql5.7 踩坑

这周做了一个工作：把一份 helm 部署的方案使用 client-go 进行迁移以进行后续代码部署。
然后一个神奇的现象发生了，同样是 mysql 5.7.30，mysql helm 成功部署了，但我照抄yaml失败了，且到最后都没有找到最核心的解决方案，转而通过低版本解决了问题。
但还是心有牵挂，记录一下，后续进行更多的尝试。

问题描述

mysql helm 成功利用空的 pvc 部署成功了一个 mysql 的 deployment，使用 client-go 代码迁移配置无论如何都没法在同一个集群中部署成功。

报错是[ERROR] --initialize specified but the data directory has files in it. Aborting.

一开始排查可能是因为删除不干净，导致 mysql 无法通过检查，但是在 init_container 中我删除所有文件（包括 lost+found）后，使用另一个 init_container list all 显示已经全部清空。这时候仍然报同样的错。

PS： 此时使用的是 azure 的 pvc, 访问模式 RWX 和 RWO 都失败。
stack over flow answer

1. 降低版本

这个时候如果降低版本为 5.6, 则问题直接解决。但该场景不可以降低版本，因为直接依赖了 mysql5.7 的一个新特性。

2. 启动项控制
   另外有回答添加启动项也可以解决，所以我进一步进行了尝试。

   Args: []string{
       "--ignore-db-dir=lost+found",
   },

   依然失败。
   PS： 此时使用的是 azure 的 pvc, 访问模式 RWX 和 RWO 都失败。

3. 降低小版本 + 启动项控制
   更仔细的查找github issue，有一条回答描述了它使用的 5.7.15 并通过启动项控制就启动成功了，所以进行了一下尝试，真的成功了。

4. 降低小版本 + init_container 清理环境
   同样成功了。证明了单纯通过 init_container 清理环境也是可以的。

5. 不使用 azure 的 pvc，使用机器的磁盘。
   注意到 mysql helm 使用 mysql 5.7.30 的同时，使用的是 default stroage class 的pvc，所以进行了一组这样的实验，结果成功了。
   PS： 此时使用的是 default 的 pvc, 访问模式 RWO 成功， RWX pending。

结论

这个结论有点扯，5.7.15 版本的 mysql 可以在使用云存储的 k8s 中运行，但是 5.7.30 始终不行。而使用本地存储的 5.7.30 只要规避了 lost+found 文件夹即可成功运行。
具体的引起原因需要进一步去比较两个版本的差异。
不过成功完成了既定的目标还是很快乐的。