最近看到一篇推文，痛述MySQL不能上容器的各种理由，基本是N年前的陈词滥调，东拼西凑出的一篇水帖，文末对于数据库是否能上容器，也是模糊不清，没有确切的观点，标题倒是吸引眼球，不明就里的人容易产生一种倾向：数据库不适合容器。
在如今这种信息泛滥的年代，好像否定一种事物，比接纳他更容易引起共鸣，小编君也在自问：为什么数据库容器化容易被否定？是他本身的逻辑导致的吗？做为一名数据库从业者，小编君举双手支持数据库容器化！
首先来看看数据库能否容器化受到的各种质疑：
▌ 1. 如果容器突然崩溃，数据库未正常关闭，可能会损坏数据
荒谬，按照这个逻辑，把容器两字换成物理机，这句子念的也是通畅的吧？当然数据持久化姿势要正确，可以用PV/PVC外挂存储或目录的方式，数据IO直接透传出容器，数据库本身是有WAL日志保护的，只要磁盘不存在损坏，故障重启后的日志前滚回滚，会保证commit的你看得见，未commit的你看不见。不管是容器，还是物理机，都是这套流程。而他们面对的崩溃导致异常的概率基本是一致的，可能物理机崩溃事还更大一点吧？
▌ 2. 容器里共享数据卷组，对物理机硬件损伤也比较大
这个不知从何说起，容器也是一个OS进程，他发起的IO也和其他原生态进程一样经由内核驱动下发到硬件设备上，写5TB的数据下去，既不会使硬盘变重，也不会破空击伤了他的。我猜作者是担心多个容器挂载了共享目录，没控制写冲突，导致数据的逻辑损坏。这还是个姿势问题，与容器无关了。
▌ 3. 容器是无状态的，对于数据库这种IO密集型应用，会拖垮IO性能
从本质来讲，容器是通过cgroup做的资源限额，通过命名空间做的用户态隔离，单纯CPU/内存的测试，跟物理机是没有区别的，IO层面使用的是aufs内部文件系统，这一层的性能确实是差劲的，所以当发现容器IO跑不起来时，建议你看看是否把某些密集操作，落到了aufs上，对于数据库跑容器，都是使用的PV/PVC外挂透传，瓶颈不在容器，而在外部设备,无论是吞吐还是IOPS，都可以无损消耗，所以该质疑不成立。
▌ 4. 容器不安全，担心数据泄漏
小编君承认，容器不如虚拟机安全，他共享os内核，一些关键目录隔离性不够，镜像本身的安全性等，似乎到处都是刺。但大家也要理解一点，容器输出的是服务，虚拟机交付的是os，如果你硬是要把容器当成os交付出去，安全肯定是打折扣的。就数据库容器化而言，我最终给出的肯定是端口之类的服务暴露，所以这个安全是可控的。也许有人会问：你就没有要进入容器内部去排错的时候吗？ok，排错也是这套系统的管理服务人员，而非终端服务使用者。另外，既然上了容器化，他也有配套的可观测系统，就不要再以管os的方式管容器了。
▌ 5. 容器网络复杂
所以从技术层面来看，把数据库塞进容器，会有一些学习和开发成本，但不是什么大的障碍。我们公司的数据库融合平台就是基于容器+K8S这条技术路线，目前支持主流数据库的全生命周期管理，公有云Squids和私有云QFusion，可以满足用户线上线下双轨需求，现已经成功上线了多家客户，在这个平台的建设上小编君可以说说感受！
图：squids平台架构
不知道是什么时候开始，数据库这块也开始聊"CI/CD"了，频繁创库成了一个高频次操作，而维护开发/测试/生产数据库环境的精准一致性就显得特别重要，中国已经有240+数据库厂商，琳琅满目。
要在这种多库多OS的排列组合下做到一次打包，多次使用，我们选了容器化这条路。
我们的squids.cn是直接基于公有云ECS提供RDS服务的，云主机种类繁多，还有arm/x86，本来以为适配工作会非常繁重，是容器化让这个路径大幅缩短。
我们有个客户的数据库资源池构建也比较有意思，因为前期预算有限，机器规模一开始很小，那么就会有Mongo/Redis/MySQL可能挤到一台机器上的情况，性能是扛得住的，但环境安装很麻烦。要是以后再加一款新库，所有机器还得更新一次。其实他就是需要将数据库应用和os层做解耦，容器的namespace隔离就非常适合。当然虚拟化也可以做，但考虑到资源损耗，还有客户那边应用研发正在力推容器化改造，就放弃了。
数据库塞进容器，只是第一步，还得有HA保护，备份恢复，升级扩容，性能可观测这些配套设施，就像火箭和火箭发射塔一样，两者结合，才能稳定高效的运行。最近几年明显感觉DBA这个行业开始快餐化了，都能上去耍一哈子，但精通的不多。不是人不聪明，而是我们的精力很难再聚焦，大家都是快速理解掌握，解决眼前的问题，立马再下一站。未来可能都不再会有DBA这一职业了，所以将DBA的思想，经验转化为代码，并不断地根据场景、需求去调整，是长远之策。我们需要用平台化、云原生的思路去构建数据库运行的环境。
在K8S里面有一种控制器模式，你指定了运行两副本，那就一定是两副本，不管是杀掉进程，还是重启关机，只要K8S的这一套体系还在，他就不断的调整资源，达到你声明的效果。这种倔强顽强的机制，就很适合数据库HA检测保护，我们只需要将数据库复制，切换，故障检测的业务逻辑封装进去，一套健壮的HA机制就可以运行起来。K8S的Service服务暴露，也为数据库集群切换提供了统一访问入口，避免应用修改连接串。再比如他的label标签，亲和调度策略，对于池化的资源平衡能起到很好的效果。类似的例子还有很多。我们发现，一旦理解适应了k8s这套体系后，你基于他去做数据库平台化的改造就会非常顺畅，他帮你解决了很多底层的复杂逻辑，你专注数据库业务就行。
也有人跟小编君探讨过，他说你这些说的都对，但你说的每一个点，我都可以用非容器化，不借助k8s来实现掉。以前我一定会上去跟他争的面红脖子粗，现在不会了。我觉得我们只是在容器化，云原生的潮流下，选了顺应趋势的技术路线，目前，我们受益匪浅！
