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

[sud0day]

[sanxianA]

好奇+1 ，但是一般这种 k8s 集群不是应该都有双活集群设计或者灾备设计的嘛

[kdd0063]

难道生产环境敢直接 k8s 升大版本？这未免也太心大了。好歹搞个灰度环境用金丝雀策略试试水吧

[assassing]

看了眼居然还在用 1.12 以下版本。
控制节点升错了版本确实没有什么办法能回退，只能重建集群。估计开始还想着能不能降级回来，所以停了那么久。

[dianso]

是升级 xp 的时候弄坏了，各种谣言

[NX2023]

想起来前几周的 Gopher China （（

[NX2023]

@NX2023 滴滴着重介绍了他们是怎么升级 k8s 版本的（（

https://github.com/gopherchina/conference/blob/master/2023-shanghai/1.1.2%E6%BB%B4%E6%BB%B4%E5%BC%B9%E6%80%A7%E4%BA%91%E5%9F%BA%E4%BA%8EK8S%E7%9A%84%E8%B0%83%E5%BA%A6%E5%AE%9E%E8%B7%B5.pdf

[kuituosi]

明显是借口，而且很长时间都没有恢复
明显是数据出问题了，工程师修复数据太花时间了

[fujohnwang]

嘀嘀为啥也崩了这么长时间？
https://afoo.me/posts/2023-11-29-didi-crash-badly.html

[gam2046]

运维问题导致中断服务不至于这么久，即使直接上生产，即使升崩了，即使整个集群重建，12 个小时还是太久了。

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

网上有用户说故障期间，计费、派单等异常，虽然不知道滴滴是怎么设计的，但是以普遍理性而言，如果集群内部分服务降级甚至不可用，一般会导致依赖服务降级或不可用。但是出现短距离的打车出现千元的计费，猜起来确实更像数据被污染了。

[mightybruce]

k8s 是包含服务注册、降级、也是很多服务配置中心以及元数据存储的地方
滴滴技术在文章里写原地大版本升级，艺高人胆大，链接在下
https://mp.weixin.qq.com/s/nMSIsS72fSXGqJO9Vy_Pfw

[xuanbg]

@mightybruce 他们这两个方案，要么原地升级，要么全量替代，确实很极端。。。

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

因为作为生产者的服务和数据两个环境都是一样的，所以对消费者而言就无感。

[golangLover]

@mightybruce 他都能写出来了，肯定不是一个月前的升级了。。。

[kiddingU]

@sanxianA master 节点在这个机房

[dyllen]

@golangLover
@xuanbg 文章都一个月前的了，能公开写出来，升级工作肯定早就做完了。

[kiddingU]

@dyllen 别人多机房多集群了？这种原地升级的本身就很极端。。。。

[wr410]

根据我的经验，超过 1 小时恢复不了的问题都是数据库问题

[kiddingU]

原地升级简直爆炸，不理解为啥不是单独新增机房慢慢迁移，出了事故就是这帮人自己背锅了，只能说艺高人胆大~

[golangLover]

@dyllen 对阿。这么多人都理解错了。。。还有说是 k8s 版本看错的，也有人信。真的什么有人都有

[kiddingU]

@golangLover 文章写出来了，所有的机房所有的集群就都升级完了？一个公司的机房又不是一个，内网升级了部分机房，然后写出技术文章，有毛病吗？

[buffzty]

@gam2046 升级是很快 有些兼容问题很难解决 比如你升级了 k8s rook-ceph 就不兼容了 但是 rook 官网说它兼容 k8s 这个版本 实际上根本运行不了 在网上也找不到答案 只能慢慢看 ceph 源码 他们这 18 个小时要么是去找人了 要么就是去看源码了 可能就改一个参数就好了 但是这个参数官网没写 网上也搜不到