Istio引入了服务版本的概念，可以通过版本（v1、v2）或环境对服务进行进一步的细分。这些版本不一定是不同的API版本，可能是部署在不同环境（如生产环境，预发环境、测试环境等）中的同一服务的不同迭代版本。使用这种方式的常见场景包括A/B测试或金丝雀部署。Istio的流量路由规则可以根据服务版本对服务流量进行附加控制。
图4-3 基于请求内容的分发
如图4-4所示，服务的客户端不知道服务不同版本间的差异，但可以使用服务的主机名或者IP地址继续访问服务。Envoy代理拦截并转发客户端和服务器之间的所有请求和响应。
图4-4 启用Istio后的Kubernetes服务调用
运维人员使用Pilot指定路由规则，Envoy根据这些规则动态地确定其服务版本的实际选择。该模型使应用程序代码与服务解耦，不受服务演进的影响。路由规则让Envoy能够根据诸如header、与源/目的地相关联的标签和/或分配给每个版本的权重等标准来进行版本选择。
Istio还为同一服务版本的多个实例提供流量负载均衡。
Istio不提供DNS，应用程序可以尝试使用底层平台（kube-dns、mesos-dns等）中存在的DNS服务来解析全限定域名FQDN。
Kubernetes service如何关联一个Istio虚拟服务？参见图4-5，步骤如下：
图4-5 Kubernetes service如何关联Istio虚拟服务
1）Envoy Proxy首先根据请求匹配一个Istio虚拟服务，每一个Proxy都会对应一个主机与虚拟服务信息列表，根据请求地址，选择其中对应的主机（Kubernetes服务），并根据选择的主机信息，找到对应的Istio虚拟服务。
2）Istio虚拟服务描述路由到目标主机的规则，并根据选择的主机信息，找到对应的Istio虚拟服务；根据规则，Proxy找到满足条件的第一个目标主机（对应到一个Kubernetes service）。
3）Proxy调用目标pod，Proxy根据满足条件的目标主机信息寻找对应的目标pod，并根据定义的流量策略（包括负载均衡等）路由到相应的pod。