geeknoid
commented
7 years ago Your #2 feels like the right choice for Istio. The mixer is able to return attributes back to the proxy, which the proxy can use in routing decisions. Overall, this would mean a single call to Check from the proxy to the mixer to perform access control and to get routing information. And because we aggressively cache results from Check, the routing response will automatically get cached and reused as appropriate.
We're still finishing up the logic to have adapters producing attributes to return to the proxy. We'll probably have something running here by next week at some point. We have currently no code in the proxy to consumed and act upon returned attributes from the mixer, so that needs to be created.
galo
Sorry if this is not the right location for this topic, feel free to close so I can ask this in a different place.
One use case I am trying to design is dynamic routing of HTTP requests based on some information that is part of the URL path, query string or header (ie jwt claim).
A common scenario for this is sharding or routing requests to the right data center based on a userId, or some other routing key. We have this model implemented using other proxies like Zuul or APIgee Microgateway using a filter or plugin in the proxy, the routing key is extracted and we query a lookup system where we register the mapping between routingKey and service instances. In our case we use the entity locator service a DynamoDB backed that also contains which instances are read, vs write, etc.
I would like to validate what is the best way on the Istio model to implement this use case. I think there can be two models, but correct me if I am totally wrong
Option 1. Envoy HTTP filter. This model is similar two our current model, but unlike with Zuul (groovy) and Apigee (node) the filter must be added at build time. The istio Manager can be used to configure at runtime some aspects of this filter (ie URL or Header regex, etc). Proxy and ELS can be located in the same pod which results in better latency and simpler implementation (health check, retries, no required)
Option 2. Mixer adapter. Right now there are 3 API, check, report and quota. I can extend the check API, or add a new API for routing. The Adapter will be in charge of processing the request doing the lookup in ELS to return a new request.host, and request.path so the Envoy can forward the request. This results in an extra query outside of the pod per request, which is same price some other polices will pay.
If this use case makes sense to more people I can do a PR following your design guidelines.