add waypoint context to envoyfilter

[dprotaso]

Part of https://github.com/istio/istio/issues/43720

/assign @howardjohn

[istio-policy-bot]

😊 Welcome @dprotaso! This is either your first contribution to the Istio api repo, or it's been a while since you've been here.

You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines by referring to Contributing to Istio.

Thanks for contributing!

Courtesy of your friendly welcome wagon.

[istio-testing]

Hi @dprotaso. Thanks for your PR.

I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[keithmattix]

I added my thoughts here: https://github.com/istio/istio/pull/55149#issuecomment-2669135461

[linsun]

We discussed this in a meeting recently, and we couldn't reach consensus that we need to implement envoy filter support in waypoint.

[zirain]

IMO, you cannot add every features envoy supported into first class API.

For RateLimit, ExtProc, we can support it by first class API. How to tweak some configuration in Cluster/Route/Listerner?

If you search the github issue, lot of edge cases were fixed by EnvoyFilter, I don't think it won't happen in Waypoint.

In the end, every vendor need to add EF support in their forks, that's the worst to the community.

[vikaschoudhary16]

Yeah, I noticed https://github.com/istio/istio/pull/55149#issuecomment-2667362269 and we also need EF patching at waypoint. There could be many users affected. so +1 to @zirain.

[zhaohuabing]

+1

I’d really love to see this PR land—EF support for Waypoint is an important step forward. It helps ensure a smooth migration path for existing sidecar users and builds confidence for those looking to adopt Ambient.

Regarding the concern around unstable xDS and patch compatibility across Istio versions: I believe all EF users understand that patches can break and would take the necessary steps to validate them before upgrading. Giving users the option to move forward—while being aware of the risks—feels more empowering than blocking EF entirely due to potential issues.

[hzxuzhonghu]

Personally i'd like to see same features applied to ambient as envoyfilter, it will benefit the community a lot.

So LGTM

[vikaschoudhary16]

@ramaraochavali wdyt?

[ramaraochavali]

@linsun what are the specific concerns discussed in WG meeting for enabling Envoy filters for waypoints?

[adamplansky]

Hey guys, we are currently looking into ambient mode and we found it is hard to move from sidecarproxy to ambient mode without envoyfilters. In sidecar proxy we are using HTTPRoute/GRPCRoute (Gateway API) with Destination Rule and because GatewayAPI does not support all the features as VirtualService we implemented faultInjection and retry with the help of EnvoyFilter. I think without waypoint supporting envoyfilter we are not able to fully migrated from sidecar mode to ambient mode without significant changes (e.g. migration from Gateway API to VirtualService).

[Yufeireal]

Three use cases from us is

1. internal global/local rate limiting Re-implementing one use WASM is probably doable. I don't know how to decently mount configs in WASM VM vs using a k8s way, Envoyfilter with ext service + configmaps.

2. (Not sure if this is supported by Telemetry API already) we use Envoyfilter to write logs to otel through gRPC and defined schema and sampling rate[this is not supported by Telmetry API as far as I know].

3. Dev env We have an Envoyfilter written by Lua to do something like "if requests have dev env headers", route it to dev pods(it's not simply the header based routing); otherwise route to main pods.

[mikemorris]

@adamplansky Good news is that at least retries are now available in the Gateway API experimental channel (introduced in https://gateway-api.sigs.k8s.io/geps/gep-1731/) and have been implemented in Istio in https://github.com/istio/istio/pull/54800

Fault injection isn't supported yet, but please keep an eye on https://github.com/kubernetes-sigs/gateway-api/issues/3575 and upvoting/commenting with your use case will help us prioritize it.

[mikemorris]

@Yufeireal I'm hoping we can generate enough demand for rate-limiting in Gateway API to reopen https://github.com/kubernetes-sigs/gateway-api/issues/326 - a few other implementations have already been experimenting with impl-specific approaches to this and I hope we can get it into the actual spec soon.

[zirain]

@Yufeireal I'm hoping we can generate enough demand for rate-limiting in Gateway API to reopen kubernetes-sigs/gateway-api#326 - a few other implementations have already been experimenting with impl-specific approaches to this and I hope we can get it into the actual spec soon.

For local ratelimit, we can proposal a route filter to support it. But it's hard for global, as we need to config RLS backend at the same time.

For such features, there is always a place for EF in Ambient.

[linsun]

@linsun what are the specific concerns discussed in WG meeting for enabling Envoy filters for waypoints?

Sorry didn't see this earlier, mainly maintenance/support concerns and potential breakage. I think this topic also being discussed in last week's TOC mtg which may have a more recent update. cc @istio/technical-oversight-committee

[costinm]

We don't need to wait for upstream gateway to define anything - for any feature like ratelimit and almost anything that envoy filters support I think we can add explicit istio vendor API with the normal attachment.

We can even take entire envoy filters (if they are v1/stable in envoy) and add them as Istio vendor APIs. That can make it easier for users because LLMs will not have trouble generating with slightly different syntax in istio or envoy.

The top problem with the envoy filter API is the unlimited scope. The second problem is the 'patch' semantics instead of proper attachment.

If 'upstream' happens to adopt an API or another - we can support it if it's v1, otherwise we can wait and keep using ours.

[istio-testing]

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.