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

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

  •  
  •   seekseat · 307 天前 · 4705 次点击
    这是一个创建于 307 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

    30 条回复    2024-02-22 12:48:16 +08:00
    Alexonx
        1
    Alexonx  
       307 天前   ❤️ 1
    个人感觉把数据库这种重 IO 高稳定性需求的服务塞到 K8s 里面不是啥好主意,`很多基于 K8s 的数据库产品和服务` 很可能只是对稳定性和性能没有那么高,图方便舍弃稳定性的产物. 这里冯若航有一篇文章,也持有相似的观点. https://mp.weixin.qq.com/s/4a8Qy4O80xqsnytC4l9lRg
    挺有意思的是,他发出这篇文章后,Sealos 也发了篇持相反观点的文章来"迎战":https://mp.weixin.qq.com/s/IDsF_f7ZnB19jEu8ZtO-Nw .但是遗憾的是,这篇文章通篇充斥着对自家产品的吹嘘,而对上文抛出的观点给不出实质性的反驳[like:"K8s 的稳定性问题?我们由专业的 xxx 团队提供支持,我们的稳定性已经远超许多非专业团队的运维水平(此处没有任何数据)"].反正看完这篇文章,我更坚持冯若航的观点了🤣.
    yulgang
        2
    yulgang  
       307 天前 via iPhone
    没有必要,本来只需要维护一个数据库,现在有加了个容器,操作系统、网络存储都要非常了解,要不崩了 hold 不住
    Syriana
        3
    Syriana  
       307 天前
    1 楼的两篇文章也看过,下面这个链接是我最近看到的,里面至少有几种容器化方案和压测的数据。但我并不擅长这方面,只能贴出来和大家一起分享下。
    https://www.infoq.cn/article/Sh2TJYW1dKI4ZqpakUJJ?utm_campaign=geek_search&utm_content=geek_search&utm_medium=geek_search&utm_source=geek_search&utm_term=geek_search
    acerphoenix
        4
    acerphoenix  
       307 天前
    容器化的好处是维护时方便迅速低成本管理服务实例,新增删除节点,谁敢没事儿随便增删数据库节点,
    lairdnote
        5
    lairdnote  
       307 天前
    性能是一方面 离散的数据库 是一个痛苦
    lance6716
        6
    lance6716  
       307 天前 via Android
    分布式数据库,可以没事扩容缩容,也能自动容错啥的,才比较适合 k8s 吧
    mightybruce
        7
    mightybruce  
       307 天前
    历史上工业革命出现的时候一些人也是认为马车还是比蒸汽机车好,后来就不用说了吧。

    现在都有数据库容器化弹性伸缩的云服务并对外提供, 并且还是支持分库分表的,

    试用一下 plantscale 吧, 基于云原生 vitess 的 mysql

    国内创业团体做的 kubeblocks 也可以看看
    miao1007
        8
    miao1007  
       307 天前
    物理机房上就没法容器化,好点的数据库都需要用 ROCE 光口直连存储设备
    kkwa56188
        9
    kkwa56188  
       307 天前
    不需要, 容器留给有需要的人吧.
    jhdxr
        10
    jhdxr  
       307 天前
    我赞同 DB 这种**传统**状态化的应用无法直接通过容器现有的服务方便的进行扩展,并且我也不认为未来能够解决这一点。但是在裸机上扩容就容易了吗?另外一方面,新型的分布式存储/数据库也越来越多。

    我自己目前还是更倾向于将数据库放入容器中,更多的是为了简化环境部署的要求。如果你的产品有部署去不同环境的需求(例如 to B/G 需要部署去用户的自有机房),容器化会极大地降低部署的成本。但如果是你自有+裸金属的环境,容器化可能并不会带来很多收益。
    Cola98
        11
    Cola98  
       307 天前
    交付方面来说更加简单和方便,只是维护起来会比较心累。。
    luoqeng
        12
    luoqeng  
       307 天前
    share nothing 架构不适合 k8s
    linshenqi
        13
    linshenqi  
       307 天前
    看好容器化
    CivAx
        14
    CivAx  
       307 天前   ❤️ 3
    fovecifer
        15
    fovecifer  
       307 天前
    @mightybruce 在电动汽车领域也总有人拿汽车取代马车来做类比,我认为这个类比不合适。从各个方面汽车都是完全优于马车的,但是目前在数据库,尤其是非分布式数据库方面,没有看到这种优势,如果有这种优势的话,早就完全铺开了。
    vlinx
        16
    vlinx  
       307 天前
    建议不要容器化
    wangkun025
        17
    wangkun025  
       307 天前
    都是直接用阿里云的数据库服务。
    kuituosi
        18
    kuituosi  
       307 天前
    数据库适不适合容器化看云厂商就知道了,
    云厂商的数据库都是有一套自己的运维方式,跟 k8s 没有办法兼容
    生产上肯定不适合容器化,但是开发测试部署毕竟方便
    iseki
        19
    iseki  
       307 天前
    容器化的前提是,你玩的转~~~人家提供容器化云服务的厂商可不是简简单单 K8S 起个 Pod 就完了。
    除非你对稳定性、性能、运维什么的全都没要求,跑起来能用就行,那自然是随便
    kaneg
        20
    kaneg  
       307 天前 via iPhone
    用不用容器,要看业务场景和数据库的需求有多高,如果是开发,测试,或者小规模的使用,数据存储放在高性能的共享存储,比如启用 RMDA 的 NFS 卷,起个 statefulset 的 pod 直接搞定。只要数据不丢,容器创建,升级啥的都是易如反掌。
    但如果业务场景是高性能,高可用,数据容不得半点闪失,那还是老老实实找专业的 DBA 来实施和维护。
    amon
        21
    amon  
       307 天前
    测试环境 DB 放在 pod 中没毛病,生产环境要这么玩就有点儿戏了。
    举个例子,如果阿里云服务出现故障,你 DB 放在 RDS 中,你就和 RDS 的售后团队对接,你 DB 放在 K8s 中,你就和 K8s 售后团队对接,你去找 RDS 售后,看他鸟你不。
    再说,数据库机器的配置、运维标准和保障,和 K8s 机器的配置、运维等也不一样。

    有些时候,不能追求又不是不能用。比如打开个脑洞,数据库我不放 RDS 了,也不放 K8s 了,直接放在我本地电脑上。可能对于大多数小业务来说大多数情况下也可以用,但是出一次问题,就够你蛋疼的了。

    打篮球,最好是穿篮球鞋,你穿休闲鞋也能打,顶多不舒服而已,你穿个拖鞋和皮鞋,鞋子和脚坏的时候就懂了。
    mh494078416
        22
    mh494078416  
       306 天前   ❤️ 1
    有状态服务适不适合进 k8s ,很重要一个选择因素是 k8s 上的远程存储。云上 ebs 具有的几个特性,高性能、三副本、io burst 、attach 、deattach 等。这些特性,依赖硬件投入,如高性能网络 RDMA ,在自建 IDC 情况下不一定具备。
    所以,自建 IDC 下的 k8s 和云上是有一些不同的,难度和挑战会更大。
    云上,云厂商供应有状态服务的云实例,背后已经转向 k8s 化,这个方向已经发生,争议不大的。
    自建 IDC 场景,有更高的难度,不过 TiDB 针对 IDC 场景也给出了解法 TiDB Operator ,依赖本地磁盘 LPV ,而非远程存储。LPV 有易失性,TiKV 内置三副本特性,正好补充这块的不足。类似的还有 Kafka 的多副本机制。但对于其它不具备三副本的基础服务,进 k8s 没那么容易了,必须面临两难选择:本地磁盘 需要自己解决多副本问题;远程磁盘 性能不高,将有很大的性能损耗。靠远程存储自身来解决这个性能问题,看起来非常难跨越。
    me1onsoda
        23
    me1onsoda  
       306 天前
    云 rds 不都是容器云化,有什么不能的?看运维水平了
    ychost
        24
    ychost  
       306 天前
    主要看运维能力,熟悉容器的话,放容器里面没啥问题
    xuanbg
        25
    xuanbg  
       306 天前
    容器化部署快,真的 1 秒完成。
    louisxxx
        26
    louisxxx  
       306 天前 via iPhone
    容器里面存储性能跟得上就行
    blueTrain
        27
    blueTrain  
       306 天前 via iPhone
    了解一下 matrixone
    hezhiming1993
        28
    hezhiming1993  
       298 天前
    @mh494078416
    Kafka 、Redis 这类凡是 有状态的, 是不是都不适合放入 K8S ?
    julyclyde
        29
    julyclyde  
       298 天前
    @hezhiming1993 redis 如果纯内存模式(不存盘)、kafka 集群模式
    我觉得也还好吧
    YzSama
        30
    YzSama  
       294 天前 via iPhone
    我倾向于 k8s ,未来更多的是声明式部署。通过 operator 去检测更新服务。这个趋势越来越明显了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5070 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 08:33 · PVG 16:33 · LAX 00:33 · JFK 03:33
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.