Canary Deployment patterns (spike)

[evanlouie]

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.

[evanlouie]

https://dev.azure.com/indiasfdevcrew/SamsCXOSprints/_workitems/edit/2

[bnookala]

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.

[andrebriggs]

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

[evanlouie]

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.

[dtzar]

yes @andrebriggs I agree it should be a separate task. I created this one: https://github.com/CatalystCode/kubemalt/issues/45