基于Wasm和ORAS如何简化扩展服务网格功能

基于Wasm和ORAS如何简化扩展服务网格功能，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

创新互联建站服务项目包括东阳网站建设、东阳网站制作、东阳网页制作以及东阳网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，东阳网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到东阳省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

小编将介绍如何使用 ORAS 客户端将具有允许的媒体类型的 Wasm 模块推送到 ACR 注册库（一个 OCI 兼容的注册库）中，然后通过 ASM 控制器将 Wasm Filter 部署到指定工作负载对应的 Pod 中。Wasm Filter 部署中的所有步骤都使用声明方式，也就是说可以创建一个自定义资源 CRD 来描述 Wasm Filter 的部署。一旦该 CRD 创建之后，ASM 控制器可以将 Wasm 模块加载到数据平面层中的相应 Envoy 代理中，同时在控制平面层中也会创建相应的 Istio EnvoyFilter 自定义资源。

Envoy Filter 介绍

首先回顾一下 EnvoyProxy 的实现机制。Envoy 的核心是一个 L3/L4 网络代理，并支持 L7 代理，通过提供可插入 filter chain 机制允许开发人员编写 filter 来执行不同的任务，譬如我们常用到的 HTTP connection manager，将原始字节转换为 HTTP 级别的消息和事件，还处理所有 HTTP 连接和请求共有的功能包括访问日志、tracing 等。

上图可以看到：Downstream 作为连接到 Envoy 并发送请求以及接收响应的客户端部分， 监听器 Listener 组件用于绑定到 IP 地址/端口并接收来自 Downstream 下游的连接。通过配置 Listener，用户可以启用通过代理的流量管理能力，然后使用多个 Filter 增强数据流，多个 Filter 构成了一个 Filter Chain。可以看到经过这些 Filter chain 处理之后， 会把请求映射到相应的 Cluster（此处的 Cluster 集群是指 Envoy 连接到的逻辑上相同的一组上游主机，与下文中提交的 Kubernetes 集群没有关系），而 Cluster 的作用是负责连接到一组上游节点服务, 并使用关联的负载均衡策略转发这些请求。

根据处理任务的不同，Envoy Filter 分为三类：

• Listener Filter：用于操作处理 L4 连接中的元数据。

• Network Filter：用于操作处理 L4 连接中的原始数据。

• HTTP Filter：用于操作处理 L7 连接中的 HTTP 请求与响应。

除了这些 built-in Filter 之外，还可以开发自定义的 Filter，可使用 native c++ 编译方式，或是通过 wasm 技术构建 Filter。

此外，Envoy 提供了一组 API，也就是我们常说的 xDS API。通过这些 API，控制平面可以动态地配置 Envoy 代理。

如上图所示，与进站流量类似，对于出站流量来说，监听器在配置的地址或者端口进行监听网络流量的请求。每个监听器同样会定义一组位于数据路径中的 Filter，并形成一组过滤器链 Filter Chain。通过这样的一组过滤器，用户可以配置 Envoy 来针对出站流量做特定的任务，包括数据协议处理、生成调用的统计信息、执行 RBAC 权限等。

为了更好地理解这些 Envoy Filter 以及 Filter Chain，下面来看一个实际的例子。这个就是 Istio 官方示例 bookinfo 中的第一个服务 productpage。首先, productpage pod 中 Envoy Proxy 配置了一个监听 9080 端口的监听器，进入这个 pod 的端口 9080 上的流量请求都会被拦截到这个 proxy 中，然后请求就会经过这些 Filter Chain 进行处理。具体如下：

• 第一个 filter 是 envoy.filters.network.metadata_exchange，它的主要作用顾名思义，用来在 filter 之间交换元数据。

• 第二个 filter: envoy.http_connection_manager，它下面通常会有以下几个跟 http 特定的 filter，包括：

• envoy.filters.http.wasm/envoy.wasm.metadata_exchange（用于元数据交互）

• Istio_authn filter（用于授权认证）

• envoy.filters.http.cors（处理跨域资源共享的 filter）

• envoy.filters.http.fault（故障注入过滤器，可以用来测试微服务架构中容错能力，用户可以自定义错误代码来实现延时注入或者终止请求，在不同的失败场景下提供错误处理的能力，例如服务失败、服务过载、服务高延时等情况，这个也是较为常用的 filter）

• envoy.filters.http.wasm/envoy.wasm.stats、envoy.filters.http.wasm/xxx-wasmfilter（用户自定义的 wasm 实现的filter）

• envoy.filters.http.router（实现 HTTP 转发，几乎所有 HTTP 场景下都会使用到这一过滤器）

备注：可以通过请求这个 URL 地址获取配置信息：kubectl exec -it [productpage-xxx] -c istio-proxy curl localhost:15000/config_dump

添加新的 Filter

Envoy 社区已经提供了若干个 Built-in Filters，具体参见：https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/http_filters。

在服务网格中，可以通过 API 启用这些 Built-in Filter 能力。

如果这些 Built-in Filter 无法满足需求，还可以通过自定义 Filter 实现，有以下两种方式：

• 静态预编译：

• 将其他过滤器集成到 Envoy 的源代码中，并编译新的 Envoy 版本。

• 这种方法的缺点是您需要维护 Envoy 版本，并不断使其与官方发行版保持同步。

• 由于 Envoy 是用 C++ 实现的，因此新开发的过滤器也必须用 C++ 实现。 

• 动态运行时加载：

• 在运行时将新的过滤器动态加载到 Envoy 代理中。

• 为了简化扩展 Envoy 的过程, 通过引入 WebAssembly 技术 - 它是一种有效的可移植二进制指令格式，提供了可嵌入和隔离的执行环境。

使用 Wasm 扩展 Envoy Proxy 的优缺点

在实际应用中，会根据以下优缺点来决定是否使用 Wasm 这种方式扩展 Envoy Filter。

Pros

• 敏捷性：过滤器可以动态加载到正在运行的 Envoy 进程中，而无需停止或重新编译。

• 可维护性：不必更改 Envoy 自身基础代码库即可扩展其功能。

• 多样性：可以将流行的编程语言（例如 C/C++ 和 Rust）编译为 WASM，因此开发人员可以选择实现过滤器的编程语言。

• 可靠性和隔离性：过滤器会被部署到 VM 沙箱中，因此与 Envoy 进程本身是隔离的；即使当 WASM Filter 出现问题导致崩溃时，它也不会影响 Envoy 进程。

• 安全性：过滤器通过预定义 API 与 Envoy 代理进行通信，因此它们可以访问并只能修改有限数量的连接或请求属性。

Cons

• 性能约为 C++ 编写的原生静态编译的 Filter 的 70％。

• 由于需要启动一个或多个 WASM 虚拟机，因此会消耗一定的内存使用量。

• The WebAssembly ecosystem is still young。

envoy-wasm 运行机制

如下图所示，envoy-wasm 运行机制包括以下几个步骤：

• Wasm 二进制代码需要能够被动态加载进来，无论是通过 local file 方式还是 xds 远程获取方式。

• 一个 Wasm filter 是否被允许加载，需要一致性校验：https://github.com/proxy-wasm/spec。

• 一旦被加载之后，Wasm filter 就成为 filter chain 的一部分，当新的请求进来之后，还是先进入到原生的 filter，之后进入到 Proxy-Wasm 扩展控制器。

• Proxy-Wasm 扩展控制器会根据在 filter chain 中定义的 configuration 信息，调用并执行注册的校验过的这些 Wasm filter。

• 内置的 Wasm runtime 支持：LLVM-based WAVM ~20MB, and V8 ~10MB。

• 事件驱动模型。

• 兼容 native filter 调用方式。

如下所示，是下发到 Envoy Proxy 侧的一个 Wasm Filter 的配置内容。

以上讲述了 Envoy Filter 以及通过 Wasm 扩展的方式，引出了 Wasm filter 机制，这将是未来的主流方式。

在一个服务网格体系中，如何以有效并且简单的方式来管理 Wasm filter 的部署运行，将是云产品需要解决的一个问题。

OPAS 及 Wasm filter 注册库

在 Cloud Native 生态系统中，如何管理一个 Artifact 文件，相信绝大多数人会想到 oci 规范标准，是否可以像管理 Docker 镜像那样去管理这些 Wasm filter。

ORAS 项目就是用来解决这个问题的，它的全称为 OCI Registry As Storage。ORAS 是 OCI Artifacts 项目的参考实现，可以显著地简化 OCI 注册库中任意内容的存储。

使用 ORAS API/SDK Library 可以构建自定义工具，完成以下功能：

• 将 WebAssembly 模块推入到 OCI 注册库中。

• 从 OCI 注册库中拉取 WebAssembly 模块。

oras cli 的使用类似于 docker cli，如下所示：

以阿里云容器镜像服务企业版 ACR EE 为例，作为企业级云原生应用制品管理平台，已经提供了容器镜像、Helm Chart 以及符合 OCI 规范的制品的生命周期管理。开通之后，创建一个镜像仓库，会分配一个地址，提供了 vpc 和公网两种方式。

使用 oras login 命令行登录, 执行以下命令：

oras login --username=<登录账号> acree-1-registry.cn-hangzhou.cr.aliyuncs.com

通过oras push命令推送, 执行以下命令：

oras push acree-1-registry.cn-hangzhou.cr.aliyuncs.com/******/asm-test:v0.1 --manifest-config runtime-config.json:application/vnd.module.wasm.config.v1+json  example-filter.wasm:application/vnd.module.wasm.content.layer.v1+wasm

注意参数 --manifest-config，可以参考 Wasm Artifact 镜像规范。

Wasm filter 被推送到 ACR EE 注册库中之后，可以查看相关信息，如下：

阿里云服务网格 ASM 架构

在阿里云服务网格 ASM 产品中是如何使用 Wasm 技术呢？首先我们了解一下 ASM 产品的技术架构，如下图所示。作为业内首个全托管 Istio 兼容的服务网格产品，ASM 的定位是专注打造全托管、安全、稳定、易用的服务网格，以及支持跨地域多集群、多云混合云服务的统一治理。控制平面的组件托管在阿里云侧，与数据面侧的用户集群解耦独立，降低用户使用的复杂度，用户只需要专注于业务应用的开发部署。在托管模式下，保持与 Istio 的兼容，支持声明式的方式定义灵活的路由规则，支持多个 Kubernetes 集群的统一流量管理。

服务网格 ASM 作为连接上层应用和下层计算基础设施的重要环节，可以分为 3 个角度来理解：

• 从向下与基础设施融合的角度

• 服务网格自身的能力建设的角度

• 向上支持应用层以及被集成能力的角度

其中, 从服务网格自身的能力建设来看，ASM 作为一个托管的服务网格产品，提供了柔性架构，可以支持不同版本的、定制的 Istio 控制面与数据面 Proxy 代理。

• 在托管侧，将控制面核心组件进行改造托管，并负责整个控制面和数据面组件的生命周期管理。在产品能力方面，ASM 在 Mesh CA、安全审计方面做了增强提升网格实例的安全度；把客户场景的常见问题形成了诊断规则，用户可以自行运行诊断分析。 

• 在做核心托管侧的建设之外，ASM 优化整合了阿里云的多个产品服务，如：在可观测性方面，整合了 xtrace、arms、日志服务等；在跨 vpc 网络打通方面整合了 cen，实现多集群的互联互通；在限流方面集成了 AHAS 的限流服务。

• ASM 还集成扩展了社区开源的组件能力，包括在安全方面的 OPA 安全引擎的支持、spiffe/spire 的支持、envoyfilter 的扩展支持等。所以这一部分需要提供一种简单有效的方式帮助用户轻松扩展这些能力。

在阿里云 ASM 中使用 Wasm

随着新架构的优化，WebAssembly 技术被引入服务网格中，解决代理扩展的问题。这样一来， ASM 架构就变成了“托管的高可用弹性控制平面 + 可扩展的插件式的数据平面“的模式。

阿里云服务网格 ASM 产品中提供了对 WebAssembly（WASM）技术的支持，服务网格使用人员可以把扩展的 WASM Filter 通过 ASM 部署到数据面集群中相应的 Envoy 代理中。通过 ASMFilterDeployment  Controller 组件,  可以支持动态加载插件、简单易用、以及支持热更新等能力。

通过这种过滤器扩展机制，可以轻松扩展 Envoy 的功能并将其在服务网格中的应用推向了新的高度。

下面我们具体来看在 ASM 实例中是怎样启用这个能力的？

部署一个 ASM 实例之后，默认该功能是没有开启的，用户需要主动去开启。例如通过如下 aliyun cli 方式：

aliyun servicemesh UpdateMeshFeature  --ServiceMeshId=xxxxxx --WebAssemblyFilterEnabled=true

开启该功能之后，ASM 实例会部署相关组件并执行如下任务：

• 部署一个 DaemonSet(asmwasm-controller) 到 K8s 集群中。

• asmwasm-controller 监听一个 configmap，该 configmap 存放要拉取的 wasm filter 的地址，例如：acree-1-registry.cn-hangzhou.cr.aliyuncs.com/*******/sample:v0.1。

• 如果需要授权认证，该 asmwasm-controller 会根据定义的 pullSecret 值获得相应的 secret 值。

• 然后，调用 oras API 从注册库中动态拉取 Wasm filter。

• 该 asmwasm-controller 使用 HostPath 方式挂载 volume，所以拉取的 Wasm filter 会落盘到对应的节点上。

启用了该功能之后，如何开始部署一个 Wasm filter 并挂载到对应 workload 的 Envoy Proxy 中呢？

阿里云服务网格 ASM 产品提供了一个新的 CRD ASMFilterDeployment 以及相关的 controller 组件。这个 controller 组件会监听 ASMFilterDeployment 资源对象的情况，会做 2 个方面的事情：

• 创建出用于控制面的 Istio EnvoyFilter Custom Resource，并推送到对应的 asm 控制面 istiod 中。

• 从 OCI 注册库中拉取对应的 wasm filter 镜像，并挂载到对应的 workload pod 中。

以下是一个 ASMFilterDeployment CR 示例：

apiVersion: istio.alibabacloud.com/v1beta1
kind: ASMFilterDeployment
metadata:
  name: details-v1-wasmfiltersample
spec:
  workload:
    kind: Deployment
    labels:
      app: details
      version: v1
  filter:
    parameters: '{"name":"hello","value":"hello details"}'
    image: 'acree-1-registry.cn-hangzhou.cr.aliyuncs.com/asm/asm-test:v0.1'
    imagePullOptions: 
      pullSecret: 'asmwasm-cache'
    rootID: 'my_root_id'
    id: 'details-v1-wasmfiltersample.default'

生成的 Istio Envoy Filter 资源如下所示：

其中，match 片段中定义了 envoy.router 这个 filter、patch 片段中定义了 INSERT_BEFORE 操作，插入一个 Wasm filter，如下：

挂载了 Wasm filter 的工作负载定义更新后如下，其中以 hostpath 方式挂载 Wasm filter 文件到 Proxy 容器中：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
.…
spec:
   ….
   template:
      metadata:
          annotations:
              sidecar.istio.io/userVolume: '[{"name":"wasmfilters-dir","hostPath":{"path":"/var/local/lib/wasm-filters"}}]’
              sidecar.istio.io/userVolumeMount: '[{"mountPath":"/var/local/lib/wasm-filters","name":"wasmfilters-dir"}]'

确认 Wasm filter 是否生效。登录到 productpage Pod 的 istio-proxy 容器中，执行以下命令，将一些流量发送到 details 服务上。在响应中，可以看到过滤器的头添加到响应头中。

kubectl exec -ti  deploy/productpage-v1 -c istio-proxy -- curl -v http://details:9080/details/123

*   Trying 172.21.9.191...
* TCP_NODELAY set
* Connected to details (172.21.9.191) port 9080 (#0)
> GET /details/123 HTTP/1.1
> Host: details:9080
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
xxxxxxx
< resp-header-demo: added by our filter
xxxxx
* Connection #0 to host details left intact
xxxxx

关于基于Wasm和ORAS如何简化扩展服务网格功能问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注创新互联行业资讯频道了解更多相关知识。