（三）Istio架構介紹
Istio服務網格在邏輯上分為資料平面和控制平面。
- 資料平面由一組部署為邊車的智慧代理(Envoy)組成。這些代理負責協調和控制微服務之間的所有網路通訊。他們還收集和報告所有網格流量的遙測資料。
- 控制平面管理並將代理配置為路由流量。
下圖顯示了構成每個平面的不同元件：（下圖來自官網）
Istio中的交通分為資料平面交通和控制平面交通。資料平面流量是指工作負載的業務邏輯傳送和接收的訊息。控制平面交通是指在Istio元件之間傳送的配置和控制訊息來對網格的行為進行程式設計。Istio中的流量管理專門指資料平面流量。
1. 元件
1.1 Envoy
Istio使用Envoy代理的擴充套件版本。Envoy是用c++開發的高效能代理，用於協調服務網格中所有服務的所有入站和出站流量。Envoy代理是唯一與資料通訊互動的Istio元件。
Envoy代理被部署為服務的邊車，從邏輯上講，它增加了Envoy的許多內建特性：
- Dynamic service discovery
- Load balancing
- TLS termination
- HTTP/2 and gRPC proxies
- Circuit breakers
- Health checks
- Staged rollouts with %-based traffic split
- Fault injection
- Rich metrics
這種sidecar部署允許Istio提取大量關於流量行為的訊號作為屬性。Istio可以使用這些屬性來執行策略決策，並將它們傳送到監控系統，以提供關於整個網格的行為的資訊。
sidecar代理模型還允許您向現有部署新增Istio功能，而不需要重新架構或重寫程式碼。
由envoy代理啟用的一些Istio功能和任務包括:
- Traffic control features: enforce fine-grained traffic control with rich routing rules for HTTP, gRPC, WebSocket, and TCP traffic.
- Network resiliency features: setup retries, failovers, circuit breakers, and fault injection.
- Security and authentication features: enforce security policies and enforce access control and rate limiting defined through the configuration API.
- Pluggable extensions model based on WebAssembly that allows for custom policy enforcement and telemetry generation for mesh traffic.
1.2 Pilot
Pilot針對提供智慧路由（比如，A/B測試、金絲雀部署）的Envoy Sidecar，流量管理的能力提供了服務發現。針對彈性提供了超時，重試，斷路保護等功能。
Pilot將控制流量行為的高階路由規則轉換為特定於環境的配置，並在執行時將它們傳播到邊車。Pilot將特定於平臺的服務發現機制抽象出來，並將它們合成為任何符合Envoy API的sidecar都可以使用的標準格式。
下圖顯示了平臺介面卡和Envoy代理如何互動:
- 平臺啟動一個服務的新例項，該例項通知其平臺介面卡。
- 平臺介面卡使用Pilot抽象模型註冊例項。
- Pilot將分發流量規則和配置給Envoy代理，以說明更改的原因。
這種耦合允許istio執行在比如kubernetes、Consul或者Nomad等平臺上。
1.3 Citadel
Citadel支援強大的服務對服務和終端使用者身份驗證，內建身份和憑證管理。您可以使用Citadel來升級服務網格中的未加密流量。使用Citadel，運營商可以執行基於服務身份的策略，而不是基於相對不穩定的第3層或第4層網路識別符號。從0.5版開始，您可以使用Istio的授權特性來控制誰可以訪問您的服務。
1.4 Gallery
Galley是Istio的配置驗證、注入、處理和分發元件。它負責將其餘的Istio元件與從底層平臺(例如Kubernetes)獲取使用者配置的細節隔離開來。
2. 設計目標
- 最大化的透明度：為了採用Istio，操作人員或開發人員需要做盡可能少的工作，才能從系統中獲得真正的價值。為此，Istio可以自動將自己注入到服務之間的所有網路路徑中。Istio使用sidecar代理來捕獲流量，並在可能的情況下，在不更改已部署的應用程式程式碼的情況下，自動對網路層進行程式設計，以通過這些代理路由流量。在Kubernetes中，代理被注入到pods中，通過編寫iptables規則捕獲流量。一旦sidecar代理被注入並且流量路由被處理，Istio可以協調所有的流量。這個原則也適用於效能。當將Istio應用於部署時，操作人員會看到所提供功能的資源成本的最小增加。元件和api的設計必須考慮到效能和可伸縮性。
- 擴充套件性：隨著操作人員和開發人員越來越依賴於Istio提供的功能，系統必須隨著他們的需求而增長。當我們繼續新增新特性時，最大的需求是擴充套件策略系統的能力，與其他策略和控制源的整合，以及將關於網格行為的訊號傳播到其他系統進行分析的能力。策略執行時支援用於插入其他服務的標準擴充套件機制。
- 可移植性：使用Istio的生態系統在許多方面都有所不同。Istio必須在任何雲環境或本地環境中以最小的努力執行。將基於isti的服務移植到新環境的任務必須是瑣碎的。使用Istio，您可以操作部署到多個環境中的單個服務。例如，可以在多個雲上部署冗餘。
- 策略的一致性：策略在服務之間的API呼叫上的應用提供了對網格行為的大量控制。然而，將策略應用於API級別上不一定表示的資源也同樣重要。例如，對ML訓練任務消耗的CPU數量應用配額比對發起工作的呼叫應用配額更有用。為此，Istio使用自己的API將策略系統維護為一個獨立的服務，而不是將策略系統整合到代理sidecar中，從而允許服務根據需要直接與之整合。