共計 3118 個字符，預計需要花費 8 分鐘才能閱讀完成。

本篇內容主要講解“Istio 設計目標是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“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 設計目標是什么”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！