部署方案搞得花里胡哨并不会有什么好处，只会陷入失控

[ccde8259]

故事的背景是来自于 HomeLab 上的一套 K8S ，部署了 Grafana 等应用，后端存储需要一个 MySQL……怎么部署这个 MySQL 呢？
先看了一眼 dev.mysql.com 里边，有个 MySQL Operator for Kubernetes 。很好，就他了！默认直接一个三副本集群，走的是 Group Replication 的方案……
然后 MySQL 存储 PVC 咋么搞呢？ local pv ？不如直接 Ceph ？然后看了一眼 Rook Ceph ，直接一把梭……默认又是一个三副本的集群起来了……
很好，到这里一份数据存三遍在一块盘里，三块盘一共存了九份……倒也不是不能接受……反正就是浪费一丢丢丢空间而已嘛……
重启了一趟，运维灾难就来了。重启以后得等 Rook Ceph 的所有 Pod 拉起来，然后所有 Pod 的 PV 才能用……进一步的，MySQL Group Replication 要开始选举，选举出 Master 以后还不能用……所有的 Slave 要重新做主从同步，这个时候由于 Ceph 本身 I/O 性能不如裸盘导致这个同步奇慢无比……再加上 MySQL Group Replication 插件时不时还会有一些报错：Fatal error during execution on the Applier module of Group Replication.自始至终集群状态都是不可用，MySQL Router 一直处于 CrashLoopBackOff 的状态……进一步所有应用因为连不上 MySQL ，一直 CrashLoopBackOff……
每次重启就得为这个错误的选择浪费一下午时间……

[Senorsen]

数据库应用，为啥不直接 local pv

[mightybruce]

这不是部署花里胡哨，是根本没有选型。operator 那么多，为什么选 dev.mysql.com
ceph 是作为网络存储，慢一点那是必然。
更大一点的 mysql 集群，要么自己魔改 mysql 存储引擎，要么用云厂商的 mysql 吧。

[dw2693734d]

感觉 Kubernetes 好复杂

[seers]

数据库还是单独虚拟个环境部署好

[chendy]

数据库这玩意对动态扩缩又没要求的，直接找个物理机或者虚拟机跑一个放着就行了呗…

[thevita]

怎么就得出`不会有什么好处` 的结论呢？最多就是他解决的不是你的问题而已

[billzhuang]

这不是花里胡哨

[laminux29]

这是节约资金与管理运维便捷性的矛盾。

每个业务一台物理机，管理运维最方便，但最浪费钱。

虚拟化集群 + 虚拟机内嵌容器 + k8s ，最节约资金，但管理运维非常麻烦。

自己权衡吧。

[anubu]

如果能够接受 k8s 的复杂度，在 homelab+k8s 的场景里，大部分时候额外的复杂度都是 sts 和存储引入的。
存储建议独立出来 smb\nfs\iscsi ，或者 local pv ，分布式存储会比较折腾。
sts 最好就是 standalone ，尽量避免应用层集群。

在不稳定的 k8s 集群和分布式存储上部署有状态的应用层集群简直是灾难。

[fengxsong]

三节点的 ceph 集群亏你用的起来

[pckillers]

真正云部署时都是买云上的 mysql rds 的啊。。。 所以实验环境直接 Deployment 或 statefulset 限定单副本起个 docker 官方 MYSql 镜像不就完事了？
至于持久化储存，单机 localpv ，多机就挑一个机器起 NFS 。

[salmon5]

建议你直接上专有云 https://apsara-stack.aliyun.com

[jones2000]

集群这种东西， 不建议重启， 除非是机房搬迁。