Open evanlouie opened 5 years ago
Question raised by @dtzar: will istioctl be a hard requirement for applying istio virtualservice rule updates?
Also to investigate: azure devops plugin for gated rollouts based on monitoring and metrics gathered from prometheus/grafana
@andrebriggs - This will impact how your team deploys and configures flux/azure devops for multiple clusters.
Question raised by @dtzar: will istioctl be a hard requirement for applying istio virtualservice rule updates?
@bnookala I'm not sure why it would be a hard requirement. Can't we achieve canary deployments with only kubectl apply
? Seems to fit the current flux-enabled cluster deploy strategy right now.
Also to investigate: azure devops plugin for gated rollouts based on monitoring and metrics gathered from prometheus/grafana
The above sounds like a separate issue. We have various meeting notes on the strategy able being alluded to.
@andrebriggs - This will impact how your team deploys and configures flux/azure devops for multiple clusters.
Agreed. This scenario is a "run" stage scenario as opposed to the current "crawl" and "walk" scenarios
No requirement specifies the use of istioctl
. In fact, if possible, I would stay away from istioctl
. I think it should be manageable for most operators to manage even complex routing rules with manifests alone.
yes @andrebriggs I agree it should be a separate task. I created this one: https://github.com/CatalystCode/kubemalt/issues/45
As an operator, I want best practices on how to do A/B testing and canary testing within the context of Istio.
AC: documentation and guidance on how to properly do canary testing for multiple services within the mesh.