近期互联网故障频发,各大公众号各抒己见,指点江山,激扬文字,颇有百花齐放,百家争鸣的味道。一众吃瓜群众也是对此乐此不疲,津津乐道。 大家能够积
背景 前面我们已经对 kube-apiserver 内存消耗 进行了阐述,文中最后提到了使用流式的请求来支持 List 的效果,从而实现对于单个请求来说,空间复杂度从 O(n) 转换成 O(1),
继阿里云之后,滴滴崩了上了热搜,故障原因了解了一些,会在文章最后谈到。近期国内多个公司发生了 P0 事故,当然也包括我司,只不过可能不出名,很多人
转自知乎 https://zhuanlan.zhihu.com/p/408731614,略有修改 背景与挑战 背景 大型互联网公司内部资源池非常庞大
背景 前面我们已经对 kube-apiserver 内存消耗进行了阐述,文中最后提到了使用流式的请求来支持 List 的效果,从而实现对于单个请求来说,空间复杂度从 O(n) 转换成 O(1),
背景 前两篇已经介绍过 Informer 和 Cacher 的实现,也介绍了其中存在的一些问题,本篇主要针对 Stale read 问题展开,分析新版 Informer & Kube-apiserver 中是如何解决这个问题的。 如果对 Informer 和 Kube-apiserver WatchCache