Hello! Today, I’d like to talk about a powerful weapon in the service mesh environment: Istio and Wasm (WebAssembly). With Istio, you can control and observe communication between services. Adding Wasm allows you to freely extend the functionality of the Envoy proxy. It’s like installing any app you want on your smartphone! π±
But how are you deploying these powerful Wasm modules? Are you perhaps injecting configurations directly using EnvoyFilter? While possible, it can be a dangerous method that could potentially cripple your entire service if done incorrectly.
Today, we’ll thoroughly explore why the WasmPlugin resource is a much safer and smarter choice than EnvoyFilter.

π£ A Time Bomb Method: EnvoyFilter
EnvoyFilter is a very powerful but difficult-to-handle feature of Istio. It allows you to directly modify Envoy proxy settings at a very low level. It’s like opening a car engine and directly replacing parts or changing wiring. π§
Why is it dangerous?
EnvoyFilter literally ‘patches’ Envoy’s configuration dump directly. A small mistake here can stop the entire proxy’s operation or cause unexpected network failures.
- Configuration Complexity: You need a complete understanding of Envoy’s internal configuration structure. You must precisely specify where in the filter chain and in what format to insert the Wasm filter.
- Typos and Structural Errors: Just one indentation error or a typo in a field name in the YAML configuration can prevent Istio from parsing the configuration correctly, potentially breaking the Envoy proxies of the entire workload. π±
- Version Dependency: If Istio or Envoy versions are upgraded and the internal configuration structure changes, an existing EnvoyFilter that was working fine might suddenly cause errors.
Example of Wasm Deployment using EnvoyFilter
Below is an example of injecting a Wasm filter using EnvoyFilter. See how complex and verbose the code is.
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: my-wasm-filter-example
namespace: my-app
spec:
workloadSelector:
labels:
app: my-product-api
configPatches:
- applyTo: HTTP_FILTER
match:
context: SIDECAR_INBOUND
listener:
filterChain:
filter:
name: "envoy.filters.network.http_connection_manager"
subFilter:
name: "envoy.filters.http.router"
patch:
operation: INSERT_BEFORE
value:
name: envoy.filters.http.wasm
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
config:
name: "my_wasm_module"
root_id: "my_root_id"
vm_config:
vm_id: "my_vm_id"
runtime: "envoy.wasm.runtime.v8"
code:
local:
filename: "/etc/envoy/wasm/my_module.wasm"
configuration:
"@type": "type.googleapis.com/google.protobuf.StringValue"
value: |
{
"message": "Hello from Wasm!"
}
Doesn’t it look dizzying just by looking at it? There are too many things to pay attention to, such as applyTo, match, and patch, and it’s difficult to write without knowing Envoy’s internal structure.
β¨ A Safe and Elegant Method: WasmPlugin
To solve the risks and complexities of EnvoyFilter, the WasmPlugin resource emerged. WasmPlugin is a high-level, abstract API created for the specific purpose of deploying Wasm modules.
To use the car analogy again, it’s like setting a destination on a well-designed navigation screen instead of directly touching the engine. Much simpler and safer!
Why is it safe and good?
WasmPlugin concisely receives only the information needed to deploy Wasm modules. Istio handles the complex Envoy configuration patching automatically.
- Simple and Clear API: You only need to enter essential information such as the Wasm module’s URL and required configuration values. Users don’t need to know Envoy’s internal workings.
- Reduced Error Risk: The simplicity of the configuration significantly reduces the chance of human error. Istio internally performs validation to prevent incorrect configurations from being deployed. β
- Excellent Portability and Reusability: The WasmPlugin resource is self-contained, making it easy to reapply to different environments or workloads.
Example of Wasm Deployment using WasmPlugin
How would the same task be implemented with WasmPlugin? Look at the code below.
apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
name: my-wasm-plugin-example
namespace: my-app
spec:
selector:
matchLabels:
app: my-product-api
url: oci://my-registry/wasm/my_module:1.0.0
pluginConfig:
message: "Hello from Wasm!"
Incredibly simple, isn’t it? π€©
- selector: Selects which workloads to apply to.
- url: Specifies the location of the Wasm module to deploy (e.g., OCI image).
- pluginConfig: Easily enter configuration to pass to the Wasm module.
Without complex patch logic, you declare “What” to deploy, and Istio handles “How”.
π― Comparing in Context: EnvoyFilter vs. WasmPlugin
| Item | EnvoyFilter Β π₯ | WasmPlugin β¨ |
|---|---|---|
| Abstraction Level | Low (Low-level) | High (High-level) |
| Purpose | Generic tool to patch all Envoy settings | Dedicated to Wasm module deployment |
| Safety | Low (Configuration errors can cause entire proxy failure) | High (Provides safe abstraction) |
| Complexity | Very High | Very Low |
| Recommended Use | As a last resort when special Envoy settings not possible with WasmPlugin are needed | Standard and recommended method for Wasm module deployment |
In conclusion, using EnvoyFilter to deploy Wasm modules is like trying to fix a watch with a hammer. It’s possible, but there’s no need to take the risk when a safer and more suitable tool (WasmPlugin) is available.
For stable service operation, please start using WasmPlugin for Wasm module deployment from now on! Your service mesh will become even more robust. πͺ
Leave a Reply