kubernetes中實現Istio流量管理有什么好處

小編給大家分享一下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 連接失敗的形式表現。

以上是“kubernetes中實現Istio流量管理有什么好處”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！