近期互联网故障频发，各大公众号各抒己见，指点江山，激扬文字，颇有百花齐放，百家争鸣的味道。一众吃瓜群众也是对此乐此不疲，津津乐道。 大家能够积

背景 前面我们已经对 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