大规模服务网格性能优化 | Aeraki xDS 按需加载

最新推荐文章于 2024-08-31 09:26:13 发布

「已注销」

最新推荐文章于 2024-08-31 09:26:13 发布

阅读量477

点赞数

文章标签： K8S Prometheus Istio Serverless containerd Etcd Pod TKE 云原生腾讯云原生边缘集群最佳实践 kubernetes 云计算 docker 容器经验分享

本文链接：https://blog.csdn.net/yunxiao6/article/details/122071056

版权

本文介绍了在大规模服务网格场景下，Istio xDS的性能瓶颈以及现有优化方案的局限性。腾讯云团队提出了Aeraki Lazy xDS，这是一种无入侵的按需加载方案，有效降低了sidecar内存消耗并提升了性能。通过Egress和Controller组件，实现了服务依赖的动态分析和xDS数据的按需下发，避免了全量更新带来的开销。性能测试显示，该方案能显著降低envoy内存使用，并减少了xDS更新次数。

摘要由CSDN通过智能技术生成

作者

钟华，腾讯云专家工程师，Istio project member、contributor，专注于容器和服务网格，在容器化和服务网格生产落地方面具有丰富经验，目前负责 Tencent Cloud Mesh 研发工作。

Istio 在大规模场景下 xDS 性能瓶颈

xDS 是 istio 控制面和数据面 envoy 之间的通信协议，x 表示包含多种协议的集合，比如：LDS 表示监听器，CDS 表示服务和版本，EDS 表示服务和版本有哪些实例，以及每个服务实例的特征，RDS 表示路由。可以简单的把 xDS 理解为，网格内的服务发现数据和治理规则的集合。xDS 数据量的大小和网格规模是正相关的。

当前 istio 下发 xDS 使用的是全量下发策略，也就是网格里的所有 sidecar，内存里都会有整个网格内所有的服务发现数据。比如下图，虽然 workload 1 在业务逻辑上只依赖 service 2，但是 istiod 会把全量的服务发现数据（service 2、3、4）都发送给 workload 1。

这样的结果是，每个 sidecar 内存都会随着网格规模增长而增长，下图是我们对网格规模和内存消耗做的一个性能测试，x 轴是网格规模，也就是包含多少个服务实例，y 轴是单个 envoy 的内存消耗。可以看出，如果网格规模超过 1万个实例，单个 envoy 的内存超过了 250 兆，而整个网格的开销还要再乘以网格规模大小。