使用雲平臺能夠爲組織提供豐富的好處。然而,不能否認的是,採用雲可能會給 DevOps 團隊帶來壓力。開發人員必須使用微服務已知足應用的可移植性,同時運營商管理了極其龐大的混合和多雲部署。Istio 容許您鏈接、保護、控制和觀測服務。git
在較高的層次上,Istio 有助於下降這些部署的複雜性,並減輕開發團隊的壓力。它是一個徹底開源的服務網格,能夠透明地分層到現有的分佈式應用程序上。它也是一個平臺,包括容許它集成到任何日誌記錄平臺、遙測或策略系統的 API。Istio 的多樣化功能集使您可以成功高效地運行分佈式微服務架構,並提供保護、鏈接和監控微服務的統一方法。github
在從單體應用程序向分佈式微服務架構的轉型過程當中,開發人員和運維人員面臨諸多挑戰,使用 Istio 能夠解決這些問題。編程
服務網格(Service Mesh)這個術語一般用於描述構成這些應用程序的微服務網絡以及應用之間的交互。隨着規模和複雜性的增加,服務網格愈來愈難以理解和管理。它的需求包括服務發現、負載均衡、故障恢復、指標收集和監控以及一般更加複雜的運維需求,例如 A/B 測試、金絲雀發佈、限流、訪問控制和端到端認證等。後端
Istio 提供了一個完整的解決方案,經過爲整個服務網格提供行爲洞察和操做控制來知足微服務應用程序的多樣化需求。api
Istio 提供一種簡單的方式來爲已部署的服務創建網絡,該網絡具備負載均衡、服務間認證、監控等功能,而不須要對服務的代碼作任何改動。想要讓服務支持 Istio,只須要在您的環境中部署一個特殊的 sidecar 代理,使用 Istio 控制平面功能配置和管理代理,攔截微服務之間的全部網絡通訊:安全
Istio 旨在實現可擴展性,知足各類部署需求。網絡
Istio 在服務網絡中統一提供了許多關鍵功能:架構
經過簡單的規則配置和流量路由,您能夠控制服務之間的流量和 API 調用。Istio 簡化了斷路器、超時和重試等服務級別屬性的配置,而且能夠輕鬆設置 A/B測試、金絲雀部署和基於百分比的流量分割的分階段部署等重要任務。併發
經過更好地瞭解您的流量和開箱即用的故障恢復功能,您能夠在問題出現以前先發現問題,使調用更可靠,而且使您的網絡更增強大——不管您面臨什麼條件。負載均衡
Istio 的安全功能使開發人員能夠專一於應用程序級別的安全性。Istio 提供底層安全通訊信道,並大規模管理服務通訊的認證、受權和加密。使用Istio,服務通訊在默認狀況下是安全的,它容許您跨多種協議和運行時一致地實施策略——全部這些都不多或根本不須要應用程序更改。
雖然 Istio 與平臺無關,但將其與 Kubernetes(或基礎架構)網絡策略結合使用,其優點會更大,包括在網絡和應用層保護 pod 間或服務間通訊的能力。
Istio 強大的跟蹤、監控和日誌記錄可以讓您深刻了解服務網格部署。經過 Istio 的監控功能,能夠真正瞭解服務性能如何影響上游和下游的功能,而其自定義儀表板能夠提供對全部服務性能的可視性,並讓您瞭解該性能如何影響您的其餘進程。
Istio 的 Mixer 組件負責策略控制和遙測收集。它提供後端抽象和中介,將 Istio 的其他部分與各個基礎架構後端的實現細節隔離開來,併爲運維提供對網格和基礎架構後端之間全部交互的細粒度控制。
全部這些功能可讓您能夠更有效地設置、監控和實施服務上的 SLO。固然,最重要的是,您能夠快速有效地檢測和修復問題。
Istio 是獨立於平臺的,旨在運行在各類環境中,包括跨雲、內部部署、Kubernetes、Mesos 等。您能夠在 Kubernetes 上部署 Istio 或具備 Consul 的 Nomad 上部署。Istio 目前支持:
策略執行組件能夠擴展和定製,以便與現有的 ACL、日誌、監控、配額、審計等方案集成。
Istio 服務網格邏輯上分爲數據平面和控制平面。
下圖顯示了構成每一個面板的不一樣組件:
Istio 架構
Istio 使用 Envoy 代理的擴展版本,Envoy 是以 C++ 開發的高性能代理,用於調解服務網格中全部服務的全部入站和出站流量。Envoy 的許多內置功能被 istio 發揚光大,例如:
Envoy 被部署爲 sidecar,和對應服務在同一個 Kubernetes pod 中。這容許 Istio 將大量關於流量行爲的信號做爲屬性提取出來,而這些屬性又能夠在 Mixer 中用於執行策略決策,併發送給監控系統,以提供整個網格行爲的信息。
Sidecar 代理模型還能夠將 Istio 的功能添加到現有部署中,而無需從新構建或重寫代碼。能夠閱讀更多來了解爲何咱們在設計目標中選擇這種方式。
Mixer 是一個獨立於平臺的組件,負責在服務網格上執行訪問控制和使用策略,並從 Envoy 代理和其餘服務收集遙測數據。代理提取請求級屬性,發送到 Mixer 進行評估。有關屬性提取和策略評估的更多信息,請參見 Mixer 配置。
Mixer 中包括一個靈活的插件模型,使其可以接入到各類主機環境和基礎設施後端,從這些細節中抽象出 Envoy 代理和 Istio 管理的服務。
Pilot 爲 Envoy sidecar 提供服務發現功能,爲智能路由(例如 A/B 測試、金絲雀部署等)和彈性(超時、重試、熔斷器等)提供流量管理功能。它將控制流量行爲的高級路由規則轉換爲特定於 Envoy 的配置,並在運行時將它們傳播到 sidecar。
Pilot 將平臺特定的服務發現機制抽象化並將其合成爲符合 Envoy 數據平面 API 的任何 sidecar 均可以使用的標準格式。這種鬆散耦合使得 Istio 可以在多種環境下運行(例如,Kubernetes、Consul、Nomad),同時保持用於流量管理的相同操做界面。
Citadel 經過內置身份和憑證管理能夠提供強大的服務間和最終用戶身份驗證。可用於升級服務網格中未加密的流量,併爲運維人員提供基於服務標識而不是網絡控制的強制執行策略的能力。從 0.5 版本開始,Istio 支持基於角色的訪問控制,以控制誰能夠訪問您的服務。
Istio 的架構設計中有幾個關鍵目標,這些目標對於使系統可以應對大規模流量和高性能地服務處理相當重要。
最大化透明度:若想 Istio 被採納,應該讓運維和開發人員只需付出不多的代價就能夠從中受益。爲此,Istio 將自身自動注入到服務間全部的網絡路徑中。Istio 使用 sidecar 代理來捕獲流量,而且在儘量的地方自動編程網絡層,以路由流量經過這些代理,而無需對已部署的應用程序代碼進行任何改動。在 Kubernetes中,代理被注入到 pod 中,經過編寫 iptables 規則來捕獲流量。注入 sidecar 代理到 pod 中而且修改路由規則後,Istio 就可以調解全部流量。這個原則也適用於性能。當將 Istio 應用於部署時,運維人員能夠發現,爲提供這些功能而增長的資源開銷是很小的。全部組件和 API 在設計時都必須考慮性能和規模。
增量:隨着運維人員和開發人員愈來愈依賴 Istio 提供的功能,系統必然和他們的需求一塊兒成長。雖然咱們指望繼續本身添加新功能,可是咱們預計最大的需求是擴展策略系統,集成其餘策略和控制來源,並將網格行爲信號傳播到其餘系統進行分析。策略運行時支持標準擴展機制以便插入到其餘服務中。此外,它容許擴展詞彙表,以容許基於網格生成的新信號來執行策略。
可移植性:使用 Istio 的生態系統將在不少維度上有差別。Istio 必須可以以最少的代價運行在任何雲或預置環境中。將基於 Istio 的服務移植到新環境應該是垂手可得的,而使用 Istio 將一個服務同時部署到多個環境中也是可行的(例如,在多個雲上進行冗餘部署)。
策略一致性:在服務間的 API 調用中,策略的應用使得能夠對網格間行爲進行全面的控制,但對於無需在 API 級別表達的資源來講,對資源應用策略也一樣重要。例如,將配額應用到 ML 訓練任務消耗的 CPU 數量上,比將配額應用到啓動這個工做的調用上更爲有用。所以,策略系統做爲獨特的服務來維護,具備本身的 API,而不是將其放到代理/sidecar 中,這允許服務根據須要直接與其集成。