kubernetes實踐之七十：Istio之流量管理(上)

一：簡介

Istio流量管理的核心元件是Pilot,它管理和配置部署在特定Istio服務網格中的所有Envoy代理例項。它允許您指定在Envoy代理之間使用什麼樣的路由流量規則，並配置故障恢復功能，如超時，重試和熔斷器。它還維護了網格中所有服務的規範模型，並使用這個模型通過發現服務讓Envoy瞭解網格中的其它例項。每個Envoy例項都會維護負載均衡資訊，負載均衡資訊是基於從Pilo獲得的資訊，以及其負載均衡池中的其它例項的定期健康檢查。從而允許其在目標例項之間智慧分配流量，同時遵循其指定的路由規則。

二：流量管理的好處

使用 Istio 的流量管理模型，本質上是將流量與基礎設施擴容解耦，讓運維人員可以通過 Pilot 指定流量遵循什麼規則，而不是執行哪些 pod/VM 應該接收流量——Pilot 和智慧 Envoy 代理會幫我們搞定。因此，例如，您可以通過 Pilot 指定特定服務的 5％ 流量可以轉到金絲雀版本，而不必考慮金絲雀部署的大小，或根據請求的內容將流量傳送到特定版本

將流量從基礎設施擴充套件中解耦，這樣就可以讓 Istio 提供各種流量管理功能，這些功能在應用程式程式碼之外。除了 A/B 測試的動態請求路由，逐步推出和金絲雀釋出之外，它還使用超時、重試和熔斷器處理故障恢復，最後還可以通過故障注入來測試服務之間故障恢復策略的相容性。這些功能都是通過在服務網格中部署的 Envoy sidecar/代理來實現的。

Pilot 負責部署在 Istio 服務網格中的 Envoy 例項的生命週期管理。

如上圖所示，Pilot維護了網格中的服務的規範表示，這個表示是獨立於底層平臺的。Pilot中的平臺特定介面卡負責適當填充此規範模型。例如，Pilot中的Kubernetes介面卡實現必要的控制器來監控Kubernetes API server中pod註冊資訊，Ingress資源以及用於儲存流量管理規則的第三方資源的更改。該資料被翻譯成規範表示。Envoy特定配置是基於規範表示生成的。

Pilot公開了用於服務發現，負載均衡池和路由表的動態更新的API。這些API將Envoy從平臺特有的細微差別中解脫出來，簡化了設計並提升了跨平臺的可移植性。

運維人員可以通過Pilot的Rules API指定高階流量管理規則。這些規則被翻譯成低階配置，並通過discovery API分發到Envoy例項。

三：請求路由

如Pilot所述，特定網格中的服務的規範由Pilot維護。服務的Istio模型和在底層平臺（Kubernetes,Mesos以及Cloud Foundry等）中的表達無關。特定平臺的介面卡負責從各自平臺中獲取後設資料的各種欄位，然後對服務模型進行填充。Istio引入服務版本的概念，可以通過版本(v1,v2)或環境(staging,prod)對服務進行進一步的細分。這些版本不一定是不同的API版本：它們可能是部署在不同環境(prod,staging或者dev等)中的同一服務的不同迭代。使用這種方式的常見場景包括A/B測試或金絲雀部署。Istio的流量路由規則可以根據服務版本來對服務之間流量進行附加控制。

四：服務之間的通訊

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

運維人員使用 Pilot 指定路由規則，Envoy 根據這些規則動態地確定其服務版本的實際選擇。該模型使應用程式程式碼能夠將它從其依賴服務的演進中解耦出來，同時提供其他好處（參見 Mixer）。路由規則讓 Envoy 能夠根據諸如 header、與源/目的地相關聯的標籤和/或分配給每個版本的權重等標準來進行版本選擇。

Istio 還為同一服務版本的多個例項提供流量負載均衡。可以在服務發現和負載均衡中找到更多資訊。

Istio 不提供 DNS。應用程式可以嘗試使用底層平臺（kube-dns，mesos-dns 等）中存在的 DNS 服務來解析 FQDN。

五：服務發現和負載均衡

服務註冊： Istio假定存在服務登錄檔，以跟蹤應用程式中服務的pod/vm. 它還假設服務的新例項自動註冊到服務登錄檔，並且不健康的例項將會被自動刪除。諸如kubernetes,mesos等平臺已經為基於容器的應用程式提供了這樣的功能。

服務發現： Pilot使用來自服務註冊的資訊，並提供與平臺無關的服務發現介面。網格中的Envoy例項執行服務發現，並相應地動態更新其負載均衡池。

如上圖所示，網格中的服務使用其 DNS 名稱訪問彼此。服務的所有 HTTP 流量都會通過 Envoy 自動重新路由。Envoy 在負載均衡池中的例項之間分發流量。雖然 Envoy 支援多種複雜的負載均衡演算法，但 Istio 目前僅允許三種負載平衡模式：輪循、隨機和帶權重的最少請求。

除了負載均衡外，Envoy 還會定期檢查池中每個例項的執行狀況。Envoy 遵循熔斷器風格模式，根據健康檢查 API 呼叫的失敗率將例項分類為不健康或健康。換句話說，當給定例項的健康檢查失敗次數超過預定閾值時，它將從負載均衡池中彈出。類似地，當通過的健康檢查數超過預定閾值時，該例項將被新增回負載均衡池。您可以在處理故障中瞭解更多有關 Envoy 的故障處理功能。

服務可以通過使用 HTTP 503 響應健康檢查來主動減輕負擔。在這種情況下，服務例項將立即從呼叫者的負載均衡池中刪除。

六：故障處理

Envoy提供了一套開箱即用，可選的故障恢復功能，對應用中的服務大有裨益。這些功能包括：

1. 超時
   

2. 具備超時預算，並能夠在重試之間進行可變抖動(間隔)的有限重試功能

3. 併發連線數和上游服務請求數限制

4. 對負載均衡池中的每個成員進行主動（定期）執行健康檢查

5. 細粒度熔斷器（被動健康檢查）-適用於負載均衡池中的每個例項

6. 這些功能可以使用Istio的流量管理規則在執行時進行動態配置
   

七：微調

Istio 的流量管理規則允許運維人員為每個服務/版本設定故障恢復的全域性預設值。然而，服務的消費者也可以通過特殊的 HTTP 頭提供的請求級別值覆蓋超時和重試的預設值。在 Envoy 代理的實現中，對應的 Header 分別是 x-envoy-upstream-rq-timeout-ms 和 x-envoy-max-retries。

八：故障注入

雖然 Envoy sidecar/proxy 為在 Istio 上執行的服務提供了大量的故障恢復機制，但測試整個應用程式端到端的故障恢復能力依然是必須的。錯誤配置的故障恢復策略（例如，跨服務呼叫的不相容/限制性超時）可能導致應用程式中的關鍵服務持續不可用，從而破壞使用者體驗。

Istio 能在不殺死 Pod 的情況下，將協議特定的故障注入到網路中，在 TCP 層製造資料包的延遲或損壞。我們的理由是，無論網路級別的故障如何，應用層觀察到的故障都是一樣的，並且可以在應用層注入更有意義的故障（例如，HTTP 錯誤程式碼），以檢驗和改善應用的彈性。

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

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28624388/viewspace-2199996/，如需轉載，請註明出處，否則將追究法律責任。