小规模私有部署场景下，将 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 的经验吗？想向大佬们征求一些建议，我实在是纠结得不行...

[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 。