k8s运⾏MySQL到底合适吗？
导读 下⾯是我对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⽬录。
mysql 要钱吗核⼼三：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的官⽅⽂档。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。