Quite new to Istio, Kubernetes. These question are very much Kubernetes + Istio centric.
Are Istio VirtualService instances part of the Istio Service Registry such that VirtualService A can route traffic to VirtualService B via A’s spec.http.route.destination.host: B.name ? Or are destination.host values limited to Kubernetes service entities? Is there a CLI mechanism to determine what the Service Registry contains? Great concept but being able to view ‘contents’ pretty useful too 
I don’t see any mention of any of my defined VirtualServices in the istioctl proxy-config route pod -o json for the Pods in my mesh, except for metadata.filterMetadata.istio.config paths (eg. “config”: “/apis/networking/v1alpha3/namespaces/default/virtual-service/mms-elastic-debug-vs”). In the same output, I do see plenty of references to expected K8S DNS entries (eg. alfresco.default.svc.cluster.local)
Am I wrong in my understanding that once a VirtualService routes via a k8s Service instance, that Service instance can only make use of a Deployment/Pod via the Service’s selector? To chain VirtualServices, k8s Services must be kept out of the chain? And therefore, my earlier question about VirtualService being a route destination.
Just looking to flush out my understanding so I don’t go down the wrong path, mesh topology speaking.
Thanks,
Hi.
I’m also pretty new, but I’ll try to answer you.
You can’t route traffic via spec.host. However you say for host A route traffic to host B. (https://istio.io/docs/reference/config/networking/virtual-service/).
You can make use of other labels than selector labels to create subsets via DestinationRule (here you also say what loadbalancer you want to use) object and then use those subsets in VirtualService to route traffic.
I think that Galley knows about each pod that is present in mesh, each pod is considered as an endpoint. Try to run istioctl proxy-config endpoints pod-name.namespace .
VirtualService so not create new DNS entry. For that you’d have to enable istio-coredns and make use of ServiceEntry.
Also try to determine if pod in namespace A should know about pod in namespace B. By default each proxy will know about every other proxy in the mesh so the configuration can be quite big.
If my conclusions are wrong, please correct me. 
Hi Tomas,
Thanks for the quick reply. Another Tomas is coming over with his chainsaw shortly to help with some post-storm removal so I hope I don’t rush my reply.
I left out that the various services are all in the same namespace. My bad.
I’m not using spec.host to route but the spec.http.destination.host - all the examples I’ve seen so far have ‘regular’ k8s DNS entries like service-name.default.svc.cluster.local which are defined as a result of the ‘standard’ k8s service + dns behaviors. I’ve not yet seen any Istio examples in which an Istio VirtualService is used as a destination. My understanding so far is that an Istio VirtualService thus requires an associated k8s Service via the destination’s host value. And since a k8s Service needs a Deployment or Pod to select, chaining 1 VirtualService to route to another VirtualService may not be possible?
Re the proxy-config, thanks for the suggestion - the output for endpoints is useful but, like that for route, doesn’t show any of the 3 VirtualService instances. But as these are virtual, their endpoints are those of the associated Service.
I’m going to stop typing for a bit & get back to rethinking on how I can use subsets to accomplish the same goal that chaining would allow - more partitioning of rules, policies to be applied to the associated services.
Thanks again for the useful insights.
-Steve
I think that you got it wrong. VirtualService is similar to Service in k8s in that manner that it allows you to route traffic based on your demands. VirtualService do not have dns name nor create one. To create dns entry you should use ServiceEntry (Istio with enabled istio-coredns) or Service (k8s).
VirtualService is only abstraction above Envoy configuration.
You are welcome. I hope that I’ve not confused you. 
Edit: As VirtualService only configure Envoy to do some magic, it is possible to say that request to host A must be forwarded to host B via VirtualService.
Thanks Tomas, the clarification is very helpful, that was my understanding as well. That the VS provides the additional routing, etc. ‘around’ a k8s Service instance. So any use of a Service that has a VS associated with it has the VS route (matching, destination, etc.) definitions applied to it.
The rational for our approach was to be able to apply these routing, destination directives for various testing scenarios for intra-mesh service interactions. So the same reasons for using VS on exposed services might be applicable for internal service interactions too. Interestingly, when I removed the 2nd layer of VS instances, my routing started working.
1 Like