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

[sud0day]

[dx3759]

原地升级方案介绍：

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

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

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

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

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

[gam2046]

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

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

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

[MuSit]

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

[MuSit]

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

[MuSit]

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

[singer]

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

[golangLover]

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

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

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

[kiddingU]

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

[golangLover]

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

[kiddingU]

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