数据库等服务，到底要不要容器化？体验下来，各自真正的优劣是什么？

[seekseat]

一直模糊记得不推荐数据库这类服务放到容器中，但现在好像很多基于 K8s 的数据库产品和服务。

线上没有用过基于 K8s 部署的 mysql 服务，更多还是用自有的机器搭建&外加一部分腾讯云 CDB ，阿里云 RDS 等。

容器化数据库服务，究竟解决了什么痛点？又带了什么问题？目前大家接触到的服务都是怎么样的？

[Alexonx]

个人感觉把数据库这种重 IO 高稳定性需求的服务塞到 K8s 里面不是啥好主意,`很多基于 K8s 的数据库产品和服务` 很可能只是对稳定性和性能没有那么高,图方便舍弃稳定性的产物. 这里冯若航有一篇文章,也持有相似的观点. https://mp.weixin.qq.com/s/4a8Qy4O80xqsnytC4l9lRg
挺有意思的是,他发出这篇文章后,Sealos 也发了篇持相反观点的文章来"迎战":https://mp.weixin.qq.com/s/IDsF_f7ZnB19jEu8ZtO-Nw .但是遗憾的是,这篇文章通篇充斥着对自家产品的吹嘘,而对上文抛出的观点给不出实质性的反驳[like:"K8s 的稳定性问题?我们由专业的 xxx 团队提供支持,我们的稳定性已经远超许多非专业团队的运维水平(此处没有任何数据)"].反正看完这篇文章,我更坚持冯若航的观点了🤣.

[yulgang]

没有必要，本来只需要维护一个数据库，现在有加了个容器，操作系统、网络存储都要非常了解，要不崩了 hold 不住

[Syriana]

1 楼的两篇文章也看过，下面这个链接是我最近看到的，里面至少有几种容器化方案和压测的数据。但我并不擅长这方面，只能贴出来和大家一起分享下。
https://www.infoq.cn/article/Sh2TJYW1dKI4ZqpakUJJ?utm_campaign=geek_search&utm_content=geek_search&utm_medium=geek_search&utm_source=geek_search&utm_term=geek_search

[acerphoenix]

容器化的好处是维护时方便迅速低成本管理服务实例，新增删除节点，谁敢没事儿随便增删数据库节点，

[lairdnote]

性能是一方面 离散的数据库 是一个痛苦

[lance6716]

分布式数据库，可以没事扩容缩容，也能自动容错啥的，才比较适合 k8s 吧

[mightybruce]

历史上工业革命出现的时候一些人也是认为马车还是比蒸汽机车好，后来就不用说了吧。

现在都有数据库容器化弹性伸缩的云服务并对外提供， 并且还是支持分库分表的，

试用一下 plantscale 吧， 基于云原生 vitess 的 mysql

国内创业团体做的 kubeblocks 也可以看看

[miao1007]

物理机房上就没法容器化，好点的数据库都需要用 ROCE 光口直连存储设备

[kkwa56188]

不需要, 容器留给有需要的人吧.

[jhdxr]

我赞同 DB 这种**传统**状态化的应用无法直接通过容器现有的服务方便的进行扩展，并且我也不认为未来能够解决这一点。但是在裸机上扩容就容易了吗？另外一方面，新型的分布式存储/数据库也越来越多。

我自己目前还是更倾向于将数据库放入容器中，更多的是为了简化环境部署的要求。如果你的产品有部署去不同环境的需求（例如 to B/G 需要部署去用户的自有机房），容器化会极大地降低部署的成本。但如果是你自有+裸金属的环境，容器化可能并不会带来很多收益。

[Cola98]

交付方面来说更加简单和方便，只是维护起来会比较心累。。

[luoqeng]

share nothing 架构不适合 k8s

[linshenqi]

看好容器化

[CivAx]

[fovecifer]

@mightybruce 在电动汽车领域也总有人拿汽车取代马车来做类比，我认为这个类比不合适。从各个方面汽车都是完全优于马车的，但是目前在数据库，尤其是非分布式数据库方面，没有看到这种优势，如果有这种优势的话，早就完全铺开了。

[vlinx]

建议不要容器化

[wangkun025]

都是直接用阿里云的数据库服务。

[kuituosi]

数据库适不适合容器化看云厂商就知道了，
云厂商的数据库都是有一套自己的运维方式，跟 k8s 没有办法兼容
生产上肯定不适合容器化，但是开发测试部署毕竟方便

[iseki]

容器化的前提是，你玩的转~~~人家提供容器化云服务的厂商可不是简简单单 K8S 起个 Pod 就完了。
除非你对稳定性、性能、运维什么的全都没要求，跑起来能用就行，那自然是随便

[kaneg]

用不用容器，要看业务场景和数据库的需求有多高，如果是开发，测试，或者小规模的使用，数据存储放在高性能的共享存储，比如启用 RMDA 的 NFS 卷，起个 statefulset 的 pod 直接搞定。只要数据不丢，容器创建，升级啥的都是易如反掌。
但如果业务场景是高性能，高可用，数据容不得半点闪失，那还是老老实实找专业的 DBA 来实施和维护。

[amon]

测试环境 DB 放在 pod 中没毛病，生产环境要这么玩就有点儿戏了。
举个例子，如果阿里云服务出现故障，你 DB 放在 RDS 中，你就和 RDS 的售后团队对接，你 DB 放在 K8s 中，你就和 K8s 售后团队对接，你去找 RDS 售后，看他鸟你不。
再说，数据库机器的配置、运维标准和保障，和 K8s 机器的配置、运维等也不一样。

有些时候，不能追求又不是不能用。比如打开个脑洞，数据库我不放 RDS 了，也不放 K8s 了，直接放在我本地电脑上。可能对于大多数小业务来说大多数情况下也可以用，但是出一次问题，就够你蛋疼的了。

打篮球，最好是穿篮球鞋，你穿休闲鞋也能打，顶多不舒服而已，你穿个拖鞋和皮鞋，鞋子和脚坏的时候就懂了。

[mh494078416]

有状态服务适不适合进 k8s ，很重要一个选择因素是 k8s 上的远程存储。云上 ebs 具有的几个特性，高性能、三副本、io burst 、attach 、deattach 等。这些特性，依赖硬件投入，如高性能网络 RDMA ，在自建 IDC 情况下不一定具备。
所以，自建 IDC 下的 k8s 和云上是有一些不同的，难度和挑战会更大。
云上，云厂商供应有状态服务的云实例，背后已经转向 k8s 化，这个方向已经发生，争议不大的。
自建 IDC 场景，有更高的难度，不过 TiDB 针对 IDC 场景也给出了解法 TiDB Operator ，依赖本地磁盘 LPV ，而非远程存储。LPV 有易失性，TiKV 内置三副本特性，正好补充这块的不足。类似的还有 Kafka 的多副本机制。但对于其它不具备三副本的基础服务，进 k8s 没那么容易了，必须面临两难选择：本地磁盘 需要自己解决多副本问题；远程磁盘 性能不高，将有很大的性能损耗。靠远程存储自身来解决这个性能问题，看起来非常难跨越。

[me1onsoda]

云 rds 不都是容器云化，有什么不能的？看运维水平了

[ychost]

主要看运维能力，熟悉容器的话，放容器里面没啥问题

[xuanbg]

容器化部署快，真的 1 秒完成。

[louisxxx]

容器里面存储性能跟得上就行

[blueTrain]

了解一下 matrixone

[hezhiming1993]

@mh494078416
Kafka 、Redis 这类凡是 有状态的， 是不是都不适合放入 K8S ？

[julyclyde]

@hezhiming1993 redis 如果纯内存模式（不存盘）、kafka 集群模式
我觉得也还好吧

[YzSama]

我倾向于 k8s ，未来更多的是声明式部署。通过 operator 去检测更新服务。这个趋势越来越明显了。