Hi folks,
What is your application’s release model like?
Do you use Helm? Do you use helm install or helm template piped to kubectl apply/delete?
Do you have a single Service object representing your application? Or do you have a Service object for each release of your application?
After going back and forth, I think we’re going with having a Service object for each release. That way, each release’s Helm chart is self-contained. We can install and uninstall each one without affecting the other releases.
Each release will have its own:
Deployment
Service
DestinationRule
However, VirtualService is the biggest fly in the ointment for me. I can’t have one for each release since you can only have one catch-all VirtualService. Plus, I actually have to create/edit VirtualService objects during a canary release, you know, like when updating the traffic split ratio.
How do you deal with VirtualService in general? Is it something you generate on-the-fly, instead of being part of the application’s Helm chart? But, it has other settings that each team may want to customize for their application (e.g. retry, fault injection). So you probably can’t just make one up on the fly. Teams would want to specify those in their own Helm chart.
This is the part where I’m wishing the routing part was decoupled from all the other VirtualService settings.
Thoughts on VirtualService or in general?
Thanks,
jaid