不推荐 MySQL 部署在容器中

MySQL可以部署在容器里，但是为什么不推荐？

具有实际生产经验的人会发现MySQL等数据库部署在容器了会出现很多问题。

主要从下面几点：

1. 数据持久化

数据库的数据必须持久保存，这意味着你必须挂载外部 Volume（持久化存储），也可以是PV/PVC。

实际问题：

• 多节点 Kubernetes 集群中，Volume 的跨节点挂载复杂且不稳定
• 本地挂载（hostPath）可用性差，很少用。
• 存储挂载（如NFS、Ceph）可能存在延迟、丢包、IO 抖动。

2. 网络问题

容器的网络一般使用 overlay 网络（如 flannel、calico），相比宿主机直连：

• 多一层容器网络转发，延迟增加，查询变慢
• 容器间通信不稳定，主从复制容易断链
• 遇到节点重启、Pod 重建，IP 地址会变

3. 性能问题

Kubernetes 会自动把容器调度到不同节点，哪里有资源就安排你去哪。

数据库需要稳定：

• 要稳定的 CPU 和内存
• IO 带宽独占或高优先级

但容器环境中：

• Pod 可能被调度到任意节点，性能差异大
• 多容器共享一个宿主机资源，容易资源抢占
• 容器热迁移或水平扩缩容，对数据库毫无意义（状态无法同步）

4. 总结

从架构设计上看，虽然 MySQL 可以部署在容器中，但在生产环境不推荐这么做。主要原因是容器天生短生命周期、网络不稳定、存储持久化复杂，与数据库对高可用、高一致性和性能稳定的要求冲突。

开发和测试环境可以使用容器部署 MySQL 提高效率，但生产环境更倾向使用虚拟机或裸机部署，并搭配成熟的高可用方案，如 MGR、ProxySQL 或云数据库服务。