I’ve got multiple applications deployed in a kubernetes cluster, across namespaces, and some apps reference another app’s service to communicate with it. All apps are deployed with helm, and I’m wanting to use a blue/green approach to deployments… I’ve seen several solutions where you pull the service outside of the helm chart (as in, in their own separate file) and have 2 services – one live and one staging. Then your ingress url’s for live and staging point to its corresponding service. Then to swap traffic back and forth between deployment pods created from a blue helmrelease and green helmrelease, you’d simply update the selector label tags on the service. However, this doesn’t work if one application references a service for another application. I have a near-hard-requirement that the service has to remain within the helm chart/helmrelease because of this. Also, not every application gets deployed at the same time. i.e. appA could get released and blue is live, but appB that references appA’s service could not have a release. I need to be able to stand up the staging environment for appA and QA test against it and potentially against appB as well, before cutting over traffic. I can’t just leave appB always referencing, say, the blue service because we don’t always know that blue is live or blue is staging. Do I just need to make it a requirement that both, appA and appB get “released” every cycle, even if we just stand up the same app image as what’s already in the live environment, if there’s no new build to deploy? Then every app would always have blue is live, green is staging, and vice versa? I’d imagine this would complicate rollbacks if one app needs to rollback but another doesn’t.

I’ve already got a POC working where I pulled the service out of the helm chart, then deployed the chart as a blue helmrelease and a green helmrelease, separately. I can swap traffic almost instantaneously by updating the services’ selector labels. It’s the cross-app service name references that complicate things.