Istio 是什么?

使用雲平台可以為組織提供豐富的好處。然而，不可否認的是，采用雲可能會給 DevOps 團隊帶來壓力。開發人員必須使用微服務以滿足應用的可移植性，同時運營商管理了極其龐大的混合和多雲部署。Istio 允許您連接、保護、控制和觀測服務。

在較高的層次上，Istio 有助於降低這些部署的復雜性，並減輕開發團隊的壓力。它是一個完全開源的服務網格，可以透明地分層到現有的分布式應用程序上。它也是一個平台，包括允許它集成到任何日志記錄平台、遙測或策略系統的 API。Istio 的多樣化功能集使您能夠成功高效地運行分布式微服務架構，並提供保護、連接和監控微服務的統一方法。

什么是服務網格？

在從單體應用程序向分布式微服務架構的轉型過程中，開發人員和運維人員面臨諸多挑戰，使用 Istio 可以解決這些問題。

服務網格（Service Mesh）這個術語通常用於描述構成這些應用程序的微服務網絡以及應用之間的交互。隨着規模和復雜性的增長，服務網格越來越難以理解和管理。它的需求包括服務發現、負載均衡、故障恢復、指標收集和監控以及通常更加復雜的運維需求，例如 A/B 測試、金絲雀發布、限流、訪問控制和端到端認證等。

Istio 提供了一個完整的解決方案，通過為整個服務網格提供行為洞察和操作控制來滿足微服務應用程序的多樣化需求。

為什么要使用 Istio？

Istio 提供一種簡單的方式來為已部署的服務建立網絡，該網絡具有負載均衡、服務間認證、監控等功能，只需要對服務的代碼進行一點或不需要做任何改動。想要讓服務支持 Istio，只需要在您的環境中部署一個特殊的 sidecar 代理，使用 Istio 控制平面功能配置和管理代理，攔截微服務之間的所有網絡通信：

• HTTP、gRPC、WebSocket 和 TCP 流量的自動負載均衡。

• 通過豐富的路由規則、重試、故障轉移和故障注入，可以對流量行為進行細粒度控制。

• 可插入的策略層和配置 API，支持訪問控制、速率限制和配額。

• 對出入集群入口和出口中所有流量的自動度量指標、日志記錄和追蹤。

• 通過強大的基於身份的驗證和授權，在集群中實現安全的服務間通信。

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 目前支持：

• 在 Kubernetes 上部署的服務

• 使用 Consul 注冊的服務

• 在虛擬機上部署的服務

集成和定制

策略執行組件可以擴展和定制，以便與現有的 ACL、日志、監控、配額、審計等方案集成。

架構

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

• 數據平面由一組以 sidecar 方式部署的智能代理（Envoy）組成。這些代理可以調節和控制微服務及 Mixer 之間所有的網絡通信。

• 控制平面負責管理和配置代理來路由流量。此外控制平面配置 Mixer 以實施策略和收集遙測數據。

下圖顯示了構成每個面板的不同組件：

                                                                                             Istio 架構

Envoy

Istio 使用 Envoy 代理的擴展版本，Envoy 是以 C++ 開發的高性能代理，用於調解服務網格中所有服務的所有入站和出站流量。Envoy 的許多內置功能被 Istio 發揚光大，例如：

• 動態服務發現
• 負載均衡
• TLS 終止
• HTTP/2 & gRPC 代理
• 熔斷器
• 健康檢查、基於百分比流量拆分的灰度發布
• 故障注入
• 豐富的度量指標

Envoy 被部署為 sidecar，和對應服務在同一個 Kubernetes pod 中。這允許 Istio 將大量關於流量行為的信號作為屬性提取出來，而這些屬性又可以在 Mixer 中用於執行策略決策，並發送給監控系統，以提供整個網格行為的信息。

Sidecar 代理模型還可以將 Istio 的功能添加到現有部署中，而無需重新構建或重寫代碼。可以閱讀更多來了解為什么我們在設計目標中選擇這種方式。

Mixer

Mixer 是一個獨立於平台的組件，負責在服務網格上執行訪問控制和使用策略，並從 Envoy 代理和其他服務收集遙測數據。代理提取請求級屬性，發送到 Mixer 進行評估。有關屬性提取和策略評估的更多信息，請參見 Mixer 配置。

Mixer 中包括一個靈活的插件模型，使其能夠接入到各種主機環境和基礎設施后端，從這些細節中抽象出 Envoy 代理和 Istio 管理的服務。

Pilot

Pilot 為 Envoy sidecar 提供服務發現功能，為智能路由（例如 A/B 測試、金絲雀部署等）和彈性（超時、重試、熔斷器等）提供流量管理功能。它將控制流量行為的高級路由規則轉換為特定於 Envoy 的配置，並在運行時將它們傳播到 sidecar。

Pilot 將平台特定的服務發現機制抽象化並將其合成為符合 Envoy 數據平面 API 的任何 sidecar 都可以使用的標准格式。這種松散耦合使得 Istio 能夠在多種環境下運行（例如，Kubernetes、Consul、Nomad），同時保持用於流量管理的相同操作界面。

Citadel

Citadel 通過內置身份和憑證管理賦能強大的服務間和最終用戶身份驗證。可用於升級服務網格中未加密的流量，並為運維人員提供基於服務標識而不是網絡控制的強制執行策略的能力。從 0.5 版本開始，Istio 支持基於角色的訪問控制，以控制誰可以訪問您的服務，而不是基於不穩定的三層或四層網絡標識。

Galley

Galley 代表其他的 Istio 控制平面組件，用來驗證用戶編寫的 Istio API 配置。隨着時間的推移，Galley 將接管 Istio 獲取配置、 處理和分配組件的頂級責任。它將負責將其他的 Istio 組件與從底層平台（例如 Kubernetes）獲取用戶配置的細節中隔離開來。

設計目標

Istio 的架構設計中有幾個關鍵目標，這些目標對於使系統能夠應對大規模流量和高性能地服務處理至關重要。

• 最大化透明度：若想 Istio 被采納，應該讓運維和開發人員只需付出很少的代價就可以從中受益。為此，Istio 將自身自動注入到服務間所有的網絡路徑中。Istio 使用 sidecar 代理來捕獲流量，並且在盡可能的地方自動編程網絡層，以路由流量通過這些代理，而無需對已部署的應用程序代碼進行任何改動。在 Kubernetes中，代理被注入到 pod 中，通過編寫 iptables 規則來捕獲流量。注入 sidecar 代理到 pod 中並且修改路由規則后，Istio 就能夠調解所有流量。這個原則也適用於性能。當將 Istio 應用於部署時，運維人員可以發現，為提供這些功能而增加的資源開銷是很小的。所有組件和 API 在設計時都必須考慮性能和規模。

• 可擴展性：隨着運維人員和開發人員越來越依賴 Istio 提供的功能，系統必然和他們的需求一起成長。雖然我們期望繼續自己添加新功能，但是我們預計最大的需求是擴展策略系統，集成其他策略和控制來源，並將網格行為信號傳播到其他系統進行分析。策略運行時支持標准擴展機制以便插入到其他服務中。此外，它允許擴展詞匯表，以允許基於網格生成的新信號來執行策略。

• 可移植性：使用 Istio 的生態系統將在很多維度上有差異。Istio 必須能夠以最少的代價運行在任何雲或預置環境中。將基於 Istio 的服務移植到新環境應該是輕而易舉的，而使用 Istio 將一個服務同時部署到多個環境中也是可行的（例如，在多個雲上進行冗余部署）。

• 策略一致性：在服務間的 API 調用中，策略的應用使得可以對網格間行為進行全面的控制，但對於無需在 API 級別表達的資源來說，對資源應用策略也同樣重要。例如，將配額應用到 ML 訓練任務消耗的 CPU 數量上，比將配額應用到啟動這個工作的調用上更為有用。因此，策略系統作為獨特的服務來維護，具有自己的 API，而不是將其放到代理/sidecar 中，這容許服務根據需要直接與其集成。

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】