Do I need a dedicated kubernetes service to split traffic between helm deployments?

1

Hi!

I’m looking for some help with Istio’s traffic shifting for canary deployments and how it fits in with our existing use of helm releases. Specifically we’re looking to deploy different configurations of an existing statefulset, and see which one performs better…

Our helm releases normally create a kubernetes service that routes to that set of pods specified in the helm’s deployment or statefulset manifests. The pods are labelled by “normal” things, as well as the release name.

So for example, a typical service + pods for a helm release called “my-first-release” would look like:

image
image1214×1074 18.2 KB

From what I understand, in order for Istio to shift traffic, it needs:

  • the pods that it is directing traffic to need a version in the label, and a DestinationRule that defines each version
  • a kubernetes service that selects all the pods that comprise all of the versions
  • a VirtualService that routes traffic between the DestinationRules

In which case - assuming we don’t want to do away with the existing service that our helm templates already give us, we’d essentially need something like this

image
image1914×1502 284 KB

i.e.

  • a kubernetes service that is helm release-agnostic
  • each different helm deployment to have a proper version name for the pods
  • each helm deployment to have a DR that describes the name & labelling for its version of the pods
  • a virtual service that references the release-agnostic kubernetes service as the host, that then routes across the different subsets

Is anybody able to provide any thoughts or opinions on this?

We’ve looked at ServiceEntry but it doesn’t seem to give us that sort of a “virtual” service entry, thus our - assumed - need for a kubernetes service.

2

You don’t need to have a single Service that selects all pods. You can have 1 service and select within it with subsets, or just route between two services

1 Like
3

So just any Kubernetes service that doesn’t select anything?

And then use the virtual service to specify the actual “real” Kubernetes service in the destination.host value?

4

Just tried as you’d suggested and it worked like a charm.

Now we just need to figure out how to set up the appropriate deployment artefacts.

Thank you very much! :smile: