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

此账号已注销
• 阅读 1097

作者

钟华,腾讯云专家工程师,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。

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

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

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

Istio 当前优化方案

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

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

这个方案本身是有效的。但这种方式在大规模场景下很难落地:首先这个方案需要用户提前配置服务间完整的依赖关系,大规模场景下的服务依赖关系很难梳理清楚,而且通常依赖关系也会随着业务的变化而变化。

Aeraki Lazy xDS

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

大规模服务网格性能优化 | Aeraki 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 性能测试

测试方案

大规模服务网格性能优化 | Aeraki 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。

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

接下来是内存对比,绿色数据表示开启按需加载后 envoy 的内存消耗,红色的是未开启的情况。900 pods 规模 mesh,envoy 内存减少 14M ,降低比例约 40%;一万 pods 规模 mesh,envoy 内存减少约 150M,降低比例约 60%。

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

随着服务可见性的限制,envoy 不会再接收全量的 xDS 更新,下图是在测试周期内 envoy 接收到 CDS 更新次数的对比,开启按需加载后,更新次数从 6 千次降低到了 1 千次。

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

小结

Lazy xDS 已经在 github 开源,请访问 lazyxds README了解如何使用。

Lazy xDS 功能还在持续演进,未来我们将支持多集群模式、ServiceEntry 按需加载等功能。

如果您希望了解更多关于 Aeraki 的内容,欢迎访问 Github 主页:https://github.com/aeraki-framework/aeraki

关于我们

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

福利:

①公众号后台回复【手册】,可获得《腾讯云原生路线图手册》&《腾讯云原生最佳实践》~

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

③公众号后台回复【白皮书】,可获得《腾讯云容器安全白皮书》&《降本之源-云原生成本管理白皮书v1.0》

点赞
收藏
评论区
推荐文章
Effective HPA:预测未来的弹性伸缩产品
作者胡启明,腾讯云专家工程师,专注Kubernetes、降本增效等云原生领域,Crane核心开发工程师,现负责成本优化开源项目Crane开源治理和弹性能力落地工作。余宇飞,腾讯云专家工程师,专注云原生可观测性、成本优化等领域,Crane核心开发者,现负责Crane资源预测、推荐落地、运营平台建设等相关工作。田奇,腾讯高级工程师,专注分布式资源管
blmius blmius
3年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
皕杰报表之UUID
​在我们用皕杰报表工具设计填报报表时,如何在新增行里自动增加id呢?能新增整数排序id吗?目前可以在新增行里自动增加id,但只能用uuid函数增加UUID编码,不能新增整数排序id。uuid函数说明:获取一个UUID,可以在填报表中用来创建数据ID语法:uuid()或uuid(sep)参数说明:sep布尔值,生成的uuid中是否包含分隔符'',缺省为
KubeCon 2021|使用 eBPF 代替 iptables 优化服务网格数据面性能
作者刘旭,腾讯云高级工程师,专注容器云原生领域,有多年大规模Kubernetes集群管理及微服务治理经验,现负责腾讯云服务网格TCM数据面产品架构设计和研发工作。引言目前以Istioiptables实现流量劫持首先看一下当前社区使用的基于iptables的流量劫持方案,下图是一个Pod的创建过程,sidecarinjector会向
光速从0到1掌握Prometheus和Grafana,腾讯云专家5万字精华教程免费送
作者黄雷,腾讯云高级工程师,曾负责构建腾讯云云监控新一代多维业务监控系统,擅长大规模分布式监控系统设计,对golang后台项目架构设计有较深理解,后加入TKE团队,致力于研究Kubernetes相关运维技术,拥有多年Kubernetes集群联邦运维管理经验,目前在团队主要负责大规模集群联邦可观测性提升,主导研发了腾讯云万级Kubernetes
Stella981 Stella981
2年前
Service Mesh 最火项目: Istio 架构解析
Istio是一个开源的服务网格,可为分布式微服务架构提供所需的基础运行和管理要素。随着各组织越来越多地采用云平台,开发者必须使用微服务设计架构以实现可移植性,而运维人员必须管理包含混合云部署和多云部署的大型分布式应用。Istio采用一种一致的方式来保护、连接和监控微服务,降低了管理微服务部署的复杂性。从架构设计上来看,Istio服务网格在逻辑上分为
Stella981 Stella981
2年前
Istio Sidecar注入原理
概念简单来说,Sidecar注入会将额外容器的配置添加到Pod模板中。这里特指将Envoy容器注应用所在Pod中。Istio服务网格目前所需的容器有:istioinit用于设置iptables规则,以便将入站/出站流量通过Sidecar代理。初始化容器与应用程序容器在以下方面有所不同:
Stella981 Stella981
2年前
Redis 备份、容灾及高可用实战
郝朝阳,宜搜科技,运维工程师,负责前端运维工作。专注于运维自动化的实现。致力于DevOps思想的推广,帮助企业形成形成自有文化的运维体系建设。一,Redis简单介绍Redis是一个高性能的keyvalue非关系型数据库,由于其具有高性能的特性,支持高可用、持久化、多种数据结构、集群等,使其脱颖而出,成为常用的非关系型数据库。此
Stella981 Stella981
2年前
Android蓝牙连接汽车OBD设备
//设备连接public class BluetoothConnect implements Runnable {    private static final UUID CONNECT_UUID  UUID.fromString("0000110100001000800000805F9B34FB");
精彩分享 | 欢乐游戏 Istio 云原生服务网格三年实践思考
作者吴连火,腾讯游戏专家开发工程师,负责欢乐游戏大规模分布式服务器架构。有十余年微服务架构经验,擅长分布式系统领域,有丰富的高性能高可用实践经验,目前正带领团队完成云原生技术栈的全面转型。导语欢乐游戏这边对istio服务网格的引进,自2019开始,从调研到规模化落地,至今也已近三年。本文对实践过程做了一些思考总结,期望能给对网格感兴趣的同学们以参考