关于腾讯云:大规模服务网格性能优化-Aeraki-xDS-按需加载

作者

钟华，腾讯云专家工程师，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 兆，而整个网格的开销还要再乘以网格规模大小。

Istio 以后优化计划

针对这个问题，社区提供了一个计划，就是 Sidecar 这个 CRD，这个配置能够显式的定义服务之间的依赖关系，或者说可见性关系。比方下图这个配置的意思就是 workload 1 只依赖 service 2，这样配置当前，istiod 只会下发 service 2 的信息给 workload 1。

这个计划自身是无效的。但这种形式在大规模场景下很难落地：首先这个计划须要用户提前配置服务间残缺的依赖关系，大规模场景下的服务依赖关系很难梳理分明，而且通常依赖关系也会随着业务的变动而变动。

Aeraki Lazy xDS

针对上述问题，TCM 团队设计了一套无入侵的 xDS 按需加载计划，并开源到 github Aeraki 我的项目，这是 Lazy xDS 具体的实现细节：

咱们在网格里减少 2 个组件，一个是 Lazy xDS Egress，Egress 充当相似网格模型中默认网关角色，另一个是 Lazy xDS Controller，用来剖析并补全服务间的依赖关系。

1. 首先配置 Egress 的服务直达能力：Egress 会获取网格内所有服务信息，并配置所有 HTTP 服务的路由，这样充当默认网关的 Egress 就能够转发网格内任意 HTTP 服务的流量。
2. 第 2 步，对于开启了按需加载个性的服务（图中 Workload 1），利用 envoyfilter，将其拜访网格内 http 服务的流量，都路由到 egress。
3. 第 3 步，利用 istio sidecar CRD，限度 Workload 1 的服务可见性。
4. 通过步骤 3 后，Workload 1 初始只会加载最小化的 xDS。
5. 当 Workload 1 发动对 Service 2 的拜访时，（因为步骤 2）流量会转发到 Egress。
6. （因为步骤 1）Egress 会剖析接管到的流量特色，并将流量转发到 Service 2。
7. Egress 会将拜访日志，异步地上报给 Lazy xDS Controller，上报服务是利用 Access Log Service。
8. Lazy xDS Controller 会对接管到的日志进行拜访关系剖析，而后把新的依赖关系（Workload 1 -> Service 2）表白到 sidecar CRD 中。
9. 同时 Controller 还会将（步骤 2）Workload 1 须要转发 Service 2 流量到 Egress 的规定去除，这样将来 workload 1 再次拜访 Service 2 就会是直连。
10. （因为步骤 8）istiod 更新可见性关系，后续会将 Service 2 的服务信息发给 Workload 1。
11. Workload 1 通过 xDS 接管到 Service 2 的服务信息。
12. 当 Workload 1 再次发动对 Service 2 的拜访，流量会中转 Service 2（因为步骤 9）。

这个计划的益处：

• 首先不须要用户提前配置服务间的依赖，而且服务间依赖是容许动静的减少的。
• 最终每个 envoy 只会取得本身须要的 xDS，性能最优。
• 这个实现对用户流量影响也比拟小，用户的流量不会阻塞。性能损耗也比拟小，只有前几次申请会在 Egress 做直达，前面都是直连的。
• 此计划对 istio 和 envoy 没有任何入侵，咱们没有批改 istio/envoy 源码，使得这套计划能很好的适应将来 istio 的迭代。

目前咱们只反对七层协定服务的按需加载，起因是流量在 Egress 这里直达的时候，Egress 须要通过七层协定里的 header 判断原始目的地。纯 TCP 协定是没有方法设置额定的 header。不过因为 istio 次要目标就是为了做七层流量的治理，当网格的大部分申请都是七层的，这个状况目前能够承受的。

Lazy xDS 性能测试

测试计划

在同一网格内的不同 namespace 中，咱们创立了 2 组 book info，右边 namespace lazy-on 中 productpage 开启按需加载，左边 namespace lazy-off 放弃默认状况。

而后在这个网格内，咱们逐步减少服务数量，应用的是 istio 官网负载测试工具集（以下简称「负载服务」），每个 namespace 里有 19 个服务，其中 4 个 tcp 服务，15 个 http 服务，每个服务初始 pod 数目为 5，共 95 个 pod（75 个 http，20 个 tcp）。咱们逐步减少负载服务的 namespace 数量，用于模仿网格规模增长。

性能比照

首先是 CDS 和 EDS 的比照，下图每组数据代表负载服务 namespace 的减少，每组数据里 4 个值：前 2 个值是开启按需加载后的 CDS 和 EDS，前面 2 个值是没开启按需加载的 CDS 和 EDS。

接下来是内存比照，绿色数据表示开启按需加载后 envoy 的内存耗费，红色的是未开启的状况。900 pods 规模 mesh，envoy 内存缩小 14M，升高比例约 40%；一万 pods 规模 mesh，envoy 内存缩小约 150M，升高比例约 60%。

随着服务可见性的限度，envoy 不会再接管全量的 xDS 更新，下图是在测试周期内 envoy 接管到 CDS 更新次数的比照，开启按需加载后，更新次数从 6 千次升高到了 1 千次。

小结

Lazy xDS 曾经在 github 开源，请拜访 lazyxds README 理解如何应用。

Lazy xDS 性能还在继续演进，将来咱们将反对多集群模式、ServiceEntry 按需加载等性能。

如果您心愿理解更多对于 Aeraki 的内容，欢送拜访 Github 主页：https://github.com/aeraki-fra…

对于咱们

更多对于云原生的案例和常识，可关注同名【腾讯云原生】公众号~

福利：

①公众号后盾回复【手册】，可取得《腾讯云原生路线图手册》&《腾讯云原生最佳实际》~

②公众号后盾回复【系列】，可取得《15 个系列 100+ 篇超实用云原生原创干货合集》，蕴含 Kubernetes 降本增效、K8s 性能优化实际、最佳实际等系列。

③公众号后盾回复【白皮书】，可取得《腾讯云容器平安白皮书》&《降本之源 - 云原生老本治理白皮书 v1.0》

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！