小规模私有部署场景下，将 mysql/redis/sentinel/minio 这些放到 k8s 里面是否可行呢

[eephee]

公司目前是 springboot 微服务 + mysql/minio/redis/redis-sentinel 的服务搭配

在企业版环境下，springboot 这套部署在 k8s 集群上面，mysql 这些是直接用的云厂商提供的服务 在私有部署环境下，springboot 这套部署在 k8s/k3s 集群上面，mysql 这些是直接装在机器上面

我现在想将私有化部署的 mysql 这些也放到 k8s 集群中运行，主要考虑是：

1. 使得部署起来更加方便

   1.1 目前服务的安装部署太麻烦麻烦，就算用 ansible 脚本，还是需要去适配不同的操作系统，而且对于离线部署的情形也是方便了许多，直接一个镜像就搞定，否则还需要去下载离线软件包/离线软件镜像，如果软件存在依赖那就很麻烦...

   1.2 因为 mysql 部署完需要创建库表，redis 部署完需要加载 lua 脚本，minio 部署完需要创建 bucket 等，虽然用一些脚本可以做到，还是感觉不太方便。用 k8s 的话，用 job/initContainer/sidecar 之类的就可以自动搞定，写成 helm 模板就可以一键部署，很方便

2. 提高对机器资源的利用。目前我们给客户做私有化部署的话，如果是钱多的客户，会给 mysql, redis, minio 每个服务分别给机器；如果是钱少的客户，最终讨论下来的结果一般是 将几个服务挤在一台机器上面，这样虽然可以，但是不好限制不同服务进程的资源占用，可能会存在某个服务影响其他服务的情况。部署到集群中的话，限制服务的资源就很容易

3. 部署到集群中，对于备份、监控等设施，都可以做得相对集中，易于维护。不需要搞各种脚本，那样太离散了，很容易搞错搞漏

可能存在的挑战或者问题，我能想到的大概是

1. 存储问题，目前看起来使用 local pv 或者 local-path-provisioner 是最好的选择，但这个毕竟不是共享存储的方式，因此还是会将 mysql 这些分别固定在某个特定节点上，这样做丢失了 k8s 调度的优势

2. 目前可能只能做单实例，没法做到真正的高可用。对于 mysql 主从，mysql cluster 可能会有问题：一方面可用的经验不多，另一方面可能服务本身不太适合上 k8s 集群，比如 redis sentinel 自身对于服务的监控和 k8s 对服务的监控和重启可能会存在冲突...

3. mysql/minio 好像有官方那个的 operator ，但是我担心把握不住或者不够自定义化，大概率不会去用这些 operator ，而是自己写 yaml ，可能会比较麻烦，还有 redis sentinel 这种，目前要怎么做心里还没底

4. 性能问题，比如 mysql ，在 k8s 中性能到底怎么样还是个未知数，可能需要做实验测一测

5. 因为我只会做单实例，不会做高可用，所以这一套只适合小规模的私有化部署场景（ 100 人左右吧），我担心到时候架构图给出去，会被客户 challenge：把 mysql 放到 k8s 中的稳定性问题。因为我看到网上有人提到过这点

有吃过螃蟹的前辈分享一些在 k8s 中使用 mysql/redis/minio 的经验吗？想向大佬们征求一些建议，我实在是纠结得不行...

[token10086]

可行，但没必要。除非加钱

[yyttrr]

用 operator 的注意选能长期维护的，要不然等集群版本要升级了很麻烦

[eephee]

@yyttrr operator 我感觉太麻烦了，用着有点担心，还是直接用 yaml 或者 yaml 模板方便些

[eephee]

@token10086 诶，是说客户加钱还是老板加钱

[hervey0424]

我的建议是别给自己添堵

[dululu]

看看这个： https://github.com/apecloud/kubeblocks

[pharsalia]

我们有 openstack 也有 k8s 的。用到 mysql 的业务，k8s 好像是单机单集群的，存储用 nfs 。mysql 没有用到 op ，redis 自己魔改了个 operator 。

[eephee]

@pharsalia 诶，好奇 nfs 的话，性能跟得上吗？

[pharsalia]

@eephee 我也不太清楚，是管理某些网元的系统，这个项目平时的负载不高

[julyclyde]

把存储类业务放 k8s 里通常没有什么好下场

[buchikoma]

先看看这个：
https://mp.weixin.qq.com/s/4a8Qy4O80xqsnytC4l9lRg
https://mp.weixin.qq.com/s/IDsF_f7ZnB19jEu8ZtO-Nw

再说下部分公司数据库上云的技术方案：
1.openstack 全套
2.虚机+传统有状态服务（自研框架实现的控制面+数据面）
3.k8s 、StatefulSet 、自己开发 operator

数据库上云核心就是怎么做高可用，怎么处理 failover ，怎么处理各种备份恢复场景

[julyclyde]

从你列举的内容来看，你是先确定要这么用，然后再“论证”，也就是找证据
你都已经看到了真正的问题了，也找了很多借口去抵制自己不喜欢的做法了，其实没什么必要这么纠结
自己的想法最重要

[anubu]

几乎一样的场景，给客户部署的就是 MySQL 、mongodb 、redis 、minio 都部署在 k8s 集群中。尽量使用 helm 而不是 operator ，存储使用 local pv ，配合 node selector 强制绑定。
肯定不是最佳实践，但还要看具体场景。小规模客户，没有太多资源，在主应用必须部署到 k8s 的情况下，把其它组件拉到集群部署也是一种选择。本身也不是追求高可用、弹性调度，只是借助 k8s 部署和管理。实际上，客户规模够大，有能力的话，也不会同意这样的方案，直接把基础组件甩给客户基础设施团队是最好的。

[RangerWolf]

可以的~ 比如你去看那些开源项目，比如 superset \ sentry ，他们的免费版本都是一个 docker compose 搞定，里面把前后端数据库全都搞定了。
特别是 Sentry ，几年前我部署的版本里面只有 18 个 container ，今年重新部署的里面塞了 24 个 container ...

[eephee]

> 把存储类业务放 k8s 里通常没有什么好下场

@julyclyde 大佬是亲身经历过相关的事故吗？可以分享一下吗？毕竟这么用的案例应该不多，比较想知道

[eephee]

@buchikoma 感谢，我看了下公众号的观点，对于大型项目确实不能用 mysql in k8s ，只是我在想对于小规模的话，做好数据备份的前提下能不能这么搞，主要还是为了部署方便

[eephee]

@anubu 哇这样子，感谢感谢！
方便了解下你们部署完有遇到过稳定性和性能方面的问题吗？还有你们的 helm 是自己写吗还是参考一些开源的实现呢？以及你们用 k3s 还是 k8s 呀？

大规模客户的话，这套确实就不适用了，用他们提供的集群和各种服务

[eephee]

@RangerWolf 嗯嗯是的，毕竟 sentry 他们是面向开发，所以给 docker compose 也完全 OK

[PhosphorLin]

可以但没必要，大规模部署放 k8s 里方便，小规模部署就是给自己增加麻烦

[eephee]

@PhosphorLin 大规模的话，我们是 hold 不住的，所以大规模还是让云厂商去做

小规模部署增加麻烦是为什么呢

[PhosphorLin]

@eephee 推荐一篇文章： https://vonng.com/cn/blog/db/db-in-k8s/

[xuanbg]

你这数据库分成了多个实例后，数据的一致性就没了呀。而且这些都是部署一次就行，没谁天天部署数据库的吧？

[eephee]

@xuanbg

> 你这数据库分成了多个实例后，数据的一致性就没了呀

可能是我哪里写得不准确，我其实只部署单实例，不会部署集群版本的数据库

> 而且这些都是部署一次就行，没谁天天部署数据库的吧？

是这样没错，主要是时不时就要给客户私有化部署，次数多了就觉得麻烦

[litchinn]

存储选什么呢，万一碰上一次停电直接头皮发麻
看了你上面说的这些，你用 k8s 的唯一原因是觉得它部署方便
1. 我并不觉得 k8s 部署方便，写个 helm chart 的时间肯定比写个脚本多（除非你更擅长写 chart 而不是 shell 脚本），只能说他看起来更规范
2. k8s 显然比直接部署更占用资源，它的优势在于自动扩缩容，但是你说你想固定节点且单节点。限制服务器资源 docker 一样可以
3. 管理集中或许这个算一点小优势，你用 k8s 会很自觉的把 yaml 或 chart 文件搞个仓库放好，并且有统一的入口去查看日志之类的，但是写个脚本也是一样的，易于维护则不一定，出现问题，你还要额外考虑 k8s 上的问题，而且出问题的概率比这些基础应用本身要大

综上对于你目前的情况而言你列出的优点都不算优点或者优势不明显

[INCerry]

就算是大规模部署，也有实际的案例，很多大厂的 db 集群就是在 k8s 上的呀

[bigpigB]

楼主，我就是专门做云平台开发的
你的场景我熟悉(之前做运维的)
1 、私有化部署中间件可行的前提是有一支专业的 SRE ，能 hold 得住 ceph 和中间件 operator 那一套
2 、redis 、mongodb 可以用官方的 operator(没啥子太多坑),minio 建议先用 chart 。mysql 自己用 mgr 去实现，需要基于 mgr 写一个 operator (目前 mgr 没有看到成熟的开源 operator)
3 、关于性能，私有云肯定是会损失一些的(ceph)。在公有云上(阿里腾讯云都会提供 csi ，损失比较少)，性能损失主要跟存储相关，跟 k8s 网络关系有一点，但是不多。

[eephee]

@bigpigB 感谢大佬 Orz 。只是 ceph 太重了，我们自己估计是 hold 不住，所以打算用 localpv 。搞单实例的话，可能用不到 operator ，我自己本身不太喜欢 operator 因为感觉有点黑盒的意思

[julyclyde]

@eephee pod 故障的时候，volume 有时候状态不太对
说白了就单纯是因为你加一层容器而导致的无法成功重启，责任完全在你了

[xuanbg]

@eephee 明白了，这种情况不建议使用 k8s ，最好的办法其实就是提供一个虚拟机镜像。通过镜像开虚拟机，直接一步到位什么都有了。

[buchikoma]

@eephee #16
k8s 核心是不关心服务状态，即开即用，但对于数据库这种产品，即使部署出来了，也不一定是一个可用的状态，除非你完全不关心数据的一致性，我理解部署方便跟丢数据和可用性降低相比，重要性要小得多。

当然你直接用 local pv 保证这部分数据不变能减少一些迁移带来的风险，但你几乎就只能做到单实例，最简单的主从都不好实现，要做主从就需要最简单的一些服务来维护主从关系。

至于性能其实是最不需要关心的，因为数据库瓶颈几乎都在网络和磁盘 io 上

[anubu]

@eephee 使用 kubeadm 部署的标准 k8s 集群，稳定性没有遇到特别大的问题，可能是规模比较小，稳定性要求也不高。使用 local pv 的话最好使用独立的磁盘，避免存储空间不足导致 Pod 调度异常。尽量避免在 k8s 集群上部署维护有状态应用集群，sts 集群在节点故障时处理起来很烦人。

大部分回复基于理想情况，最佳实践来评价这样做的坏处，的确没有错，说的风险也的确都存在。但实际做项目部署往往一言难尽，用户可能规模很小，或者只是初步的试用意向。如果要 k8s 集群 3master3worker ，MySQL 单机 1 台，minio 单机 1 台，Redis 单机 1 台等等，随随便便就小十台服务器是很难和人谈的。用户甚至希望服务器配置高一些，数量少一些都能接受。所以一个很自然的需求就是同一台高配服务器即部署基础组件，又能当做 k8s 工作节点。这个时候用 k8s 统一资源管理，也是一个选择。

[yayoi]

数据库一般要求单独部署,用 localpv 也丧失了 k8s 的各种特性,退一步说用共享存储,部分涉及系统参数的优化还是要绑定节点,从你想更加方便的角度来说,这个一点都不方便.写 helm 和写 ansible 也没啥区别,适配操作系统的问题更多的解决方法是要求提供特定的几个系统版本,而不是去适配每个操作系统

[burymme11]

@PhosphorLin
这个公众号很迷，你分享的这篇是不建议数据库放 k8s ，但是这个作者又写了一篇，数据库一定要放在 k8s 里面。
https://mp.weixin.qq.com/s?__biz=MzU5ODAyNTM5Ng==&mid=2247486592&idx=1&sn=152067dde3c01d0cb9153f067a7363b0&chksm=fe4b395bc93cb04dbe47e84480d84c733c8d7fc1f038d45990f025512a3f8c21f0c9b241ce28&scene=132&exptype=timeline_recommend_article_extendread_samebiz#wechat_redirect

[eephee]

@burymme11 这个是转载 SealOS 公众号的文章

[xabclink]

你需要的是 docker-compose

[mh494078416]

核心在于，你的部署方案是单机版，还是高可用版本。单机版本，放在 k8s/k3s ，还是放在 vm image ，docker compose ，都只是部署方式的差异，以及虚拟化层数带来的一些性能影响。本质上都是单机的，无法应对单机宕机这种情况。
高可用的方案，核心在于数据层的设计了。在不在 k8s 里不是关键。

[eephee]

@mh494078416 是的，是这样子

[wjfq]

放 k8s 是可行的，现在云厂商也都是容器化的。 可以看下 https://github.com/apecloud/kubeblocks 。 一个 operator 管理所有数据库，现在集成了很多流行的数据库，比如 mysql/pg/redis/kafka 等等，并且支持高可用，备份恢复，很多其他的 operation 。 也有一些其他应该插件比如 minio 。