This is a simple question: when handling in mesh service call, does Envoy route the call directly to one of the pod endpoints, or does it route to Kubernetes service ClusterIP, and let it (the iptables redirect rules on the host which were setup by Kube-proxy) route to one of the destination pod IP?
I think Envoy chooses the destination pod directly based on the routing rules we setup with VirtualServices and DestinationRules, without going through kube service ClusterIP, otherwise service ClusterIP would route round robin and you loose the fine traffic control ability promised by Istio.
But I just want to make sure my understanding is correct. The reason I have a little doubt is that I dumped out pilot eds and config json files, for a single service (say the “details” service comes with the BookInfo sample app), I saw the true “details” POD IP in endpoints section, but I also saw the service ClusterIP in dynamic_route_configs section.
What is the point of including ClusterIP in the xDS data if Envoy doesn’t use it for routing? Is the purpose that just in case some client uses the ClusterIP (say 10.96.225.126:9080) rather than the service name /details:9080 in the URL, Istio still knows how to route it to the POD endpoint, without truly going through ClusterIP?