Istio流量管理之請求路由分析
前面我們了解了 Gateway 和 VirtualService 資源對象的作用，以及它們是如何影響 Envoy 的配置的，那么這些資源對象又是如何影響流量的呢？通過 Istio 如何實現(xiàn)流量管理的呢？
流量管理概述
Istio 的流量路由規(guī)則可以很容易的控制服務之間的流量和 API 調用。Istio 簡化了服務級別屬性的配置，比如熔斷器、超時和重試，并且能輕松的設置重要的任務，如 A/B 測試、金絲雀發(fā)布、基于流量百分比切分的分階段發(fā)布等。它還提供了開箱即用的故障恢復特性， 有助于增強應用的健壯性，從而更好地應對被依賴的服務或網(wǎng)絡發(fā)生故障的情況。
為了在網(wǎng)格中路由，Istio 需要知道所有的 endpoint 在哪以及它們屬于哪些服務。為了定位到 service registry（服務注冊中心），Istio 會連接到一個服務發(fā)現(xiàn)系統(tǒng)。如果在 Kubernetes 集群上安裝了 Istio，那么它將自動檢測該集群中的服務和 endpoint。
請求路由
首先我們來實現(xiàn)下最基本的流量請求路由的功能，這里我們將學習如何將請求動態(tài)路由到微服務的多個版本。
我們知道 Bookinfo 示例包含四個獨立的微服務，每個微服務都有多個版本。其中 reviews 服務的三個不同版本已經(jīng)部署并同時運行。我們可以在瀏覽器中訪問 Bookinfo 應用程序并刷新幾次。正常會看到三種不同的 reviews 服務版本的輸出，有時書評的輸出包含星級評分，有時則不包含。這是因為沒有明確的默認服務版本可路由，Istio 將以循環(huán)方式將請求路由到所有可用版本。
我們首先來將所有流量路由到微服務的 v1 版本，稍后，您將應用規(guī)則根據(jù) HTTP 請求 header 的值路由流量。
路由到指定版本
要只路由到一個版本，則需要為微服務設置默認版本的 VirtualService。
應用規(guī)則
Istio 使用 VirtualService 來定義路由規(guī)則，只需要應用下面的資源對象即可：
$ kubectl apply -f samples/bookinfo/networking/virtual-service-all-v1.yaml
virtualservice.networking.istio.io/productpage created
virtualservice.networking.istio.io/reviews created
virtualservice.networking.istio.io/ratings created
virtualservice.networking.istio.io/details created該資源清單中定義了四個 VirtualService 對象，分別是 productpage、reviews、ratings、details，它們分別對應著 Bookinfo 應用中的四個微服務，完整的清單如下所示：
# virtual-service-all-v1.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: productpage
spec:
hosts:
- productpage
http:
- route:
- destination:
host: productpage
subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- route:
- destination:
host: ratings
subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: details
spec:
hosts:
- details
http:
- route:
- destination:
host: details
subset: v1
---我們可以看到這里的 VirtualService 對象中都定義了 subset 字段，這個字段就是用來指定微服務的版本的，這里我們將所有的微服務都指定為 v1 版本，這樣所有的流量都會被路由到 v1 版本的微服務中，包括 reviews 服務，這樣我們就不會再看到星級評分了。
但是如果我們現(xiàn)在直接去訪問 Bookinfo 應用的話，是不能正常訪問的，因為我們壓根就還沒指定這些 v1 版本的微服務到底在哪里。
bookinfo error
這個時候就需要用到另外一個資源對象 DestinationRule 了，我們需要為每個微服務創(chuàng)建一個 DestinationRule 對象，用來指定這些微服務的實際地址，這樣 VirtualService 對象才能將流量路由到這些微服務中。Istio 在 DestinationRule 目標規(guī)則中使用 subsets 定義服務的版本，運行以下命令為 Bookinfo 服務創(chuàng)建默認的目標規(guī)則即可：
$ kubectl apply -f samples/bookinfo/networking/destination-rule-all.yaml
destinationrule.networking.istio.io/productpage created
destinationrule.networking.istio.io/reviews created
destinationrule.networking.istio.io/ratings created
destinationrule.networking.istio.io/details created該資源清單中定義了四個 DestinationRule 對象，分別是 productpage、reviews、ratings、details 幾個服務的目標規(guī)則，它們分別對應著 Bookinfo 應用中的四個微服務，完整的清單如下所示：
# destination-rule-all.yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: productpage
spec:
host: productpage
subsets:
- name: v1
labels:
version: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
- name: v3
labels:
version: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: ratings
spec:
host: ratings
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
- name: v2-mysql
labels:
version: v2-mysql
- name: v2-mysql-vm
labels:
version: v2-mysql-vm
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: details
spec:
host: details
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
---現(xiàn)在我們就可以正常訪問 Bookinfo 應用了，并且無論刷新多少次，頁面的評論部分都不會顯示評級星標，這是因為我們將 Istio 配置為將 reviews 服務的所有流量路由到版本 reviews:v1，而此版本的服務不訪問星級評分服務。
v1版本review
這樣我們就成功將流量路由到服務的某一個版本上了。
原理分析
前面章節(jié)中我們只定義了一個名為 bookinfo 的 VirtualService 資源對象就可以正常訪問了：
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: bookinfo
namespace: default
spec:
gateways:
- bookinfo-gateway
hosts:
- "*"
http:
- match:
- uri:
exact: /productpage
- uri:
prefix: /static
- uri:
exact: /login
- uri:
exact: /logout
- uri:
prefix: /api/v1/products
route:
- destination:
host: productpage
port:
number: 9080很明顯上面這個虛擬服務對象是我們訪問 Bookinfo 應用的入口路由規(guī)則，所以這個虛擬服務對象實際上是為 istio-ingressgateway 入口網(wǎng)關服務定義的。 它將所有的流量都路由到了 productpage 這個服務上，而 productpage 這個服務又會去調用其他的服務來獲取數(shù)據(jù)，在 productpage 服務中調用其他微服務 其實就是直接通過服務名稱來調用的，比如調用 reviews 服務就是直接通過 reviews:9080 這個服務來調用的，我們可以查看 productpage 的代碼來驗證這一點：
productpage
我們可以再次查看 Bookinfo 在網(wǎng)格內的請求架構圖：
BookInfo 架構
當我們在瀏覽器中訪問 http://<gateway url>/productpage 時，請求將進入網(wǎng)格中的 istio-ingressgateway 服務，然后將請求轉發(fā)到 productpage 服務。productpage 服務將調用 reviews 和 details 服務來填充頁面的內容，然后將其返回給用戶。（reviews 服務包括 3 個不同版本的應用，可以通過 version 標簽區(qū)分）
現(xiàn)在我們只想將流量路由到 reviews:v1 版本去，按照傳統(tǒng)的方法只需要將 reviews 的 Service 對象去強制關聯(lián) version: v1 這個標簽即可，現(xiàn)在我們所有的服務都被注入了一個 Envoy 的 Sidecar 代理，通過 Envoy 很容易就可以實現(xiàn)這個路由功能，而相應的在 Istio 中我們只需要通過 VirtualService 和 DestinationRule 這兩個資源對象就可以來實現(xiàn)了。上面我們創(chuàng)建的關于 reviews 服務的這兩個對象如下所示：
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
- name: v3
labels:
version: v3那么這兩個對象是如何來影響 Envoy Sidecar 的呢？前面我們已經(jīng)分析了流量從 istio-ingressgateway 進來后被路由到了 productpage 服務，那么 productpage 又該如何去訪問其他微服務呢？同樣我們可以使用 istioctl proxy-config 來查看 productpage 服務的 Envoy 配置。
每個 Envoy Sidecar 都有一個綁定到 0.0.0.0:15001 的監(jiān)聽器，然后利用 IP tables 將 pod 的所有入站和出站流量路由到這里，此監(jiān)聽器會配置一個 useOriginalDst: true，這意味著它將請求交給最符合請求原始目標的監(jiān)聽器。如果找不到任何匹配的虛擬監(jiān)聽器，它會將請求發(fā)送給返回 404 的 BlackHoleCluster，我們可以查看下 15001 端口的監(jiān)聽器配置：
$ istioctl proxy-config listeners productpage-v1-564d4686f-wwqqf --port 15001 -oyaml
- address:
socketAddress:
address: 0.0.0.0
portValue: 15001
filterChains:
- filterChainMatch:
destinationPort: 15001
filters:
- name: istio.stats
typedConfig:
'@type': type.googleapis.com/stats.PluginConfig
- name: envoy.filters.network.tcp_proxy
typedConfig:
'@type': type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxy
cluster: BlackHoleCluster
statPrefix: BlackHoleCluster
name: virtualOutbound-blackhole
- filters:
- name: istio.stats
typedConfig:
'@type': type.googleapis.com/stats.PluginConfig
- name: envoy.filters.network.tcp_proxy
typedConfig:
'@type': type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxy
# ......
cluster: PassthroughCluster
statPrefix: PassthroughCluster
name: virtualOutbound-catchall-tcp
name: virtualOutbound
trafficDirection: OUTBOUND
useOriginalDst: true實際上我們的請求是到 9080 端口（productpage 服務綁定 9080 端口）的 HTTP 出站請求，這意味著它被切換到 0.0.0.0:9080 虛擬監(jiān)聽器。所以我們查看下 9080 端口的監(jiān)聽器配置：
# productpage 默認訪問其他服務的 9080 端口
$ istioctl proxy-config listeners productpage-v1-564d4686f-wwqqf --port 9080 -oyaml
- address:
socketAddress:
address: 0.0.0.0
portValue: 9080
# ......
rds:
configSource:
ads: {}
initialFetchTimeout: 0s
resourceApiVersion: V3
routeConfigName: "9080" # RDS的路由配置名稱
# ......
name: 0.0.0.0_9080
trafficDirection: OUTBOUND # 出流量可以看到此監(jiān)聽器在其配置的 RDS 中查找名為 9080 的路由配置，我們可以使用 istioctl proxy-config routes 命令來查看這個路由配置的詳細信息：
# 查看 9080 這個路由配置
$ istioctl proxy-config routes productpage-v1-564d4686f-wwqqf --name 9080 -oyaml
- name: "9080"
virtualHosts:
- domains:
- details.default.svc.cluster.local
- details
- details.default.svc
- details.default
- 10.111.83.224
name: details.default.svc.cluster.local:9080
routes:
- decorator:
operation: details.default.svc.cluster.local:9080/*
match:
prefix: /
metadata:
filterMetadata:
istio:
config: /apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/details
route:
cluster: outbound|9080|v1|details.default.svc.cluster.local
# ......
- domains:
- productpage.default.svc.cluster.local
- productpage
- productpage.default.svc
- productpage.default
- 10.97.120.23
name: productpage.default.svc.cluster.local:9080
routes:
- decorator:
operation: productpage.default.svc.cluster.local:9080/*
match:
prefix: /
name: default
route:
cluster: outbound|9080||productpage.default.svc.cluster.local
# ......
- domains:
- ratings.default.svc.cluster.local
- ratings
- ratings.default.svc
- ratings.default
- 10.101.184.235
name: ratings.default.svc.cluster.local:9080
routes:
- decorator:
operation: ratings.default.svc.cluster.local:9080/*
match:
prefix: /
metadata:
filterMetadata:
istio:
config: /apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/ratings
route:
cluster: outbound|9080|v1|ratings.default.svc.cluster.local
# ......
- domains:
- reviews.default.svc.cluster.local
- reviews
- reviews.default.svc
- reviews.default
- 10.97.120.56
name: reviews.default.svc.cluster.local:9080
routes:
- decorator:
operation: reviews.default.svc.cluster.local:9080/*
match:
prefix: /
metadata:
filterMetadata:
istio:
config: /apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/reviews
route:
cluster: outbound|9080|v1|reviews.default.svc.cluster.local
# ......
- domains:
- '*'
name: allow_any
routes:
- match:
prefix: /
name: allow_any
route:
cluster: PassthroughCluster
# ......這個路由配置中其實包含了 K8s Service 對象中監(jiān)聽 9080 端口的所有服務，如果沒有創(chuàng)建對應的 VirtualService 對象，對應的路由配置就沒有 metadata.filterMetadata.istio.config 這個屬性。比如現(xiàn)在我們正在通過 productpage 請求前往 reviews 服務，因此 Envoy 將選擇我們的請求與域匹配的虛擬主機。一旦在域上匹配，Envoy 會查找與請求匹配的第一條路徑，我們這里沒有任何高級路由，因此只有一條路由匹配所有內容。這條路由告訴 Envoy 將請求發(fā)送到 outbound|9080|v1|reviews.default.svc.cluster.local 集群，因為前面我們創(chuàng)建的 reviews 這個 VirtualService 對象配置了的 destination.subset: v1，所以這里的集群命名上多了一個 subset。
需要注意的是我們在 VirtualService 對象里面配置了 destination.subset: v1，那么必須要有對應的 subset 存在才行，否則不會生成對應的 Envoy 集群配置，那么就不能正常訪問該服務了，而該 subset 就是通過前面的 DestinationRule 對象來定義的，現(xiàn)在我們就可以來查看這個集群配置了：
$ istioctl proxy-config cluster productpage-v1-564d4686f-wwqqf --fqdn reviews.default.svc.cluster.local -o yaml
- edsClusterConfig:
edsConfig:
ads: {}
initialFetchTimeout: 0s
resourceApiVersion: V3
serviceName: outbound|9080||reviews.default.svc.cluster.local
lbPolicy: LEAST_REQUEST
metadata:
filterMetadata:
istio:
config: /apis/networking.istio.io/v1alpha3/namespaces/default/destination-rule/reviews
services:
- host: reviews.default.svc.cluster.local
name: reviews
namespace: default
# ......
name: outbound|9080||reviews.default.svc.cluster.local
type: EDS
- edsClusterConfig:
edsConfig:
ads: {}
initialFetchTimeout: 0s
resourceApiVersion: V3
serviceName: outbound|9080|v1|reviews.default.svc.cluster.local
lbPolicy: LEAST_REQUEST
metadata:
filterMetadata:
istio:
config: /apis/networking.istio.io/v1alpha3/namespaces/default/destination-rule/reviews
services:
- host: reviews.default.svc.cluster.local
name: reviews
namespace: default
subset: v1
name: outbound|9080|v1|reviews.default.svc.cluster.local
# ......
type: EDS
- edsClusterConfig:
edsConfig:
ads: {}
initialFetchTimeout: 0s
resourceApiVersion: V3
serviceName: outbound|9080|v2|reviews.default.svc.cluster.local
filters:
- name: istio.metadata_exchange
typedConfig:
'@type': type.googleapis.com/envoy.tcp.metadataexchange.config.MetadataExchange
protocol: istio-peer-exchange
lbPolicy: LEAST_REQUEST
metadata:
filterMetadata:
istio:
config: /apis/networking.istio.io/v1alpha3/namespaces/default/destination-rule/reviews
services:
- host: reviews.default.svc.cluster.local
name: reviews
namespace: default
subset: v2
name: outbound|9080|v2|reviews.default.svc.cluster.local
# ......
type: EDS
- edsClusterConfig:
edsConfig:
ads: {}
initialFetchTimeout: 0s
resourceApiVersion: V3
serviceName: outbound|9080|v3|reviews.default.svc.cluster.local
filters:
- name: istio.metadata_exchange
typedConfig:
'@type': type.googleapis.com/envoy.tcp.metadataexchange.config.MetadataExchange
protocol: istio-peer-exchange
lbPolicy: LEAST_REQUEST
metadata:
filterMetadata:
istio:
config: /apis/networking.istio.io/v1alpha3/namespaces/default/destination-rule/reviews
services:
- host: reviews.default.svc.cluster.local
name: reviews
namespace: default
subset: v3
name: outbound|9080|v3|reviews.default.svc.cluster.local
# ......
type: EDS從上面配置可以看到里面一共包含了 4 個 reviews 相關的集群，一個是原始的不包含 subset 的，而另外三個就是前面我們在 DestinationRule 對象中配置的 3 個 subset，所以其實 DestinationRule 映射到 Envoy 的配置文件中就是 Cluster。
最后我們同樣還可以查看每個集群下面包含的 endpoint 有哪些：
$ istioctl proxy-config endpoint productpage-v1-564d4686f-wwqqf --cluster "outbound|9080||reviews.default.svc.cluster.local" -o yaml
- edsServiceName: outbound|9080||reviews.default.svc.cluster.local
- address:
socketAddress:
address: 10.244.2.84
portValue: 9080
# ......
weight: 1
- address:
socketAddress:
address: 10.244.2.83
portValue: 9080
# ......
weight: 1
- address:
socketAddress:
address: 10.244.2.88
portValue: 9080
# ......
weight: 1
name: outbound|9080||reviews.default.svc.cluster.local
observabilityName: outbound|9080||reviews.default.svc.cluster.local
$ istioctl proxy-config endpoint productpage-v1-564d4686f-wwqqf --cluster "outbound|9080|v1|reviews.default.svc.cluster.local" -o yaml
- edsServiceName: outbound|9080|v1|reviews.default.svc.cluster.local
hostStatuses:
- address:
socketAddress:
address: 10.244.2.84
portValue: 9080
weight: 1
name: outbound|9080|v1|reviews.default.svc.cluster.local
observabilityName: outbound|9080|v1|reviews.default.svc.cluster.local
# 過濾 versinotallow=v1 的 reviews pod
$ kubectl get pod -l app=reviews,versinotallow=v1 -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
reviews-v1-86896b7648-zjh2n 2/2 Running 4 (5h18m ago) 6d17h 10.244.2.84 node2 <none> <none>可以看到不包含 subset 的集群下面的 endpoint 其實就是 reviews 這個 Service 對象的 endpoint 集合，包含 subset 就只有和該子集匹配的后端實例了。到了這一步，一切皆明了，后面的事情就跟之前的套路一樣了，具體的 Endpoint 對應打了標簽 versinotallow=v1 的 Pod。
到這里我們是不是就實現(xiàn)了通過 VirtualService 和 DestinationRule 對象將流量路由到了指定的版本上面了，上面的整個過程就是請求從 productpage 到 reviews 的過程，從 reviews 到網(wǎng)格內其他應用的流量與上面類似，就不展開討論了。
基于用戶身份的路由
接下來我們繼續(xù)更改路由配置，將來自特定用戶的所有流量路由到特定服務版本。我們這里將配置來自名為 Jason 的用戶的所有流量被路由到服務 reviews:v2。
注意 Istio 對用戶身份沒有任何特殊的內置機制，productpage 服務在所有到 reviews 服務的 HTTP 請求中都增加了一個自定義的 end-user 請求頭來實現(xiàn)該效果：headers['end-user'] = session['user']。
要實現(xiàn)該功能，只需要創(chuàng)建下面的資源對象即可：
$ kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml
virtualservice.networking.istio.io/reviews configured該資源清單文件創(chuàng)建了一個如下所示的 VirtualService 資源對象：
# virtual-service-reviews-test-v2.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v1該對象設置了一條路由規(guī)則，它會根據(jù) productpage 服務發(fā)起的請求的 end-user 自定義請求頭內容進行匹配，如果有該內容且為 jason 則會將流量路由到 reviews 服務的 v2 版本，其余的還是被路由到 v1 版本去。
現(xiàn)在我們可以前往瀏覽器訪問 Bookinfo 應用，多刷新幾次可以看到評論始終訪問到的是 v1 版本的服務，即沒有星標的：
Bookinfo
然后我們點擊頁面右上角的 Sign in 按鈕，使用 jason 進行登錄，登錄后頁面就會出現(xiàn)帶有黑色星標的 v2 版本的評論服務，即使多刷新幾次依然如此：
Bookinfo jason
如果我們選擇使用其他用戶進行登錄或者注銷則星標就會消失，這是因為除了 Jason 之外，所有用戶的流量都被路由到 reviews:v1。
同樣的我們可以去查看下對應的 Envoy Sidecar 配置的變化，因為這里我們只更新了一個 VirtualService 對象，所以只會對 Envoy 的路由表產(chǎn)生影響，查看對應的路由配置即可：
$ istioctl proxy-config routes productpage-v1-564d4686f-wwqqf --name 9080 -oyaml
- name: "9080"
validateClusters: false
virtualHosts:
# ......
- domains:
- reviews.default.svc.cluster.local
- reviews
- reviews.default.svc
- reviews.default
- 10.97.120.56
includeRequestAttemptCount: true
name: reviews.default.svc.cluster.local:9080
routes:
- decorator:
operation: reviews.default.svc.cluster.local:9080/*
match:
caseSensitive: true
headers:
- name: end-user
stringMatch:
exact: jason
prefix: /
metadata:
filterMetadata:
istio:
config: /apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/reviews
route:
cluster: outbound|9080|v2|reviews.default.svc.cluster.local
maxGrpcTimeout: 0s
# ......
- decorator:
operation: reviews.default.svc.cluster.local:9080/*
match:
prefix: /
metadata:
filterMetadata:
istio:
config: /apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/reviews
route:
cluster: outbound|9080|v1|reviews.default.svc.cluster.local
maxGrpcTimeout: 0s
# ......從配置上我們可以看到現(xiàn)在的 Envoy 配置中新增了一條路由規(guī)則，如下所示：
match:
caseSensitive: true
headers:
- name: end-user
stringMatch:
exact: jason
prefix: /
route:
cluster: outbound|9080|v2|reviews.default.svc.cluster.local當請求頭中包含 end-user：jason 的時候請求會被路由到 outbound|9080|v2|reviews.default.svc.cluster.local 這個 Envoy Cluster 集群，這個集群就是前面我們通過 DestinationRule 創(chuàng)建的 v2 這個子集，所以最后請求會被路由到帶有黑色星標的評論服務去。
Kiali Dashboard
到這里我們就明白了要通過 Istio 實現(xiàn)服務的流量管理，需要用到 Gateway、VirtualService、DestinationRule 三個 CRD 對象，這些對象其實最終都是去拼湊 Envoy 的配置，每個對象管理 Envoy 配置的一部分，把這個關系搞清楚我們就能更好的掌握 Istio 的使用了。
