第二部分 Istio流量管理概述

流量管理

使用 Istio 的流量管理模型，本質上是将流量與基礎設施擴容解耦，讓運維人員可以通過Pilot指定流量遵循什麼規則，而不是指定哪些 pod/VM 應該接收流量。例如，你可以将10%的流量轉發到測試版本服務，或根據請求的内容将流量發送到特定版本。如下圖所示：

将流量從基礎設施擴充中解耦，這樣就可以讓 Istio 提供各種獨立于應用程式代碼之外的流量管理功能。除了A/B測試的動态路由外，它還具有逾時、重試和熔斷等功能來處理故障，最後還可以通過故障注入來測試服務之間故障恢複政策的相容性。這些功能都是通過部署的Envoy/sidecar代理來實作的。

Pilot和Envoy

Istio流量管理核心元件是Pilot，它管理和配置部署在Istio服務中的所有Envory代理，它允許您指定在 Envoy 代理之間使用什麼樣的路由流量規則，并配置故障恢複功能，如逾時、重試和熔斷等。它還維護了所有Istio服務的規範模型，并使用這個模型通過發現服務讓 Envoy 了解網格中的其他執行個體。

每個 Envoy 執行個體都會維護負載均衡資訊資訊，這些資訊來自 Pilot 以及對負載均衡池中其他執行個體的定期健康檢查。進而允許其在目标執行個體之間智能配置設定流量，同時遵循其指定的路由規則。

Pilot 負責管理通過Istio服務中的Envoy執行個體的生命周期。Pilot架構圖如下：

如上圖所示，Pilot維護了一個服務規則表并獨立于底層平台。Pilot中的特定于平台的擴充卡負責适當地填充這個規範模型。如：在Pilot中的Kubernetes 擴充卡實作了必要的控制器，來觀察kubernetes API 伺服器，用于更改 pod 的注冊資訊、入口資源以及存儲流量管理規則的第三方資源。這些資料被轉換為規範表示。然後根據規範表示生成特定的 Envoy 的配置。

Pilot 公開了用于服務發現 、負載均衡池和路由表的動态更新的 API。

運維人員可以通過 Pilot 的 Rules API 指定進階流量管理規則。這些規則被翻譯成低級配置，并通過 discovery API 分發到 Envoy 執行個體。

請求路由

根據之前内容可知，Pilot維護Istio服務規範表。服務的 Istio 模型和在底層平台（Kubernetes、Mesos 以及 Cloud Foundry 等）中的表達無關。特定平台的擴充卡負責從各自平台中擷取中繼資料的各種字段，然後對服務模型進行填充。

Istio引入了服務版本的概念，可以通過版本（

v1

、

v2

）或環境（

staging

、

prod

）對服務進行進一步的細分。這些版本不一定是不同的 API 版本：它們可能是部署在不同環境（prod、staging 或者 dev 等）中的同一服務的不同疊代。例如：A/B測試或金絲雀部署。Istio 的流量路由規則可以根據服務版本來對服務之間流量進行附加控制。

服務間通訊

如上圖所示，服務的用戶端不知道服務不同版本間的差異。它們可以使用服務的主機名或者 IP 位址繼續通路服務。Envoy sidecar/代理攔截并轉發用戶端和伺服器之間的所有請求和響應。

運維人員使用Pilot指定路由規則，Envoy根據這些規則動态地确定實際的服務版本，如，Envoy可以根據規則中的header、标簽或權重等标準進行版本選擇。該模型使應用程式代碼能夠将它從其依賴服務的演進中解耦出來，同時還有諸多好處，下面具體讨論。

Istio 還為同一服務版本的多個執行個體提供流量負載均衡。Istio 不提供 DNS，應用程式可以使用底層平台的DNS服務，如kubernetes平台的CoreDNS等。

Ingress 和 Egress

Istio假定進站流量和出站流量都會通過Envoy代理進行傳輸。通過将Envoy代理部署在服務之前，運維人員可以通過使用者的服務進行A/B測試、部署金絲雀服務等。比如，運維人員通過Pilot編寫路由規則，由Envoy解析和應用該規則将流量路由到外部Web服務，當然，運維人員也可以為這些服務添加逾時、熔斷和重試等功能，同時也可以從服務連接配接中擷取各種細節名額。流量流如下圖所示：

服務發現和負載均衡

Istio假定存在服務系統資料庫，來跟蹤應用程式中服務的 pod/VM。它還假定新的服務将被注冊到服務系統資料庫中，并且不健康的執行個體被自動删除。如Kubernetes、Mesos 等平台已經為基于容器的應用程式提供了這樣的功能。

Pilot使用服務注冊資訊，并提供與平台無關的服務發現接口。Istio中的Envoy執行個體執行服務發現，并相應地動态更新其負載均衡池。

如上圖所示，網格中的服務使用其 DNS 名稱通路彼此。服務所有的HTTP流量都會通過Envoy自動重新路由。Envoy在負載均衡池中的執行個體之間分發流量，雖然 Envoy 支援多種複雜的負載均衡算法，但 Istio 目前僅允許三種負載均衡模式：

• 輪詢
• 随機
• 權重

除了負載均衡外，Envoy 還會定期檢查池中每個執行個體的運作狀況。Envoy 遵循熔斷器風格模式，根據健康檢查 API 調用的失敗率将執行個體分為健康和不健康兩種。換句話說，當給定執行個體的健康檢查失敗次數超過預定門檻值時，将會被從負載均衡池中移除，同理，失敗次數低于預定門檻值時，該執行個體将被添加回負載均衡池。

服務可以通過使用 HTTP 503 響應健康檢查來主動減輕負擔。在這種情況下，服務執行個體将立即從調用者的負載均衡池中删除。

故障處理

Envoy提供了一套可選的故障恢複功能，主要包括：

1、逾時處理

2、重試處理

3、請求數限制，即限流

4、對負載均衡器中每個成員主動（定期）運作健康檢查

5、細粒度熔斷器，被動的去檢查服務

以上功能都可以使用Istio的流量管理規則在運作時動态配置，主動和被動健康檢查（上述 4 和 5 ）的組合最大限度地減少了在負載均衡池中通路不健康執行個體的機會。當将其與平台級健康檢查（例如由 Kubernetes 或 Mesos 支援的檢查）相結合時， 可以確定應用程式将不健康的 Pod/容器/虛拟機快速地從服務網格中去除，進而最小化請求失敗和延遲産生影響。

總之，以上功能，都有利于故障排查和修複，提高服務運作的穩定性。

微調

Istio 的流量管理規則允許運維人員為每個服務/版本設定故障恢複的全局預設值。然而，服務的消費者也可以通過特殊的 HTTP 頭提供的請求級别值覆寫逾時和重試的預設值。在 Envoy 代理的實作中，對應的 Header 分别是

x-envoy-upstream-rq-timeout-ms

和

x-envoy-max-retries

。

故障注入

雖然Envoy sidecar/proxy 為Istio上運作的服務提供了大量的故障恢複機制，但測試整個應用程式端到端的故障恢複能力依然是必須的。錯誤配置的故障恢複政策

，

可能導緻應用程式中的關鍵服務持續不可用，進而破壞使用者體驗。

Istio 能在不殺死 Pod 的情況下，将特定協定的故障注入到網絡中，應用層觀察到的故障都是一樣的，并且可以在應用層注入更有意義的故障，以檢驗和改善應用的彈性。

運維人員可以為符合特定條件的請求配置故障，還可以進一步限制遭受故障的請求的百分比。可以注入兩種類型的故障：延遲和中斷。延遲是計時故障，模拟網絡延遲上升或上遊服務超載的情況。中斷是模拟上遊服務的崩潰故障。中斷通常以 HTTP 錯誤代碼或 TCP 連接配接失敗的形式表現。