滴滴崩溃，损失几个亿的k8s 方案

起因从震惊吃瓜开始

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

简单整理下崩溃原因

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

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

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

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

DD的升级方案

通用的解决方案

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

问题一 集群规模过大

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

通用的方案

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

问题二 如何选择升级方案

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

通用的方案

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

问题三多控制节点

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

胡言乱语

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

最后希望各位程序员技术越来越稳，默默奉献的同时也能有自己的收获