networking extensions

[kyessenov]

Generalization of #1842 to support forward-thinking, proprietary extensions in the HTTP rules.

This roughly matches HTTPRouteFilter.

/assign @howardjohn
/assign @mandarjog
/assign @douglas-reid

Signed-off-by: Kuat Yessenov [email protected]

[istio-testing]

@kyessenov: The following test failed, say /retest to rerun all failed tests:

Test name	Commit	Details	Rerun command
release-notes_api	2ba5cc4	link	/test release-notes_api

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/test-infra repository. I understand the commands that are listed here.

[mandarjog]

I think this is fine, but it only deal with client side extensions, which are only really used at gateways. We need something equivalent on the server side.

[mandarjog]

ENUM ? or a list in the doc?

[kyessenov]

I want to leave it open-ended just like in k8s.

[dgn]

what kind of categories would these be? if we're referencing a generic Extension resource here, that resource will define its category itself, right?

[kyessenov]

Yes, name is sufficient. This is trying to align GVK from k8s Gateway with extensions, so it could help to have an explicit "type" of an extension here.

[mandarjog]

UpdaStruct, so Istio can verify it against some proto.

[kyessenov]

Istio API are only using proto for a schema, and I imagine the extension may chose to use k8s schema instead. UDPA struct is pure proto.

[kyessenov]

@mandarjog Yes, I think for server-side extensions we can generalize Wasm extensions API to cover native extensions. This would be a brand new API. cc @dgn It might be OK to reference extensions API in a per-route extension reference. I just don't see how k8s gateway covers server-side use cases in principle.

[kyessenov]

@dgn I think the back-reference from the Extension resource to the VirtualService route is also a viable approach. I do want to make sure that k8s Gateway can be translated to a set of Extension and VirtualService resources. I think there are a few requirements for this to be possible:

1. k8s allows arbitrary order of filtesr, which is inconsistent with "phases" approach.
2. We need an individual route match in the match context in Extension.
3. Wasm filters can be applied per route via a generic typed_per_filter_config mechanism or something like that (cc @PiotrSikora )

[istio-testing]

@kyessenov: 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/test-infra repository.

[douglas-reid]

@kyessenov do we have a doc or more info on usage / alignment with other proposed APIs ?

[kyessenov]

Daniel's proposal deals with server-side extensions. That is more restricted and simpler, so it should take priority. Ingress/client side can follow.