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

[seekseat]

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

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

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

[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 去检测更新服务。这个趋势越来越明显了。