Istio路由規則配置：VirtualService之TLSRoute、TCPRoute及三種對比及實踐

1、TLS路由

2、TCP路由（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

以上只是典型的應用，掌握了規則的定義和語法，邊可以自由配置需要的多業務功能，非常靈活方便。
可能會覺得很複雜，所以要加強練習，後面的一些資源對象規則則沒有複雜了。
（如果覺得寫得還好，請多多點贊，覺得有用就收藏起來，方便食用）

Istio路由規則配置：VirtualService之TLSRoute、TCPRoute及三種對比及實踐