造成滴滴损失几十个亿的k8s 方案

点击关注公众号：互联网架构师，后台回复 2T获取2TB学习资源！

上一篇：2T架构师学习资料干货分享

大家好，我是互联网架构师！

背景

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

造成奔溃的原因

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

图片

不过，后来内部人员说是K8s升级版本的问题。

图片

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

修复方案

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

问题一 集群规模过大

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

通用的方案

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

问题二 如何选择升级方案

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

通用的方案

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

问题三多控制节点

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

最后，关注公众号互联网架构师，在后台回复：2T，可以获取我整理的 Java 系列面试题和答案，非常齐全。

正文结束

推荐阅读 ↓↓↓

1.JetBrains 如何看待自己的软件在中国被频繁破解?

2.无意中发现了一位清华妹子的资料库！

3.程序员一般可以从什么平台接私活？

4.40岁，刚被裁，想说点啥。

5.为什么国内 996 干不过国外的 955呢？

6.中国的铁路订票系统在世界上属于什么水平？                        

7.15张图看懂瞎忙和高效的区别！