More detail about this feature
Implements Envoy WASM extension based on Sentinel Go and proxy-go (github.com/tetratelabs/proxy-wasm-go-sdk), which will support traffic governance for both HTTP traffic and gRPC services, also it will support configuring rules through Sentinel CRD standard methods
I will work on this feature. If you have any questions or something else want to discuss, welcome to discuss in this issue.
Repo: https://github.com/sentinel-group/sentinel-go-proxy-wasm-extension
3条答案
按热度按时间wyyhbhjk1#
/assign @halfrost
xxb16uws2#
Regarding my current progress:
I am taking the most basic flow.Rule as an example to run through the whole basic wasm extension logic. I initialize an Entry with simply configure WithTrafficType(base.Inbound). I run sentinel locally and read the wiki, and I found that the interception logic is triggered by the runtime. So what I do now is to initialize sentinel when the Envoy begins to load the wasm plugin. After configuration, I start the go coroutine, and sentinel starts to work (this is my expectation). Then call the entry method in wasm's onXXX api to get the SentinelEntry result.
The problem currently being resolved:
vjrehmav3#
Update current progress, I encountered 2 problems and blocked the progress:
In the wasm plugin, common statistical counts are easy to implement, but it involves some low-level metrics in prometheus, which are currently limited by tinygo, resulting in compilation errors. I also looked for solutions on Stack Overflow and github, and saw some more complicated wasm plugins. The tinygo version has not yet written functions related to prometheus. Regarding the issue of cgo, I has been submit an issue to the tinygo team. They are currently working on a fix, the issue is here: tinygo cgo compile error tinygo-org/tinygo#3044
For some of the reasons above. I didn't run sentinel wasm plugin completely. Because prometheus is currently involved, I haven't thought of a workaround for the time being. The case I am currently testing is to run the wasm I wrote on envoy. Then curl the corresponding interface on this machine. Trigger the wasm tcp filter, which in turn can test the logic of the tcp filter. I think this feature's main part is to test the logic of sentinel on the wasm plugin.
So currently this feature is still in progress. I will focus on solving the above 2 problems. If you have any good ideas, welcome to discuss with me. Let's make sentinel better. 💪🏻