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

时间 2021-03-07

标签 c++ git github docker 编程 json api 跨域安全网络栏目 C&C++ 繁體版

原文原文链接

做者 | 王夕宁阿里云高级技术专家
来源 | 阿里巴巴云原生公众号c++

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

Envoy Filter 介绍

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

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

根据处理任务的不一样，Envoy Filter 分为三类：编程

Listener Filter：用于操做处理 L4 链接中的元数据。
Network Filter：用于操做处理 L4 链接中的原始数据。
HTTP Filter：用于操做处理 L7 链接中的 HTTP 请求与响应。

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

此外，Envoy 提供了一组 API，也就是咱们常说的 xDS API。经过这些 API，控制平面能够动态地配置 Envoy 代理。api

如上图所示，与进站流量相似，对于出站流量来讲，监听器在配置的地址或者端口进行监听网络流量的请求。每一个监听器一样会定义一组位于数据路径中的 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 sdk/编程语言，建立编译出一个 wasm 二进制文件，经过使用 oras cli 上传到 oci 镜像仓库中。

在部署运行阶段：

首先确认已经在 ASM 中开启 Wasm 支持能力，而后建立一个 ASMFilterDeployment 自定义资源，注意这个 CR 是在服务网格 ASM 实例对应的 apiserver 中建立。一旦建立，相应的 crd controller 会监听同步相应的资源，一方面生成一个 Istio EnvoyFilter CR 并发送到 ASM 实例的控制面 apiserver 中，用户能够查看生成的这个 Istio Envoyfilter CR 是否知足指望。

另外一方面，确认 Workload 部署变动生效，包括：

能够登陆到 proxy container 进行查看 Wasm filter 是否挂载成功。
经过调整 wasm log level 来打印相关信息。

做为业内首个全托管 Istio 兼容的服务网格产品，阿里云服务网格（简称 ASM）是一个统一管理微服务应用流量、兼容 Istio 的托管式平台，专一打造全托管、安全、稳定、易用的服务网格，支持跨地域多集群、多云混合云服务的统一治理。经过流量控制、网格观测以及服务间通讯安全等功能，服务网格 ASM 能够全方位地简化您的服务治理，并为运行在异构计算基础设施上的服务提供统一的管理能力，适用于 Kubernetes 集群、Serverless Kubernetes 集群、ECS 虚拟机以及自建集群。

欢迎登陆到阿里云服务网格 ASM 产品官网进行体验！

做者简介

王夕宁阿里云高级技术专家，阿里云服务网格 ASM 技术负责人，专一于 Kubernetes、服务网格以及其余云原生领域。以前曾在 IBM 中国开发中心工做，曾担任专利技术评审委员会主席，做为架构师和主要开发人员负责或参与了一系列在 SOA 中间件、云计算等领域的工做，拥有 50 多项相关领域的国际技术专利。曾在多个技术大会如 Kubecon、ArchSummit、云栖大会等参与技术分享。编写《服务网格技术解析与实践》并在多个技术社区发布文章若干。