Open howardjohn opened 4 years ago
We have considered translating Istio config into Envoy but was afraid it wasn't fit into a hackday project as we wanted to delivery something concrete to add to our pipeline before applying the virtualservices.
This indeed looks a promising approach moving forward tho. Highly appreciate the input.
I think the biggest problem is also the fact that the envoy tool is based on routes, so you need a way to translate the request
from the test to which route will be used. Normally that is handled by listeners/filter chain matching - hopefully we would not re-implement that logic. The actual part of running the istio -> envoy offline isn't super clean but we are working on improving it. https://github.com/istio/istio/blob/bdac0787e932c747154e996cfb2aabef6c820b88/pilot/pkg/xds/bench_test.go#L58 is a good example of doing it (and other stuff, so its a bit messier)
Thanks, this reference will be quite useful and already gives me a direction, I will get more familiar with the tool and codebase and try to come up with a proof of concept after my vacation. Do you think this would be valuable for upstream istioctl
? like istioctl analyze
today. I haven't look at the code/dependencies, etc. to see how much work would be, just something I thought.
My main concern there is that it needs to call out to an external binary (the envoy tool). Might be easiest to ship it as a docker image of something that contains the go binary doing the logic and the envoy binary we call out to. That go binary may or may not be istioctl itself. Probably short term it would be it's own thing then possibly in the future it can be merged in
yeah right, it makes sense. Let's start with that.
An update on this old issue. I've built a prototype and we have been running internally in parallel with existing tooling.
To make it work with our existing tests I forked Istio proxy to build and patch the envoy router tool to work around runtime configuration issues. I've opened an issue https://github.com/envoyproxy/envoy/issues/35174 to find a way forward without patching the tool.
https://www.envoyproxy.io/docs/envoy/latest/install/tools/route_table_check_tool
It would be pretty interesting to directly use the envoy check tool mentioned above. That should allow much richer/lower maintenance test cases as you can cover all of Istio api surface.
I would imagine this looks like translating the istio config to envoy config then running through the envoy tool