服务网格规模化应用下的Istio Sidecar配置管理挑战与实践｜IstioCon 2022

服务网格是服务间通信的基础设施层， 服务网格 Istio 近期已经宣布了加入云原生计算基金会（CNCF）的意向，今后会得到更多开发者的信任和应用。阿里云内部很早就开始调研并实践 ServiceMesh 技术，通过总结业务场景落地经验，持续驱动技术发展，积累一系列服务网格核心技术，并将其沉淀成为业界首个兼容 Istio 的托管式服务网格平台 ASM（ Alibaba Cloud Service Mesh，简称 ASM）。

阿里云服务网格 ASM 在帮助客户落地实践过程中发现，随着集群管理的规模增长和配置复杂度的提升，对于不同的工作负载，目前 Sidecar 代理配置不够灵活。希望通过本次分享，能帮助大家在不同的业务场景下灵活配置 Sidecar 代理的配置来满足个性化需求、优化系统性能。

01

Istio Sidecar代理配置现状

Aliware

01

社区Istio Sidecar代理配置

在 Istio 社区方案中，修改 Sidecar 代理配置的方法有很多种。

1）最细粒度的方式，通过逐个修改 Deployment 等 workload 的 templateAnnotation，从而对注入到 Pod 中的 Sidecar 代理配置生效。

2）服务网格全局配置，可以在 Global Mesh Options 中配置 ProxyConfig 内容，这种方式对服务网格中所有注入了 Sidecar 的 Pod 全部生效，但生效优先级低于前者。前 2 种配置完成后，需要重新创建 Pod。

3）通过 EnvoyFilter 的方式，与前面 2 种方式配置的角度不同，它提供了一种来定制 Istiod 下发给 Envoy 的配置的机制，类似于插件的能力。使用 EnvoyFilter 可以修改下发配置字段的值、添加特定 cluster、listener。通常不需要重新创建 Pod。

EnvoyFilter 与 Istio 的内部实现和 envoy 的 XDS API 相关，虽然 EnvoyFilterAPI 本身保持向后兼容性，但 EnvoyFilter 配置中的内容在 Sidecar 代理版本升级过程中有不兼容的风险。不正确或者不兼容的 EnvoyFilter 配置内容可能会破坏整个服务网格的稳定性。阿里云服务网格 ASM 将 EnvoyFilter 抽象为插件市场的能力，提供了更好的升级兼容性，优化了作用范围。

02

管理Sidecar代理配置的难点

随着服务网格中管理的 Pod 规模的增长，现有的 Sidecar 代理配置管理方案，配置范围的粒度过粗或者过细。以下 2 个场景为例。

• 命名空间范围

对于中小型企业，只有单个 Kubernetes 集群，通过命名空间的划分，将不同的环境或者开发组进行划分。例如，开发环境和测试环境分别对应命名空间 Dev 和 Prod。需要在开发环境的命名空间中使用较小的 Istio-proxy 资源配置，在生产环境的命名空间中，配置更大的 Istio-proxy 资源限制。按照目前的方式，就必须使用 Pod Annotation 的方式为它们逐个添加注解。

当资源配置需要变更或者有新的 Deployment 需要部署时，也容易造成配置遗漏。同一命名空间下的 Sidecar 代理配置存在共性，但是目前缺少为整个命名空间进行 Sidecar 资源配置的手段。

• 工作负载标签范围

ServiceA/B/C 分别表示视频/文字/图片转换的 AI 服务。对应的 Pod 都标有 performancesensitive 的标签来标识为性能敏感的业务。用户希望配置来使指定 Port 的入流量不经过 Sidecar 代理，提升系统性能。这里使用到的配置参数为 IncludeOutboundPorts 来设置端口使出口流量经过 Sidecar 代理，同时 excludeInboundPorts 来设置端口使入口流量免于经过 Sidecar 代理。由于服务网格中其它业务的 Pod 不需要此配置，所以无法使用全局配置。目前也只能逐个为这一类 workload 添加 Annotation。当 Port 端口变更时，也需要逐一修改。从这两种用户场景中我们总结发现，目前 Sidecar 代理配置不够灵活和覆盖全面，难以管理。

02

阿里云服务网格ASM架构

Aliware

阿里云服务网格 ASM 提供一个全托管式的服务网格平台，兼容 Istio 开源社区。在产品能力方面，用于简化服务的治理，包括服务调用之间的流量路由与拆分管理、服务间通信的认证安全以及网格可观测性能力，减轻开发与运维的工作负担。同时 ASM 增强了多协议支持以及动态扩展能力，提供精细化服务治理，完善零信任安全体系，大规模集群支持能力，并集成了 Multi-Buffer 等技术来持续提升性能。

阿里云服务网格 ASM 定位于混合云、多云、多集群、非容器应用迁移等核心场景中，构建托管式统一的服务网格能力。使用一致的方式来管理运行于 ACK 托管 Kubernetes 集群、专有 Kubernetes 集群、Serverless Kubernetes 集群、混合云或多云场景下的接入集群上的应用服务，从而提供一致的可观测性和流量控制。托管控制平面的核心组件，最大限度地降低用户资源开销和运维成本，助力客户在生产环境中进行大规模落地。

03

阿里云服务网格ASM Sidecar代理灵活配置方案

Aliware

01

阿里云服务网格ASM Sidecar代理配置能力

当前从使用类型上可以划分为 9 类：

1）Istio-proxy 用于为服务网格中服务提供入站和出站的流量控制、安全和身份验证、重试、故障转移等能力。过小的 Istio-proxy 配置会对于高并发量的服务产生性能瓶颈，在阿里云服务网格 ASM，可以对它的 CPU/内存的请求值、最大值进行配置。

2）Istio-init 的资源配置。此 init 容器用于设置 iptables 规则，以便入站/出站流量将通过 sidecar 代理。init 容器执行完初始化后就会被销毁，但是它的资源大小也是我们需要关心的。在弹性容器实例（ECI）的环境中，按照容器实际使用的资源付费，init 容器配额过高，使得一段时间内资源消耗增加，从而增加费用。

3）performance。可以设置 Istio-proxy 中的并发数，默认并发数为 2，在使用中需要根据 Istio-proxy 的 CPU 核数进行配置。此外，可以启用基于 Intel 的 Multi-Buffer 技术的 TLS 加解密性能优化配置。

4）设置日志等级。支持配置不同范围的 Istio-proxy Loglevel，协助问题排查。

5）设置 Envoy 统计数据。为了减少 Istio-proxy 的内存和 CPU 开销，Istio 代理默认情况下只统计并上报一部分。ProxyStatsMatcher 用于配置哪些数据需要统计并上报。这些数据可以用于 Prometheus 监控。

6）入流量管理。用于配置 Sidecar 代理拦截哪些 inbound 流量。IncludeInboundPorts 设置端口使入口流量经过 Sidecar 代理，excludeInboundPorts 设置端口使入口流量免于经过 Sidecar 代理。

7）出流量管理。用于配置 Sidecar 代理拦截哪些 outbound 流量。includelPRanges 为拦截对外访问的地址范围，excludelPRanges 设置不拦截对外访问的地址范围。IncludeOutboundPorts 设置端口使出口流量经过 Sidecar 代理，excludeOutboundPorts 设置端口使出口流量免于经过 Sidecar 代理。

8）DNS 代理功能。从 Istio1.8 开始，Sidecar 上的 Istio 代理具备缓存 DNS 代理的功能。当服务网格收到来自应用程序的 DNS 查询时，Istio 代理将进行透明地拦截并提供解析能力。

9）生命周期管理。可以配置启动后执行脚本 postStart 和终止前执行的 preStop。终止等待时间 TerminationDrainDuration，以及设置 holdApplicationUntilProxyStarts 是否开启，用于延迟应用程序启动，直到 Istio-proxy 准备好接受流量，从而缓解启动竞争。后面实例中会更加详细的介绍生命周期管理。

02

灵活配置Istio Sidecar代理方案

阿里云服务网格 ASM 中，是如何实现的灵活配置 Istio Sidecar 代理方案呢？我们在 Istio 控制平面新增了 CRD ASMCustomProxyConfigInjectionTemplate，用于配置上述丰富的 Sidecar 代理字段。并且提供了 UI 控制台，方便用户理解和修改配置。

此 CRD 中的 workloadSelector 可以设定此配置内容的作用范围，如果不设置 workloadSelector 则为命名空间级别的配置。在 sidecar-injector 模块我们进行了自研开发，在注入 Pod 时结合 Global Mesh Options/CRD/Pod Annotation 内容，作用在最终生成的 Pod 的环境变量、启动参数等内容。在优先级实现上方面，Pod Annotation> Workload > namespace > Global。

03

实现细节

首先需要理解下在 Istio 社区版本中，全局和 Pod 级别的 Istio 代理配置是如何生效的。Istio 中， pod 正常情况是基于 sidecar 注入模板注入的，注入模板保存在 istio-sidecar-injector Configmap 中。对于全局配置来说，Istio 控制面会根据 GlobalMesh Options 中的 Proxy Config 内容，修改注入模板的 Configmap。当 Pod 级别的 ResourceAnnotation 配置后，Sidecar-injector 获取 Annotation 的内容，对 ProxyConfig 进行更新。在生成被注入的 Pod 时，根据 ProxyConfig 对环境变量、启动参数等内容进行修改，从而生效配置。

在阿里云服务网格 ASM 的 Sidecar 代理配置方案中，用户在 ASMCustomProxyConfigInjectionTemplate 的 configPatches 中定义配置内容，workloadSelector 设定配置的作用范围。我们在社区的实现基础上，在 sidecar-injector 模块读取 CR 中的内容。在 Pod 进行注入时，读取此命名空间下的所有 CR 和当前 Pod Annotation。如果 CR 中未设置 workload Selector 或者 Selector 能够匹配 Pod 的标签，则表示匹配成功。

为了兼容已有的用户习惯和存量使用 Pod Annotation 的用户，如果 Annotation 中存在 CR 中对应参数的配置，则以 Pod Annotation 的优先级更高。如果不存在，则使用 CR 中的配置。

04

实践应用

Aliware

01

配置Sidecar代理生命周期

• 问题现象

此客户问题问题的表现为注入 sidecar 代理后，当集群中的某些 Pod 被终止时：

1）请求该 Pod 的一些处理耗时较长的请求丢失；

2） 如果该 Pod 停止时需要调用其他服务，终止前的调用有时会失败。用户使用监控运维工具发现，当 Deployment 重新部署或缩容时，会偶发 503 错误。

此问题可以进行复现，我们在 default 命名空间下部署测试服务，并注入 Sidecar 代理。为了方便测试，此测试服务基于 httpbin 服务改造，去掉了 delay 接口的延迟等待最大时间限制。执行 curl -i httpbin.default.svc.cluster.local:8000/delay/28 发送一个延迟为 28 秒的请求，当请求发出的同时。我们重新部署后端服务 httpbin。可以看到在等待了 24 秒左右后，刚刚发出的请求返回错误提示 503（服务不可用）。

• 问题原因

查看 Sidecar 代理生命周期，发现上述问题的原因是由于 Istio-proxy 进程被终止掉了。Pod 开启 Sidecar 注入后，流量被 istio-proxy 代理，当 Pod 开始停止时，对应的 Service 不再转发流量给它，istio-proxy 收到退出信号，不再接收新的 inbound 连接（入流量），继续处理存量的 inbound 连接。那为何存量的连接会没有处理完呢？

是因为在 Istio 中，收到退出信号后，如果未设置 preStop 生命周期参数，则会默认 5 秒后会 kill Istio-proxy。进程退出后就无法处理任何存量的入流量/出流量。所以，如果被停止的服务提供的接口调用的耗时较长，已有的 inbound 连接没有处理完就被终止掉了。同理，耗时较长的 outbound 连接也会被终止掉。新的连接请求会被 Service 转发到同一 Deployment 的其他的运行状态的 Pod 上，所以感知到的影响范围是处理中的耗时较长的请求连接部分受损。

• 解决方案 1

分析完原因后，我们可以从终止等待时间 terminationDrainDuration 或者 preStop 脚本入手解决。在阿里云服务网格 ASM 控制台中，选择 Sidecar 管理中的 Sidecar 代理配置，选择 default 命名空间。我们可以为 default 命名空间设置终止等待时间为 15s。重新部署 Pod 后再次进行测试，发起请求，同时终止被请求的 Pod。可以看到请求耗时 28 秒后，被成功处理，并且被请求的 httpbin pod 在处理完成后被成功销毁。

• 解决方案 2

从刚刚的执行状态图中可以看到，还可以通过设置终止前执行的程序 preStop 脚本，在 preStop 脚本中判断是否还存在正在处理中的连接。如图所示，正常情况下，当 preStop 执行完毕后，才会进入终止等待时间 terminationDrainDuration 的倒计时环节。这样来保证所有的存量的 inbound/outbound 连接都被处理完成。

postStart 脚本程序使用的是 Istio 中默认的命令，等待 Istio-proxy 就绪，再接收请求。通过 netstat 这一网络状态查询工具，查询是否有处理中的连接。在 preStop 脚本程序的 exec command 中，在命令行执行一个循环，netstat -plunt 显示哪些进程正在 TCP 和 UDP 端口上侦听，管道后面通过 grep tcp 命令筛选出我们关注的 TCP 侦听。再使用 grep -v 命令排除 envoy 的进程本身。此时得到的数量就是正在处理的业务连接数。如果存量的连接都被处理完成，这里的数应当为 0。所以在脚本程序中，循环终止的判断为如果上述筛选得到的侦听数不为 0，休眠 1 秒钟。

在阿里云服务网格 ASM 控制台，Sidecar 代理配置中，设置上述生命周期脚本程序，更新设置后，重新部署 Pod，istio-proxy 由于设置了 preStop。再次进行请求测试，发现能够处理完成后再销毁。

• 注意事项

在前面介绍的 2 种 Sidecar 代理配置的设置中，需要关注以下两个潜在问题。

1）如果 terminationDrainDuration 设置的值超过 30 秒钟，需要设置 Pod 的 terminationGracePeriodSeconds。这是因为在重启或删除 Pod 时，Pod 的状态会变成 Terminating 并且一直处于该状态，直到其 terminationGracePeriodSeconds 被耗尽为止，这时 Pod 会被杀死。30s是因为terminationGracePeriodSeconds在 Kubernetes 中的默认值是 30s。

2）preStop/postStart 执行的日志不会在 Pod 事件中公开，有用户尝试在这个脚本中 echo 打印，是无法显示的，但是确实是被执行了；如果处理失败，将播放一个事件 FailedPreStopHook/FailedPostStartHook 事件。

02

基于Intel Multi-Buffer的TLS加速

在服务网格中，入口网关和服务、以及服务之间的通信都用到了大量的 mTLS 双向对等身份认证。过去十多年来，英特尔通过指令集的创新，微体系结构的改进和软件技术的优化，通过这些技术创新，英特尔在降低和优化密码算法的计算成本方面一直处于业界领先地位。在“IceLake”的第三代至强可扩展处理器中，英特尔引入 CryptoAcceleration 来提升目前最广泛使用的 TLS 协议的性能。

03

阿里云服务网格ASM与Intel Multi-Buffer技术结合

阿里云服务网格 ASM 是如何结合 Intel Multi-Buffer 技术，配置启用此功能来进行 TLS 加解密加速：

1）在未启用 Multi-Buffer 时, TLS 的配置只需要包含一个 private key。而一旦启用了 Multi-Buffer, TLS 的配置里就需要提供一个 private keyprovider, 也就是图中显示的cryptomb，provider 处理的消息为 CryptoMbPrivateKeyMethodConfig 类型, 包括了 2 个主要的字段, 一个是使用到的 privatekey, 另外一个是用来设置每个线程处理队列应当被执行的等待时间, 用来控制延迟和吞吐量之间的平衡；

2）控制面的配置可以通过 xDS 协议下发到数据面 Envoy 代理中。结合 Intel 开源的加密库和 CryptoMB private key provider，使用 AVX512 指令集，服务网格实现可以卸载  TLS 握手，以处理更多连接，降低延迟并节省 CPU；

3）阿里云服务网格 ASM 通过判断机器型号，通过判断此机型是否支持 AVX512 指令集，决定是否启用此功能；

04

修改SIdecar代理配置启用TLS加速

在 Istio master 分支的最新代码中，目前已经支持了 PrivateKeyProvider 的全局和 Pod Annotation 的方式，选择是否启用 Intel Multi-Buffer 的 TLS 性能优化功能。这表明此配置也是社区认可的能力。在阿里云服务网格 ASM 中，目前提供了全局配置，并正在逐步支持此配置的多级别配置。在阿里云的 G7 类型的机器上进行测试，启用 Multi-Buffer 的 TLS 性能优化后，进行压力测试，请求 QPS 数目提升了 80.7%。

05

Istio-proxy性能调优

Sidecar 模式中，请求业务容器的流量通过 Istio-proxy 进行了代理，那么 Istio-proxy 代理的资源配置如何设置才能最小化对性能的影响呢？在本示例中，将介绍 Istio-proxy 的资源配额设置和并发度对 Istio-proxy 的性能带来的影响。

我们在阿里云容器服务中创建一个集群，该集群下有 2 个 Node 节点。节点的机器都为 12 核（vCPU）、32GB。使用开源的 fortio 工具，在 default 命名空间和 foo 命名空间下分别部署一个服务，其中 foo 命名空间下的为 fortio-server，被注入了 Sidecar 代理。default 命名空间下为客户端 fortio-client。并且设置节点亲和性使得客户端 Pod 和服务端 Pod 部署在不同的 Node 上。

执行如下命令，模拟并发度为 2000，测试时长为 60 秒，查看最终 QPS 指标。

• 性能对比

使用上述环境进行对比测试后，将 istio-proxy 的 CPU 核数上限从原来的 1 核设置为 5 核后，QPS 提升了 2 倍，延迟降低了为 1/2。没有得到 5 倍的提升，原因在于 istio-proxy 的运行的工作线程数过小，并没有充分利用 CPU 能力。当我们在上一步的基础上，把 Concurrency 设置为和 CPU 核心数相同，也就是 5。再次测试后发现，与最初相比，QPS 提升了 5 倍左右，延迟也降低为 1/5。

• 配置方式

如何完成上述的灵活配置呢？在阿里云服务网格中，在 Sidecar 代理配置，可以设置 namespace 级别的 Istio-proxy 的 CPU、内存等。作用于整个命名空间。也可以为 fortio 标签的pod创建配置规则。可以创建如下的 CR 到阿里云服务网格 ASM 控制面。当重新部署后，新的 istio-proxy 的资源配额就发生了改变，info 日志等级下，可以从 istio-proxy 的日志中看到 Concurrency 为 5。

06

控制流量是否经过Sidecar代理

• 问题背景

如图所示的示例中，3 个 AI 计算相关的服务作为服务端，被标记为 performance: sensitive。它们的压力主要来自特定端口访问时的 inbound 流量，但是对于特定端口的 outbound 流量，又使用了 Istio 中的负载均衡等能力。所以不能取消 Sidecar 代理的注入。

通过配置进出流量是否经过 Sidecar 代理，来指定特定端口的入口流量免于经过 Sidecar 代理，仅特定端口的出流量经过 Sidecar 代理。然后将 Sidecar 代理配置生效到到带有 performance: sensitive 标签的 Pod 中。

• Sidecar代理配置

具体是如何设置 SIdecar 代理配置呢？在阿里云服务网格 ASM 中，创建 CRDASMCustomProxyConfigInjectionTemplate，选中标签 performance:sensitive  作为 workloadSelector 中的 label。在具体的配置内容 configPatches 中，额外设置 IncludeOutboundPorts 来设置端口使出口流量经过 Sidecar 代理，在 excludeInboundPorts 来设置端口使入口流量免于经过 Sidecar 代理。如果是多个端口号，需要使用逗号进行分割。

创建好配置内容后，重启 Pod，配置生效后，效果如图所示，只有特定端口的出流量经过 Sidecar 代理，其他出流量不再经过 Sidecar 代理。设置的特定端口的入流量不再经过 Sidecar 代理，直接访问 AI 计算的业务容器，显著提升了性能。与未配置前进行对比测试，发现入流量不经过 Sidecar 代理后，QPS 和延迟都提升了 5 倍左右。

05

Istio社区ProxyConfig

Aliware

01

ProxConfig介绍

随着 Istio 社区功能的完善，在最新的 Istio 1.13 中，为了解决配置范围不灵活、管理复杂的痛点，与阿里云服务网格 ASM 的产品思路相同，提供了 ProxyConfig CRD 来对 Sidecar 代理的配置进行修改。ProxyConfig 用 CR 的方式进行管理。但是目前能力还在初期阶段，只支持了 concurrency 和 imageType 的修改。使用方式上有如下的 4 点特征：

1. 如果 ProxyConfig 创建在 istio-system 命名空间，则为全局生效的配置内容；

2. istio-system 命名空间下的 ProxyConfig 优先级高于 Global Mesh Config 中的 ProxyConfig；

3. 创建在其他命名空间，则为命名空间级别配置。如果还有 workloadselector 则为 workload 级别配置；

4. 多个 workload 级别的 CR 配置作用到同一个 Pod 时，按照 ProxyConfig 的 CR 创建时间排序，使用最先创建的。

02

ProxyConfig与阿里云服务网格ASM方案对比

• 相似性：

Istio 社区正在演进的 ProxyConfig 与阿里云服务网格 ASM Sidecar 代理配置管理方案的相似性很多。

1）出发点都是为了在集群规模增长，Sidecar 代理配置管理成本提升的背景下，希望改善用户体验，用多维度的方式进行灵活配置。

2）对于 Workload 级别的配置，都考虑到了多个配置的 CR 被同一个 Pod 匹配的情况，选择最先被创建的 CR 的配置内容。

• 差异性：

1）阿里云服务网格 ASM 解决方案中，是从 istio 1.10 版本起，为了解决客户的配置痛点，就提出了此方案，并且随着后续的演进，已经有了比较丰富的配置参数。社区的还只支持 concurrency 和 imageType 的修改，不过也在快速发展演进中。

2）优先级差异。全局配置和命名空间配置的优先级考量是一样的，但是在阿里云服务网格 ASM 中，Pod Annotation 的方式比通过 Workload 级别的 CR 配置内容优先级更高。也就是说，通过单独给 Deployment 添加注解的，会直接作用到对应的 Pod 上。由于 Workload 级别的配置可能存在多个 CR 中，如果不小心配置了多个，还需要考虑创建时间问题。从兼容性和稳定性上，阿里云服务网格 ASM 的方案出发点是已有用户的使用习惯依然保留。减少错误配置 Workload 级别 CR 配置产生的影响面。

在 Istio ProxyConfig 中，使用 Workload 级别的 CR 配置内容优先级比单独添加 Deployment 注解的方式更高，社区这样的做法是为了今后将所有级别的 Sidecar 代理配置管理，收敛到 ProxyConfig CR 中，全局的就使用 istio-system 命名空间下的 CR，如果需要为 Pod 进行配置，就选择 pod 所在命名空间下的匹配的 CR 内容。

06

未来展望

Aliware

随着未来 Istio 社区的 ProxyConfigCRD 功能的逐渐增强，ProxyConfig CR 会作为 Sidecar 代理配置的推荐入口。但是在此之前，阿里云服务网格 ASM ASMCustomProxyConfigInjectionTemplate CRD 和社区 ProxyConfig 方案会融合补充，用来弥补当前社区 Sidecar 代理配置能力的不足。在配置生效的优先级方面，阿里云服务网格 ASM 的方案会对 Workload 配置和 PodAnnotation 配置的优先级进行调整，和 Istio 社区对齐，保证使用的一致性。

相关链接

1、IstioConn2022 

https://www.crowdcast.io/e/istiocon-2022/12

2、阿里云服务网格ASM

https://www.aliyun.com/product/servicemesh

3、IstioProxyConfig 

https://istio.io/latest/docs/reference/config/networking/proxy-config/

阿里云服务网格 ASM 目前正式推出商业版，为您提供丰富的产品能力、强大的规模支持和完善的技术保障。

更多功能欢迎前往【阅读原文】体验。