Description
This is a summarize and discussion of the ways to extend or custom Envoy functionalities, let's compare below 4 methods, we don't talk about details of the implementation, just compare and choose which we want to make Contour to support.
Comparison:
WASM:
ref. #4276
Security: Medium
For Envoy, it provide sandbox to make WASM run in an isolation area, the Envoy main process will not be affected.
Extendibility: High
Users can implement any logic in WASM and set the WASM run in any stage of Envoy.
Performance: Low
The WASM performance is not good, from an Istio expert, the WASM only has 50% performance of Envoy native logic.
Others: WASM will increase the NACKs, because load WASM depends on WASM file and from configuration to load file, there is more chances to NACKs.
Lua:
ref. #3006
Security: Low
If user write a bad script, Envoy will be affected.
Extendibility: High
As same as WASM user can create any logic by Lua.
Performance: Medium / Low
From some Istio usage experience, for performance Lua is better then WASM, and from gateway use case, the performance still not good.
External Processing
ref. #5038
Security: High
Like ExAuth and Traffic Ratelimit, use external processing to extend envoy functionalities is a good way, because there is no logic code running in Envoy, just get response from a external service (like auth server), so if the external service has problem, for Envoy, it works well.
Extendibility: Low
For External Processing, must design by the standard, if user want to do anything not related the rules, maybe that can't work.
Performance: High
The external service can deploy more replica and assign more resources to improve performance.
GO filter
Security: Low
As my understanding the filter of envoy be extended will inject envoy process, if there is any problem, it will affect envoy.
Extendibility: High
As same as WASM and Lua, we can code anything we want.
Performance: High
For GOLANG the performance is higher than WASM and Lua, but still need to test.