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

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

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

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

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

想起来前几周的 Gopher China （（

@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

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

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

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

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

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

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

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

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

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

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

@sanxianA master 节点在这个机房

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

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

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

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

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

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

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

原地升级方案介绍：

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

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

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

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

他们一定充分测试了版本兼容性吧。

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

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

当然啦，也不排除集群设计的时候，降级困难甚至无法降级回退，只能硬着头皮在线上修吧

我推测应该是这样 像滴滴这种高并发实时性强的业务肯定很多地方用的的是内存 cache 12 升 20 一开始服务起不来 修复起来后发现 sc 可能因为版本关系也重建了 缓存持久化

的东西是存在 pv 里 也就是 pv 也都重建了 业务重启后面对全国服务重新 init cache 不亚于一次大规模 ddos 导致大量服务不正常

测试集群可能没这么大的 cache 不会影响 或者之前测试升级时候升 sc 本来是在后边的版本进行 需要对
pv 数据备份 误操作直接干上去导致数据都丢了

滴滴的不知道是不是有隐藏 bug ，虽然爆发在 11 月 28 晚上，但我在 11 月 25 晚碰到了类似的情况。打了专车，司机定位就在我边上，就是死活找不到车。给司机打电话后，司机挂断电话。再次拨打电话号码变了，再拨打，再变。每次拨打都在通话中。

@kiddingU 你仔细看一下滴滴的文章吧:

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

升级从来都是非核心然后到核心，也就是说他这个升级方案已经通过了非核心应用，以及所有核心应用的验证。

@golangLover 吹的再好，也是发生了事故，别再这里抬杠，结果就是除了事故

@kiddingU 有事故是事实。但把滴滴运维当普通人的言论, 什么看错 k8s 版本啊，是不是所有机房都升级完了才发文章之类，推敲一下就有答案了

@golangLover 你在说神马？？？？？你赢了。。