I would like to achieve canary deployments with Istio on Kubernetes. However, I am stuck implementing it because I would like to do the canary on a helm chart level. That means, I have a running helm release color-backend which contains a deployment color-backend that runs the Docker image color-backend:1.0 and a Service (ClusterIP) color-backend-svc with incoming port 8080 for tcp connections and outgoing port 8080 (matching the port on the deployment.

Now, let’s say I build a new Docker image color-backend:2.0 and create a new helm chart version 2.0 for chart color-backend. In other words, in my deployment.yaml template, I only specify one deployment with the latest Docker image tag. I consciously do not specify two deployments (for the old and new image) in the deployment.yaml , as is often done in Istio tutorials. When I deploy this new helm chart version as color-backend-v2, I get a new deployment color-backend-v2 that runs image color-backend:2.0 and a new ClusterIP service color-backend-svc-v2. I.e. at this point I have the following resources running on the cluster

Now, I have to somehow introduce a VirtualService and a DestinationRule. For a DestinationRule you need a common service (host) which can be used to split pods into subsets. I could introduce a new service color-backend-svc-canary that uses a selector that encompasses both deployments color-backend and color-backend-v2 (via a common label). However, pods from other applications in my cluster might be using the DNS color-backend-svc.namespace.cluster.local and if I introduce a new service that DNS would have to change.

The simplicity in the Istio tutorials comes from the fact that you have one ClusterIP service that you can reference in the host(s) section of a VirtualService and DestinationRule and two deployments (in the same helm chart). Then it’s very easy to setup canary deployment. But how do you proceed when you want to canary between different helm chart versions?