通过滴滴技术博客:探寻造成此次P0故障的真正原因
1.最佳实践-使用Github Actions来构建跨平台容器镜像2.滚动更新和回滚部署在 Kubernetes 中的工作原理3.Kubernetes 中的服务注册与发现原理分析
4.通过滴滴技术博客:探寻造成此次P0故障的真正原因
5.从物理机到K8S:应用系统部署方式的演进及其影响6.如何基于 k8s做私有化部署7.一文搞定K8S监控告警平台选型8.如何通过port-forward命令在本地访问 k8s 集群服务9.什么是革命性技术eBPF?为什么可观测性领域都得用它10.在k8s中快速搭建基于Prometheus监控系统11.Prometheus 与 VictoriaMetrics对比12.什么是Helm?它是如何提升云原生应用私有化部署效率的13.十分钟教你在 k8s 中部署一个前后端应用2023年11月27日晚至2023年11月28日早晨,滴滴发生了长达12小时的P0级故障,导致滴滴核心业务都受到了影响,比如不显示定位无法打车、滴滴单车无法扫码等问题,期间滴滴进行了多次致歉
来源:https://weibo.com/2838754010/NuMAAaUEl
目前问题故障已经恢复,根据最新的消息得知造成此次事故的原因,是由于升级K8S 集群导致
那么在K8s升级过程中,遇到了那些问题,我们可以从滴滴弹性云基于 K8S 的调度实践 文章中看出一些原因
1. 集群体量大
最大集群规模已经远远超出了社区推荐的5千个 node 上限,有问题的爆炸半径大;
2. 版本升级跨度大
直接从1.12 升级到了1.20,跨越多个版本,有可能存在api不兼容的问题
3. 升级方式应该选择了原地升级
虽然滴滴有能力基于K8S二次开发,但是由于版本跨度较大,细节点较多,原地升级风险我觉得比替换升级
大不少。
比如集群版本已经升级为1.20,但是Node节点的kubelet
的版本还是 1.12,如果api不兼容,那么这个影响是非常大的,集群回滚又没有那么快。
基于以上三点P0故障就这样产生了,至于为什么不采用替换升级方式?
作者认为替换升级需要业务系统配合,推进困难
通常情况下,替换升级的风险最小,因为一旦出现问题,可以及时回滚,然而这种方式需要与业务系统进行配合改造。
对于像滴滴这样规模巨大的业务,让每个业务方逐一配合是非常困难的(也可能业务方核心人员被降本增效了)。
同时,如果替换升级出现问题,业务方也有一定的责任,因此干脆由运维团队来负责这个任务可能更为合适。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 实操Deepseek接入个人知识库
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· 【.NET】调用本地 Deepseek 模型
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库