作者回复: 感谢总结补充更多场景。 1. 负载不均衡问题,k8s apiserver新增了--goaway-chance参数来缓解。 To prevent HTTP/2 clients from getting stuck on a single apiserver, randomly close a connection (GOAWAY). The client's other in-flight requests won't be affected, and the client will reconnect, likely landing on a different apiserver after going through the load balancer again. 2. 4-可以调大apiserver watch cache size来缓解。 3. 5-request is too large问题一般是应用层来拆分解决,etcd大包请求读写性能都会下降比较厉害。 4. 更多apiserver稳定性的问题,可以参考下我之前在archsummit上分享的一个pdf. https://static001.geekbang.org/con/85/pdf/1890348645/file/%E8%85%BE%E8%AE%AF%E5%A4%A7%E8%A7%84%E6%A8%A1%E4%BA%91%E5%8E%9F%E7%94%9F%E5%B9%B3%E5%8F%B0%E7%A8%B3%E5%AE%9A%E6%80%A7%E5%AE%9E%E8%B7%B5-%E5%94%90%E8%81%AA.pdf
作者回复: 好问题,一般情况下,这个buffer是很小的,etcd异步goroutine每隔100ms会将一批写事务提交,提交后就可以清空buffer了哈。并发大的时候,拷贝这个buffer可能会耗点CPU,对性能有点影响,目前社区测试结果是影响可控的,并暴露了相关指标监控当前有多少个并发读事务。
作者回复: 推荐看下我的文章有状态服务如何容器化,里面有深入分析 https://mp.weixin.qq.com/s/TvZZVow5H9HwMrNBLLoSsQ
作者回复: 你好,你们用的什么版本etcd, 使用的api是v2还是v3? db文件多大? 目前我们在生产环境中一般30分钟备份一次到cos,还未发现导致读写请求延时影响业务的。如果snapshot save操作导致你们业务请求出现超时了,可以看看当时磁盘io延时是否有抖动。你也可以在etcd 3.5 learner上做snapshot操作, 不会影响任何投票成员节点。
作者回复: 你好,你是希望原地更新吗?还是希望pod ip重建后不变化, 原地升级可以参考下tapp和openkrusier的解决方案。 https://github.com/tkestack/tapp https://jimmysong.io/kubernetes-handbook/practice/in-place-update.html
作者回复: 嗯,是的,可以更详细点,比如为什么Continue字段能保证分页读和不带分页带效果是一样的呢?不漏数据,读取的都是同一个时间点的数据呢