kubernetes中如何實現(xiàn)Istio流量管理

191次閱讀

共計 6515 個字符，預(yù)計需要花費 17 分鐘才能閱讀完成。

這篇文章主要為大家展示了“kubernetes 中如何實現(xiàn) Istio 流量管理”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓丸趣 TV 小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“kubernetes 中如何實現(xiàn) Istio 流量管理”這篇文章吧。

一：簡介

Istio 提供了一個簡單的配置模型，用來控制 API 調(diào)用以及應(yīng)用部署內(nèi)多個服務(wù)之間的四層通信。運維人員可以使用這個模型來配置服務(wù)級別的屬性，這些屬性可以是斷路器、超時、重試，以及一些普通的持續(xù)發(fā)布任務(wù)，例如金絲雀發(fā)布、A/B 測試、使用百分比對流量進(jìn)行控制，從而完成應(yīng)用的逐步發(fā)布等。

例如，將 reviews 服務(wù) 100% 的傳入流量發(fā)送到 v1 版本，這一需求可以用下面的規(guī)則來實現(xiàn)：

apiVersion: networking.istio.io/v1alpha3
 kind: VirtualServicemetadata:
 name: reviewsspec:
 hosts:
 - reviews http:
 - route:
 - destination:
 host: reviews 
 subset: v1

這個配置的用意是，發(fā)送到 reviews 服務(wù)（在 host 字段中標(biāo)識）的流量應(yīng)該被路由到 reviews 服務(wù)實例的 v1 子集中。路由中的 subset 制定了一個預(yù)定義的子集名稱，子集的定義來自于目標(biāo)規(guī)則配置

apiVersion: networking.istio.io/v1alpha3
 kind: DestinationRulemetadata:
 name: reviewsspec:
 host: reviews 
 subsets:
 - name: v1 
 labels:
 version: v1 
 - name: v2 
 labels:
 version: v2

子集中會指定一或多個標(biāo)簽，用這些標(biāo)簽來區(qū)分不同版本的實例。假設(shè)在 Kubernetes 上的 Istio 服務(wù)網(wǎng)格之中有一個服務(wù)，version: v1 代表只有標(biāo)簽中包含“version:v1”的 Pod 才會收到流量。

規(guī)則可以使用 istioctl 客戶端工具進(jìn)行配置，如果是 Kubernetes 部署，還可以使用 kubectl 命令完成同樣任務(wù)，但是只有 istioctl 會在這個過程中對模型進(jìn)行檢查，所以我們推薦使用 istioctl。在配置請求路由任務(wù)中包含有配置示例。

Istio 中包含有四種流量管理配置資源，分別是 VirtualService、DestinationRule、ServiceEntry、以及 Gateway。下面會講一下這幾個資源的一些重點。在網(wǎng)絡(luò)參考中可以獲得更多這方面的信息。

二：Virtual Services

Virtual Services 在 Istio 服務(wù)網(wǎng)格中定義了對服務(wù)的請求如何進(jìn)行路由控制。例如一個 Virtual Service 可以把請求路由到不同版本，甚至是可以路由到一個完全不同于請求要求的服務(wù)上去。路由可以用很多條件進(jìn)行判斷，例如請求的源和目的、HTTP 路徑和 Header 以及各個服務(wù)版本的權(quán)重等。

路由規(guī)則定義

路由規(guī)則對應(yīng)著一或多個用 VirtualService 配置指定的請求目的主機(jī)。這些主機(jī)可以是、也可以不是實際的目標(biāo)負(fù)載，甚至可以不是一個網(wǎng)格內(nèi)可路由的服務(wù)。例如要給到 reviews 服務(wù)的請求定義路由規(guī)則，可以使用內(nèi)部的名稱 reviews，也可以用域名 bookinfo.com，VirtualService 可以這樣使用 host 字段：

hosts:

– reviews

– bookinfo.com

host 字段用顯示或者隱式的方式定義了一或多個完全限定名（FQDN）。上面的 reviews，會隱式的擴(kuò)展成為特定的 FQDN，例如在 Kubernetes 環(huán)境中，全名會從 VirtualService 所在的集群和命名空間中繼承而來（比如說 reviews.default.svc.cluster.local）

2. 根據(jù)來源或 Header 制定規(guī)則

a. 根據(jù)特定用戶進(jìn)行限定。例如，可以制定一個規(guī)則，只對來自 reviews 服務(wù)的 Pod 生效

apiVersion: networking.istio.io/v1alpha3
 kind: VirtualServicemetadata:
 name: ratingsspec:
 hosts:
 - ratings 
 http:
 - match:
 sourceLabels:
 app: reviews ...

sourceLabels 的值依賴于服務(wù)的實現(xiàn)。比如說在 Kubernetes 中，跟服務(wù)的 Pod 選擇標(biāo)簽一致。

b. 根據(jù)調(diào)用方的特定版本進(jìn)行限定。例如下面的規(guī)則對前一個例子進(jìn)行修改，reviews 服務(wù)的 v2 版本發(fā)出的請求才會生效：

apiVersion: networking.istio.io/v1alpha3
 kind: VirtualServicemetadata:
 name: ratingsspec:
 hosts:
 - ratings 
 http:
 - match:
 - sourceLabels:
 app: reviews 
 version: v2 ...

c. 根據(jù) HTTP Header 選擇規(guī)則。下面的規(guī)則只會對包含了 end-user 頭，且值為 jason 的請求生效：

apiVersion: networking.istio.io/v1alpha3
 kind: VirtualServicemetadata:
 name: reviewsspec:
 hosts:
 - reviews 
 http:
 - match:
 - headers:
 end-user:
 exact: jason ...

3. 在服務(wù)之間分拆流量

每個路由規(guī)則都需要對一或多個有權(quán)重的后端進(jìn)行甄別并調(diào)用合適的后端。每個后端都對應(yīng)一個特定版本的目標(biāo)服務(wù)，服務(wù)的版本是依靠標(biāo)簽來區(qū)分的。如果一個服務(wù)版本包含多個注冊實例，那么會根據(jù)為該服務(wù)定義的負(fù)載均衡策略進(jìn)行路由，缺省策略是 round-robin。

例如下面的規(guī)則會把 25% 的 reviews 服務(wù)流量分配給 v2 標(biāo)簽；其余的 75% 流量分配給 v1：

apiVersion: networking.istio.io/v1alpha3
 kind: VirtualServicemetadata:
 name: reviewsspec:
 hosts:
 - reviews 
 http:
 - route:
 - destination:
 host: reviews 
 subset: v1 
 weight: 75
 - destination:
 host: reviews 
 subset: v2 
 weight: 25

4. 超時和重試

缺省情況下，HTTP 請求的超時設(shè)置為 15 秒，可以使用路由規(guī)則來覆蓋這個限制：

apiVersion: networking.istio.io/v1alpha3
 kind: VirtualServicemetadata:
 name: ratingsspec:
 hosts:
 - ratings 
 http:
 - route:
 - destination:
 host: ratings 
 subset: v1 
 timeout: 10s

5. 在請求中進(jìn)行錯誤注入

在根據(jù)路由規(guī)則向選中目標(biāo)轉(zhuǎn)發(fā) http 請求的時候，可以向其中注入一或多個錯誤。錯誤可以是延遲，也可以是退出。

下面的例子在目標(biāo)為 ratings:v1 服務(wù)的流量中，對其中的 10% 注入 5 秒鐘的延遲。

apiVersion: networking.istio.io/v1alpha3
 kind: VirtualServicemetadata:
 name: ratingsspec:
 hosts:
 - ratings 
 http:
 - fault:
 delay:
 percent: 10
 fixedDelay: 5s 
 route:
 - destination:
 host: ratings 
 subset: v1

三：DestinationRule

1. 目標(biāo)規(guī)則

在請求被 VirtualService 路由之后，DestinationRule 配置的一系列策略就生效了。這些策略包含斷路器、負(fù)載均衡以及 TLS 等的配置內(nèi)容。DestinationRule 還定義了對應(yīng)目標(biāo)主機(jī)的可路由 subset（例如有命名的版本）。VirtualService 在向特定服務(wù)版本發(fā)送請求時會用到這些子集。

apiVersion: networking.istio.io/v1alpha3
 kind: DestinationRulemetadata:
 name: reviewsspec:
 host: reviews trafficPolicy:
 loadBalancer:
 simple: RANDOM 
 subsets:
 - name: v1 
 labels:
 version: v1 
 - name: v2 
 labels:
 version: v2 
 trafficPolicy:
 loadBalancer:
 simple: ROUND_ROBIN 
 - name: v3 
 labels:
 version: v3

2. 斷路器

可以用一系列的標(biāo)準(zhǔn)，例如連接數(shù)和請求數(shù)限制來定義簡單的斷路器。

例如下面的 DestinationRule 給 reviews 服務(wù)的 v1 版本設(shè)置了 100 連接的限制：

apiVersion: networking.istio.io/v1alpha3
 kind: DestinationRulemetadata:
 name: reviewsspec:
 host: reviews 
 subsets:
 - name: v1 
 labels:
 version: v1 
 trafficPolicy:
 connectionPool:
 tcp:
 maxConnections: 100

3. 目標(biāo)規(guī)則的評估

和路由規(guī)則類似，這些策略也是和特定的 host 相關(guān)聯(lián)的，如果指定了 subset，那么具體生效的 subset 的決策是由路由規(guī)則來決定的。

規(guī)則評估的第一步，是確認(rèn) VirtualService 中所請求的主機(jī)相對應(yīng)的路由規(guī)則（如果有的話），這一步驟決定了將請求發(fā)往目標(biāo)服務(wù)的哪一個 subset（就是特定版本）。下一步，被選中的 subset 如果定義了策略，就會開始是否生效的評估。

這一算法需要留心是，為特定 subset 定義的策略，只有在該 subset 被顯式的路由時候才能生效。例如下面的配置，只為 review 服務(wù)定義了規(guī)則（沒有對應(yīng)的 VirtualService 路由規(guī)則）。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRulemetadata:
 name: reviewsspec:
 host: reviews 
subsets:
 - name: v1 
labels:
 version: v1 
trafficPolicy:
 connectionPool:
 tcp:
 maxConnections: 100

既然沒有為 reviews 服務(wù)定義路由規(guī)則，那么就會使用缺省的 round-robin 策略，偶爾會請求到 v1 實例，如果只有一個 v1 實例，那么所有請求都會發(fā)送給它。然而上面的策略是永遠(yuǎn)不會生效的，這是因為，缺省路由是在更底層完成的任務(wù)，策略引擎無法獲知最終目的，也無法為請求選擇匹配的 subset 策略。

有兩種方法來解決這個問題。可以把路由策略提高一級，要求他對所有版本生效：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRulemetadata:
 name: reviewsspec:
 host: reviews 
trafficPolicy:
 connectionPool:
 tcp:
 maxConnections: 100
 subsets:
 - name: v1 
 labels:
 version: v1

還有一個更好的方法，就是為服務(wù)定義路由規(guī)則，例如給 reviews:v1 加入一個簡單的路由規(guī)則：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualServicemetadata:
 name: reviewsspec:
 hosts:
 - reviews 
http:
 - route:
 - destination:
 host: reviews 
 subset: v1

雖然 Istio 在沒有定義任何規(guī)則的情況下，能將所有來源的流量發(fā)送給所有版本的目標(biāo)服務(wù)。然而一旦需要對版本有所區(qū)別，就需要制定規(guī)則了。從一開始就給每個服務(wù)設(shè)置缺省規(guī)則，是 Istio 世界里推薦的最佳實踐。

四：Service Entries

Istio 內(nèi)部會維護(hù)一個服務(wù)注冊表，可以用 ServiceEntry 向其中加入額外的條目。通常這個對象用來啟用對 Istio 服務(wù)網(wǎng)格之外的服務(wù)發(fā)出請求。例如下面的 ServiceEntry 可以用來允許外部對 *.foo.com 域名上的服務(wù)主機(jī)的調(diào)用。

apiVersion: networking.istio.io/v1alpha3
 kind: ServiceEntrymetadata:
 name: foo-ext-svcspec:
 hosts:
 - *.foo.com 
 ports:
 - number: 80
 name: http 
 protocol: HTTP 
 - number: 443
 name: https 
 protocol: HTTPS

五：Gateway

Gateway 為 HTTP/TCP 流量配置了一個負(fù)載均衡，多數(shù)情況下在網(wǎng)格邊緣進(jìn)行操作，用于啟用一個服務(wù)的 Ingress 流量。

和 Kubernetes Ingress 不同，Istio Gateway 只配置四層到六層的功能（例如開放端口或者 TLS 配置）。綁定一個 VirtualService 到 Gateway 上，用戶就可以使用標(biāo)準(zhǔn)的 Istio 規(guī)則來控制進(jìn)入的 HTTP 和 TCP 流量。

例如下面提供一個簡單的 Gateway 代碼，配合一個負(fù)載均衡，允許外部針對主機(jī) bookinfo.com 的 https 流量：

apiVersion: networking.istio.io/v1alpha3
kind: Gatewaymetadata:
 name: bookinfo-gatewayspec:
 servers:
 - port:
 number: 443
 name: https 
protocol: HTTPS 
hosts:
 - bookinfo.com 
 mode: SIMPLE 
serverCertificate: /tmp/tls.crt 
privateKey: /tmp/tls.key

要為 Gateway 配置對應(yīng)的路由，必須為定義一個同樣 host 定義的 VirtualService，其中用 gateways 字段來綁定到定義好的 Gateway 上：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualServicemetadata:
 name: bookinfospec:
 hosts:
 - bookinfo.com gateways:
 - bookinfo-gateway #  ----  綁定到  Gateway
 http:
 - match:
 - uri:
 prefix: /reviews 
route:
 ...

雖然主要用于管理 Ingress 流量，Gateway 還可以用在純粹的內(nèi)部服務(wù)之間或者 egress 場景下使用。不管處于什么位置，所有的網(wǎng)關(guān)都可以以同樣的方式進(jìn)行配置和控制。

以上是“kubernetes 中如何實現(xiàn) Istio 流量管理”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道！

正文完