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

滴滴史上最严重服务故障是因为“k8s”版本升级错误?

  •  
  •   sud0day · 145 天前 · 5250 次点击
    这是一个创建于 145 天前的主题,其中的信息可能已经有所发展或是发生改变。
    30 条回复    2023-12-27 11:02:40 +08:00
    sanxianA
        1
    sanxianA  
       145 天前 via Android
    好奇+1 ,但是一般这种 k8s 集群不是应该都有双活集群设计或者灾备设计的嘛
    kdd0063
        2
    kdd0063  
       145 天前
    难道生产环境敢直接 k8s 升大版本?这未免也太心大了。好歹搞个灰度环境用金丝雀策略试试水吧
    assassing
        3
    assassing  
       145 天前
    看了眼居然还在用 1.12 以下版本。
    控制节点升错了版本确实没有什么办法能回退,只能重建集群。估计开始还想着能不能降级回来,所以停了那么久。
    dianso
        4
    dianso  
       145 天前
    是升级 xp 的时候弄坏了,各种谣言
    NX2023
        5
    NX2023  
       145 天前
    想起来前几周的 Gopher China ((
    kuituosi
        7
    kuituosi  
       145 天前
    明显是借口,而且很长时间都没有恢复
    明显是数据出问题了,工程师修复数据太花时间了
    fujohnwang
        8
    fujohnwang  
       145 天前
    嘀嘀为啥也崩了这么长时间?
    https://afoo.me/posts/2023-11-29-didi-crash-badly.html
    gam2046
        9
    gam2046  
       145 天前
    运维问题导致中断服务不至于这么久,即使直接上生产,即使升崩了,即使整个集群重建,12 个小时还是太久了。

    个人偏向认为#7 说的数据问题的可能性更大。由于误操作或者其他原因导致生产数据被污染需要更久的恢复时间。

    网上有用户说故障期间,计费、派单等异常,虽然不知道滴滴是怎么设计的,但是以普遍理性而言,如果集群内部分服务降级甚至不可用,一般会导致依赖服务降级或不可用。但是出现短距离的打车出现千元的计费,猜起来确实更像数据被污染了。
    mightybruce
        10
    mightybruce  
       145 天前
    k8s 是包含服务注册、降级、也是很多服务配置中心以及元数据存储的地方
    滴滴技术在文章里写原地大版本升级,艺高人胆大,链接在下
    https://mp.weixin.qq.com/s/nMSIsS72fSXGqJO9Vy_Pfw
    xuanbg
        11
    xuanbg  
       145 天前
    @mightybruce 他们这两个方案,要么原地升级,要么全量替代,确实很极端。。。

    就不能用折衷方案?就是部署一套新的运维环境,这要不了几台机器。然后新环境上一个 node 就切一点流量,一会儿功夫也就切完了,只要不在这个过程中升级服务,哪里会有什么 P 事。

    因为作为生产者的服务和数据两个环境都是一样的,所以对消费者而言就无感。
    golangLover
        12
    golangLover  
       144 天前 via Android
    @mightybruce 他都能写出来了,肯定不是一个月前的升级了。。。
    kiddingU
        13
    kiddingU  
       144 天前
    @sanxianA master 节点在这个机房
    dyllen
        14
    dyllen  
       144 天前
    @golangLover
    @xuanbg 文章都一个月前的了,能公开写出来,升级工作肯定早就做完了。
    kiddingU
        15
    kiddingU  
       144 天前
    @dyllen 别人多机房多集群了?这种原地升级的本身就很极端。。。。
    wr410
        16
    wr410  
       144 天前
    根据我的经验,超过 1 小时恢复不了的问题都是数据库问题
    kiddingU
        17
    kiddingU  
       144 天前
    原地升级简直爆炸,不理解为啥不是单独新增机房慢慢迁移,出了事故就是这帮人自己背锅了,只能说艺高人胆大~
    golangLover
        18
    golangLover  
       144 天前 via Android
    @dyllen 对阿。这么多人都理解错了。。。还有说是 k8s 版本看错的,也有人信。真的什么有人都有
    kiddingU
        19
    kiddingU  
       144 天前
    @golangLover 文章写出来了,所有的机房所有的集群就都升级完了?一个公司的机房又不是一个,内网升级了部分机房,然后写出技术文章,有毛病吗?
    buffzty
        20
    buffzty  
       144 天前
    @gam2046 升级是很快 有些兼容问题很难解决 比如你升级了 k8s rook-ceph 就不兼容了 但是 rook 官网说它兼容 k8s 这个版本 实际上根本运行不了 在网上也找不到答案 只能慢慢看 ceph 源码 他们这 18 个小时要么是去找人了 要么就是去看源码了 可能就改一个参数就好了 但是这个参数官网没写 网上也搜不到
    dx3759
        21
    dx3759  
       144 天前
    原地升级方案介绍:

    只有一个 k8s 集群,将 master 和周边组件直接从 1.12 升级到 1.20 ;

    逐步将集群中的 node 也就是 kubelet 从 1.12 版本升级到 1.20 ;

    不做任何业务负载相关的操作,也就是 sts 和 pod 无需重建,其实的流量分布也不做操作,随着 node 升级流量天然就逐步从 1.12 切到 1.20 了;

    有问题的时候需要部分回滚 node 的 kubelet ,当出现全局性风险的时候需要全量回滚 master 和周边组件。

    他们一定充分测试了版本兼容性吧。
    gam2046
        22
    gam2046  
       144 天前
    @buffzty 之前我和阿里的老哥聊天,谈到过,如果线上遇到任何故障/bug ,哪怕只是文本错误,处理方案有且只有一种,回退。并不存在线上修 bug 的可能性,回退以后,测试环境继续修 bug ,然后重新走测试、上线流程。

    滴滴也是个独角兽企业了,大体流程上,不能够这么草率吧,线上业务都停了,然后找人在线上改 bug 。

    当然啦,也不排除集群设计的时候,降级困难甚至无法降级回退,只能硬着头皮在线上修吧
    MuSit
        23
    MuSit  
       144 天前 via Android
    我推测应该是这样 像滴滴这种高并发实时性强的业务肯定很多地方用的的是内存 cache 12 升 20 一开始服务起不来 修复起来后发现 sc 可能因为版本关系也重建了 缓存持久化
    MuSit
        24
    MuSit  
       144 天前 via Android
    的东西是存在 pv 里 也就是 pv 也都重建了 业务重启后面对全国服务重新 init cache 不亚于一次大规模 ddos 导致大量服务不正常
    MuSit
        25
    MuSit  
       144 天前 via Android
    测试集群可能没这么大的 cache 不会影响 或者之前测试升级时候升 sc 本来是在后边的版本进行 需要对
    pv 数据备份 误操作直接干上去导致数据都丢了
    singer
        26
    singer  
       144 天前 via iPhone
    滴滴的不知道是不是有隐藏 bug ,虽然爆发在 11 月 28 晚上,但我在 11 月 25 晚碰到了类似的情况。打了专车,司机定位就在我边上,就是死活找不到车。给司机打电话后,司机挂断电话。再次拨打电话号码变了,再拨打,再变。每次拨打都在通话中。
    golangLover
        27
    golangLover  
       140 天前 via Android
    @kiddingU 你仔细看一下滴滴的文章吧:

    目前已无损升级滴滴所有核心机房万级别的 node 和十万级别 pod ,且升级过程中业务完全无感,未发生一次故障。

    升级从来都是非核心然后到核心,也就是说他这个升级方案已经通过了非核心应用,以及所有核心应用的验证。
    kiddingU
        28
    kiddingU  
       139 天前
    @golangLover 吹的再好,也是发生了事故,别再这里抬杠,结果就是除了事故
    golangLover
        29
    golangLover  
       139 天前 via Android
    @kiddingU 有事故是事实。但把滴滴运维当普通人的言论, 什么看错 k8s 版本啊,是不是所有机房都升级完了才发文章之类,推敲一下就有答案了
    kiddingU
        30
    kiddingU  
       117 天前
    @golangLover 你在说神马?????你赢了。。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1171 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 23:09 · PVG 07:09 · LAX 16:09 · JFK 19:09
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.