Istio流量管理的示例分析

本篇文章給大家分享的是有關(guān)Istio流量管理的示例分析，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

綜述

本頁面概述了Istio中流量管理的工作原理，包括流量管理原則的優(yōu)點(diǎn)。我們假定你已經(jīng)閱讀了什么是Istio？ 并熟悉Istio的高層架構(gòu)。 您可以在本節(jié)的其他指南中找到有關(guān)流量管理功能的更多信息。

Pilot 和Envoy

Istio中流量管理的核心組件是Pilot，它管理和配置部署在Istio服務(wù)網(wǎng)格中的所有Envoy代理實(shí)例。它允許你指定要使用哪些規(guī)則在Envoy代理之間路由流量，并配置故障恢復(fù)功能，例如超時(shí)，重試和斷路器。 它還維護(hù)網(wǎng)格中所有服務(wù)的規(guī)范模型，并使用它來讓Envoys 通過其服務(wù)發(fā)現(xiàn)了解網(wǎng)格中的其他實(shí)例。

每個(gè)Envoy實(shí)例根據(jù)從Pilot獲取的信息和其負(fù)載平衡池中其他實(shí)例的定期運(yùn)行狀況檢查獲取的信息來維護(hù)負(fù)載平衡信息，從而使其能夠在遵循其指定的路由規(guī)則的情況下智能分配目標(biāo)實(shí)例之間的流量。

流量管理的好處

使用Istio的流量管理模型基本上將交通流量和基礎(chǔ)設(shè)施擴(kuò)展分離，讓運(yùn)維通過Pilot為流量配置規(guī)則，而不是哪些特定的Pod/VM應(yīng)該接收流量 - Pilot和智能Envoy代理負(fù)責(zé)監(jiān)督其余流量。因此，例如，你可以通過Pilot指定您希望特定服務(wù)的5％流量轉(zhuǎn)換為金絲雀版本，而不用考慮金絲雀版本的大小，或根據(jù)請(qǐng)求內(nèi)容將流量發(fā)送到特定版本。

將流量從基礎(chǔ)架構(gòu)中分離出來，使Istio能夠提供各種流量管理功能，而且這些功能與應(yīng)用代碼分離。除了A/B測(cè)試，滾動(dòng)部署和金絲雀發(fā)布之外，它還使用超時(shí)、重試和斷路器處理故障恢復(fù)，以及故障注入，以測(cè)試跨服務(wù)的故障恢復(fù)策略的兼容性。 這些功能都是通過在服務(wù)網(wǎng)格中部署的Envoy sidecars/proxy 實(shí)現(xiàn)的。

Pilot

Pilot負(fù)責(zé)整個(gè)Istio服務(wù)網(wǎng)格中部署的Envoy實(shí)例的生命周期。

如上圖所示，Pilot維護(hù)一個(gè)獨(dú)立于底層平臺(tái)的服務(wù)網(wǎng)格，所有的服務(wù)都通過Envoy 加入服務(wù)風(fēng)格中。Pilot中的Platform Adapter 負(fù)責(zé)適當(dāng)?shù)靥畛浯艘?guī)范模型。 例如，Pilot中的Kubernetes適配器實(shí)現(xiàn)必要的controllers，以觀察Kubernetes API server以更改pod注冊(cè)信息、ingress 資源和存儲(chǔ)流量管理規(guī)則的第三方資源。 這些數(shù)據(jù)被翻譯成規(guī)范的表示。Envoy的配置是基于規(guī)范表（canonical representation）示生成的。

Pilot公開了用于 服務(wù)發(fā)現(xiàn) 的API，可動(dòng)態(tài)更新負(fù)載平衡池和路由表。這些API將Envoy與平臺(tái)特定的細(xì)微差別分離開來，簡(jiǎn)化了設(shè)計(jì)并提高了跨平臺(tái)的可移植性。

運(yùn)維可以通過Pilot的規(guī)則API指定高級(jí)流量管理規(guī)則。 這些規(guī)則被轉(zhuǎn)換成低級(jí)（low-level）配置并通過discovery API分發(fā)給Envoy實(shí)例。

Request Routing（請(qǐng)求路由）

描述如何在Istio服務(wù)網(wǎng)格中的服務(wù)之間路由請(qǐng)求。

服務(wù)模型和服務(wù)版本

如Pilot所述，服務(wù)網(wǎng)格中服務(wù)的規(guī)范表示是由Pilot維護(hù)的。服務(wù)的Istio模型與其在底層平臺(tái)（Kubernetes，Mesos，Cloud Foundry等）中的表現(xiàn)方式無關(guān)。平臺(tái)相關(guān)的適配器負(fù)責(zé)使用平臺(tái)中的元數(shù)據(jù)填充Istio內(nèi)部模型。

Istio引入了服務(wù)版本的概念，該版本是按版本(v1, v2)或環(huán)境(staging, prod)細(xì)分服務(wù)實(shí)例的更細(xì)化的方式。 這些變體不一定是不同的API版本：它們可能是對(duì)同一服務(wù)的迭代更改，部署在不同的環(huán)境中（prod，staging，dev等）。 常用的場(chǎng)景包括A/B測(cè)試或金絲雀發(fā)布。 Istio的流量路由規(guī)則可以指服務(wù)版本，以提供對(duì)服務(wù)之間流量的額外控制。

服務(wù)之間的通信

如上圖所示，client不知道服務(wù)的不同版本。他們可以繼續(xù)使用服務(wù)的主機(jī)名/IP地址訪問服務(wù)。 Envoy sidecar/proxy 攔截并轉(zhuǎn)發(fā)client和服務(wù)之間的所有請(qǐng)求/響應(yīng)。

Envoy 根據(jù)運(yùn)運(yùn)維人員使用Pilot指定的路由規(guī)則動(dòng)態(tài)確定其實(shí)際服務(wù)版本。該模型使應(yīng)用程序代碼能夠?qū)⑵渥陨韽钠湎嚓P(guān)服務(wù)的演變中分離出來，同時(shí)還提供其他好處（請(qǐng)參Mixer）。 路由規(guī)則允許Envoy根據(jù)標(biāo)準(zhǔn)選擇版本，例如headers，與source/destination關(guān)聯(lián)的標(biāo)簽，分配給每個(gè)版本的權(quán)重。

Istio還為流量提供相同服務(wù)版本的多個(gè)實(shí)例的負(fù)載平衡。 您可以在Discovery和Load-Balancing中找到更多關(guān)于此的信息。

Istio不提供DNS。 應(yīng)用程序可以嘗試使用底層平臺(tái)中存在的DNS服務(wù)（kube-dns，mesos-dns等）來解析FQDN。

Ingress 和 egress

Istio假設(shè)進(jìn)入和離開服務(wù)網(wǎng)格的所有流量都通過Envoy代理。通過在服務(wù)前面部署Envoy代理，運(yùn)維人員可以進(jìn)行A/B測(cè)試，金絲雀部署服務(wù)等，以用于面向用戶的服務(wù)。 同樣，運(yùn)維人員可以通過sidecar Envoy將流量路由到外部Web服務(wù)（例如，訪問Maps API或視頻服務(wù)API），從而增加故障恢復(fù)功能，例如超時(shí)，重試，斷路器等，并獲取詳細(xì)信息 有關(guān)這些服務(wù)連接的度量標(biāo)準(zhǔn)。

服務(wù)發(fā)現(xiàn)和負(fù)載均衡

本節(jié)介紹Istio如何負(fù)載均衡服務(wù)網(wǎng)格中服務(wù)實(shí)例間的流量。

服務(wù)注冊(cè)：Istio假設(shè)存在一個(gè)服務(wù)注冊(cè)中心，以跟蹤應(yīng)用程序中服務(wù)的Pod/VM。它還假設(shè)新的服務(wù)實(shí)例會(huì)自動(dòng)注冊(cè)到服務(wù)注冊(cè)中心，不健康的實(shí)例會(huì)被自動(dòng)刪除。Kubernetes，Mesos等平臺(tái)已經(jīng)為基于容器的應(yīng)用程序提供了這樣的功能。 基于VM的應(yīng)用程序存在過多的解決方案。

服務(wù)發(fā)現(xiàn)：Pilot 使用來自服務(wù)注冊(cè)中心的信息并提供與平臺(tái)無關(guān)的服務(wù)發(fā)現(xiàn)接口。Mesh中的Envoy實(shí)例執(zhí)行服務(wù)發(fā)現(xiàn)并相應(yīng)地動(dòng)態(tài)更新其負(fù)載均衡池。

如上圖所示，網(wǎng)格中的服務(wù)使用其DNS名稱相互訪問。 綁定到服務(wù)的所有HTTP流量都會(huì)通過Envoy自動(dòng)重新路由。 Envoy 在負(fù)載均衡池中的實(shí)例之間分配流量。 雖然Envoy支持多種復(fù)雜的負(fù)載均衡算法，但I(xiàn)stio目前允許三種負(fù)載均衡模式：輪詢，隨機(jī)和權(quán)重最小請(qǐng)求。

除了負(fù)載平衡之外，Envoy還會(huì)定期檢查負(fù)載均衡池中每個(gè)實(shí)例的健康狀況。Envoy遵循斷路器配置模式，根據(jù)健康檢查API調(diào)用的故障率將實(shí)例歸類為健康或不健康。 換句話說，當(dāng)給定實(shí)例的狀況檢查失敗次數(shù)超過預(yù)先指定的閾值時(shí)，它將從負(fù)載均衡池中移除。類似地，當(dāng)運(yùn)行狀況檢查數(shù)超過預(yù)先指定的健康閾值時(shí)，實(shí)例將被添加回負(fù)載均衡池。 你可以在處理故障中找到有關(guān)Envoy故障處理功能的更多信息。

服務(wù)可以通過HTTP 503響應(yīng)健康檢查來積極減輕負(fù)載。 在這種情況下，服務(wù)實(shí)例將立即從調(diào)用者的負(fù)載平衡池中移除。

故障處理

Envoy提供了一套開箱即用的插拔式故障恢復(fù)功能，可以在應(yīng)用程序中利用這些功能。功能包括：

1. 超時(shí)

2. 根據(jù)超時(shí)時(shí)間和重試次數(shù)、間隔等配置進(jìn)行重試

3. 并發(fā)連接數(shù)和對(duì)上游服務(wù)的請(qǐng)求限制

4. 對(duì)負(fù)載均衡池的每個(gè)成員進(jìn)行主動(dòng)（定期）健康檢查

5. 針對(duì)負(fù)載平衡池中針對(duì)每個(gè)實(shí)例應(yīng)用的細(xì)粒度斷路器（被動(dòng)健康檢查）

這些功能可以在運(yùn)行時(shí)通過Istio的流量管理規(guī)則進(jìn)行動(dòng)態(tài)配置。

重試之間的抖動(dòng)使重試對(duì)超負(fù)載的上游服務(wù)的影響最小，而超時(shí)設(shè)置可確保調(diào)用服務(wù)在可預(yù)測(cè)的時(shí)間范圍內(nèi)獲得響應(yīng)（成功/失敗）。

主動(dòng)和被動(dòng)健康檢查（上述4和5）的組合可最大限度地減少訪問負(fù)載均衡池中不健康實(shí)例的機(jī)會(huì)。與平臺(tái)級(jí)健康檢查（如Kubernetes或Mesos支持的那些）結(jié)合使用時(shí)，應(yīng)用程序可以確保不健康的pods/容器/虛擬機(jī)可以快速服務(wù)網(wǎng)格中清除，從而最大限度地減少請(qǐng)求失敗并減少對(duì)延遲的影響。

這些功能一起使服務(wù)網(wǎng)格能夠容忍失敗的nodes ，并防止由于級(jí)聯(lián)不穩(wěn)定而導(dǎo)致本地故障影響到其他nodes。

微調(diào)

Istio的流量管理規(guī)則允許運(yùn)維為每個(gè)服務(wù)/版本的故障恢復(fù)設(shè)置全局默認(rèn)值。但是，服務(wù)的使用者也可以通過特殊的HTTP頭提供請(qǐng)求級(jí)覆蓋來覆蓋超時(shí)和重試默認(rèn)值。 通過Envoy代理實(shí)現(xiàn)，頭文件分別是 x-envoy-upstream-rq-timeout-ms 和 x-envoy-max-retries。

FAQ

Q: 在Istio中運(yùn)行時(shí)，應(yīng)用程序是否還能處理失??？

可以。 Istio提高了網(wǎng)格中服務(wù)的可靠性和可用性。但是，應(yīng)用程序需要處理失敗（錯(cuò)誤）并采取適當(dāng)?shù)暮髠洌╢allback）操作。例如，當(dāng)負(fù)載平衡池中的所有實(shí)例都失敗時(shí)，Envoy將返回HTTP 503.應(yīng)用程序負(fù)責(zé)處理來自上游服務(wù)的HTTP 503錯(cuò)誤。

Q: Envoy的故障恢復(fù)功能是否會(huì)中斷已使用容錯(cuò)庫（例如Hystrix）的應(yīng)用程序？

不會(huì)。Envoy 對(duì)應(yīng)用是完全透明的。由Envoy返回的失敗響應(yīng)與由進(jìn)行調(diào)用的上游服務(wù)返回的失敗響應(yīng)無法區(qū)分。

Q: 在同時(shí)使用應(yīng)用程序級(jí)類庫和Envoy時(shí)如何處理失?。?/strong>

給同一個(gè)服務(wù)的兩個(gè)故障恢復(fù)策略（例如，兩個(gè)超時(shí) - 一個(gè)設(shè)置在Envoy中，另一個(gè)設(shè)置在應(yīng)用程序的庫中），當(dāng)故障發(fā)生時(shí)，兩個(gè)限制中較強(qiáng)的將會(huì)被觸發(fā)。 例如，如果應(yīng)用程序?yàn)榉?wù)的API調(diào)用設(shè)置5秒的超時(shí)，而操作員配置了10秒的超時(shí)，則應(yīng)用程序的超時(shí)將首先啟動(dòng)。 同樣，如果Envoy的斷路器在應(yīng)用程序的斷路器之前觸發(fā)，API調(diào)用服務(wù)將從Envoy獲得503。

故障注入

雖然Envoy sidecar/proxy為運(yùn)行在Istio上的服務(wù)提供了大量故障恢復(fù)機(jī)制，但仍然有必要測(cè)試整個(gè)應(yīng)用程序的端到端故障恢復(fù)能力。 錯(cuò)誤配置的故障恢復(fù)策略（例如，跨服務(wù)調(diào)用的不兼容/限制性超時(shí)）可能導(dǎo)致應(yīng)用程序中關(guān)鍵服務(wù)持續(xù)不可用，從而導(dǎo)致用戶體驗(yàn)不佳。

Istio支持將指定協(xié)議的故障注入到網(wǎng)絡(luò)中，而不是殺死Pod，延遲或破壞TCP層的數(shù)據(jù)包。 我們的基本原理是，無論網(wǎng)絡(luò)級(jí)別失敗，應(yīng)用層觀察到的失敗都是相同的，并且可以在應(yīng)用層注入更有意義的失敗（例如，HTTP錯(cuò)誤代碼）以增加應(yīng)用程序的彈性。

運(yùn)維人員可以配置故障注入到符合特定標(biāo)準(zhǔn)的請(qǐng)求中。運(yùn)維可以進(jìn)一步限制應(yīng)該發(fā)生故障的請(qǐng)求的百分比?？梢宰⑷雰煞N類型的故障：延遲和中止。延遲是定時(shí)失敗，模仿網(wǎng)絡(luò)延遲增加或上游服務(wù)超負(fù)荷。中止是模仿上游服務(wù)故障的崩潰故障。 中止通常以HTTP錯(cuò)誤代碼或TCP連接失敗的形式出現(xiàn)。

有關(guān)更多詳細(xì)信息，請(qǐng)參閱下一節(jié)Istio的流量管理規(guī)則。

規(guī)則配置

Istio提供了一個(gè)簡(jiǎn)單的配置模型來控制API調(diào)用和第4層流量如何在應(yīng)用程序中的各種服務(wù)之間流動(dòng)。配置模型允許運(yùn)維配置服務(wù)級(jí)屬性，如斷路器，超時(shí)，重試，以及設(shè)置常見的持續(xù)部署任務(wù)，如金絲雀部署，A/B測(cè)試，基于百分比流量的分階段發(fā)布等。

例如，可以使用以下配置將reviews服務(wù)的傳入流量的100％發(fā)送到版本“v1”：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1

該配置表示發(fā)送到reviews服務(wù)（在hosts 字段中指定）的流量應(yīng)該路由到reviews服務(wù)實(shí)例的v1子集中。 路由subset 在相應(yīng)的目標(biāo)規(guī)則配置中指定定義的子集的名稱：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

subset 指定一個(gè)或多個(gè)標(biāo)識(shí)版本實(shí)例的標(biāo)簽。例如，在Istio的Kubernetes部署中，“version：v1”表示只有包含“version：v1”標(biāo)簽的pod才會(huì)接收流量。

可以使用istioctl CLI配置規(guī)則，也可以使用kubectl命令在Kubernetes deployment 中配置規(guī)則，但只有istioctl 會(huì)驗(yàn)證配置是否正確，我們建議使用istioctl 。 有關(guān)示例，請(qǐng)參閱配置請(qǐng)求路由任務(wù)。

Istio中有四種流量管理配置資源：VirtualService，DestinationRule，ServiceEntry和Gateway。 下面介紹使用這些資源的一些重要方面。詳細(xì)信息請(qǐng)參閱參考。

Virtual Services

VirtualService定義了控制服務(wù)請(qǐng)求如何在Istio服務(wù)網(wǎng)格中路由的規(guī)則。例如，virtual service可以將請(qǐng)求路由到不同版本的服務(wù)，或者實(shí)際上可以將請(qǐng)求路由到完全不同的服務(wù)。 請(qǐng)求可以根據(jù)請(qǐng)求源和目標(biāo)、HTTP路徑和header 字段以及與各個(gè)服務(wù)版本相關(guān)的權(quán)重進(jìn)行路由。

Rule destinations

路由規(guī)則對(duì)應(yīng)于VirtualService配置中指定的一個(gè)或多個(gè)請(qǐng)求目標(biāo)hosts。 這些hosts可能與實(shí)際的目標(biāo)工作負(fù)載相同也可能不同，甚至可能沒有對(duì)應(yīng)網(wǎng)格中的實(shí)際可路由服務(wù)。例如，要使用其內(nèi)部網(wǎng)格名稱reviews 或通過hostbookinfo.com為請(qǐng)求評(píng)論服務(wù)定義路由規(guī)則，VirtualService可以有一個(gè)hosts字段，如下所示：

hosts:
  - reviews
  - bookinfo.com

hosts字段隱式或顯式指定一個(gè)或多個(gè)全限定域名（FQDN）。上面的短名稱reviews將隱式擴(kuò)展為FQDN。 例如，在Kubernetes環(huán)境中，reviews完整的域名為來自VirtualSevice的集群和名稱空間（例如，reviews.default.svc.cluster.local）。

通過source/headers 來限定規(guī)則

Rules 可以選擇性地限定為僅適用于匹配某些特定條件的請(qǐng)求，例如以下條件：

1. 限制為特定調(diào)用者。 例如，Rules 可以指定ratings僅適用于來自reviews 服務(wù)（pods）的的調(diào)用。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
      sourceLabels:
        app: reviews
    ...

sourceLabels 的值取決于service的實(shí)現(xiàn)。 例如，在Kubernetes中，它可能與相應(yīng)Kubernetes 中pod選擇器中使用的標(biāo)簽相同。

2. 限制為特定版本的調(diào)用者。 例如，以下規(guī)則將之前示例限定為僅允許reviews 服務(wù)“v2”版本的調(diào)用。

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

3. 根據(jù)HTTP headers選擇規(guī)則。 例如，以下規(guī)則僅適用于包含字符串“user = jason”的“cookie”頭的請(qǐng)求。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - match:
    - headers:
        cookie:
          regex: "^(.*?;)?(user=jason)(;.*)?$"
    ...

如果配置了多個(gè)header，則必須所有的header全部匹配才可以。

可以同時(shí)設(shè)置多個(gè)標(biāo)準(zhǔn)。 在這種情況下，根據(jù)嵌套情況，使用AND或OR語義。 如果多個(gè)條件嵌套在單個(gè)匹配子句中，則條件為ANDed。 例如，以下規(guī)則僅適用于請(qǐng)求的來源為“reviews:v2”且包含“user = jason”的“cookie”的情況。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - sourceLabels:
        app: reviews
        version: v2
      headers:
        cookie:
          regex: "^(.*?;)?(user=jason)(;.*)?$"
    ...

相反，如果條件顯示在單獨(dú)的匹配條件中，則有一個(gè)匹配即可（OR語義）：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - sourceLabels:
        app: reviews
        version: v2
    - headers:
        cookie:
          regex: "^(.*?;)?(user=jason)(;.*)?$"
    ...

在服務(wù)版本之間拆分流量

每條路由規(guī)則標(biāo)識(shí)一個(gè)或多個(gè)加權(quán)后端，以便在規(guī)則激活時(shí)進(jìn)行調(diào)用。每個(gè)后端對(duì)應(yīng)于目標(biāo)服務(wù)的特定版本，其中版本可以使用標(biāo)簽表示。如果多個(gè)已注冊(cè)實(shí)例有相同的標(biāo)簽，則根據(jù)配置的負(fù)載平衡策略進(jìn)行路由，默認(rèn)為循環(huán)。

例如，以下規(guī)則將reviews 服務(wù)的25％流量路由到具有“v2”標(biāo)簽的實(shí)例，剩余流量（即75％）路由到“v1”。

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

超時(shí)和重試

默認(rèn)情況下，http請(qǐng)求的超時(shí)時(shí)間為15秒，但是這可以在路由規(guī)則中配置，如下所示：

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

也可以在路由規(guī)則中配置http請(qǐng)求的重試次數(shù)。 在超時(shí)期限內(nèi)，最大嘗試次數(shù)或盡可能多的嘗試次數(shù)可以設(shè)置如下：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
    - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    retries:
      attempts: 3
      perTryTimeout: 2s

請(qǐng)注意，請(qǐng)求超時(shí)和重試也可以基于每個(gè)請(qǐng)求進(jìn)行配置。

請(qǐng)參閱請(qǐng)求超時(shí)任務(wù)以了解超時(shí)控制的示例。

注入請(qǐng)求路徑中的錯(cuò)誤

路由規(guī)則可以指定一個(gè)或多個(gè)故障注入（人為制造故障），同時(shí)將http請(qǐng)求轉(zhuǎn)發(fā)到規(guī)則的相應(yīng)請(qǐng)求目標(biāo)。 故障可以是延遲或中止。

以下示例將向微服務(wù)ratings “v1”版本的10％請(qǐng)求中引入5秒延遲。

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

另一種類型的故障，中止，可用于模擬請(qǐng)求中斷故障。

以下示例會(huì)將ratings 服務(wù)“v1”版本10％請(qǐng)求的HTTP請(qǐng)求返回 400錯(cuò)誤代碼。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      abort:
        percent: 10
        httpStatus: 400
    route:
    - destination:
        host: ratings
        subset: v1

有時(shí)延遲和中止故障一起使用。例如，以下規(guī)則將從reviews 服務(wù)“v2”到評(píng)ratings 服務(wù)“v1”的所有請(qǐng)求延遲5秒，然后中止10％：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - sourceLabels:
        app: reviews
        version: v2
    fault:
      delay:
        fixedDelay: 5s
      abort:
        percent: 10
        httpStatus: 400
    route:
    - destination:
        host: ratings
        subset: v1

要查看故障注入的實(shí)際情況，請(qǐng)參閱故障注入任務(wù)。

HTTP路由規(guī)則優(yōu)先級(jí)

當(dāng)給定destination有多個(gè)規(guī)則時(shí)，它們按照它們?cè)赩irtualService中出現(xiàn)的順序進(jìn)行評(píng)估，即列表中的第一個(gè)規(guī)則具有最高優(yōu)先級(jí)。

為什么優(yōu)先級(jí)重要？ 如果服務(wù)的路由規(guī)則純粹是基于權(quán)重的時(shí)候，就可以在單個(gè)規(guī)則中配置它。但是，當(dāng)使用其他標(biāo)準(zhǔn)（例如，來自特定用戶的請(qǐng)求）來路由流量時(shí)，需要多個(gè)規(guī)則來配置路由。這里必須仔細(xì)考慮規(guī)則優(yōu)先級(jí)，以確保以正確的順序執(zhí)行規(guī)則。

通用路由規(guī)范的一種常見模式是提供一個(gè)或多個(gè)優(yōu)先級(jí)更高的規(guī)則，以便通過source/headers來限定規(guī)則，然后提供一個(gè)沒有匹配條件的單個(gè)基于權(quán)重的規(guī)則，最后為所有其他情況提供流量的加權(quán)分配。

例如，以下VirtualService包含2個(gè)規(guī)則，這些規(guī)則一起指定包含名為“Foo”且值為“bar”的header的reviews服務(wù)的所有請(qǐng)求都將發(fā)送到“v2”實(shí)例。 所有其余的請(qǐng)求將被發(fā)送到“v1”。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        Foo:
          exact: bar
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

請(qǐng)注意，這里配置中基于header的規(guī)則具有更高的優(yōu)先級(jí)。如果它較低，這些規(guī)則將不會(huì)如預(yù)期的那樣工作，因?yàn)榛跈?quán)重的規(guī)則（沒有特定的匹配標(biāo)準(zhǔn)）將首先被評(píng)估，然后將所有流量簡(jiǎn)單地路由到“v1”，甚至包括匹配的“Foo “頭。一旦找到適用于傳入請(qǐng)求的規(guī)則，它將被執(zhí)行并且規(guī)則評(píng)估過程將終止。 這就是為什么當(dāng)存在多個(gè)規(guī)則時(shí)仔細(xì)考慮每個(gè)規(guī)則的優(yōu)先級(jí)是非常重要的。

Destination Rules

DestinationRule配置在虛擬服務(wù)路由發(fā)生后，應(yīng)用于請(qǐng)求的一組策略。它們由服務(wù)所有者去配置定義，描述斷路器，負(fù)載平衡器設(shè)置，TLS設(shè)置等。

DestinationRule還定義相應(yīng)目的地主機(jī)的可尋址子集（即，版本名）。 在將流量發(fā)送到特定版本的服務(wù)時(shí)，這些子集用于VirtualService路由規(guī)范。

以下DestinationRule 配置reviews 服務(wù)的策略和subsets ：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  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

請(qǐng)注意，可以在單個(gè)DestinationRule配置中指定多個(gè)策略（例如，默認(rèn)和v2）。

斷路器

可以根據(jù)許多標(biāo)準(zhǔn)（例如連接和請(qǐng)求限制）設(shè)置簡(jiǎn)單的斷路器。

例如，以下DestinationRule設(shè)置了與reviews 服務(wù)版本“v1”后端限制100個(gè)連接。

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

查看斷路器控制的斷路任務(wù)演示。

DestinationRule evaluation

與路由規(guī)則類似，策略與特定host相關(guān)聯(lián)，但是如果它們配置了子集，則激活哪個(gè)取決于路由規(guī)則評(píng)估結(jié)果。

規(guī)則評(píng)估過程中的第一步評(píng)估與所請(qǐng)求的主機(jī)相對(duì)應(yīng)的VirtualService中的路由規(guī)則（如果定義了），以確定當(dāng)前請(qǐng)求將被路由到的目的地服務(wù)的subset （即，特定版本）。 接下來，評(píng)估與所選子集相對(duì)應(yīng)的一組策略，以確定它們是否適用。

注意：要牢記算法的一個(gè)細(xì)微之處在于，只有在相應(yīng)的子集被明確路由到時(shí)才會(huì)應(yīng)用為特定子集定義的策略。 例如，考慮以下配置，作為為評(píng)論服務(wù)定義的唯一規(guī)則（即相應(yīng)虛擬服務(wù)中沒有路由規(guī)則） 。

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

由于沒有為reviews 服務(wù)定義特定的路由規(guī)則，因此將應(yīng)用默認(rèn)的循環(huán)路由行為，有時(shí)可能會(huì)調(diào)用“v1”實(shí)例，如果“v1”是唯一正在運(yùn)行的版本，甚至可能始終會(huì)調(diào)用“v1”實(shí)例。 不過，由于默認(rèn)路由是在較低級(jí)別完成的，因此不會(huì)調(diào)用上述策略。 規(guī)則評(píng)估引擎將不知道最終目標(biāo)，因此無法將子集策略與請(qǐng)求匹配。

你可以通過以下兩種方式之一修復(fù)上述示例。你可以將流量策略向上移動(dòng)一個(gè)級(jí)別以適用于任何版本：

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

或者更好的是，為服務(wù)定義合適的路由規(guī)則。 例如，您可以為“reviews:v1”添加簡(jiǎn)單的路由規(guī)則。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1

雖然默認(rèn)的Istio行為可以不設(shè)置任何規(guī)則就方便地將流量從任何源發(fā)送到目標(biāo)服務(wù)的所有版本，但只要需要版本區(qū)分，就需要規(guī)則。 因此，最佳做法是從一開始就為每項(xiàng)服務(wù)設(shè)置默認(rèn)規(guī)則。

Service Entries

ServiceEntry用于將其他條目添加到Istio內(nèi)部維護(hù)的服務(wù)注冊(cè)表中。 它最常用于啟用Istio服務(wù)網(wǎng)格外服務(wù)的請(qǐng)求。 例如，以下ServiceEntry可用于允許對(duì)* .foo.com域名下托管的服務(wù)進(jìn)行外部調(diào)用。

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

ServiceEntry的目標(biāo)是使用hosts字段指定的，該字段可以是完全限定的域名或通配符域名。 它表示允許服務(wù)網(wǎng)格中的服務(wù)訪問的一個(gè)或多個(gè)服務(wù)的白名單中。

ServiceEntry不限于外部服務(wù)配置，它可以有兩種類型：網(wǎng)格內(nèi)部或網(wǎng)格外部。 網(wǎng)格內(nèi)部條目與所有其他內(nèi)部服務(wù)一樣，但用于向網(wǎng)格顯式添加服務(wù)。 它們可用于添加服務(wù)，作為擴(kuò)展服務(wù)網(wǎng)格以包含非托管基礎(chǔ)架構(gòu)（例如，添加到基于Kubernetes的服務(wù)網(wǎng)格的VM）的一部分。 網(wǎng)格外部條目代表網(wǎng)格外部的服務(wù)。 對(duì)于他們來說，mTLS身份驗(yàn)證被禁用，并且在客戶端執(zhí)行策略實(shí)施，而不是在通常的服務(wù)器端執(zhí)行內(nèi)部服務(wù)請(qǐng)求。

只要服務(wù)條目使用匹配的hosts引用服務(wù)，服務(wù)條目就可以與虛擬服務(wù)和目標(biāo)規(guī)則配合使用。 例如，可以將以下規(guī)則與上述ServiceEntry規(guī)則結(jié)合使用，以便在bar.foo.com上為外部服務(wù)的呼叫設(shè)置10秒超時(shí)。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bar-foo-ext-svc
spec:
  hosts:
    - bar.foo.com
  http:
  - route:
    - destination:
        host: bar.foo.com
    timeout: 10s

規(guī)則重定向和轉(zhuǎn)發(fā)流量，定義重試，超時(shí)和故障注入策略都支持外部地址。 然而，加權(quán)（基于版本）路由是不可以的，因?yàn)闆]有多個(gè)外部服務(wù)版本的概念。

查看出口任務(wù) 以獲取更多關(guān)于訪問外部服務(wù)的信息。

Gateways

網(wǎng)關(guān)為HTTP/TCP流量配置負(fù)載均衡器，通常在服務(wù)網(wǎng)格的邊緣運(yùn)行，以便為應(yīng)用程序啟用入口流量。

與Kubernetes Ingress不同，Istio Gateway僅配置網(wǎng)絡(luò)中L4-L6層的功能（例如，要暴露的端口，TLS配置）。 然后，用戶可以使用標(biāo)準(zhǔn)的Istio規(guī)則來控制HTTP請(qǐng)求，以及通過綁定VirtualService來控制進(jìn)入網(wǎng)關(guān)的TCP流量。

例如，以下網(wǎng)關(guān)配置負(fù)載均衡器，以允許主機(jī)bookinfo.com的外部https流量進(jìn)入網(wǎng)格：

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

要配置相應(yīng)的路由，必須為同一個(gè)主機(jī)定義一個(gè)VirtualService，并使用配置中的gateways 字段綁定到網(wǎng)關(guān)：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
    - bookinfo.com
  gateways:
  - bookinfo-gateway # <---- bind to gateway
  http:
  - match:
    - uri:
        prefix: /reviews
    route:
    ...

雖然主要用于管理入口流量，但也可以使用網(wǎng)關(guān)對(duì)純粹的內(nèi)部或出口代理進(jìn)行建模。無論內(nèi)部或外部網(wǎng)絡(luò)，所有網(wǎng)關(guān)都可以用相同的方式進(jìn)行配置和控制。

以上就是Istio流量管理的示例分析，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。