吵了6年的数据库话题，会在冯若航这里终结吗？

2024-07-04码农

谈及在 k8s/Docker 上部署数据库服务时，业界意见分歧显著，形成了一场围绕「数据库容器化」的持久辩论。

一方面，支持者强调 k8s 在提供环境无关性、自动化运维及资源优化方面的潜力；另一方面，反对者则担忧数据库的特殊需求与 k8s 的设计理念存在冲突，可能导致安全、性能及成本效率上的挑战。

本文跟踪了一下这场持续六七年的辩论，从 Mikhail Chinkov 与王渊命的早期论战，到王竹锋、姜承尧对于在 k8s 上部署数据库的必要性思考，以及冯若航提到的可能面临的「双输」情况，来看看数据库容器化在 k8s 生态中的争议与前景。

第一回合：Mikhail Chinkov VS. 王渊命：数据库容器化合理吗？

2017 年，Docker 宣布完成 7500 万美元融资，其总市值达到了 13 亿美元，这标志着容器技术在 IT 领领域的巨大潜力和影响力。

当时 Docker 的发展如日中天，几乎成了容器的代名词。

与此同时，一篇 【为什么数据库不适合容器】 （中文版：）引发了一场技术圈内的激烈辩论。

作者 Mikhail Chinkov 提出了数据库容器化并不合理的观点，并列举了七大理由，包括数据安全、运行环境匹配、网络挑战、状态问题、与 Docker 核心功能的协调性、过度隔离的负担以及云平台应用的局限性。

数据不安全：Docker 数据存储在主机上仍面临丢失风险，Docker volumes 基于 Union FS 设计，但缺乏数据保护的绝对保障。容器崩溃可能导致数据库损坏，尤其是未正确关闭时。

运行环境不匹配：数据库管理系统（DBMS）与其它服务共用主机时，因硬件需求差异大，可能导致资源浪费。数据库对 I/O 要求高，通常需专用环境。水平扩展优于垂直扩展，但容器化数据库可能需要过多资源调整。

网络挑战：Docker 网络复杂，需深入理解网络虚拟化且常遇未解决的 bug。数据库复制需主从间稳定连接，而 Docker 网络问题可能影响这点，增加管理难度。

状态问题：容器化适合无状态服务，数据库作为有状态服务加入容器环境会增加系统故障范围，应用崩溃可能波及数据库。

与 Docker 核心功能不协调：数据库应用并不直接获益于 Docker 的便捷构建、快速部署、水平扩展和环境一致性等优点，这些特性对数据库管理来说价值有限。

过度隔离的负担：容器化的额外隔离层导致资源开销增加，对数据库而言，这种隔离并未带来显著好处，反而可能不如专用环境高效。

云平台应用局限：在云环境中，容器化数据库并未利用云平台的便捷性，如快速启动实例和环境一致性。数据库容器化可能与云服务的弹性扩展和管理便利性不兼容，限制了云服务的优势。

毫不意外，文章的观点遭到了诸多反对。

技术极客王渊命认为数据库容器化具有重要的价值，撰写了一文进行反驳。

王渊命曾任新浪微博架构师、微米技术总监，2014 年作为联合创始人创立团队协作 IM 服务 Grouk，2016 年加入青云从事容器方面开发。

对于 Mikhail Chinkov 的质疑，王渊命逐一分析并指出：

安全方面，容器实际上增加了隔离层，提升了安全性。

IO 性能方面，容器通常不对 IO 进行限制，与宿主机差异不大。

网络问题，容器网络方案成熟且多样化，用户可根据需要选择。

成本方面，容器技术的接纳成本相对较低，且长期收益显著。

他认为，数据库部署和运维之间存在巨大鸿沟，传统方法难以满足高可用、易维护等需求。而容器技术，特别是 Docker 和 k8s，通过提供环境无关的封装、基础架构的可编程性、动态调度与编排能力，能够帮助构建自动化高可用数据库服务，减少人为错误，促进运维经验的沉淀和复用。

引入容器固然会带来的技术成本和风险，如安全性、IO 性能、网络性能等方面，但这些成本和风险相对于收益来说是可以接受的。「即便是它现在存在着许多问题，但绝对是一个潜力股，值得投入。」

遗憾的是，Mikhail Chinkov 和王渊命这场争论没有来回交锋，对于很多问题的讨论还不够深入。

但这恰恰激发了更多人的思考：数据库容器化，是否就是一场双刃剑的游戏呢？

这场技术论战，当然不会就这样草草结束。

图片来源于 Mikhail Chinkov 个人博客

第二回合：王竹锋 VS. 姜承尧：数据库上 k8s 有必要吗？

四年之后，又开始了新一轮的讨论，只不过，一些新情况的出现了。

在容器编排领域，相较于 Docker，Kubernetes 在企业采用率、社区活跃度和技术发展趋势上明显占据了优势，讨论的对象从 docker 变成了 k8s。

关于是否应该在 k8s 上部署数据库，争论的焦点已经发生了变化。

在 k8s 的早期版本中，可能更适合无状态服务，不适用于部署有状态服务，而数据库就是典型的有状态服务。

因为 k8s 的初衷是提供一个能够自动化部署、可扩展、应用容器可运营的平台。无状态服务通常更符合这些设计目标，因为它们没有持久化状态，可以轻松地进行扩展和故障恢复。

但从 1.5 版本开始，k8s 引入了 StatefulSet 控制器来支持有状态服务，并且这一功能自引入后就持续进化，对有状态服务的支持不断成熟，包括对数据持久化、存储卷管理、网络策略等特性的增强，使得数据库已经可以很好地运行在 k8s 上。

不支持有状态服务，已经不是 k8s 明显的弱点。因此，争论的焦点变成了，在 k8s 上部署数据库，是业务所需吗？

去哪儿网数据库总监的王竹锋在【】中认为，在 docker/k8s 部署 MySQL 是隔靴搔痒，作茧自缚。言辞颇为犀利。

你想上 k8s，是为了解决什么问题？编排部署安装找资源的问题？

MySQL 是一个有状态的大型通用数据库，这么重存储的服务，找资源安装，问题很大吗？

又说是资源隔离的问题，资源隔离的需求很紧迫吗？单机单实例就不说了，即使在单机多实例的情况下，也没几个实例，并且 MySQL 本身内部就是多线程的，均衡问题也比较好，同一台机器上一个实例影响其它实例的案例少之又少，所以这需求有那么紧迫吗？

而且对于使用 MySQL 没有上到一定量级的情况下，非 k8s 的自动化平台就可以很好的解决资源部署安装编排的问题，为了解决这个问题，创造一个上 k8s 的大问题，这样就有点和初衷背道而驰了。

同时 k8s 是一个新的技术栈，支撑它上线，是需要另一个专业团队来做的，投入产出比非常低。

我反过来再问一下， MySQL 本身的问题你解决完了吗？慢查询有没有好的工具去优化？主从切换能不能不影响业务？机器挂了能不能不丢数据？数据库服务能不能做到不同机房的多活？自动化 SQL 审核可以自助服务了吗？如果哪个没做到，那就先放弃 k8s 吧。

再者，我们专业的 MySQL 运维技术人员，非要作茧自缚，给 MySQL 套一个壳，出了问题，是壳的问题？还是 MySQL 本身的问题？

当引入一个变量的时候，可服务率肯定就会有一定程度的下降，因为 99.99%*99.99% 的结果是 99.98%。

总结来说就是，对于资源不足的公司来说，没必要将 MySQL 部署到 k8s，而且收益并不大，还可能引入新的问题，应该先确保现有的 MySQL 问题得到妥善解决。

姜承尧在一文中对王竹锋的观点进行了肯定，认为其正确之处在于数据库需要先满足业务的需求。但显然他不满意仅仅只有这一个说法。

姜承尧拥有近 15 年的 MySQL 内核研发、运维和管理经验，曾任腾讯云数据库技术负责人，在 MySQL 技术和开源社区领域有很高的知名度和影响力。

他提到，不是数据库需要跑在 k8s 上，而是业务需要数据库提供这样的服务能力。" 在 k8s 上跑数据库的意义在于，可以提供数据库服务，也就是 DBaaS，能够解决开发过程中面临的业务多环境部署的问题，这是 Paas 办不到的。"

所谓多环境部署，不是指一个业务部署在腾讯云、阿里云等多个云环境，因为这种情况概率不大，而是指研发过程中会面临的开发环境、自测环境、联调环境、UAT 环境、生产环境等多环境。不仅要保证这些环境和最终的生产环境是一致，还要保证各个环境数据库的表结构、索引一致。

「这款数据库服务不仅提供数据库访问，还提供数据库实例的自愈、故障转移、负载均衡、备份、监控、日常操作等一系列的数据库配套工具。同时，这个数据库服务可以通过镜像、编排、容器等技术快速复制到不同研发和生产环境，对业务用户提供极致的 CI、CD、CO 体验。」

姜承尧认为，虽然将数据库部署在 k8s 上还存在这样或者那样的问题，但 Cloud Native Database，DBaaS 的趋势不可逆转。

冯若航：将数据库放入 k8s 中会导致「双输」

「k8s 为数据库带来的收益相比其引入的问题与麻烦，实在是微不足道。」开源项目 Pigsty 的作者冯若航在 【】 中表示，在分布式网络存储的可靠性与性能超过本地存储前，将数据库放入 k8s 是一种不明智的选择。

尽管 k8s 提供了诸如 StatefulSet、PV、PVC、LocalhostPV 等抽象原语用于支持有状态服务（i.e. 数据库），但这些东西对于运行有着更高可靠性要求的生产级数据库服务来说仍然远远不够。

数据库是「宠物」而非「家畜」，需要细心地照料呵护。将数据库放入 k8s 作为「牲畜」对待，本质上是将外部的磁盘 / 文件系统 / 存储服务变为了新的「数据库宠物」。

使用 EBS / 网络存储 / 云盘运行数据库，在可靠性与性能上有巨大劣势；然而如果使用高性能本地 NVMe 磁盘，与节点绑定无法调度的数据库又失去了放入 k8s 的主要意义。

将数据库放入 k8s 中会导致「双输」 —— k8s 失去了无状态的简单性，不能像纯无状态使用方式那样灵活搬迁调度销毁重建；而数据库也牺牲了一系列重要的属性：可靠性，安全性，性能，以及复杂度成本，却只能换来有限的「弹性」与资源利用率 —— 但虚拟机也可以做到这些！对于公有云厂商之外的用户来说，几乎都是弊远大于利的。

以 k8s 为代表的「云原生」狂热已经成为了一种畸形的现象：为了 k8s 而上 k8s。

工程师想提高不可替代性堆砌额外复杂度，管理者怕踩空被业界淘汰互相卷着上线。

骑自行车就能搞定的事情非要开坦克来刷经验值 / 证明自己，却不考虑要解决的问题是否真的需要这些屠龙术 —— 这种架构杂耍行为终将招致恶果。

冯若航

作为 PostgreSQL 专家和全栈开发者，冯若航对数据库管理、开发以及优化有着深厚的理解和经验，经常在其主理的公众号「非法加冯」公开发表观点。同时他是一名活跃的开源贡献者，其开源的 Pigsty 是一个旨在替代 Amazon RDS PostgreSQL 服务的开源解决方案。

8 月 16 日，冯若航将以特邀嘉宾的身份出席 GOTC 2024 「开源数据库与 AI 协同创新」论坛，并发表主题演讲。

「开源数据库与 AI 协同创新」论坛还将邀请 Byzer 社区 PMC / 资深数据架构师、Kyligence 技术合伙人祝海林，爱可生 AI 创新事业部负责人苏鹏，与冯若航一起探讨智能索引优化、数据压缩革新、自动化运维进阶、业务决策智能化、AI 与数据库的融合未来、实战案例剖析等方面，探索 AI 与数据库领域的结合能够为行业带来怎样革命性的变革。

报名通道现已开启，
诚邀全球各技术领域开源爱好者共襄盛举！

扫码或长按识别二维码

8 月 15 日至 16 日，GOTC 2024 将在上海张江科学会堂盛大开启。

GOTC 2024 将与上海浦东软件园联合举办，并结合「 GOTC（全球开源技术峰会）」与「 GOGC（全球开源极客嘉年华）」，旨在打造一场全新开源盛会。2024 全球开源极客嘉年华（GOGC 2024）由浦东软件园携手 S 创共建，与开放原子开源基金会、开源中国、Linux 基金会等品牌联合呈现。

此次大会将集结全球范围内对开源技术充满热情的开发者、社区成员、创业者、企业领袖、媒体人，以及各开源项目应用场景的产业精英、跨界才俊与年轻力量。通过主题演讲、圆桌讨论、创新集市、人才集市、黑客松、技术展示和互动工作坊等形式，与会者将有机会交流实践经验、探索前沿技术，让我们一起激发创新活力、展示开源魅力、促进跨领域合作。

更多信息，访问官网查看：
https://gotc.oschina.net

参考链接：

为什么数据库不适合容器

https://myopsblog.wordpress.com/2017/02/06/why-databases-is-not-for-containers/

数据库不适合 Docker 及容器化的 7 大原因

https://mp.weixin.qq.com/s/bx_zgJs88GljYH0zdvDCTQ

数据库容器化的价值 —— 反驳数据库不适合容器化的错误观点

https://mp.weixin.qq.com/s/9OzNAALcy2OLdl3blOHMRg

一个数据库十年老兵的思考与总结

https://mp.weixin.qq.com/s/un84g7fUMrn5Yp8Vcfj8-Q

在 Kubernetes 上跑数据库，真的没有意义么？

https://mp.weixin.qq.com/s/vEg8Y65JDmw3JTkOxNzZ1g