By Yuanyuan Ma
Alibaba Cloud Service Mesh (ASM) is a fully managed service mesh platform. ASM is compatible with the open source Istio service mesh. ASM simplifies service management. For example, you can use ASM to route and split inter-service traffic, secure inter-service communication based on authentication, and observe the behavior of services in meshes. This greatly reduces your development and O&M work.
ASM is designed to help you quickly build secure and reliable services in cloud-native environments. By default, ASM provides rich traffic routing, authentication and authorization, and observability capabilities. However, in real-world production and deployments, there are always specific business requirements that cannot be met by the standard capabilities of the development framework and ASM, such as:
• Custom traffic tagging logic: tags HTTP requests based on customer IDs, application versions, or external data sources.
• Custom authentication/authorization logic: implements special authentication rules and depends on external data sources. This cannot be achieved using ASM's standard authorization policies.
• Manipulate request/response body.
• Add specific business information to the default logs and metrics provided by ASM.
If you choose to implement these features directly in your business code, it would result in high coupling with your business logic. This approach requires addressing issues like supporting multiple languages, enforcement, and upgrades, leading to significant challenges during actual implementation.
ASM has inherent advantages in this regard:
The ASM data plane Layer 7 proxy (gateways, sidecars, waypoints) is implemented based on Envoy, which provides various extension methods to achieve rich customization capabilities. This topic describes the various extension methods provided by ASM and their respective use scenarios.
ASM provides the following extension methods:
We will introduce each of these extension methods.
Filter is a concept in Envoy. Different filters form a filter chain in a certain order. Requests that enter Envoy are processed by these filters in this order and then forwarded to the upstream service. These filters are developed in C++ and compiled together with the core code of Envoy into Envoy binary files with high performance.
In the ASM context, an Envoy filter is a Kubernetes resource provided by ASM. You can use the Envoy filter resource to modify existing filters or add new filters in the data plane proxy.
Envoy filters are highly flexible and prone to configuration errors or incompatibilities. Therefore, using Envoy filters requires a certain understanding of the data plane implementation.
To address potential differences in Envoy filter configurations across different versions, ASM provides Envoy filter templates for reference: https://www.alibabacloud.com/help/en/asm/user-guide/manage-envoy-filters
Lua, Wasm, and custom authorization services are also filters in Envoy. Unlike ordinary filters, these filters can implement some user-defined logic. This section only discusses standard Envoy filters designed to achieve specific features.
Limits:
• You can use only the filters provided by Envoy and cannot implement custom logic.
Recommended scenarios: We recommend that you use Envoy filters as long as Envoy provides filters that meet your requirements. For example, you can customize the error page and set the cache size when the request returns 413.
Lua is a lightweight and efficient scripting language. It is mainly used for embedded development and game programming. Known for its simplicity and flexibility, it is widely applied in various fields. Envoy includes a special Lua filter that allows you to write Lua code directly within the filter configuration. This code is then invoked by Envoy during the request processing phase. For more information, see: https://www.alibabacloud.com/help/en/asm/user-guide/routing-based-on-client-ip-on-asm-gateway
Currently, Lua scripts can only take effect when processing HTTP requests. You cannot directly use them to manipulate TCP byte streams.
Limits:
• You need to write Lua code directly in the Envoy filter configuration, which means you cannot reference external libraries. When the logic becomes complex, maintaining the Envoy filter configuration can become challenging. Therefore, it is not recommended to implement overly complicated logic in Lua.
• We recommend that you do not process requests or response bodies in Lua scripts. When you process a request or response body in Lua scripts, Envoy will cache the entire body. If the body is large, it could lead to high memory usage by Envoy or result in a 413 error.
Recommended scenarios: When your requirements are relatively simple and can be met with a small amount of code, Lua is a great choice. In this case, Lua offers high execution efficiency and simple configuration.
Wasm (WebAssembly) is a portable binary format for executable code. Your code is compiled into a binary file that runs at a nearly-native speed in a memory-safe (for host) sandbox. The sandbox has clearly defined resource constraints and provides a clearly defined API for communicating with the embedding host environment (here refers to a proxy). This way, the security is reinforced. Wasm supports multiple programming languages including Rust, C++, and Go.
Unlike Lua, because you provide Wasm binaries directly to Envoy for execution, you can manage the code of these extension capabilities separately and use external libraries to meet specific needs. For more information, see:
• Go
• Rust
Both Lua and Wasm support calling external services through HTTP protocols. Compared with Lua, Wasm is more powerful in processing requests or responses in the following ways:
Limits:
• The Wasm runtime faces challenges with garbage-collected (GC) languages like Go. When running Go-written Wasm plugins in Envoy, memory consumption noticeably increases. The community recommends non-GC languages such as Rust and C++ due to their lower memory footprint and higher execution efficiency. However, these languages often have higher barriers to entry for writing or compiling. You can choose according to your needs.
Recommended scenarios: Wasm is suitable for those familiar with relevant development languages and understanding Envoy's internal processing logic, especially when dealing with complex requirements. Go is simple to write and can be used in scenarios that are not sensitive to performance and resources. For performance and resource-sensitive applications, Rust and C++ are recommended.
External Processing is a native C++ HTTP filter introduced in Envoy 1.23 (corresponding to ASM 1.15). It can call specified external services to process requests at different stages of HTTP requests based on your configurations. The following operations can be implemented:
• Obtain and modify HTTP request or response headers.
• Obtain and modify HTTP request or response bodies.
• Obtain and modify dynamic stream metadata for requests, which can be used to output custom information in metrics and access logs.
• Directly return a custom response.
For more information, see: Use Envoy External Processing for custom processing of requests
Its capabilities are constantly being improved:
• 1.30 (corresponding to ASM 1.22) supports the transfer of various Envoy metadata and Envoy Attribute.
• 1.32 (corresponding to ASM 1.24) supports the asynchronous invocation mode.
Limits:
• If processing is required across multiple stages of a request and response, Envoy has to initiate multiple external requests to the External Processing service, potentially causing higher latency.
• The External Processing service only supports HTTP protocols and cannot process TCP byte streams.
In scenarios where HTTP requests are processed, Wasm and External Processing have similar capabilities.
• Wasm:
• External Processing:
Recommended scenarios: External Processing is suitable for businesses that are insensitive to latency and require complex processing logic. You can use any programming language that provides the gRPC interface required by Envoy.
The principle behind the custom authorization service is that Envoy supports configuring an external authorization filter. When a request is processed by this filter, it calls an external standard HTTP or gRPC service to determine whether to deny or allow the request. This service can also modify or add specific headers to the request. Although the custom authorization service's capability to manipulate requests is more limited compared with Lua or Wasm, its main advantage lies in being decoupled from Envoy, offering a very stable API that does not depend on specific programming languages or frameworks. You only need to implement the HTTP or gRPC interfaces required by Envoy.
For more information, see:
• Develop a custom HTTP-based authorization service
• Implement custom authorization by using the HTTP protocol
• A gRPC protocol custom authorization service development guide
• Implement custom authorization by using the gRPC protocol
Limits:
• It only applies to HTTP requests and cannot be used for responses.
• The accessible request metadata is limited compared with Lua and Wasm. You can only read the request body but cannot manipulate it.
• You need to explicitly configure the available request headers, which cannot be entirely determined by the custom authorization service.
• The custom authorization service is deployed separately, which increases the request processing latency.
Recommended scenarios: The custom authorization service is suitable for authentication and authorization scenarios. It can be combined with the authorization policies of ASM to implement finer-grained authentication and authorization operations.
The ASM plug-in center provides many built-in plug-ins, which are implemented either based on Envoy’s native filters or Lua and Wasm. When you have specific customization needs, it is recommended to first check the plug-in center to see if there is a suitable built-in plug-in available. If not, then consider configuring or developing your own.
Envoy is becoming more and more popular in the cloud-native field, and its powerful extensibility is an important reason for its widespread recognition by more projects and organizations. The ASM data plane is implemented based on Envoy. It offers you both encapsulated functionalities and flexible underlying interfaces, which can meet various customization requirements and enable application developers to focus more on business logic development. Moreover, Envoy’s various extension capabilities continue to evolve. Whether it is Wasm or External Processing, we believe that they will achieve a more balanced state in terms of performance, functionality, and security in the future.
ACK Container Storage Monitoring: Making Your Applications Run More Stably and Transparently
An Automatic Scaling Solution for LLM Inference Services Based on Knative
204 posts | 33 followers
FollowXi Ning Wang(王夕宁) - July 1, 2021
Alibaba Cloud Native Community - December 18, 2023
Alibaba Container Service - January 10, 2025
Alibaba Cloud Native - November 16, 2023
Xi Ning Wang(王夕宁) - June 10, 2020
Alibaba Container Service - May 23, 2025
204 posts | 33 followers
Follow
Cloud-Native Applications Management Solution
Accelerate and secure the development, deployment, and management of containerized applications cost-effectively.
Learn More
Container Service for Kubernetes
Alibaba Cloud Container Service for Kubernetes is a fully managed cloud container management service that supports native Kubernetes and integrates with other Alibaba Cloud products.
Learn More
ACK One
Provides a control plane to allow users to manage Kubernetes clusters that run based on different infrastructure resources
Learn More
Managed Service for Prometheus
Multi-source metrics are aggregated to monitor the status of your business and services in real time.
Learn MoreMore Posts by Alibaba Container Service
