1. 版本控制

1.1 v1 版本服务

向集群外部公开catalog服务

将流量路由到catalog服务。

1.2 所有流量路由到 v1版本

此时我们需要发布v2版本，发布前，我们先将所有流量路由到catalog服务的v1版本。

我们需要给Istio一个关于如何识别哪些工作负载是v1、哪些是v2的提示，就是增加目标规则。

更新VirtualService，将所有流量路由到catalog的v1版本

1.3 将特定请求路由到v2版本

我们希望将包含HTTP头x-istio-cohort：internal的任何流量路由到catalog服务的v2版本。

1.4 金丝雀发布

我们将研究另一种“金丝雀发布”或增量发布的方法，指定一个10%到v2的路由权重：所有流向catalog的流量的10%将流向v2，而90%的流量仍将流向v1。

2. 其他控制

2.1 流量镜像

Istio支持流量镜像，这比蓝绿和灰色发布方法更能减少部署和发布的风险。

通过这个VirtualService定义，我们将100%的实时流量路由到catalog服务的v1，但也将流量镜像到v2。
镜像是通过“即发即忘”的方式完成的，即创建请求的副本并将其发送到镜像集群（在本例中是catalog的v2）中。这个镜像请求不会影响真正的请求，因为执行镜像的Istio代理会忽略来自镜像集群的任何响应（成功/失败）。

2.2 路由到集群外部的服务（ServiceEntry）

ServiceEntry是Istio中对网格外的服务的推荐使用方式，当然也可以选择不做治理，直接让网格内的服务访问网格外的服务。

在默认情况下，Istio允许任何流量离开服务网格。为了安全，可以将Istio的默认值从ALLOW_ANY改为REGISTRY_ONLY。这意味着只有在服务网格注册表中明确将流量列入白名单时，才允许此流量离开网格。

拒绝流量流出

我们将用户连接到一个在线论坛，该论坛是在服务网格集群之外构建和部署的。在本例中，此论坛位于URL jsonplaceholder.typicode.com。

ServiceEntry允许网格内部的服务访问外部的服务。

当将出站流量设置为REGISTRY_ONLY时，ServiceEntry可以允许网格内部的服务访问外部的服务。

这个ServiceEntry资源在Istio的服务注册表中插入了一个条目，它明确地表明，允许网格中的客户端使用jsonplaceholder.typicode.com主机调用JSON Placeholder。

3. 流量管理术语理解

老王开了一家家娱乐场所，天上人间，为了气派老王花重金百万打造了一个青铜大门 istio-ingressgateway。

3.1 Gateway

特点：spec.servers

这么气派的大门必须找个 180 以上的保安gateway看门，保安的指责比较的简单明了，按摩（anmo.com）的放进来,洗浴（xiyu.com）的放进来，白嫖（baipiao.com）的请出去。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: baoan
  namespace: tianshangrenjian
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "xiyu.com"
    - "anmo.com"

3.2 VirtualService

特点：spec.hosts

每个客人都有自己喜欢的技师，大堂经理virtual service客客气气的安排着。如果你想找个白富美给您按摩，只需要告诉大堂经理virtual service ，anmo.com/baifumei,他就会客客气气告诉您上3楼找69号房间（v1）。如果你找矮矬穷anmo.com/aicuoqiong请到3楼96房间（v2）。

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: tianshangrenjian-rule
  namespace: tianshangrenjian
spec:
  hosts:
  - anmo.com
  gateways:
  - baoan
  http:
    - name: "baifumei"
    match:
    - uri:
        prefix: "/baifumei"
    route:
    - destination:
        host: anmo-service
        subset: v1
  - name: "aicuoqiong"
    route:
    - destination:
        host: anmo-service
        subset: v2

3.3 DestinationRule

特点：spec.host

告诉每个技师提前到哪个房间迎接客人，就是destination rule。

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-destination
  namespace: tianshangrenjian
spec:
  host: anmo-svc
  subsets:
  - name: v1
    labels:
      sanwei: 362436
  - name: v2
    labels:
      sanwei: 181818

就这样生意红红火火。。。大门istio-ingressgateway（你从哪里进来），看大门的istio gateway（你能不能进来），大堂经理virtual service（进来后去哪），destination rule（房间号）。

3.4 VirtualService 和 DestinationRule 理解

VirtualService也是一个虚拟Service，描述的是满足什么条件的流量被哪个后端处理。可以对应这样一个Restful服务，每个路由规则都对应其中Resource中的资源匹配表达式。只是在VirtualService中，这个匹配条件不仅仅是路径方法的匹配，还是更开放的Match条件。
而DestinationRule描述的是这个请求到达某个后端后怎么去处理，即所谓目标的规则，类似以上Restful服务端代码 addForecast()和getForecast()方法内的处理逻辑。
DestinationRule定义了满足路由规则的流量到达后端后的访问策略，从而理解负载均衡和熔断等策略为什么被定义在DestinationRule上。

3.5 Gateway 和 VirtualService 的结合

Gateway只做四层到六层的端口、TLS配置等基本功能，VirtualService则定义七层路由等丰富内容。

VirtualService 的 gateways 字段

场景1：服务只是在网格内访问的，这是最主要的场景。gateways字段可以省略，实际上在VirtualService的定义中都不会出现这个字段。一切都很正常，定义的规则作用到网格内的Sidecar。

场景2：服务只是在网格外访问的。配置要关联的Gateway，表示对应Gateway进来的流量执行在这个VirtualService上定义的流量规则。

场景3：在服务网格内和网格外都需要访问。这里要给这个数组字段至少写两个元素，一个是外部访问的Gateway，另一个是保留关键字“mesh”。使用中的常见问题是忘了配置“mesh”这个常量而导致错误。

我们很容易认为场景3是场景1和场景2的叠加，只需在内部访问的基础上添加一个可用于外部访问的Gateway。

Levon's Blog

Istio教程03-流量控制和规则术语