真相了，滴滴崩溃竟是因为K8s升级？

👉 欢迎加入小哈的星球 ，你将获得: 专属的项目实战/ Java 学习路线 / 一对一提问 / 学习打卡/  赠书福利

全栈前后端分离博客项目 1.0 版本完结啦，2.0 正在更新中...，全程手摸手，后端 + 前端全栈开发，从 0 到 1 讲解每个功能点开发步骤，1v1 答疑，直到项目上线。目前已更新了163小节，累计26w+字，讲解图：1105张，还在持续爆肝中.. 后续还会上新更多项目，目标是将Java领域典型的项目都整一波，如秒杀系统, 在线商城, IM即时通讯，Spring Cloud Alibaba 等等，戳我加入学习，已有580+小伙伴加入(早鸟价超低)

11 月 27 日晚上 10 点左右截止 2023 年 11 月 28 日中午 12 点期间，DD发生了长达12小时的p0级bug，造成的影响大家通过各种平台或者亲身经历如何我就不多说了，单说对企业造成的损失超千万单和超4个亿的交易额。我只想说不愧是大企业，这也太狠了

简单整理下崩溃原因

DD自己在微博上说的是底层系统软件发生故障，身为底层开发的我对此还是挺感兴趣的，所以简单吃了下瓜，网传是滴滴未正常升级k8s导致集群崩溃，且由于集群规模过大(相信这么大规模集群一定跑着相当多的业务)导致造成影响肯定很大

DD在微博的致歉中说是底层系统软件故障

网传是因为升级导致的故障

恰巧DD技术在公众号上曾经发布过一篇# DD弹性云基于 K8S 的调度实践文章，文章里介绍了他们选择的升级方案，以及如此选择升级方案的原因

DD的升级方案

dd 不愧是大厂，还有这么老版本的k8s集群，估计是很早就开始引入k8s集群了。

通用的解决方案

首先两种方案的对比，DD已经在他们的技术文章中给明了优缺点，身为一个菜鸟我估计是不适合评论别人的方案，所以我只从我实际工作中遇到类似的问题是如何解决的，

问题一 集群规模过大

kubernetes 官方推荐了5000个node 上限，虽然并不代表超出上限一定会出问题，但是此次事故明显告诉我们超出上限的集群一旦发生事故有多可怕了

通用的方案

实际生产环境当集群规模达到上限我们一般是怎么处理的呢，很简单——联邦集群，让多个集群打通成联邦集群，网络和k8s资源互通，提高了业务容纳的上限，同时将风险分摊给多个集群。增加了些许运维压力，但是明显要比疯狂给单个集群加节点要安全多了

问题二 如何选择升级方案

目前我遇到的大规模集群，基本上都是像dd 这样选择晚上的窗口期升级的，这点倒是没什么可说的，但是很少有直接原地升级的，基本上都是有备份升级的，流量也不会直接全部涌入升级后的集群的，要经过逐步验证才会切换到新集群的，原地升级我只能说是艺高人胆大了。

通用的方案

从dd 的技术博文上能猜出来，原地升级的方案肯定是经过他们内部验证了，最起码短期内是没出问题，才敢拿到生产集群上实践，但是很抱歉生产集群的扛风险能力还是太小了，所以还是建议老老实实选择替换升级的方案吧

问题三多控制节点

最后一点就是网传的控制节点崩溃的问题，我觉得这太离谱了，这种大厂应该知道多master 节点，以及master 不在同一机房的问题吧，不说多数据中心方案，基本的灾备思想还是要有的吧

胡言乱语

最近好像很多大厂的产品崩溃，先是阿里后是滴滴，加上最近的裁员潮，网上流出了很多笑话最知名的莫过开猿节流，降本增笑。诚然互联网企业最大成本就是人力成本，当业务成熟后开掉开发人员来降低成本似乎是一个不错的方案。但是当企业剩下的大部分都是ppt高手，真正干活的人黯然退场。如此这般难免会遇到这样那样的技术问题。希望老板领导们能慎重裁员，尊重技术。