关于生产上能不能把数据库容器化，一直是有两种声音的。一种是反对，另一种是支持。两边都是公说公有理，婆说婆有理。本人则是保持中立，不是不能上，要分场景上，像核心业务肯定就不能上，但是像一些小业务或者存放一些配置信息那就可以上，这些问题不大。那我们接下来讨论下用容器的方式部署数据库会有那些问题。

1  持久化存储

容器是“易失性”的，重启或重建后文件系统会被清空。数据库的数据必须持久保存，这意味着你必须挂载外部 Volume（持久化存储），也可以是PV/PVC。

实际问题：

  • 多节点 Kubernetes 集群中，Volume 的跨节点挂载复杂且不稳定

  • 本地挂载（hostPath）可用性差，很少用。

  • 存储挂载（如NFS、Ceph）可能存在延迟、丢包、IO 抖动

生产实践中，卷配置错误或存储漂移，轻则数据丢失，重则全库挂掉。

2 容器网络影响

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

  • 多一层容器网络转发，延迟增加，查询变慢

  • 容器间通信不稳定，主从复制容易断链

  • 遇到节点重启、Pod 重建，IP 地址会变

生产环境一旦出现数据库超时或断连，影响的可能是全平台！

3 性能问题

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

但数据库不是个“打工人”，它是个“大爷”

  • 要稳定的 CPU 和内存

  • NUMA 亲和性高

  • IO 带宽独占或高优先级

但容器环境中：

  • Pod 可能被调度到任意节点，性能差异大

  • 多容器共享一个宿主机资源，容易资源抢占

  • 容器热迁移或水平扩缩容，对数据库毫无意义（状态无法同步）

容器频繁迁移、上下线，会搞得数据库“头晕脑胀”，性能不稳，甚至崩掉。

4 数据一致性和主从复制挑战

容器生命周期短、不确定性强，而数据库讲究：

  • 数据一致性

  • 主从复制稳定性（binlog 保证）

  • 容灾恢复快速可靠

但如果：

  • 主节点容器突然宕机重建，原 IP 改变，导致从库连接失败

  • 容器重启丢失 binlog 文件，主从断裂

  • PVC 在主库 Pod 重建时尚未恢复，导致全库不可用

这些情况在 K8s 容器中非常常见。

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

参考文档：https://mp.weixin.qq.com/s/4j4dvIGT1HFEcTpiiX5waw