接下来，我们可以通过 kubectl exec -it 下令进入客户端 Pod，来测试 app 服务的具体表现。
使用一个简单的 for 循环，重复获取 http://flaskapp/env/version 的内容，也就是调用 app 服务，检察其返回结果：
$ kubectl exec -it testclient-7fbb8ddf94-qfn54 -- bashDefaulting container name to test-tools.Use 'kubectl describe pod/testclient-7fbb8ddf94-qfn54 -n default' to see all of the containers in this pod.bash-5.1# for i in `seq 10`;do curl http://app/env/version;echo; done;v1v1v2v2v1v2v1v1v2v2从上面的运行结果中可以看到，v1 和 v2 这两种结果随机出现，大约各占一半。这很容易明确，由于我们的 app 服务的选择器被界说为只根据 app 标签举行选择，两个版本的服务 Pod 数目雷同，因此会出现轮替输出的结果。
创建目标规则和路由
接下来使用 Istio 来管理这两个服务的流量。起首创建 app 应用的目标规则，输入以下内容井将其生存为 app-destinationrule.yaml：
apiVersion: networking.istio.io/v1beta1kind: DestinationRulemetadata: name: appspec: host: app subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2这里界说了一个名称为 app 的 DestinationRule，它使用 Pod 标签把 app 服务分成两个 subset，将其分别命名为 v1 和 v2。下面将 app-destinationrule.yaml 提交到集群上：
kubectl apply -f app-destinationrule.yaml destinationrule.networking.istio.io/app created接下来就须要为 app 服务创建默认的路由规则了，岂论是否举行进一步的流量控制，都发起为网格中的服务创建默认的路由规则，以防发生料想之外的访问结果。
使用下面的内容创建文本文件 app-default-vs-v2.yaml：
apiVersion: networking.istio.io/v1beta1kind: VirtualServicemetadata: name: app-default-v2spec: hosts: - app http: - route: - destination: host: app subset: v2在该文本文件中，我们界说了一个 VirtualService 对象，将其命名为 app-default-v2，它负责担当对 app 这一主机名的访问，会将全部流量都转发到 DestinationRule 界说的 v2 subset 上。
再次实验 kubectl 将 VirtualService 提交到集群上：
kubectl apply -f app-default-vs-v2.yaml virtualservice.networking.istio.io/app-default-v2 created在创建乐成后，可以再次进入客户端 Pod，看看新界说的流量管理规则是否收效：
[root@k8s-master01 istio-yaml]# kubectl exec -it testclient-7fbb8ddf94-qfn54 -- bashDefaulting container name to test-tools.Use 'kubectl describe pod/testclient-7fbb8ddf94-qfn54 -n default' to see all of the containers in this pod.bash-5.1# for i in `seq 10`;do curl http://app/env/version;echo;done;v2v2v2v2v2v2v2v2v2v2默认的路由已经收效，如今重复多次访问，返回的内容来自情况变量 version 被设置为 v2 的版本，也就是 v2 版本
总结一下
