Istio設計目標是什么

本篇內容主要講解“Istio設計目標是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Istio設計目標是什么”吧!

綜述

Istio：一個用于連接，管理和保護微服務的開放式平臺。Istio提供了一種簡單的方法，通過負載均衡，服務到服務的認證，監控等為已部署服務的創建網絡，并且無需對服務代碼做任何更改。可以通過在整個環境中部署一個特殊的sidecar 代理來將Istio功能，sidecar截取微服務之間的所有網絡通信，使用Istio的控制面板（control plane）功能進行配置和管理。

Istio目前支持在Kubernetes上部署服務，以及通過Consul或Eureka注冊的服務以及在單個VM上運行的服務。

。

為什么使用Istio

Istio解決了從單一應用程序向分布式微服務架構過渡中開發和運維人員面臨的許多挑戰。 術語service mesh （服務網格）通常用于描述構成這些應用程序的微服務網絡以及它們之間的交互。 隨著服務網格的大小和復雜程度不斷增加，可能會變得難以理解和管理。 Istio提供了包括服務發現，負載平衡，故障恢復，度量和監控，以及更復雜的操作要求，如A / B測試，金絲雀版本，流量限制，訪問控制和端到端身份驗證等。

Istio提供了一個完整的解決方案，通過對整個服務網格提供行為分析和操作控制來滿足創建微服務應用程序的各種需求。 它在整個服務網絡中統一提供許多關鍵功能：

• 流量管理。控制業務之間的流量和API調用流量，使調用更可靠，并在面對不利條件時使網絡更加健壯。

• 服務標識和安全。 在網格中提供具有可驗證身份的服務，并提供保護服務流量的能力，因為流量通過不同程度的可信性網絡流動。

• 策略執行。 將組織策略應用于服務之間的交互，確保訪問策略得到執行，資源在消費者之間公平分配。 通過配置網格來進行策略更改，而不是通過更改應用程序代碼。

• Telemetry。 了解服務之間的依賴關系以及它們之間數據傳輸的性質和流量，從而提供快速診斷問題的能力。

除了以上功能之外，Istio可擴展設計可以滿足不同的部署需求：

• 平臺支持。 Istio旨在運行在各種環境中，包括跨云，On-premises 部署，Kubernetes，Mesos等。我們最初專注于Kubernetes，但正在努力支持其他環境。

• 整合和定制。 策略實施組件可以進行擴展和定制，以與ACL，日志記錄，監控，配額，審計等現有解決方案集成。

這些功能大大減少了應用程序代碼，底層平臺和策略之間的耦合。 這種耦合減少不僅使服務更實現起來更容易，而且還使運維人員能夠更簡單地將應用在不同環境之間部署或在新策略方案之間移動。 因此，應用程序本質上更加輕便。

架構

Istio服務網格邏輯上分為數據面板和控制面板。

• 數據面板由一系列智能代理（Envoy）組成，這些智能代理部署為sidecars （邊車），用于調解和控制微服務之間的所有網絡通信，以及通用策略和監控日志中樞（混合器）。

• 控制面板負責管理和配置代理以路由流量，并配置Mixers 以執行策略并收集監控日志數據。

Envoy

Istio 是Envoy代理的擴展版本，這是一種使用C ++開發的高性能代理，用于調解服務網格中所有服務的所有入站和出站流量。 Istio利用Envoy的許多內置功能，如動態服務發現，負載平衡，TLS終止，HTTP/2 和gRPC代理，斷路器，運行狀況檢查，基于百分比的流量的分階段發布，故障注入以及豐富的metrics。

Envoy 以sidecar的形式部署在同一Kubernetes Pod相關服務中。這使Istio能夠將大量有關流量行為的信號作為屬性提取出來，從而可以在Mixer 中使用它來執行策略決策，并將其發送到監控系統以提供有關整個網格行為的信息。 sidecar代理模型還允許將Istio功能添加到已部署服務，而無需重新構建或重寫代碼。 你可以閱讀更多關于我們為什么在我們的設計目標中選擇此方法的信息。

Mixer

Mixer 是一個獨立于平臺的組件，負責在整個服務網格中實施訪問控制和使用策略，并收集來自Envoy代理和其他服務的遙測數據。代理提取請求級別屬性，將其發送到Mixer進行評估。有關此屬性提取和策略評估的更多信息可以在Mixer配置中找到。 Mixer包含靈活的插件模型，可以與各種主機環境和基礎設施后端進行交互，從這些細節中抽象出Envoy代理和Istio管理的服務。

Pilot

Pilot為Envoy sidecars提供服務發現，為智能路由（例如A / B測試，金絲雀部署等）和resiliency（超時，重試，斷路器等）提供流量管理功能。它將控制流量行為的高級路由規則轉換為特定的Envoy的配置，并在運行時將它們傳播到sidecar。Pilot將平臺特定的服務發現機制抽象化并將其合成為符合Envoy數據平面API的任何sidecar都可以使用的標準格式。這種松散耦合使得Istio能夠在多種環境下運行（例如，Kubernetes，Consul / Nomad），同時用于流量管理的界面操作都是相同的。

Citadel

Citadel提供強大的服務到服務和終端用戶身份驗證，內置身份和憑證管理。它可用于升級服務網格中未加密的流量，并為運維人員提供基于服務標識而不是網絡控制強制執行策略的能力。 從0.5版開始，Istio支持基于角色的訪問控制，以控制誰可以訪問您的服務。

設計目標

Istio的體系結構由幾個關鍵設計目標，這些目標對于使系統能夠處理大規模和高性能的服務至關重要。

• 最大化透明。 采用Istio，可以讓運維人員或開發人員盡可能減少工作量，以便從系統中獲得更多實際價值。 為此，Istio可以自動將自己注入到服務之間的所有網絡路徑中。Istio使用sidecar代理來捕獲流量，并在可能的情況下自動編程聯網層，以便通過這些代理路由流量，而不會對已部署的應用程序代碼進行任何更改。 在Kubernetes中，代理被注入到pod中，通過編程iptables規則捕獲流量。 一旦sidecar代理被注入并且編程好流量路由規則，Istio就能夠調解所有的流量。 這一原則也適用于性能。 將Istio應用于部署時，運維人員應該看到Istio提供這些功能只需要很少的資源。 組件和API的設計必須考慮到性能和可伸縮。

• 漸進性。 隨著運維人員和開發人員越來越依賴Istio提供的功能，系統必須隨著他們的需求而增長。 雖然我們希望自己繼續添加新功能，但我們預計最大的需求是擴展策略系統，與其他策略和控制來源整合，并將有關網狀行為的信號傳播到其他系統進行分析。 策略運行時支持插入其他服務的標準擴展機制。 此外，它還允許擴展其詞匯表，以便根據網格生成的新信號執行策略。

• 可移植性。 Istio將使用的生態系統在很多方面都有所不同。 Istio必須以最小的努力在任何云環境或內部環境中運行。 將基于Istio的服務移植到新環境中的工作量是非常小的，并且應該可以使用Istio將一個服務部署到多個環境中（例如，在多個云上進行冗余）。

• 策略一致性。 將策略應用于服務之間的API調用可以提供對網格行為的大量控制，但將策略應用于不一定在API級別表示的資源也同樣重要。 例如，將配額應用于ML培訓任務所消耗的CPU數量比將配額應用于啟動工作的調用更有用。 為此，該策略體系作為一項獨立的服務與其自己的API保持在一起，而不是被納入代理/sidecar，從而允許服務根據需要與其直接整合。

到此，相信大家對“Istio設計目標是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！