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

Today, I will talk to you about how to analyze the WebAssembly application in Envoy and Istio. Many people may not know much about it. In order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

Since using Envoy in 2016, the Istio project has always wanted to provide a platform on which rich extensions can be built to meet the diverse needs of users. There are many reasons to add functionality to the data plane of the service grid-such as supporting updated protocols, integrating with proprietary security controls, or enhancing observability by customizing metrics.

For the past year and a half, our team at Google has been trying to use WebAssembly to add dynamic extensions to the Envoy agent. Today we are pleased to share this work with you and launch WebAssembly (Wasm) (Proxy-Wasm) for agents: including a standardized ABI,SDK and its first key implementation: a new, low-latency Istio telemetry system.

We also work closely with the community to ensure a good developer experience for users and help them get started quickly. The Google team has been working closely with the Solo.io team, Solo, who have established WebAssembly Hub services to build, share, discover, and deploy Wasm extensions. With WebAssembly Hub,Wasm extensions, they will be as easy to manage, install, and run as containers.

The project is now in Alpha, and there's still a lot of work to do, but we're happy to hand it over to developers so they can start trying the huge possibilities that come with it.

Background

Extensible requirements have always been the basic principles of Istio and Envoy projects, but the two projects are implemented in different ways. The approach of the Istio project is to enable a general out-of-process extension model called Mixer to provide a lightweight developer experience, while Envoy focuses on in-agent extensions.

Each method has its own advantages and disadvantages. The Istio model leads to obvious resource inefficiency, which affects the tail delay and resource utilization. This model is fundamentally limited-for example, it will never support implementing custom protocol processing.

The Envoy model strengthens the monolithic build process and requires that extensions be written in C++, thus limiting the developer's ecology. Publishing new extensions to the cluster requires new binaries to be released and scrolling restarts, which can be difficult to coordinate and may lead to downtime. This has also prompted developers to submit their extensions to the upstream of Envoy, which are used only by a small number of production environments and more simply to take advantage of its release mechanism.

Over time, some of the most performance-sensitive features of Istio have been incorporated into upstream Envoy-such as traffic checking policies and telemetry reporting. Nevertheless, we have always wanted to bring extensions together on a technology stack to reduce the tradeoff between the two: this decouples the Envoy version from its extension ecosystem, allows developers to work in the language of their choice, and allows Istio to reliably introduce new features without downtime risk.

What is WebAssembly?

WebAssembly (Wasm) is a portable bytecode format written in many languages that can be executed at nearly native speed. Its initial design goal is very consistent with the above challenges, and has received considerable industry support behind it. Wasm, the fourth standard language that can be run natively in all major browsers (after HTML,CSS and JavaScript), became an official recommendation of the W3C in December 2019. This gives us the confidence to make strategic bets on it.

Although WebAssembly was originally born as a client-side technology, it also has many advantages when used on the server. The runtime is memory safe and runs like sandboxie to ensure security. It has a large ecosystem of tools for compiling and debugging Wasm in text or binary format. W3C and BytecodeAlliance have become active centers for other server-side work. For example, the Wasm community is standardizing the "WebAssembly system Interface Interface" (WASI) in the W3C and implementing it through an example that provides an OS-like abstraction for Wasm "programs."

Introducing WebAssembly into Envoy

Over the past 18 months, we have been working with the Envoy community to introduce Wasm extensions into Envoy and contribute to the upstream. We are pleased to announce that this feature is available as the Alpha version of Envoy in Istio 1.5, its source code is in the envoy-wasm development branch, and efforts are under way to merge it into the Envoy trunk. This implementation uses the WebAssembly runtime built into the Google high-performance V8 engine.

In addition to building the underlying runtime, we also built:

Embed Wasm into the agent's generic application binary interface (ABI), which means that the compiled extension will work in different versions of Envoy, even other agents, of course, they should implement the previous ABI

SDK can be easily extended and developed with Clippers, Rust and AssemblyScript, and there are many subsequent languages to support it.

Comprehensive examples and instructions on how to deploy in Istio and stand-alone Envoy

Allows the use of other abstractions from the Wasm runtime, including native compilation of extensions directly into the "null" runtime in Envoy, which is useful for testing and debugging

Extending Envoy with Wasm brings several main benefits:

Agility: you can use the Istio control plane to distribute and reload extensions at run time. This allows you to quickly extend the development → to test the → release cycle without restarting Envoy.

Publishing libraries: once merged into the main tree, Istio and other programs will be able to use Envoy's publishing libraries instead of building them themselves. This also makes it easier for the Envoy community to migrate some built-in extensions to this model, thereby reducing their work.

Reliability and isolation: extensions are deployed in sandboxes with resource constraints, which means they can now crash or leak memory without killing the entire Envoy. CPU and memory usage can also be limited.

Security: sandboxie has a clearly defined API for communicating with Envoy, so the extension can only access and modify a limited number of properties in a link or request. In addition, because Envoy coordinates the entire interaction, it can hide or clear sensitive information in the extension (for example, "Authorization" and "Cookie" in the HTTP header, or the IP address of the client).

Flexibility: more than 30 programming languages can be compiled into WebAssembly, allowing developers from a variety of technical backgrounds to write Envoy extensions in the language of their choice, such as: CrustGraver, Java, TypeScript, etc.

"I am very excited to see WASM support on Envoy; this is the extensible future of Envoy. Envoy's WASM support, combined with community-driven hub, will unleash incredible network innovation in service grids and API gateway use cases. I can't wait to see community building move forward." -Matt Klein, creator of Envoy.

For technical details of the implementation, follow the upcoming article on the Envoy blog.

The Proxy-Wasm interface between the host environment and the extension is deliberately designed to be agent-unaware. We have built it into Envoy, but it is designed for other agent vendors. We want to see that the extensions written for Istio and Envoy can also run in other infrastructure. There will be more related designs and implementations soon.

WebAssembly Construction in Istio

To significantly improve performance, Istio built several of its extensions into Envoy in the 1.5 release. In performing this work, we can compile and run these same extensions as Proxy-Wasm modules, and test to make sure that their behavior is not abnormal. Considering whether we think Wasm is supported or Alpha, we are not quite ready to set this setting as the default; however, it gives us a lot of confidence in our general implementation and hosting environment, at least ABI and SDK have been developed.

We still need to be careful to make sure that the Istio control plane and its Envoy configuration API already support Wasm. We have some examples to show several common customizations, such as custom header decoding or in-program routing, which are common requirements of users. When you evolve this support to the Beta version, you will see documentation in Istio that uses Wasm best practices.

Finally, we are working with many vendors who have written Mixer adapters to help them migrate to Wasm-if this is the best way to move forward. Mixer will be turned into a community project in a future version, and it will still be available for older systems.

Developer experience

Without an excellent developer experience, even powerful tools are useless. Solo.io recently announced the release of WebAssembly Hub, a set of tools and repositories for Envoy and Istio to build, deploy, share, and discover Envoy Proxy Wasm extensions.

WebAssembly Hub fully automates many of the steps required to develop and deploy Wasm extensions. With the WebAssembly Hub tool, users can easily compile code developed by any supported language into a Wasm extension. These extensions can be uploaded to the Hub repository and deployed and deleted in Istio with a single command.

In the background, Hub handles a lot of details, such as introducing the right tool chain, ABI version verification, permission control, and so on. The workflow also eliminates the hassle of configuration changes across Istio service agents by automating scale-out deployment. This tool helps users and operators avoid unexpected behavior caused by configuration errors or version mismatches.

The WebAssembly Hub tool provides powerful CLI and an elegant and easy-to-use graphical user interface. An important goal of WebAssembly Hub is to simplify the experience around building Wasm modules and to provide developers with a collaborative place to share and discover useful extensions.

After reading the above, do you have any further understanding of how to analyze WebAssembly applications in Envoy and Istio? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.