-
Notifications
You must be signed in to change notification settings - Fork 369
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
State and Future of EnvoyGateway Extension Points #2025
Comments
Im a +1 on this idea, it can be a safer, less scoped way than EnvoyPatchPolicy of extending EG |
@zhaohuabing @arkodg is there already some progress on integrating GoLang Filters (HTTP, Network) Envoy Docs: Envoy Examples: |
@denniskniep is it a part of envoy core? if not, maybe we should wait for it. |
@zirain Current status is What do you mean exactly with envoy core? BTW: Status of WASM Filter is also |
can you use these filter with |
yes, its only available within Is there any document in envoy where roadmap or plans for these graduation from contrib to core are listed ? |
closing this since this is completed and we are tracking the remaining issue #4627 seperately |
Current State
In v0.4.0, eg introduces ExtensionManager, grpc based extension hooks, to dynamically modify xds resources generated by EG.
In v0.5.0, eg introduces EnvoyPatchPolicy, a CRD resource, to dynamically patch xds resource generated by EG.
In the two above approaches, the extension target is the whole xds resources. It unlocks the full power of xds for vendors/teams to extend EG abilities, which is powerful and flexible.
What`s More?
EnvoyProxy itself provides some extension http filters, which allows people dynamically extend envoyproxy without restarting it, like Lua, WASM and new introduced Go Extension Filter.
I propose EG to provide high level APIs(CRDs) to abstract these extension points. From my experience of using EnvoyFilter in istio, compared with the full xds patch/modify, these ways have more specific target scopes and easier to be control, which are safer , easier and less dangerous to be used.
ExtensionRef or PolicyAttachment ?
ExtensionRef can be used per-route-rule/per-backend, and PolicyAttachment can be used to whole Gateway/xRoute.
The text was updated successfully, but these errors were encountered: