個人學習Istio系列? 學習筆記 Istio架構篇

本篇部分參考原書 https://jimmysong.io/istio-handbook/ 僅為個人學習筆記

---

這幅圖中描述了以下內容：

1.Istio 可以在虛擬機和容器中運行

2.Istio 的組成

??? Pilot：服務發現、流量管理

??? Mixer：訪問控制、遙測

??? Citadel：終端用戶認證、流量加密

3.Service mesh 關注的方面

??? 可觀察性

??? 安全性

??? 可運維性

4.Istio 是可定制可擴展的，組建是可拔插的

5.Istio 作為控制平面，在每個服務中注入一個 Envoy 代理以 Sidecar 形式運行來攔截所有進出服務的流量，同時對流量加以控制

6.應用程序應該關注于業務邏輯（這才能生錢），非功能性需求交給 Service Mesh

---

為什么要使用Istio

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

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

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

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

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

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

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

1.在 Kubernetes 上部署的服務

2.使用 Consul 注冊的服務

3.在虛擬機上部署的服務

---

Istio架構

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

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

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

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

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 支持基于角色的訪問控制，以控制誰可以訪問您的服務。

?

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 中，這容許服務根據需要直接與其集成。

---

Sidecar 模式

Sidecar 模式是 Istio 服務網格采用的模式，在服務網格出現之前該模式就一直存在，尤其是當微服務出現后開始盛行

?

什么是 Sidecar 模式

將應用程序的功能劃分為單獨的進程可以被視為 Sidecar 模式。Sidecar 設計模式允許你為應用程序添加許多功能，而無需額外第三方組件的配置和代碼。

就如 Sidecar 連接著摩托車一樣，類似地在軟件架構中， Sidecar 應用是連接到父應用并且為其擴展或者增強功能。Sidecar 應用與主應用程序松散耦合。

讓我用一個例子解釋一下。想象一下假如你有6個微服務相互通信以確定一個包裹的成本。

每個微服務都需要具有可觀察性、監控、日志記錄、配置、斷路器等功能。所有這些功能都是根據一些行業標準的第三方庫在每個微服務中實現的。

但再想一想，這不是多余嗎？它不會增加應用程序的整體復雜性嗎？如果你的應用程序是用不同的語言編寫時會發生什么——如何合并那些特定用于 .Net、Java、Python 等語言的第三方庫。

?

使用 Sidecar 模式的優勢

1.通過抽象出與功能相關的共同基礎設施到一個不同層降低了微服務代碼的復雜度。

3.因為你不再需要編寫相同的第三方組件配置文件和代碼，所以能夠降低微服務架構中的代碼重復度。

3.降低應用程序代碼和底層平臺的耦合度。

?

Sidecar 模式如何工作

Sidecar 是容器應用模式的一種，也是在 Service Mesh 中發揚光大的一種模式，詳見 Service Mesh 架構解析，其中詳細描述了節點代理和 Sidecar 模式的 Service Mesh 架構。

使用 Sidecar 模式部署服務網格時，無需在節點上運行代理（因此您不需要基礎結構的協作），但是集群中將運行多個相同的 Sidecar 副本。從另一個角度看：我可以為一組微服務部署到一個服務網格中，你也可以部署一個有特定實現的服務網格。在 Sidecar 部署方式中，你會為每個應用的容器部署一個伴生容器。Sidecar 接管進出應用容器的所有流量。在 Kubernetes 的 Pod 中，在原有的應用容器旁邊運行一個 Sidecar 容器，可以理解為兩個容器共享存儲、網絡等資源，可以廣義的將這個注入了 Sidecar 容器的 Pod 理解為一臺主機，兩個容器共享主機資源。

例如下圖 SOFAMesh & SOFA MOSN—基于Istio構建的用于應對大規模流量的Service Mesh解決方案的架構圖中描述的，MOSN 作為 Sidecar 的方式和應用運行在同一個 Pod 中，攔截所有進出應用容器的流量，SOFAMesh 兼容 Istio，其中使用 Go 語言開發的 SOFAMosn 替換了 Envoy。

總結

以上是生活随笔為你收集整理的Istio服务网格实践指南 学习笔记(二) Istio架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。