从 2023 年 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 这样选择晚上的窗口期升级的，这点倒是没什么可说的，但是很少有直接原地升级的，基本上都是有备份升级的，流量也不会直接全部涌入升级后的集群的，要经过逐步验证才会切换到新集群的，原地升级我只能说是艺高人胆大了。