I feel like I’m missing something important, and was hoping for some clarification.
Under a normal kubernetes architecture, a microservice will send traffic to another microservice via the kubernetes service resource. i.e., the service will identify which pod(s) to send traffic to based on the label selectors & health of the pods.
When there is istio in the mix… Is that still the case? The points of confusion for me are:
DestinationRules affect where traffic from VirtualServices are sent - i.e. the traffic needs to hit the VirtualService
The VirtualService is set up to inspect traffic from a Gateway, and then to route the traffic to kubernetes services based on route prefixes, or headers (etc) - and DestinationRules further refine that.
the Gateway is used essentially to expose host names (www.example.org and api.example.org) & act as a reverse proxy for external traffic
So does that mean that in an Istio enriched cluster, my microservices need to use the external host name to gain the benefit for the VirtualService and DestinationRule? That doesn’t seem right… Is there still a way for me to send requests to the kubernetes service and still benefit from the VirtualService and DestinationRule?
So does that mean that in an Istio enriched cluster, my microservices need to use the external host name to gain the benefit for the VirtualService and DestinationRule ?
Fortunately not
Virtual services do not have to refer to a Gateway, that’s actually just the corner case of ingress traffic. See here: Istio / Request Routing the virtual services refer to hosts, which are actually referring to the kubernetes Service resources.
So, Istio adds features on top of the k8s services, but those services are still in the game. You can actually have istio running (sidecars injected) and keep just your existing service resources without any destination rule / virtual service. The traffic will flow through Envoy sidecars, you’ll have istio telemetry working, Kiali working, etc. Virtual services and destination rules will allow to refine the traffic management some steps further.
Ok, I did not make the connection that that host actually can also refer to the services. Thank you very much for that!
We’re using helm for the bulk of our deployments. And based on this, I’m starting to think that we need to split up our charts, so that there is one just for deploying the deployment or statefulset and their corresponding PDB, HPA, CMs, etc. And deploy the Kubernetes service with its own corresponding set of VirtualService and DestinationRules separately.
That way, I can deploy new releases of the applications, and purely update the destination rule & VS mappings.
