2022 云原生编程挑战赛启动！导师解析服务网格赛题

大赛介绍

2022 第三届云原生编程挑战赛，是由阿里云、Intel 主办，云原生应用平台、天池联合承办的云原生顶级品牌赛事。

自 2015 年开始，大赛已经成功举办了七届，并从 2020 年开始升级为首届云原生编程挑战赛，共吸引了超过 36000 支队伍，覆盖 10 余个国家和地区。

本届大赛将继续深度探索服务网格、边缘容器、Serverless 三大热门技术领域，为热爱技术的年轻人提供一个挑战世界级技术问题的舞台，希望用技术为全社会创造更大价值。大家赶快报名参赛吧！

丰厚奖励等你来报名！

• 瓜分¥510,000 元现金大奖
• 三大热门赛道任意选择
• 邀请小伙伴报名兑换精美礼品
• 完成 Serverless 场景体验领阿里云背包

以下赛道可任选 1 个或全部扫码报名：

赛道 1（服务网格）

赛道 2（边缘容器）

赛道 3（Serverless）

更多内容尽在大赛官网，欢迎扫码了解：

赛题背景

容器作为云原生应用的交付物，既解决了环境一致性的问题，又可以更细粒度的限制应用资源。随着微服务和 DevOps 的流行，容器作为微服务的载体得以广泛应用；而Kubernetes 作为一种容器编排调度工具，解决了分布式应用程序的部署和调度问题。

在服务网格技术出现之前，可以使用 SpringCloud、Netflix OSS 等，通过在应用程序中集成 SDK，编程的方式来管理应用程序中的流量。但是这通常会有编程语言限制，而且在 SDK 升级的时候，需要修改代码并重新上线应用，会增大人力负担。服务网格技术使得流量管理变得对应用程序透明，使这部分功能从应用程序中转移到了平台层，成为了云原生基础设施。以 Istio 为首的服务网格技术，正在被越来越多的企业所瞩目。Istio 使用 Sidecar 借助 iptables 技术实现流量拦截，可以处理所有应用的出入口流量，以实现流量治理、观测、加密等能力。要了解更多有关服务网格 Istio 的基础知识，可以参考 Istio 官方网站。

可将服务网格 Istio 的流量管理过程简单理解为如下的模型：

在一个 Kubernetes 集群中，开发/运维人员将提供服务的容器（业务容器）以 Pod 的形式部署在集群中、并对外提供服务（一个 Pod 是一个或一组一起部署的容器，是可以在 Kubernetes 集群中创建和管理的最小部署单位）。Istio 在此之上进行了额外的工作，为用户提供了非侵入式的流量治理/可观测/加密等能力。具体来说，服务网格 Istio 为每个业务容器注入了一个 Sidecar，该 Sidecar 是一个 Envoy 应用的容器；并通过设定 iptables 规则拦截所有业务容器的入向和出向流量。这样，每个 Pod 中就多出了一个 Envoy 容器（Sidecar），用于提供服务网格的非侵入式能力。

通过为每个应用注入 Sidecar，服务网格能够感知和控制集群中每个服务的入向和出向流量，进而能够通过配置不同的规则，在 Sidecar 层面实现流量转发负载均衡、流量灰度、流量加密等能力；同时业务容器的代码完全不需要修改，也感知不到 Sidecar 对流量的拦截，降低了服务的运维成本，因此说服务网格提供的能力是非侵入式的。对于来自集群外的请求，Istio 则会单独部署一个 Envoy 容器在集群中、作为网关使用，进而实现对所有的流量都具有拦截和治理的能力。

理解了服务网格的基本概念后，我们再来关注赛题希望解决的问题。

服务网格提供的非侵入式流量治理能力虽然极大地降低了容器化应用的运维成本，但目前引入网格技术也会带来性能损失和资源占用增加的缺点：

1、性能损失

在典型情况下，引入服务网格技术之后会导致 QPS（每秒查询数）下降 ，以及请求延迟增加 。其中的原因可以大致分为以下几个方面（包括但不限于）：

1） Istio 设计之初的目标就是通过协议转发的方式服务于服务间流量，让服务网格尽可能对应用程序透明，从而使用了 IPtables 劫持流量。实践过程中我们发现，因为 IPtables conntrack 模块所固有的问题，随着网格规模的扩大，Istio 的性能问题开始显现。使用 iptables 的技术带来的对出入口请求的拦截，造成大量的性能损失，这对一些性能要求高的场景有明显的影响。

2）Istio控制平面默认会监听和处理Kubernetes集群中所有命名空间中的所有资源,  这对于一定规模的集群来说, 在服务发现、配置推送等方面都存在一定的性能影响。

3）随着对服务之前的数据传输、数据真实性、完整性和隐私性越来越重视,  零信任安全变得更加重要。要实现零信任，可以使用 mTLS 为您的服务发出的每个请求提供加密。然而, 使用 mTLS 实现的加密隧道增加了微服务到微服务的延迟时间。

2、资源占用

在服务网格的 Sidecar 模式中，每个业务容器的 Pod 都会多余注入一个 Envoy 容器。在处理和转发拦截的请求流量时，Envoy 容器必定会消耗集群中的 CPU 与内存资源。这导致当集群中服务规模持续增长时，这些多余的Envoy容器将消耗不可忽视的集群资源。

赛题的目标就是针对上述两个缺点对服务网格进行优化。赛题将会模拟一个资源有限的 Kubernetes 集群环境；希望通过动态地为每个 Sidecar（Envoy 容器）分配其所能使用的 CPU 及内存资源、对网格本身应用优化配置、以及开启基于英特尔®Multi-Buffer 特性的 TLS 通信优化等手段，在资源有限的环境下尽可能提高网格内应用的性能表现。

赛题解析

对于本次赛题的主题：服务网格内应用的性能与服务网格 Sidecar 资源占用的优化，赛题给出了三个不同的角度作为入手点。三个角度彼此之间比较独立，参赛者可以选择不同的角度来施行不同的优化手段，以达到最大的优化效果。

1、合理分配 Sidecar 的资源上限

如上所述，在服务网格中，每个 Pod 都会注入一个 Sidecar 代理（Envoy 容器），这些 Sidecar 代理不可避免地需要消耗一定的 CPU 和内存资源。由于进出 Pod 的所有流量都由 Sidecar 代理，Sidecar 对请求的转发和处理性能对网格中应用的性能（体现在访问延迟和 QPS）将会造成较大的影响；而 Sidecar 代理处理请求的性能又与为其分配的 CPU 与内存资源量上限成正比，因此为 Sidecar 分配较多的 CPU 和内存资源将能够有效优化网格内应用的性能。

然而，盲目为 Sidecar 分配大量资源会迅速将集群内的资源总量耗尽，最终导致 Pod 无法创建等问题；所以如何将有限的集群资源进行合理分配、提高网格整体性能是一个网格优化的重要入手点。利用注解或全局配置的机制，服务网格 Istio 能够针对性地为每个服务指定为其 Sidecar 分配的 CPU 和内存资源上限。在本赛题中，我们对这一机制进行了封装，参赛者只需要返回指定格式的返回值，就能够为评测环境中的每个服务设定分配的 CPU 和内存资源上限；利用这一机制合理地分配 Sidecar 的资源上限是完成本赛题的重要手段。

在本赛题中，测评时将使用一个资源有限的 Kubernetes 集群 + 服务网格环境作为评测环境，参赛者的程序将被告知每个时段可分配给 Sidecar 的 CPU 和内存资源总量（CPU 以核为单位、内存以 Byte 为单位），并可以选择计算并返回分配给每个服务的 Sidecar 的资源上限。同时，赛题的评测将分为多轮进行，每一轮都会向参赛者的程序传入网格内应用在上一轮评测中、发送请求产生的访问日志以及每个容器的平均资源消耗。参赛者程序无法得知实际部署在集群中的服务以及服务之间的调用关系等情况。在这个优化方向中，赛题旨在期望参赛者实现一种自适应的动态集群资源调度机制，能够根据访问网格内应用过程中产生的日志、CPU 内存指标这些可观测数据，尽快调整分配给每个服务 Sidecar 的资源上限，使网格的资源利用效率达到最大。

需要注意的是，为保证每个 Sidecar 能正常启动，为每个 Sidecar 分配的 CPU 和内存资源也是有下限的。具体来说，为 Sidecar 分配的 CPU 资源不能少于 0.1 核，分配的内存资源不得少于 128Mi（128000000Byte），否则将导致 Sidecar 无法启动，参赛者将得到 0 分。

2、Sidecar 配置调优

服务网格 Istio 中部署的每个 Sidecar 及网关都是一个 Envoy 应用。Envoy 是一个运行于7层网络协议的代理，其与 Nginx 的重大区别之一就在于 Envoy 的配置可以通过 xDS 协议来实现动态变更。服务网格正是利用这一点，制定了 VirtualService、DestinationRule 等一系列自定义资源。网格用户编写并应用这些自定义资源后，由网格的控制面将这些自定义资源翻译成 Envoy 的配置，并通过 xDS API 进行动态下发，改变网关及 Sidecar 的配置及与其相关的请求处理行为。

除基本的 VirtualService、DestinationRule 等资源外，服务网格 Istio 还制定了 Sidecar 和 EnvoyFilter 两种自定义资源。其中 Sidecar 资源可以为每个服务的 Sidecar 单独声明其进出流量的属性，不仅可以精简每个 Envoy 的配置，降低内存占用，还可以有效降低控制面对 Sidecar 的配置推送频率，减少资源消耗。而 EnvoyFilter 资源则允许用户直接修改 Envoy 的原始配置，可以有效修改和利用 Envoy 的各种已知能力。

赛题为参赛者封装了向服务网格中应用 Sidecar 与 EnvoyFilter 两种资源的机制，参赛者的程序可以选择返回这两种资源的 YAML 字符串、并由赛题方帮助应用于服务网格中。使用 Sidecar 与 EnvoyFilter 资源调整 Envoy 配置也是网格优化的重要入手点之一。在这个优化方向中，赛题旨在鼓励参赛者积极利用服务网格 Istio 及 7 层代理 Envoy 的各项配置和能力，发挥创造性提供能够降低服务网格的资源消耗与提高性能的有效配置。

此优化方向需要对服务网格 Istio 的 Sidecar 与 EnvoyFilter 资源的编写有一定了解。有关 Isito 的 Sidecar 资源，可以参考：

https://istio.io/latest/docs/...

有关 Istio 的 EnvoyFilter 资源，可以参考：

https://istio.io/latest/docs/...

本赛题的评测环境中使用的服务网格的 Istio 版本为 1.12，参赛者在编写 EnvoyFilter 时需注意遵循 Envoy 的 v3 API 进行编写。

3、平台特性调优

服务网格内的应用及 Sidecar 最终实际都运行于实际的机器节点之上。而我们同样可以利用机器的平台特性优化网格内应用的性能表现。在本赛题的评测环境中，Sidecar 之间默认都使用 mTLS 进行通信，这是服务网格提供的安全特性之一。Sidecar 之间的 mTLS 通信在提高了集群内应用的安全性的同时，却也会显著降低网格内应用访问的性能表现（因为 mTLS 实现的加密隧道增加了微服务到微服务的延迟时间）。

在上述场景中，可以使用英特尔®Multi-Buffer 加解密技术、使用 Intel CPU AVX-512 指令同时处理多个独立的缓冲区，即可以在一个执行周期内同时执行多个加解密的操作，成倍的提升加解密的执行效率，进而提升网格内应用间通信的性能表现。Multi-Buffer 技术不需要额外的硬件，只需要 CPU 包含特定的指令集。

目前阿里云在 Ice Lake 处理器中已经包含了最新的 AVX-512 指令集。本赛题的评测环境基于阿里云服务网格 ASM。作为业内首个全托管 Istio 兼容的阿里云服务网格产品 ASM，一开始从架构上就保持了与社区、业界趋势的一致性。ASM 产品是基于社区 Istio 定制实现的，在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。在本赛题中，服务网格 ASM 运行于支持 AVX-512 指令集的英特尔®Ice Lake 处理器的 ECS 节点之上，并已经集成了英特尔®Multi-Buffer 加解密技术。赛题方已经帮助参赛者封装了这一技术，参赛者的程序只需要返回 Multi-Buffer 特性开启的标志，就可以立刻启用评测环境中服务网格的 Multi-Buffer 集成技术，提升网格内应用性能。在这个优化方向中，赛题旨在让参赛者积极利用服务网格与机器平台硬件特性的结合，体会软硬结合带来的网格性能表现提升。

解题思路

赛题在“网格 Sidecar 性能与资源占用优化”这一大命题下为参赛者提供了三个具体的优化方向，而不同的优化方向之间彼此是比较独立的。因此，解题的思路也分为三个部分进行阐述。

1、合理分配 Sidecar 的资源上限

这一方向可说是本次赛题中最为基本的优化方向，也预计会是大部分参赛者都选择参与的一个优化方向。虽然优化服务网格涉及到很多复杂的概念，但具体到 Sidecar 资源上限分配这一方向上，其实问题抽象后会比较简单：在服务网格中有若干服务（每个服务都由一个或几个具体的 Pod 来提供服务），服务之间有着未知的调用关系，参赛者的目标是为每个服务的 Sidecar 都指定分配的 CPU 和内存资源上限，最终使得网格内应用访问的性能（QPS 和时延两项指标）得到最大限度的优化。在调整资源分配的过程中，分配的所有资源量（CPU 和内存）各有一个总的上限。于是，此优化方向本身就可以变成一个典型的目标优化问题；其中变量就是为每个 Sidecar 分配的 CPU 和内存上限，而优化目标则是系统整体的 QPS 和时延。

参赛者的核心目标是提供一套动态调优的算法，通过调整分配给 Sidecar 的 CPU、内存资源值，使得多次迭代中目标系统的 QPS 达到最大、时延最小，而分配的系统资源总量又不至于太多（因为评分时也会对分配资源过多的情况进行酌情扣分）。

在调优过程中，参赛者可以考虑以下因素对调优的影响：

（1）Sidecar 资源量和性能的关系建模

可以肯定的是，分配给 Sidecar 的 CPU 和内存资源量与 Sidecar 处理和转发请求的性能呈正比。分配的资源越多，Sidecar 的性能越高，网格内应用的访问延时、QPS 也将得到优化。不过，在为 Sidecar 分配的资源上限达到一定程度时，网格内应用的访问性能将会反而受制于服务本身处理请求的性能，性能优化将会呈现边际效应。

在设定为每个 Sidecar 分配的资源值时，由于资源总量存在上限，且分配过多的资源在评分上存在惩罚，因此建模 Sidecar 的 CPU 和内存资源上限与转发性能的关系、避免分配冗余的资源是比较重要的。在每轮的评测过程中，评测方都会使用 Prometheus 收集 Kubernetes 集群内部每个容器（包括业务容器和 Sidecar 容器）平均使用的 CPU 和内存资源值，可以利用来建模这一关系，指导分配合适的 CPU 和内存资源。

（2）调整资源分配的迭代算法

参赛者不能事前 hack 环境中具体运行的服务以及服务间的调用关系，在优化过程中唯一能够获知的就是 Sidecar 产生的访问日志以及每个容器的资源占用等可观测数据。然而赛题的评测是分多轮进行的，在每一轮都会将上一轮测试产生的可观测数据传回给参赛者的程序。也就是说，参赛者的程序可以收到来自上一轮的分配结果造成的反馈。基于此，参赛者可以考虑构建有效的迭代算法，用尽可能少的轮数迅速将程序的输出迭代至最大优化目标。

（3）有效利用所有数据

在评测的每一轮，参赛者的程序都会收到上一轮测试中每个容器的平均资源使用量统计，这是来自服务运行环境的最直观反馈。不过，每个服务的 Sidecar 容器所产生的的访问日志包含着更多的信息量。由于 Sidecar 拦截代理所有请求，网格中服务间互相访问的每一条请求都会对应产生一条 Sidecar 日志。日志中包括了该条请求的延迟、协议、时间点、发送请求大小、请求来源与目标等信息。若能够有效利用，分析服务间调用的模式以及服务间的具体调用链关系，将有助于更快、更好地决策为每个服务的 Sidecar 分配的 CPU 和内存资源量。

2、Sidecar 配置调优

此优化方向比较自由，旨在鼓励参赛者的创造性，动手编写对网格优化有帮助的 Sidecar 及 EnvoyFilter。注意：在本次测评中，使用的服务网格 ASM 版本为 Istio 1.12 的兼容版本，参赛者在编写 Sidecar 或 EnvoyFilter 时，请务必注意需要提供能够兼容 1.12 版本 Istio 的 Sidecar 或 EnvoyFilter YAML。否则，评测过程中服务会无法启动，参赛者将得到 0 分。建议参赛者尝试在本地安装服务网格 Istio 先行进行测试、测试好后再将生成 Sidecar/EnvoyFilter 的逻辑写到程序里，以免浪费宝贵的提交机会。可参照下方链接来尝试安装服务网格 Istio 进行测试：

https://istio.io/latest/zh/do...

（1）编写 Sidecar（Sidecar 资源）

此处所说的 Sidecar 是指 Sidecar 资源，是服务网格制定的一种自定义资源。以下将此 Sidecar 与作为服务 Sidecar 的 Envoy 容器分别阐述为 Sidecar 资源和 Sidecar 代理。

Sidecar 资源能够声明每个服务的 Sidecar 代理的出入向流量属性。默认情况下，服务网格 Istio 控制面会将 Kubernetes 集群中所有服务的信息都下发给每个服务的 Sidecar 代理。不过，通过编写 Sidecar 资源，网格将会根据 Sidecar 资源配置中描述的流量属性、对服务信息及相关配置进行选择性下发。因此，编写 Sidecar 资源将具有减少 Sidecar 代理内存占用及优化配置推送过程资源占用的功效。

比如，在提供给参赛者的示例程序中，就默认提供了一个 Sidecar 资源的 YAML：

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: default
spec:
  egress:
  - hosts:
    - "./*"
    - "istio-system/*"

该 YAML 声明了 default 命名空间下的所有 Sidecar 代理的出向流量都只可能发送到本命名空间或 istio-system 命名空间内的服务，从而能够在 Sidecar 代理的配置中排除其它命名空间内的服务。

参赛者完全有能力进行进一步的优化。比如说在访问日志中就隐含着服务之间的调用关系（只是需要一定的解析），参赛者可以设法实时分析服务的调用链，并根据调用链信息生成自定义的 Sidecar 资源、应用到服务网格中以优化 Sidecar 代理的资源占用。

（2）编写 EnvoyFilter

EnvoyFilter 的能力非常自由，其本质实际就是编写原始的 Envoy 应用配置后直接合并到现有的 Envoy 应用的配置之中。因此，参赛者完全可以发挥创造力，对网格中的 Sidecar 代理配置进行任何可能的变更、以帮助自己进行性能优化。比如说，参赛者可以尝试修改 http 协议配置下的某些参数或删除某些过滤器、优化请求处理的性能表现。又比如，参赛者可以增加日志中输出的字段来为自己的程序提供更加丰富的信息。

例如，下方的 EnvoyFilter 在日志中增加了新的字段 envoy_lua。

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
spec:
  configPatches:
    - applyTo: NETWORK_FILTER
      match:
        context: ANY
        listener:
          filterChain:
            filter:
              name: envoy.filters.network.http_connection_manager
        proxy:
          proxyVersion: ^1.12.*
      patch:
        operation: MERGE
        value:
          typed_config:
            '@type': >-
              type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
            access_log:
              - name: envoy.access_loggers.file
                typed_config:
                  '@type': >-
                    type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
                  path: /dev/stdout
                  log_format:
                    json_format:
                      envoy_lua: '%DYNAMIC_METADATA(envoy.lua)%'

虽然 EnvoyFilter 的自由度非常高，但自由度的代价是很有可能由于错误的 EnvoyFilter 配置的导致集群中的服务无法启动。在这种情况下参赛者会得到 0 分，因此请谨慎使用。

3、平台特性调优

此方向旨在希望参赛者能够有效利用服务网格 ASM 与英特尔®Multi-Buffer 加解密技术的软硬结合特性来进一步提高网格性能表现。

实际上，服务网格 ASM 已将硬件特性集成的部分进行了封装，参赛者只需传达给测评程序开启此特性即可对网格进行优化。对此，赛题方的评价是此处无需考虑太多，开就完事了，希望每个参赛者都能够感受到软硬结合的强大能力。

总结

本文从赛题背景、赛题解析和解题思路的角度，对本届比赛题目进行了分析，介绍了在三个方向下服务网格的优化思路。希望对即将参加比赛的同学们能有所帮助。在此预祝各位参赛选手能取得优异的成绩，进军复赛和总决赛，我们在决赛答辩等你。

点击此处，立即报名！