20 | Kubernetes高级应用：如何优化业务场景使etcd能支撑上万节点集群？
该思维导图由 AI 生成，仅供参考
大集群核心问题分析
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
Kubernetes和etcd在优化大规模集群场景中采取了一系列措施，包括分页、资源按namespace拆分、Informer机制、Watch bookmark机制、更高效的Watch恢复机制等，以及引入Lease对象和EndpointSlice概念，成功解决了大规模集群面临的问题。同时，etcd 3.4版本实现了并发读特性和改善Watch Notify机制，显著提升了etcd在Kubernetes场景下的稳定性和性能。这些优化措施和特性的引入，有效降低了expensive request对系统性能的影响，解决了db size和key-value大小的瓶颈，为大规模集群的稳定性和性能提升提供了重要支持。文章还提出了两个思考题，引发读者对Kubernetes集群中的数据完整性和一致性、以及稳定性、性能等问题的思考和讨论。整体而言，本文深入剖析了Kubernetes和etcd在优化大规模集群场景中的关键措施和特性，对于读者快速了解和应用这些优化技术具有重要指导意义。
《etcd 实战课》，新⼈⾸单¥59
全部留言(11)
- 最新
- 精选
- Geek_e5cec2支持和生产用差距很大、etcd不改造、还是有差距、感觉讲的不透。生产最大问题还是APIserver负载问题： 1.默认情况下APIserver endpoints过多、本身k8s的负载即使是轮训其实本身而言是不均衡的、很容易APIserver长时间后oom、因为大部分是长链接。这个时候最合适的是最小链接访问。需要依赖lb之类的 2.APIserver in cluster访问容易出问题、in cluster走的一般是service ip。这时候很容易有netfilter问题、不管走的是iptables或者ipvs。 3.in cluster也会负载不均衡、因为endpoints也是轮询。轮询不是最小链接轮询。这里不换成lb还是很难。 4. 极端情况下会触发 list -> watch -> too old resource version -> list 的恶性循环。 5. etcdserver: request is too large问题、本身APIserver序列化的问题。 6.还有日志输出不合理导致APIserver抖动等等。
作者回复: 感谢总结补充更多场景。 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
2022-04-307 
写点啥呢请问老师，etcd的并发读特性由于会复制写事务的内存，在并发量大的时候是不是会进一步加大内存压力，导致OOM的风险？作者回复: 好问题，一般情况下，这个buffer是很小的，etcd异步goroutine每隔100ms会将一批写事务提交，提交后就可以清空buffer了哈。并发大的时候，拷贝这个buffer可能会耗点CPU，对性能有点影响，目前社区测试结果是影响可控的，并暴露了相关指标监控当前有多少个并发读事务。
2021-03-055- InfoQ_aeed61b02780老师，我理解etcd的一次snapshot save也就是一次expensive request。 目前我们通过snapshot save备份任务时固定出现"request result took too long"的问题，请问下老师，这块有哪些优化的空间呢？
作者回复: 你好，你们用的什么版本etcd, 使用的api是v2还是v3? db文件多大? 目前我们在生产环境中一般30分钟备份一次到cos,还未发现导致读写请求延时影响业务的。如果snapshot save操作导致你们业务请求出现超时了，可以看看当时磁盘io延时是否有抖动。你也可以在etcd 3.5 learner上做snapshot操作, 不会影响任何投票成员节点。
2021-08-122 - 13950387940不不不，不是原地升级呢。我之前表达的不是很明确，是这样的。 node节点只要一重启，重启后该node上所有的docker容器都会重新创建，我的容器是有状态服务，里面存在数据。所以我不想他这么做，找了很多资料都没这方面的解决办法
作者回复: 推荐看下我的文章有状态服务如何容器化，里面有深入分析 https://mp.weixin.qq.com/s/TvZZVow5H9HwMrNBLLoSsQ
2021-09-151 - 13950387940老师你好，我想问一下您，我也是做云平台的。 我想问一下k8s上创建的pod基于docker的，重启之后pod里的docker就会重建。查资料也没有什么解决办法，看日志是因为重启后pod ip的原因，不知道老师是否有遇到这样的问题，希望能指点一二
作者回复: 你好，你是希望原地更新吗？还是希望pod ip重建后不变化, 原地升级可以参考下tapp和openkrusier的解决方案。 https://github.com/tkestack/tapp https://jimmysong.io/kubernetes-handbook/practice/in-place-update.html
2021-08-26 
Simon思考题: 应该是能保证的, apiserver会把continueToken返回到client, client发现返回的结果中continueToken不为空时, 下次请求会带着continueToken请求apiserver 请问老师是这样的吗?作者回复: 嗯，是的，可以更详细点，比如为什么Continue字段能保证分页读和不带分页带效果是一样的呢？不漏数据，读取的都是同一个时间点的数据呢
2021-03-054
WGJ老师,Kubernetes 为了维持上万节点的心跳，会产生大量写请求, 这句话中的心跳请求为什么也算是写请求,会触发写的动作吗2023-04-23归属地：广东- Geek_acb401赞2022-07-24
Tendrun这个watchCache的维护流程老师可以介绍下么，比如这个cache初始化的时候是如何选择数据的，比如缓存了pod类型的数据，那么这么多pod对象从那个版本开始缓存呢？或者list之后缓存全部版本数据么，但是好像这个缓存都大小的，合适不合适缓存全部数据呢？而且如果缓存过小，如果连当前所有pod的最新一个版本的数据都缓存不了，那这个时候怎么办呢2022-04-21
Trouble man总结的太好！2021-07-03
