Istio路由规则配置:VirtualService之TLSRoute、TCPRoute及三种对比及实践
1、TLS路由
在VirtualService中,tls是一种TLSRoute类型的路由集合,用于处理非终结的TLS和HTTPS的流量,使用SNI(Server Name Indication,客户端在TLS握手阶段监理连接使用的Hostname)做路由选择。在TLSRoute被应用于以下场景中。
- 服务的端口协议是TLS和HTTPS,即在服务的端口名中包含https-、tls-deng 。
- Gateway 的端口是非终结的HTTPS和TLS。
- ServiceEntry 的端口是HTTPS和TLS
1)TLSRoute配置示例
apiVerison: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: total-weather-tls
namespace: weather
spec:
host:
- "*.weather.com"
gateway:
- ingress-gateway
tls:
- meatch:
- port: 443
sniHosts:
- forntend.weather.com
route:
- destination:
host:frontend
- meatch:
- port: 443
sniHosts:
- recommendation.weather.com
route:
- destination:
host: recommendation
在以上示例中,可以通过HTTPS方式从外部访问weather应用内部的两个HTTPS服务frontend和recommendation,访问目标端口是443且SNI是“frontend.weather.com”的请求被转发到frontend服务上,访问目标端口是443并且SNI是“recommendation.weather.com”的请求会被转发到recommendation服务上。
2)TLSRoute 规则解析
TLSRoute的规则定义比HTTPRoute简单很多,规则逻辑也是将满足一定条件的流量转发到对应后端。在规则定义中,匹配条件是TLSMatchAttributes,路由规则目标是RouteDestination。
3)TLS匹配规则(TLSMatchAttributes)
在TLSRoute中,match字段是一个TLSMatchAttributes类型的数组,表示TLS的匹配条件。下面来讲解一下TLS服务的请求特征。
- sniHosts:一个重要的属性,位必选字段,用来匹配TLS请求的SNI。SNI的值必须是VirtualService的hosts子集。
- destinationSubnets:目标IP地址匹配的IP子网
- port:访问的目标端口
- sourceLabels:是一个map类型的键值对,匹配来源负载的标签。
- gateway:表示规则适用的Gateway名字,覆盖VirtualService上的gateways定义。和HTTPMatchRequest中的gateways的意思相同。
可以看到,sniHosts和destinationSubnets属性是TLS特有的,port、sourceLabels和gateways属性同HTTP的条件定义。一般的用法是匹配port和sniHosts。
4)四层路由目标RouteDestination
TLS的路由目标通过RouteDestination来描述转发的目的地址,这是一个四层路由转发地址,包含两个必选属性destination和weight。
- destination:表示满足条件的流量的目标
- weight:表示切分的流量比例。
RouteDestination上的这两字字段在使用上有较多注意点。用法和约束同HTTPRouteDestination的对应字段。
2、TCP路由(TCPRoute)
所有不满足以上HTTP和TLS条件的流量都会应用TCP流量规则。
1)TCPRoute配置示例
如下所示,将来自forecast服务23003端口的流量转发到inner-forecast服务的3003端口。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: forecast
namespace: weather
spec:
hosts:
- forecast
tcp:
- match:
- port: 23003
route:
- destination:
host: inne-forecast
port:
number: 3003
2)TCPRoute规则解析
与HTTP和TLS类似,TCPRoute的规则描述的也是将满足一定条件的流量转发到对应的目标后端,其目标后端的定义和TLS相同,也是RouteDestination。下文将重点关注TCP特有的四层匹配规则L4MatchAttributes。
3)四层匹配规则(L4MatchAttributes)
在TCPRoute中,match字段也是一个数组,元素类型是L4MatchAttributes,支持一下匹配属性:
- destinationSubnets:目标IP地址匹配的IP
- port:访问的目标端口
- sourceLabels:源工作负载标签
- gateway:Gateway的名称
这几个参数和TLSMatchAttributes对应字段的意义相同,如下所示为基于端口和源工作负载标签描述TCP流量的典型示例:
tcp:
- match:
- sourceLabels:
group: beta
- port:23003
3、三种协议路由规则对比
VirtualService 在http、tls、tcp这三个字段上分别定义了应用于HTTP、TLS和TCP三种协议的路由规则。从规则构成上都是先定义一组匹配条件,然后对满足条件的的流量执行对应的操作。因为协议的内容不同,路由匹配条件不同,所以执行的操作也不同。如下表所示对比了三种路由规则。从各个维度来看,HTTP路由规则的内容最丰富,TCP路由规则的内容最少,这也符合协议分层的设计。
比较内容 | HTTP | TLS | TCP |
---|---|---|---|
路由规则 | HTTPRoute | TLSRoute | TCPRoute |
流量匹配条件 | HTTPMatchRequest | TLSMatchAttributes | L4MatchAttributes |
条件属性 | uri、scheme、method、authority、port、sourceLabels、gateway | sniHosts、destinationSubnets、port、sourceLabels、gateway | destinationSubnets、port、sourceLabels、gateway |
流量操作 | route、redirect、rewrite、retry、timeout、faultInjection、corsPolicy | Route | Route |
目标路由定义 | HTTPRouteDestination | RouteDestination | RouteDestination |
目标路由属性 | destination、weight、headers | destination、weight | destination、weight |
4、VirtualService的典型应用
下面结合几个典型的使用场景来看看VirtualService的综合使用。
1)多个服务的组合
VirtualService是一个广义的Service,在如下配置中可以将一个weather应用的多个服务组成一个大的虚拟服务。根据访问路径得不同,对weather服务的访问会被转发到不同的内部服务上。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: weather
namespace: weather
spec:
hosts:
- weather.com
http:
- match:
- uri:
prefix: /recommendation
route:
- destination:
host: recommendation
- match:
- uri:
prefix: /forecast
route:
- destination:
host: forecast
- match:
- uri:
prefix: /advertisemment
route:
- destination:
host: advertisemment
假设访问“weather.com”服务,则根据不同的路径,流量会被分发到不同的后端服务上。当然,在内部服务间的访问,更常规的用法是直接使用服务名。
2)路由规则的优先级
我们可以对VirtualService设置N条规则,在VirtualService中通过路由的顺序即可明确表达规则,哪条规则在前面,谁的优先级就高。在下面的配置中,以“/weather/data”开头的流量被转发到v3版本,以“/weather”开头的其他流量被转发到v2版本,其他流量被转发到v1版本。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: forecast
namespace: weather
spec:
hosts:
- forecast
http:
- match:
- uri:
perfix: "/weather/data"
route:
- destination:
name: forecast
subset: v3
- match:
- uri:
perfix: "/weather"
route:
- destination:
name: forecast
subset: v2
- route:
- destination:
name: forecast
subset: v1
在路由规则执行时,只要有一个匹配,规则执行就会跳出。所有随便调整以上的三条规则,则可能导致另一条规则在理论上将没有流量。
3)复杂条件路由
灰度发布分流规则一般有两种方式:一种是基于请求的内容切分流量,另一种是比例切分流量。实际上,根据需要也可以结合使用。如下所示:
apiVersiom: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: forecast
namespace: weather
spec:
hosts:
- forecast
http:
- match:
- headers:
cookie:
regex:"xxxxx"
uri:
prefix: "/weather"
- uri:
prefix: "data"
route:
- destination:
name: forecast
subset: v3
weight: 20
- destination:
name: forecast
subset: v2
weight: 80
- route:
- destination:
name: forecast
subset: v1
对于forecast服务的请求,当请求的cookie满足“xxx”正则表达式,且uri的前缀为“/weather”,或者uri的前缀为“/data”时,流量走forecast的v2、v3版本,其中v2流量占80%,v3占20%。其余的流量都走forcast的v1版本。
4)特定版本间的访问规则
现在来看下一个通用字段sourceLabels,该字段可以用来过滤访问源。如下配置所示,只对frontend服务的v2版本到forecast服务的v1版本的请求设置20s的延迟。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
medata:
name: forecast
namespace: weather
spec:
hosts:
- forecast
http:
- match:
- sourceLabels:
app: frontend
version: v2
fault:
delay:
fixeDelay: 20s
route:
- destination:
name: forecast
subset: v1
以上只是典型的应用,掌握了规则的定义和语法,边可以自由配置需要的多业务功能,非常灵活方便。
可能会觉得很复杂,所以要加强练习,后面的一些资源对象规则则没有复杂了。
(如果觉得写得还好,请多多点赞,觉得有用就收藏起来,方便食用)