使用eBPF加速阿里云服务网格ASM-阿里云开发者社区

背景

随着云原生应用架构的快速发展，微服务架构已经成为了构建现代应用的主要方式之一。而在微服务架构中，服务间的通信变得至关重要。为了实现弹性和可伸缩性，许多组织开始采用服务网格技术来管理服务之间的通信。

Istio作为目前最受欢迎的服务网格之一，提供了一套强大的功能，以简化服务网格的管理和操作。它通过引入一组专门的代理（即Sidecar）来实现在服务之间进行流量管理、监控和安全控制等功能。

在Istio中，Sidecar是一种特殊的代理，它与每个服务实例一起部署，并负责处理该实例与其他服务之间的通信。它位于服务容器内部，与应用程序实例一同运行，并通过拦截和转发网络流量来提供服务网格的功能。

然而，正因为Sidecar与每个服务实例一同运行，它也可能引入一些潜在的性能问题，其中一个主要问题就是延迟。

由于每个服务实例都需要与其对应的Sidecar进行通信，这增加了请求路径的长度和网络延迟。此外，Sidecar还要负责执行各种功能，如流量管理、监控和安全控制等，这也会对性能产生一定的影响。

针对Sidecar引入的延迟问题，业内常用采用eBPF sockops 技术来优化，在同一个节点下，短路两个进程间的socket 通信，也就是让tcp 报文不用经过TCP/IP 协议栈。加速后的流量路径示意图如下：

阿里云服务网格最近上线了sidecar 加速组件, 接下来我们来测试验证下，特别是对比其开启前后实际的加速效果。

安装部署和环境介绍

环境准备

首先，按照文档，创建一个ASM 实例，笔者采用当前ASM 最新版本v1.18 企业版

然后，创建一个ACK 集群，ASM sidecar 加速组件仅支持ACK 托管版本和ACK 专有版本集群。笔者创建了一个ACK托管版本实例，版本使用v1.26, 集群包含3节点，节点操作系统镜像使用了文档推荐的Alibaba Cloud Linux3。并把ACK 添加到ASM 实例下。

环境信息如下：

ASM 实例

ACK 集群

网络CNI 插件选用了terway

部署测试例子

这里采用了从istio 官方的benchmark 工具下抽离出的简化版压测程序。

---apiVersion: v1
kind: Service
metadata:  name: fortioserver
spec:  ports:  - name: http-echo
    port: 8080    protocol: TCP
  - name: tcp-echoa
    port: 8078    protocol: TCP
  - name: grpc-ping
    port: 8079    protocol: TCP
  selector:    app: fortioserver
  type: ClusterIP
---apiVersion: apps/v1
kind: Deployment
metadata:  labels:    app: fortioserver
  name: fortioserver
spec:  selector:    matchLabels:      app: fortioserver
  template:    metadata:      labels:        app: fortioserver
      annotations:        sidecar.istio.io/proxyCPULimit: 2000m
        proxy.istio.io/config: |          concurrency: 2    spec:      containers:      - name: captured
        image: fortio/fortio:latest_release
        ports:        - containerPort: 8080          protocol: TCP
        - containerPort: 8078          protocol: TCP
        - containerPort: 8079          protocol: TCP
---apiVersion: v1
kind: Service
metadata:  annotations:      service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-switch: "off"  name: fortioclient
spec:  ports:  - name: http-report
    port: 8080    protocol: TCP
  selector:    app: fortioclient
  type: LoadBalancer
---apiVersion: apps/v1
kind: Deployment
metadata:  labels:    app: fortioclient
  name: fortioclient
spec:  selector:    matchLabels:      app: fortioclient
  template:    metadata:      annotations:        sidecar.istio.io/proxyCPULimit: 4000m
        proxy.istio.io/config: |           concurrency: 4      labels:        app: fortioclient
    spec:      affinity:        podAffinity:          requiredDuringSchedulingIgnoredDuringExecution:          - labelSelector:              matchExpressions:              - key: app
                operator: In
                values:                - fortioserver
            topologyKey: "kubernetes.io/hostname"      containers:      - name: captured
        volumeMounts:        - name: shared-data
          mountPath: /var/lib/fortio
        image: fortio/fortio:latest_release
        args:        - report
        ports:        - containerPort: 8080          protocol: TCP
      volumes:      - name: shared-data
        emptyDir: {}

根据Sidecar Acceleration 组件文档提示，组件开启不能加速已有存量TCP 连接，因此，笔者通过DestinationRule 配置了客户端侧的相关连接池配置，通过设置连接的空闲时间30s 来保证前后多轮测试，连接总是新建的。（前后两轮测试间隔30s 以上即可）

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:  name: fortioserver
spec:  host: fortioserver.default.svc.cluster.local
  trafficPolicy:    connectionPool:      tcp:        maxConnections: 100      http:        idleTimeout: 30s

拷贝如上yaml ，kubectl apply 即可。注意部署前已将default namespace 开启了sidecar自动注入。

压测模型：很简单就是 fortioclient -> fortioserver , 注入sidecar 后，压测流量路径变为：

[ fortioclient -> sidecar ] -> [ sidecar -> fortioserver ]

Yaml 配置简单说明如下：

1）考虑到envoy 路由和负载均衡能力大部分功能由 outbound sidecar 起作用，上述配置特意调大了 outbound sidecar 的CPU ，设置其CPU limit为4000m, concurrency 对应调整为4 （性能最优），避免压测客户端成为瓶颈。

2) 为了测试多阶段都能加速的效果，特意通过pod 亲和性将fortioclient 和 fortioserver 调度到同一个节点。

3）每一轮的压测结果可以通过fortioclient 的 8080 端口访问进行查看。

压测方法：

1) http 请求性能压测

kubectl exec deployment/fortioclient -c captured -- fortio load -c64-qps14000-t 30s -a-r0.00005 -httpbufferkb=64-labels http-after-install-acceleration-perf-test-1 http://fortioserver:8080/echo?size=1024

2) tcp 请求性能压测

kubectl exec deployment/fortioclient -c captured -- fortio load -c64-qps0-t 30s -a-r0.00005  -labels tcp-after-install-acceleration-perf-test-1 tcp://fortioserver:8078

其中labels 是对应这一轮压测的名称，可用于区别多轮压测结果。

qps 需要根据实际压测场景进行调整。设置为0 表示无上限。设置为非零表示采用固定QPS 进行压测。

fortio 相关参数含义可以参考官方链接文档： https://github.com/fortio/fortio

性能测试

为了避免压测时相关干扰信息，可以将日志暂时关闭。在ASM 控制台的可观测配置下操作关闭即可。

首先进行一轮环境的QPS 上限测试。对比开启前后的QPS 是否有提升。

压测相关参数设置：

64 并发
QPS 不设上限
持续压测30s
http payload 1024 (1KB) size

kubectl exec deployment/fortioclient -c captured -- fortio load -c64-qps0-t 30s -a-r0.00005 -httpbufferkb=64-labels http-after-install-acceleration-perf-test-1 http://fortioserver:8080/echo?size=1024

压测结果：

也可以通过fortioclient 的loadbalancer ip 访问查看相关直方图，可以看到大部分请求的latency 分布情况。

测试开启 Sidecar Acceleration加速组件后效果：

在ACK 控制台的组件管理菜单下找到加速组件，点击安装；

安装提示成功后，再次使用同样的压测命令进行压测：

kubectl exec deployment/fortioclient -c captured -- fortio load -c64-qps0-t 30s -a-r0.00005 -httpbufferkb=64-labels http-after-install-acceleration-perf-test-1 http://fortioserver:8080/echo?size=1024

压测结果：

开启前后对比：

从QPS 角度来看，13521 / 11461.0 = 1.179739987784661， 18% 左右的QPS 提升。

Latency 角度来看: 4.732/5.583 = 0.8475729894322049, 平均 AVG latency 降低16% 左右。

我们可以通过fortio UI 提供的直方图可以直观地看出，加速组件开启后，延迟更低，大部分请求在低延时区域。未开启加速组件之前的请求，对比有超出一部分请求在较高的延时区域。

笔者进行了多轮压测，排除了相关环境抖动因素。

调整并发进行多轮压测，QPS 基本提升都能保证在15% 左右。

然后，再次进行了一组TCP 的压测对比

压测相关参数配置：

64 并发
1024 payload
持续压测30s

开启前：

执行如下命令进行压测;

kubectl exec deployment/fortioclient -c captured -- fortio load -c64-qps0-t 30s -a-r0.00005 --payload-size1024-labels tcp-not-install-acceleration-perf-test-1 tcp://fortioserver:8078

进行多轮压力测试，多轮压测差异不大，排除干扰信息。

开启后：

执行如下命令：

kubectl exec deployment/fortioclient -c captured -- fortio load -c64-qps0-t 30s -a-r0.00005 --payload-size1024-labels tcp-after-install-acceleration-perf-test-1 tcp://fortioserver:8078

开启前后直方图对比：

QPS 前后对比：

85665/54564.9 = 1.5699653073679234 , 50%多的QPS 提升，这是因为对于TCP 来说，sidecar/envoy 仅做tcp 负载均衡纯转发，不用做HTTP报文解析。

因此，在这种场景下，报文通过TCP/IP 协议栈所占用的时间比重相对较高。我们通过Latency 对比也可以看出。

Latency 前后对比：

0.746 ms / 1.172.ms = 0.636 ，接近40% 的latency 降低。

总结

服务网格下的Sidecar 代理业务服务的收发请求，并提供业务层面的流量控制（路由）、负载均衡等功能，会引入一定的Latency 延迟。通过eBPF 技术（部署sidecar 加速组件）将同节点下两个进程间的TCP 报文进行socket 短路可以提升一定的性能，HTTP 场景下QPS 可提升15% 左右, 有效地降低业务请求的Latency 。

实际业务场景下，对于Latency 敏感型的业务，我们可以通过pod 亲和性将上下游的依赖服务部署在同一个节点，采用Sidecar Acceleration Using eBPF 组件来保证服务更低的Latency 和更高的QPS 。

使用eBPF加速阿里云服务网格ASM

背景

安装部署和环境介绍

环境准备

部署测试例子

性能测试

首先进行一轮环境的QPS 上限测试。对比开启前后的QPS 是否有提升。

然后，再次进行了一组TCP 的压测对比

总结

微服务

热门文章

最新文章

相关产品

相关课程

相关电子书