作者回复: 可以把这个hosts字段理解为是一个外键，它负责把gateway和vs、vs和dr连接起来。 比如你在gateway里host配置为 www.example.com, 那么当你访问这个url时请求就会找配置了同样host的vs，根据它的路由信息去分发请求。

作者回复: 这是 VirtualService hosts的官方说明：The destination hosts to which traffic is being sent. Could be a DNS name with wildcard prefix or an IP address. 这是 DestinationRule host的说明：The name of a service from the service registry. Service names are looked up from the platform’s service registry (e.g., Kubernetes services, Consul services, etc.) 简单来说就是，VS里的hosts指向的就是DR的host；DR的host设置的是底层平台（如k8s）的service名称，因为最终是需要利用平台的dns来把请求导向目的地的。 这种用2个api资源设计的目的之一就是各司其职，VS负责配置路由信息，DR负责配置目标和策略。

作者回复: 1. 对 2. 如果我们没有对reviews服务添加路由配置（Virtualservice），那它就使用k8s默认的负载均衡轮询选择版本（本质上是选择同一个服务的不同的pod，因为productpage是通过service name的方式，即reviews.default.svc.cluster.local访问的)，如果你添加了VS，并指定了subset，那它就会根据你定义的路由去选择对应版本的pod，这也就是Istio控制流量的主要方式。

作者回复: 1. 是的，全量下发。因为envoy彼此之间并不知道业务上的调用关系，所以需要获取到所有配置； 2. envoy的转发比较复杂，牵扯listener、cluster、route等核心概念，你可以简单的理解为：envoy通过改写iptables规则做了流量劫持，productpage的出流量可以通过配置知道要发到哪个review pod。 tips： 可以参考这篇文章的分析 https://www.servicemesher.com/blog/istio-traffic-management-impl-intro/ 参考envoy配置可以通过 istioctl d envoy podname 查看config dump

作者回复: 优秀👍

作者回复: Istio是基于服务（k8s service）层面进行流量管理的，所以vs 和dr的host需要和pod对应的service一致。和container name没关系

作者回复: 可以

作者回复: 是的，还不支持endpoint级别

作者回复: 只从服务发现角度讲没有必要并存。如果需要一般是既想演进到service mesh架构，使用Istio的特性，又想保留原有服务的兼容性等。他们的关系会变成上下游关系，dubbo的注册信息需要转换成Istio的配置并下发。

作者回复: 不接管