Istio 东西向流量管理

引言

这算是我看王夕宁的那本书写的总结，其中夹杂着比较白话的理解。
作为开源的服务网格，Istio可在部规模逐步扩大的过程中帮助开发人员简化流量管理。

• 南北向流量管理：使用Ingress将Kubernetes中的应用暴露成对外提供的服务，针对这个对外暴露的服务可以实现灰度发布、A/B测试、全量发布、流量管理等。我们把这种流量管理称为南北向流量管理，也就是入口请求到集群服务的流量管理。
• 东西向流量管理：Istio还有侧重于集群服务网格之间的流量管理，我们把这类管理称为东西向流量管理。

这次我们讲的是东西向流量管理，也就是服务网格之间的流量管理。下次会讲南北向的流量管理。

术语

讲之前我们还是需要解释一下这些专业术语，毕竟看这类文章还是得靠理解，不要用记忆力代替理解力，因为强行记住了也会云里雾里。不要去强行记忆配置文件中的字段，而是去理解，因为这些玩意看一眼文档就OK了。

• Sidecar(边车)：Sidecar自定义资源描述了Sidecar代理的配置，该代理协调与其连接的工作负载实例的入站和出站通信。说白话Sidecar说的是模式，其用的代理是Envoy，这么说是不是容易理解了呢？
• Service(服务)：服务是Kubernets中本身就有的，是绑定到服务注册表中唯一名称的应用程序行为单位。服务由运行在pod、容器、虚拟机上的工作负载实例实现的多个网络端点组成。说白话，Serivce在K8S中就是提供网络功能的，和代理不同，它的作用是连接容器进行对内或对外通信，最早说过，可以看成docker中overlay网络的新的替代方式。它没有代理那么多的功能，比如灰度发布等等，它只是为了提供一种访问方式，让你可以访问到容器内工作的实例（应用程序）。
• 服务版本(Service Version)：也称为子集，这在Service中label写的version不同的是，这里说的是Istio中DesitinationRule的subsets。
• 源(Source)：调用目标服务的下游客户端。（之前我也忘记我讲了还是没讲，所以这里还是写一下），下游指的是发送请求的一方，如果是HTTP服务，你可以理解为用户。上游指的是接收请求的一方，也就是我们的服务实例。
• 主机(Host)：客户端尝试连接服务时使用的地址，比如linux中在同局域网中可以使用hostname进行通讯，Windows中的计算机名，外网可以直接使用域名进行通讯，这里的Host其实讲的就是这个意思。
• 访问模型(Access Model)：应用程序在不知道各个服务版本（子集Subsets）的情况下仅对目标服务（主机Host）进行寻址。版本的实际选择由Sidecar代理确定，使应用程序代码能够脱离依赖服务的演变。
• 虚拟服务(Virtual Service)：一个虚拟服务定义了一系列针对指定服务的流量路由规则，注意：重点是路由规则。
  每个路由规则都针对协议定义的流量匹配规则。如果流量符合这些特征，就会根据规则发送到服务注册表的目标服务（或者目标服务的子集或版本）。
• 目标规则(Desitination Rule)：目标规则定义了在路由发生后应用于服务的流量策略。这些规则制定负载均衡的配置，来自Sidecar代理的连接池大小以及异常检测设置，以便从负载均衡池中检测和驱逐不健康的主机。

---

流量拆分与导向

Istio提供了两种流量路由管理方式，基于比例的流量拆分（权重），基于请求内容的流量导向。

基于比例的流量拆分

比如ServiceB加入了一个新版本，我们只想让10%的流量分配给新版本，此时就像下面这个图

创建容器组和一个服务

我们先创建2个Deployment，分配是appb的v1版本和v2版本，再创建一个Service让我们可以访问这两个容器组内的应用。
这里的自动注入使用了给命名空间打标签的方式，所以资源清单中你看不见Sidecar自动注入的东西。具体方式在之前的minikube和istio的文章中有。

# 定义APP-B的V1版本的Deployment
apiVesion: extensions/v1betav1
kind: Deployment
metadata:
  name: app-b-v1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: app-b
        version: v1
    spec:
      containers:
      - name: app-b-container
        image: private.mytestregistry.com/appb:v1
        imagePullPolicy: Always
        ports:
        - containerPort: 8081
---
# 定义APP-B的V2版本的Deployment
apiVesion: extensions/v1betav1
kind: Deployment
metadata:
  name: app-b-v2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: app-b
        version: v2
    spec:
      containers:
      - name: app-b-container
        image: private.mytestregistry.com/appb:v2
        imagePullPolicy: Always
        ports:
        - containerPort: 8081
---
# 创建一个Service，并且selector只匹配app: app-b，这样可以无视版本，只创建一个服务。
apiVersion: v1
kind: Service
metadata:
  name: ServiceB
  labels:
    app: ServiceB
spec:
  ports:
   # 如果容器内的端口不是8081 可以额外使用targetPort定义
  - port: 8081
    name: http
  selector:
    app: app-b

创建DestinationRule

目前如果我们直接通过ServiceB访问容器组中的实例，我们并不能按照想要的比例分别访问v1和v2版本，所以我们现在创建DestinationRule和VirtualService。

需要注意的是，我们讲的是东西向流量管理，也就是服务网格内的流量管理，这种规则只对网格内的服务有效，也就是ServiceA来访问ServiceB，什么是服务网格，还记得第一篇那个什么是服务网格的文章吗？

DestinationRule定义的策略决定了经过路由处理之后的流量访问策略。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ServiceB-DR
spec:
  # 定义规则的目标服务
  host: ServiceB
  subsets: # 自己的labels中对应容器组中的标签做匹配
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

创建VirtualService

看名称就知道了，DestinationRule是目标规则，但是我们没有在里面使用流量策略等，我们需要使用subsets就必须使用Virtualservice，所以我们还需要VirtualService来使用刚才定义的规则。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ServiceB-VS
  namespace: default
spec:
  # 定义规则的目标服务,和DestinationRule不同的是这里可以是好几个host
  hosts:
  - ServiceB
  http:
  - route:
    - destination:
        host: ServiceB
        subset: v1
      weight: 90
    - destination:
        host: ServiceB
        subset: v2
      weight: 10

---

基于请求内容的流量导向

创建VirtualService

我们只需要改一改VirtualService使用匹配规则即可。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ServiceB-VS
  namespace: default
spec:
  # 定义规则的目标服务,和DestinationRule不同的是这里可以是好几个host
  hosts:
  - ServiceB
  http:
  - match:
    - headers: # 匹配header version=v1
        version:
          exact: v1
    route:
    - destination:
        host: ServiceB
        subset: v1
  - match:
    - headers: # 匹配header version=v2
        version:
          exact: v2
    route:
    - destination:
        host: ServiceB
        subset: v2
  - route: # 如果没有匹配到HTTP HEADERS默认的路由规则
    - destination:
        host: ServiceB
        subset: v1
      weight: 50
    - destination:
        host: ServiceB
        subset: v2
      weight: 50