Istio 核心配置对象

Istio 中的资源分为三组进行管理,分别是 networking.istio.io、config.istio.io 及 authentication.istio.io,下面将进行分别介绍。

networking.istio.io

该对象在 Istio 中可能是使用频率最高的,Istio 的流量管理就是通过这一组对象完成的,在这里选择其中最常用的对象进行介绍。

概述

通过 VirtualService 定义一组条件,将符合该条件的流量在对象中配置对应的策略进行处理,最后匹配。以下是几种应用场景。

  • 来自服务 A 版本的1服务,如果访问了服务 B ,则把流量转发到 B 的 V2 版本
  • 如果 Header 中包含 “canary=true”,则把服务目标指向服务 Y 的版本 3,否则发给服务 Y 的版本2。
  • 为从服务 M 到服务 N 的所有访问都加入延迟,以测试在网络状况不佳时的表现。

流量控制的几个关键对象:

Gateway->VirtaulService->TCP/HTTP Router->DestinationWeight->Subset:Port

GateWay

在访问服务时,不论是网格内部访问,还是通过 Ingress 进入网格外部的流量,首先要经过的设施都是 Gateway(网关)。

网格边缘的 Ingress 流量,会通过对应的 Istio Ingress Gateway Controller 进入,网格内部的服务互访,则通过 Mesh 网关进行(Mesh 网关代表网格内部所有的 Sidecar)。

Pilot 会根据 Gateway 和主机名进行检索,如果存在对应的 VirtualService ,则交由 VirtualService 处理,如果是 Mesh Gateway 不存在这一主机名的 VirtualService,则尝试调用 Kubernetes Service;如果都不存在,则发生404错误。
这就是为什么在注入了 Istio 的 Pod 在没有建立 VirtualService 之前,无法访问一切外网的原因。如一些 CloudApi 接口,包括支付宝、微信支付等。

VirtualService

VirtualService 主要由以下部分组成

  • Host:主机名称,如果在 Kubernetes 集群中,则这个主机名可以是服务名
  • Gateway:流量来源网关,如果这一字段被省略,则代表使用的网关名为 Mesh,也就是网格内部服务互通的网关。
  • 路由对象:网格中的流量,如果符合前面的 Host 和 Gateway 的条件,就需要根据实际的协议对流量处理方式进行郑甄别。原因是:HTTP 是一种透明协议,可以经过对报文的解析,完成更细致的控制;而对于原始的TCP流量来说,就无法完成过于复杂的任务。

TCP/TLS/HTTP Router

路由对象可以是 HTTP 、TCP 、TLS,分别针对不同的协议进行工作,每种路由对象至少包含两个部分:匹配条件和目的路由。例如在 HTTPRouter 对象中就包含用于匹配的 HTTPMatchRequest 对象数组,以及用于描述目标服务的 Destination Weight 对象,并且 HTTPMatchRequest 匹配的条件较为丰富,例如 Header 或者 URI 等。除此之外,对于 HTTP 独有的专属属性,例如超时控制、重试、错误注入等。相对来说,TCPRoute 简单很多,它匹配的资源借助 L4MatchRequest 对象完成,其中除 Istio 固有的源标签和 Gateway 以外,仅包含地址和端口。

完成匹配后,就是找到适合的目标了。

DestinationWeight

各协议路由的目标定义是一致的,都由 DestinationWeight 对象数组来完成。DestinationWeight 指的是到某个目标(Destination)的流量权重,类似 L7 负载均衡的权重。所以意味着多个目标可以同时为该 VirtualService 提供服务,并按权重进行流量分配。

Destination

目标对象(Destination)由 Subset 和 Port 两个元素组成,Subset 顾名思义,就是指服务的一个子集,他再 Kubernetes 中代表使用标签选择器区分不同的 Pod (如两个 Deployment),Port 代表的是服务端口。

小结

至此,流量经过多个对象的逐级处理,成功到达 Pod。