-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Rollout model with istio and/or ambassador #1844
Comments
related #1309 |
I think Istio's way to do edge routing is to use Gateway, and bind VirtualService to it. |
It looks like Ambassador has ISTIO integration. Does that work? |
The integration means using ambassador at the edge in front of the Istio mesh (which is what we are doing now). |
ambassador has an open issue on this: emissary-ingress/emissary#255 |
Could we use the ISTIO service Gateway as our dynamic reverse proxy rather than Ambassador? I looked at this blog post about Ambassador and ISTIO I think the current way Ambassador works with ISTIO is that Ambassador routes traffic to a service inside the mesh (in the example the product page app). The product page then uses ISTIO to route traffic to its various backends. In our case we want to expose outside the cluster an API that will serve models and split traffic between different model versions. In this case we don't have a service inside the mesh that can be a backend for Ambassador (e.g. we don't have a web app sending requests to the different version of the models). /cc @kflynn @aroundthecode any thoughts? |
Yeah that's the direction I am exploring |
We have an example in Seldon for using istio to route traffic to two versions (canary) This is using Ambassador with Istio. |
@jlewi Can you please elaborate on the solution that you finally used. |
…low#1844) * remove load-restrictor kustomize flag and lint README markdown * Set kustomize loader to RestrictionRootOnly in test_util.go * review: undo changes to test scripts * review: add note to reusing patches best practices
Problem:
#1823 adds support for rolling out a new version of model, and send X% of traffic to it.
The request path is
ingress --> ambassador --> tfserving (version1 or version2)
However, it actually doesn't work because ambassador is not in istio service mesh, and Istio traffic management needs the client side to talk to Istio Pilot.
(so for ambassador --> tfserving, the client is ambassador)
Ambassador can deploy with Istio,
but we cannot inject istio sidecar to ambassador. (see issue)
So I think the options are
I think we don't want 1 as we are moving toward Istio.
2 is not ideal.
I will test if 3 can be done by Istio's VirtualService
cc @jlewi
The text was updated successfully, but these errors were encountered: