关于云原生: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 容器在集群中、作为网关应用，进而实现对所有的流量都具备拦挡和治理的能力。

了解了服务网格的基本概念后，咱们再来关注赛题心愿解决的问题。

服务网格提供的非侵入式流量治理能力尽管极大地升高了容器化利用的运维老本，但目前引入网格技术也会带来性能损失和资源占用减少的毛病：

在典型状况下，引入服务网格技术之后会导致 QPS（每秒查问数）降落，以及申请提早减少。其中的起因能够大抵分为以下几个方面（包含但不限于）：

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

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

3）随着对服务之前的数据传输、数据真实性、完整性和隐衷性越来越器重, 零信赖平安变得更加重要。要实现零信赖，能够应用 mTLS 为您的服务收回的每个申请提供加密。然而, 应用 mTLS 实现的加密隧道减少了微服务到微服务的延迟时间。

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

赛题的指标就是针对上述两个毛病对服务网格进行优化。赛题将会模仿一个资源无限的 Kubernetes 集群环境；心愿通过动静地为每个 Sidecar（Envoy 容器）调配其所能应用的 CPU 及内存资源、对网格自身利用优化配置、以及开启基于英特尔®Multi-Buffer 个性的 TLS 通信优化等伎俩，在资源无限的环境下尽可能进步网格内利用的性能体现。

对于本次赛题的主题：服务网格内利用的性能与服务网格 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 分。

服务网格 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 进行编写。

服务网格内的利用及 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 性能与资源占用优化”这一大命题下为参赛者提供了三个具体的优化方向，而不同的优化方向之间彼此是比拟独立的。因而，解题的思路也分为三个局部进行论述。

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

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

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

能够必定的是，调配给 Sidecar 的 CPU 和内存资源量与 Sidecar 解决和转发申请的性能呈反比。调配的资源越多，Sidecar 的性能越高，网格内利用的拜访延时、QPS 也将失去优化。不过，在为 Sidecar 调配的资源下限达到肯定水平时，网格内利用的拜访性能将会反而受制于服务自身解决申请的性能，性能优化将会出现边际效应。

在设定为每个 Sidecar 调配的资源值时，因为资源总量存在下限，且调配过多的资源在评分上存在惩办，因而建模 Sidecar 的 CPU 和内存资源下限与转发性能的关系、防止调配冗余的资源是比拟重要的。在每轮的评测过程中，评测方都会应用 Prometheus 收集 Kubernetes 集群外部每个容器（包含业务容器和 Sidecar 容器）均匀应用的 CPU 和内存资源值，能够利用来建模这一关系，领导调配适合的 CPU 和内存资源。

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

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

此优化方向比拟自在，旨在激励参赛者的创造性，入手编写对网格优化有帮忙的 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…

此处所说的 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 代理的资源占用。

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 分，因而请审慎应用。

此方向旨在心愿参赛者可能无效利用服务网格 ASM 与英特尔®Multi-Buffer 加解密技术的软硬联合个性来进一步提高网格性能体现。

实际上，服务网格 ASM 已将硬件个性集成的局部进行了封装，参赛者只需传播给测评程序开启此个性即可对网格进行优化。对此，赛题方的评估是此处无需思考太多，开就完事了，心愿每个参赛者都可能感触到软硬联合的弱小能力。

本文从赛题背景、赛题解析和解题思路的角度，对本届较量题目进行了剖析，介绍了在三个方向下服务网格的优化思路。心愿对行将加入较量的同学们能有所帮忙。在此预祝各位参赛选手能获得优异的问题，进军复赛和总决赛，咱们在决赛问难等你。

点击此处，立刻报名！

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

大赛介绍

丰富处分等你来报名！

赛题背景

1、性能损失

2、资源占用

赛题解析

1、正当调配 Sidecar 的资源下限

2、Sidecar 配置调优

3、平台个性调优

解题思路

1、正当调配 Sidecar 的资源下限

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

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

（3）无效利用所有数据

2、Sidecar 配置调优

（1）编写 Sidecar（Sidecar 资源）

（2）编写 EnvoyFilter

3、平台个性调优

总结