k8s运行MySQL到底合适吗？_vlambda技术博客

vlambda
2020-08-17

k8s运行MySQL到底合适吗？

导读

最近有个朋友约一起学k8s考个cka .....enmm坚持下来学完了，他说他不考了..然后我也就不想考了。

下面是我对k8s运行MySQL的思考和观点，欢迎指教一二。

k8s火了很久.. 有不少无状态的应用运行在k8s中。那么数据运行在k8s中到底合适吗？

核心一：k8s控制器

选择合适的控制器

k8s 的核心之一控制器（deployment（适合无状态的控制器）、StatefulSet（适合有状态的控制器））

deployment的特性：

deployment创建的Pod是无状态的，当挂在Volume之后，如果该Pod挂了，由于是无状态的，Pod挂了的时候与之前的Volume的关系就已经断开了，新起来的Pod无法找到之前的Pod。但是对于用户而言，他们对底层的Pod挂了没有感知，但是当Pod挂了之后就无法再使用之前挂载的磁盘了。

备：如果deployment创建的pod挂载volume时，如果后端使用nfs或者ceph，重启pod数据也不会丢失的

简单理解：deployment的pod是无状态的，Pod挂了之后无法使用之前挂载的磁盘，ip也会丢失。

StatefulSet的特性：

稳定，唯一的网络标识符，持久存储
有序，优雅的部署和扩展、删除和终止
有序，滚动更新

这几点很重要。

pod重启ip和Volume不变，但要是把pod删除或者重建IP和挂载的Volume就会变。

简单来说，做一个MySQL的主从，MySQL的主库重启或者OOM了，使用StatefulSet控制器ip不会发生变化，data目录还会挂载到原先的挂载点。

主库OOM，pod重启了。

1如果使用deployment控制器，（前提后端存储使用ceph或者nfs）首先恢复主从架构，先获得主库的ip地址，然后在主库执行 CHANGE MASTER TO命令，然后start slave；最后在修改VIP或者DNS映射。

如果使用StatefulSet控制器。由于IP不变，后端挂载的Volume不变，直接登录从库执行start slave即可。

(这里不涉及MySQL高可用的组件，只是简单对比deployment和StatefulSet的区别）

核心二：k8s的特性

k8s的特性：方便部署、快速升级或者快速的回滚应用、快速扩容。

举例部署一个nginx应用

kubectl run pod-01 --image=nginx #部署nginx镜像

kubectl scale --replicas=4 deployment nginx-app #副本扩到4

kubectl set image deployment nginx-app --image=nginx:1.11.3-alpine#升级镜像

kubectl rollout undo deployment web --to-revision=1 #回滚镜像到某个版本

kubectl rollout status -w deployment nginx-app #查看回滚状态

使用k8s部署应用真的超级方便，在配合上ci/cd等等，k8s用在应用上真的超级爽。

但这些方便的特性，对于数据库来说，完全用不上。

数据库是有状态的服务，快速部署一台MySQL数据库（个人认为分钟级就可以了）。分钟级交付一套MySQL，包括他的周边比如说注册到PMM或者一些客户端，我个人认为就合格了。

数据库没办法通过命令实现快速的扩容（MySQL的服务可以很快的拉起来，主从没法做，做主从的前提，就要获取一份主库的一致性的数据）。

快速的升级和回滚，就跟不需要了。数据库需要的是谨慎，就算你头铁，MySQL三个月更新一次版本，没事更新MySQL的程序干啥...

只能更新或者回滚MySQL的程序，不能回滚MySQL的data目录。

核心三：k8s跑MySQL就没优点了吗？

优点：

可以实现MySQL数据库的高可用。利用k8s的init容器，实现对MySQL的一个监控，如果Init容器返回失败，就可以报错出来。根据脚本进行下一步的操作。

k8s后端使用ceph或者其他共享存储方式。当MySQL发生OOM，结合k8s的init容器，实现pod重启，数据库恢复正常。

这种方式无论怎么切，都不会丢数据。除非底层的共享存储挂了。

缺点：

如果实现这种高可用的方式，基于共享存储，磁盘和网络都会成为性能的瓶颈。当然数据库都跑在k8s上了，就不考虑性能问题了。

更牛逼的一种方案：

k8s跑MySQL，在搞一个自动发现自动注册的服务，MySQL部署好了之后，直接挂载到MySQL的中间件上（暂时这个MySQL不可用，然后数据同步，等数据同步成功后在提供服务）

如果是基于time类型的分片是可行的，同步表结构即可。

这个方案只是YY，要实现还是很难的，需要很强大的团队，对MySQL中间件的改造，对应用的改造，AP业务汇总，数据的归档等等。

结论

k8s跑MySQL，对于中小企业来说是不合适的。k8s跑MySQL一点会有一些的性能损失,这个损失是否能承担。

搞定k8s涉及的技术栈也挺全的，不一定都能掌握，出问题不一定会维护，感觉StatefulSet控制器用的不如deployment多。

好不容易搞的数据库自动化运维平台啥的都需要重写咯~

k8s跑数据库还是看好TiDB，架构的设计就很适合，想对比传统的MySQL不用考虑分片问题。TiDB官方的工具TiDB Operato，有兴趣的同学可以看看TiDB的官方文档。