Shulou(Shulou.com)05/31 Report--

Based on how to simplify and expand the service grid function of Wasm and ORAS, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

The editor will show you how to use the ORAS client to push Wasm modules with allowed media types into the ACR registry (an OCI-compatible registry), and then deploy Wasm Filter to the Pod for the specified workload through the ASM controller. All the steps in the Wasm Filter deployment are declared, that is, a custom resource CRD can be created to describe the deployment of the Wasm Filter. Once the CRD is created, the ASM controller can load the Wasm module into the appropriate Envoy agent in the data plane layer, and the corresponding Istio EnvoyFilter custom resources are also created in the control plane layer.

Envoy Filter introduction

First, review the implementation mechanism of EnvoyProxy. The core of Envoy is a L3/L4 network agent and supports L7 proxy. By providing pluggable filter chain mechanism, it allows developers to write filter to perform different tasks, such as HTTP connection manager, which converts raw bytes into HTTP-level messages and events, and functions common to all HTTP connections and requests, such as access log, tracing, and so on.

As you can see in the figure above: Downstream is the client part that connects to the Envoy and sends requests and receives responses. The listener Listener component is used to bind to the IP address / port and receive connections from downstream of the Downstream. By configuring Listener, users can enable traffic management through agents, and then use multiple Filter to enhance the data flow, and multiple Filter form a Filter Chain. You can see that after these Filter chain processing, the request is mapped to the corresponding Cluster (the Cluster cluster here refers to a logically identical group of upstream hosts to which the Envoy is connected, which has nothing to do with the Kubernetes cluster submitted below), while Cluster is responsible for connecting to a group of upstream node services and forwarding these requests using the associated load balancing policy.

Depending on how you handle the task, Envoy Filter is divided into three categories:

Listener Filter: used to manipulate metadata in L4 connections.

Network Filter: used to manipulate the raw data in an L4 connection.

HTTP Filter: used for operations to process HTTP requests and responses in L7 connections.

In addition to these built-in Filter, you can develop custom Filter, compile using native C++, or build Filter through wasm technology.

In addition, Envoy provides a set of API, also known as xDS API. With these API, the control plane can configure the Envoy agent dynamically.

As shown in the figure above, similar to inbound traffic, for outbound traffic, the listener listens for requests to listen for network traffic at the configured address or port. Each listener also defines a set of Filter located in the data path and forms a set of filter chain Filter Chain. Through such a set of filters, users can configure Envoy to do specific tasks for outbound traffic, including data protocol processing, generating call statistics, executing RBAC permissions, and so on.

To better understand these Envoy Filter and Filter Chain, let's look at a practical example. This is the first service productpage in the Istio official example bookinfo. First of all, Envoy Proxy in productpage pod is configured with a listener that listens to port 9080. Traffic requests on port 9080 of this pod will be intercepted into this proxy, and then the requests will be processed through these Filter Chain. The details are as follows:

The first filter is envoy.filters.network.metadata_exchange, which, as its name implies, is used to exchange metadata between filter.

The second filter: envoy.http_connection_manager, which usually has the following filter specific to http, including:

Envoy.filters.http.wasm/envoy.wasm.metadata_exchange (for metadata interaction)

Istio_authn filter (for authorization authentication)

Envoy.filters.http.cors (filter that handles cross-domain resource sharing)

Envoy.filters.http.fault (fault injection filter, which can be used to test fault tolerance in micro-service architecture. Users can customize error codes to implement delayed injection or terminate requests, and provide error handling capabilities in different failure scenarios, such as service failure, service overload, high service latency, etc., which is also a more common filter)

Envoy.filters.http.wasm/envoy.wasm.stats, envoy.filters.http.wasm/xxx-wasmfilter (filter of user-defined wasm implementation)

Envoy.filters.http.router (implement HTTP forwarding, which is used in almost all HTTP scenarios)

Note: you can obtain configuration information by requesting this URL address: kubectl exec-it [productpage-xxx]-c istio-proxy curl localhost:15000/config_dump

Add a new Filter

Several Built-in Filters are already available in the Envoy community, see https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/http_filters for details.

In the service grid, these Built-in Filter capabilities can be enabled through API.

If these Built-in Filter cannot meet the requirements, you can also implement them through custom Filter. There are two ways to do this:

Static precompilation:

Integrate other filters into the Envoy source code and compile the new Envoy version.

The disadvantage of this approach is that you need to maintain the Envoy version and keep it in sync with the official release.

Since Envoy is implemented in C++, newly developed filters must also be implemented in C++.

Dynamic runtime loading:

The new filter is dynamically loaded into the Envoy agent at run time.

In order to simplify the process of extending Envoy, by introducing WebAssembly technology, which is an effective portable binary instruction format, it provides an embedded and isolated execution environment.

Advantages and disadvantages of using Wasm to extend Envoy Proxy

In practical applications, the following advantages and disadvantages will be used to decide whether to use Wasm to extend Envoy Filter.

Pros

Agility: filters can be dynamically loaded into a running Envoy process without stopping or recompiling.

Maintainability: you don't have to change the underlying code base of Envoy to extend its functionality.

Diversity: you can compile popular programming languages (such as Candlestick + and Rust) to WASM, so developers can choose the programming language that implements the filter.

Reliability and isolation: the filter is deployed into the VM sandbox, so it is isolated from the Envoy process itself; it does not affect the Envoy process even when there is a problem with WASM Filter that causes it to crash.

Security: filters communicate with Envoy agents through a predefined API, so they can access and modify only a limited number of connection or request properties.

Cons

The performance is about 70% of the native statically compiled Filter written by C++.

Because one or more WASM virtual machines need to be started, a certain amount of memory usage is consumed.

The WebAssembly ecosystem is still young .

Envoy-wasm operation mechanism

As shown in the following figure, the envoy-wasm operation mechanism includes the following steps:

Wasm binaries need to be able to be loaded dynamically, whether through local file or xds remote acquisition.

Whether a Wasm filter is allowed to be loaded or not requires a consistency check: https://github.com/proxy-wasm/spec.

Once loaded, the Wasm filter becomes part of the filter chain, and when a new request comes in, it goes first to the native filter and then to the Proxy-Wasm extension controller.

The Proxy-Wasm extension controller invokes and executes the registered validated Wasm filter based on the configuration information defined in the filter chain.

Built-in Wasm runtime support: LLVM-based WAVM ~ 20MB, and V8 ~ 10MB.

Event-driven model.

Compatible with native filter call mode.

As shown below, it is the configuration content of a Wasm Filter sent to the Envoy Proxy side.

The above described Envoy Filter and the way through Wasm extension, led to the Wasm filter mechanism, which will be the mainstream way in the future.

In a service grid system, how to manage the deployment and operation of Wasm filter in an effective and simple way will be a problem that cloud products need to solve.

OPAS and Wasm filter registry

In the Cloud Native ecosystem, how to manage an Artifact file, I believe that the vast majority of people will think about the oci specification standards, whether they can manage these Wasm filter like managing Docker images.

The ORAS project is designed to solve this problem, and its full name is OCI Registry As Storage. ORAS is a reference implementation of the OCI Artifacts project that can significantly simplify the storage of any content in the OCI registry.

Using ORAS API/SDK Library, you can build custom tools that perform the following functions:

Push the WebAssembly module into the OCI registry.

Pull the WebAssembly module from the OCI registry.

The use of oras cli is similar to docker cli, as follows:

Take Ali Cloud Container Image Service Enterprise Edition ACR EE as an example. As an enterprise-level cloud native application product management platform, it already provides lifecycle management of container images, Helm Chart and products that conform to OCI specifications. After activation, an image repository is created and an address is assigned, which provides both vpc and public network methods.

Log in using the oras login command line and execute the following command:

Oras login-username= acree-1-registry.cn-hangzhou.cr.aliyuncs.com

Push through the oras push command, execute the following command:

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

Pay attention to the parameter-manifest-config. You can refer to the Wasm Artifact image specification.

After Wasm filter is pushed to the ACR EE registry, you can view the relevant information, as follows:

Ali Cloud Service Grid ASM Architecture

How to use Wasm technology in Ali Cloud Service Grid ASM product? First, let's take a look at the technical architecture of the ASM product, as shown in the following figure. As the industry's first fully hosted Istio-compatible service grid product, ASM is positioned to focus on creating a fully managed, secure, stable and easy-to-use service grid and supporting unified governance of cross-regional, multi-cluster and multi-cloud hybrid cloud services. The components of the control plane are hosted on the Ali cloud side, which is decoupled and independent from the user cluster on the data side, reducing the complexity of users. Users only need to focus on the development and deployment of business applications. In managed mode, it is compatible with Istio, supports declarative way to define flexible routing rules, and supports unified traffic management of multiple Kubernetes clusters.

As an important part of connecting the upper application and the lower computing infrastructure, the service grid ASM can be understood from three angles:

From the perspective of downward integration with infrastructure

From the point of view of capacity building of service grid itself

The point of view of upward supporting the application layer and the ability to be integrated

Among them, from the point of view of the capacity building of the service grid itself, ASM, as a managed service grid product, provides a flexible architecture that can support different versions of customized Istio control plane and data plane Proxy agents.

On the hosting side, the core components of the control plane are transformed and managed, and are responsible for the life cycle management of the entire control plane and data plane components. In terms of product capabilities, ASM has enhanced the security of grid instances in terms of Mesh CA and security audit; it has formed diagnostic rules for common problems in customer scenarios, and users can run diagnostic analysis on their own.

In addition to the construction of the core hosting side, ASM optimizes and integrates many of Aliyun's products and services, such as xtrace, arms and log services in terms of observability; integrates cen in cross-vpc network access to achieve multi-cluster interconnection; and integrates AHAS's current limit service in terms of current limit.

ASM also integrates and extends the open source component capabilities of the community, including OPA security engine support in security, spiffe/spire support, envoyfilter extension support, and so on. So this part needs to provide a simple and effective way to help users easily expand these capabilities.

Using Wasm in Aliyun ASM

With the optimization of the new architecture, WebAssembly technology is introduced into the service grid to solve the problem of agent expansion. As a result, the ASM architecture becomes a "managed highly available resilient control plane + scalable plug-in data plane" mode.

Ali Cloud Service Grid ASM products provide support for WebAssembly (WASM) technology, and service grid users can deploy the extended WASM Filter to the corresponding Envoy proxy in the data side cluster through ASM. Through the ASMFilterDeployment Controller component, you can support the ability to dynamically load plug-ins, easy to use, and support hot updates.

Through this filter extension mechanism, the function of Envoy can be easily extended and its application in service grid can be pushed to a new height.

Let's take a look at how this capability is enabled in the ASM instance.

After deploying an ASM instance, this feature is not enabled by default, and users need to enable it actively. For example, through the following aliyun cli methods:

Aliyun servicemesh UpdateMeshFeature-ServiceMeshId=xxxxxx-WebAssemblyFilterEnabled=true

After enabling this feature, the ASM instance will deploy the relevant components and perform the following tasks:

Deploy a DaemonSet (asmwasm-controller) to the K8s cluster.

Asmwasm-controller listens for a configmap that stores the address of the wasm filter to be pulled, such as acree-1-registry.cn-hangzhou.cr.aliyuncs.com/*/sample:v0.1.

If authorization is required, the asmwasm-controller will get the corresponding pullSecret value based on the defined secret value.

Then, call oras API to dynamically pull the Wasm filter from the registry.

The asmwasm-controller uses HostPath to mount the volume, so the pulled Wasm filter will be dropped to the corresponding node.

Once this feature is enabled, how do you start deploying a Wasm filter and mounting it to the Envoy Proxy of the corresponding workload?

The Ali Cloud Service Grid ASM product provides a new CRD ASMFilterDeployment and related controller components. This controller component listens for ASMFilterDeployment resource objects and does two things:

Create an Istio EnvoyFilter Custom Resource for the control plane and push it to the corresponding asm control plane istiod.

Pull the corresponding wasm filter image from the OCI registry and mount it to the corresponding workload pod.

The following is an example of ASMFilterDeployment CR:

ApiVersion: istio.alibabacloud.com/v1beta1kind: ASMFilterDeploymentmetadata: name: details-v1-wasmfiltersamplespec: 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'

The generated Istio Envoy Filter resources are as follows:

The envoy.router is defined in the match fragment, and the INSERT_BEFORE operation is defined in the patch fragment, and a Wasm filter is inserted as follows:

After the workload definition with Wasm filter mounted is updated as follows, the Wasm filter file is mounted to the Proxy container in a hostpath manner:

ApiVersion: extensions/v1beta1kind: Deploymentmetadata:.... 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"}]'

Confirm that the Wasm filter is valid. Log in to productpage Pod's istio-proxy container and execute the following command to send some traffic to the details service. In the response, you can see that the filter header is added to the response header.

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 OKxxxxxxx < resp-header-demo: added by our filterxxxxx* Connection # 0 this is the answer to to host details left intactxxxxx's question on how to simplify and extend the functionality of service grid based on Wasm and ORAS. I hope the above content can help you to a certain extent, if you still have a lot of doubts to be solved, you can follow the industry information channel to learn more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.