V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
ccde8259
V2EX  ›  程序员

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

  •  
  •   ccde8259 · 2023-09-24 18:33:36 +08:00 · 3671 次点击
    这是一个创建于 424 天前的主题,其中的信息可能已经有所发展或是发生改变。

    故事的背景是来自于 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……
    每次重启就得为这个错误的选择浪费一下午时间……

    13 条回复    2023-09-25 10:52:26 +08:00
    Senorsen
        1
    Senorsen  
       2023-09-24 18:54:36 +08:00
    数据库应用,为啥不直接 local pv
    mightybruce
        2
    mightybruce  
       2023-09-24 18:56:36 +08:00
    这不是部署花里胡哨,是根本没有选型。operator 那么多,为什么选 dev.mysql.com
    ceph 是作为网络存储,慢一点那是必然。
    更大一点的 mysql 集群,要么自己魔改 mysql 存储引擎,要么用云厂商的 mysql 吧。
    dw2693734d
        3
    dw2693734d  
       2023-09-24 19:03:13 +08:00
    感觉 Kubernetes 好复杂
    seers
        4
    seers  
       2023-09-24 19:18:27 +08:00
    数据库还是单独虚拟个环境部署好
    chendy
        5
    chendy  
       2023-09-24 19:30:50 +08:00
    数据库这玩意对动态扩缩又没要求的,直接找个物理机或者虚拟机跑一个放着就行了呗…
    thevita
        6
    thevita  
       2023-09-24 19:33:55 +08:00
    怎么就得出`不会有什么好处` 的结论呢?最多就是他解决的不是你的问题而已
    billzhuang
        7
    billzhuang  
       2023-09-24 19:45:36 +08:00 via iPhone
    这不是花里胡哨
    laminux29
        8
    laminux29  
       2023-09-24 20:10:46 +08:00
    这是节约资金与管理运维便捷性的矛盾。

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

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

    自己权衡吧。
    anubu
        9
    anubu  
       2023-09-24 21:21:35 +08:00
    如果能够接受 k8s 的复杂度,在 homelab+k8s 的场景里,大部分时候额外的复杂度都是 sts 和存储引入的。
    存储建议独立出来 smb\nfs\iscsi ,或者 local pv ,分布式存储会比较折腾。
    sts 最好就是 standalone ,尽量避免应用层集群。

    在不稳定的 k8s 集群和分布式存储上部署有状态的应用层集群简直是灾难。
    fengxsong
        10
    fengxsong  
       2023-09-24 23:11:31 +08:00 via Android
    三节点的 ceph 集群亏你用的起来
    pckillers
        11
    pckillers  
       2023-09-24 23:38:15 +08:00 via Android
    真正云部署时都是买云上的 mysql rds 的啊。。。 所以实验环境直接 Deployment 或 statefulset 限定单副本起个 docker 官方 MYSql 镜像不就完事了?
    至于持久化储存,单机 localpv ,多机就挑一个机器起 NFS 。
    salmon5
        12
    salmon5  
       2023-09-25 09:08:58 +08:00
    建议你直接上专有云 https://apsara-stack.aliyun.com
    jones2000
        13
    jones2000  
       2023-09-25 10:52:26 +08:00
    集群这种东西, 不建议重启, 除非是机房搬迁。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2526 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 15:42 · PVG 23:42 · LAX 07:42 · JFK 10:42
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.