2023年11月27日晚至2023年11月28日早晨，滴滴发生了长达12小时的P0级故障，导致滴滴核心业务都受到了影响，比如不显示定位无法打车、滴滴单车无法扫码等问题，期间滴滴进行了多次致歉

目前问题故障已经恢复，根据最新的消息得知造成此次事故的原因，是由于升级K8S 集群导致

那么在K8s升级过程中，遇到了那些问题，我们可以从滴滴弹性云基于 K8S 的调度实践 文章中看出一些原因

1. 集群体量大

最大集群规模已经远远超出了社区推荐的5千个 node 上限，有问题的爆炸半径大；

2. 版本升级跨度大

直接从1.12 升级到了1.20，跨越多个版本，有可能存在api不兼容的问题

3. 升级方式应该选择了原地升级

虽然滴滴有能力基于K8S二次开发，但是由于版本跨度较大，细节点较多，原地升级风险我觉得比替换升级 大不少。

比如集群版本已经升级为1.20，但是Node节点的kubelet的版本还是 1.12，如果api不兼容，那么这个影响是非常大的，集群回滚又没有那么快。

基于以上三点P0故障就这样产生了，至于为什么不采用替换升级方式？

作者认为替换升级需要业务系统配合，推进难

通常情况下，替换升级的风险最小，因为一旦出现问题，可以及时回滚，然而这种方式需要与业务系统进行配合改造。

对于像滴滴这样规模巨大的业务，让每个业务方逐一配合是非常困难的(也可能业务方核心人员被降本增效了)。

同时，如果替换升级出现问题，业务方也有一定的责任，因此干脆由运维团队来负责这个任务可能更为合适。