介紹
Istio 服務網格從邏輯上分為數據平面和控制平面。
- 數據平面由一組智能代理（Envoy）組成，被部署為 sidecar。這些代理通過一個通用的策略和遙測中心（Mixer）傳遞和控制微服務之間的所有網絡通信。
- 控制平面管理並配置代理來進行流量路由。此外，控制平面配置 Mixer 來執行策略和收集遙測數據。
下圖展示了組成每個平面的不同組件：
Istio 架構
Istio 中的流量分為數據平面流量和控制平面流量。數據平面流量是指工作負載的業務邏輯發送和接收的消息。控制平面流量是指在 Istio 組件之間發送的配置和控制消息用來編排網格的行為。Istio 中的流量管理特指數據平面流量。
組件
Envoy
Istio 使用 Envoy 代理的擴展版本。Envoy 是用 C++ 開發的高性能代理，用於協調服務網格中所有服務的入站和出站流量。Envoy 代理是唯一與數據平面流量交互的 Istio 組件。
Envoy 代理被部署為服務的 sidecar，在邏輯上為服務增加了 Envoy 的許多內置特性，例如:
- 動態服務發現
- 負載均衡
- TLS 終端
- HTTP/2 與 gRPC 代理
- 熔斷器
- 健康檢查
- 基於百分比流量分割的分階段發佈
- 故障注入
- 豐富的指標
這種 sidecar 部署允許 Istio 提取大量關於流量行為的信號作為屬性。反之，Istio 可以在 Mixer 中使用這些屬性來執行決策，並將它們發送到監控系統，以提供整個網格的行為信息。
sidecar 代理模型還允許您向現有的部署添加 Istio 功能，而不需要重新設計架構或重寫代碼。您可以在設計目標中讀到更多關於為什麼我們選擇這種方法的信息。
由 Envoy 代理啟用的一些 Istio 的功能和任務包括:
- 流量控制功能：通過豐富的 HTTP、gRPC、WebSocket 和 TCP 流量路由規則來執行細粒度的流量控制。
- 網絡彈性特性：重試設置、故障轉移、熔斷器和故障注入。
- 安全性和身份驗證特性：執行安全性策略以及通過配置 API 定義的訪問控制和速率限制。
Mixer
Mixer 是一個平臺無關的組件。Mixer 在整個服務網格中執行訪問控制和策略使用，並從 Envoy 代理和其他服務收集遙測數據。代理提取請求級別屬性，並將其發送到 Mixer 進行評估。
Mixer 包括一個靈活的插件模型。該模型使 Istio 能夠與各種主機環境和後端基礎設施進行交互。因此，Istio 從這些細節中抽象出 Envoy 代理和 Istio 管理的服務。
Pilot
Pilot 為 Envoy sidecar 提供服務發現、用於智能路由的流量管理功能（例如，A/B 測試、金絲雀發佈等）以及彈性功能（超時、重試、熔斷器等）。
Pilot 將控制流量行為的高級路由規則轉換為特定於環境的配置，並在運行時將它們傳播到 sidecar。Pilot 將特定於平臺的服務發現機制抽象出來，並將它們合成為任何符合 Envoy API 的 sidecar 都可以使用的標準格式。
下圖展示了平臺適配器和 Envoy 代理如何交互。
這種松耦合允許 Istio 在 Kubernetes、Consul 或 Nomad 等多種環境中運行，同時維護相同的 operator 接口來進行流量管理。
您可以使用 Istio 的流量管理 API 來指示 Pilot 優化 Envoy 配置，以便對服務網格中的流量進行更細粒度地控制。
Citadel
Citadel 通過內置的身份和證書管理，可以支持強大的服務到服務以及最終用戶的身份驗證。您可以使用 Citadel 來升級服務網格中的未加密流量。使用 Citadel，operator 可以執行基於服務身份的策略，而不是相對不穩定的 3 層或 4 層網絡標識。從 0.5 版開始，您可以使用 Istio 的授權特性來控制誰可以訪問您的服務。
Galley
Galley 是 Istio 的配置驗證、提取、處理和分發組件。它負責將其餘的 Istio 組件與從底層平臺（例如 Kubernetes）獲取用戶配置的細節隔離開來。
服務模型
作為 Istio 服務網格中的一部分，Kubernetes 集群中的 Pod 和 Service 必須滿足以下要求：
- 命名的服務端口: Service 的端口必須命名。端口名鍵值對必須按以下格式：name: <protocol>[-<suffix>]。更多說明請參看協議選擇。/<suffix>/<protocol>
- Service 關聯: 每個 Pod 必須至少屬於一個 Kubernetes Service，不管這個 Pod 是否對外暴露端口。如果一個 Pod 同時屬於多個 Kubernetes Service， 那麼這些 Service 不能同時在一個端口號上使用不同的協議（比如：HTTP 和 TCP）。
- 帶有 app 和 version 標籤（label） 的 Deployment: 我們建議顯式地給 Deployment 加上 app 和 version 標籤。給使用 Kubernetes Deployment 部署的 Pod 部署配置中增加這些標籤，可以給 Istio 收集的指標和遙測信息中增加上下文信息。app 標籤：每個部署配置應該有一個不同的 app 標籤並且該標籤的值應該有一定意義。app label 用於在分佈式追蹤中添加上下文信息。version 標籤：這個標籤用於在特定方式部署的應用中表示版本。
- 應用 UID: 確保你的 Pod 不會以用戶 ID（UID）為 1337 的用戶運行應用。
- NET_ADMIN 功能: 如果你的集群執行 Pod 安全策略，必須給 Pod 配置 NET_ADMIN 功能。如果你使用 Istio CNI 插件 可以不配置。要了解更多 NET_ADMIN 功能的知識，請查看所需的 Pod 功能。
Istio 使用的端口
Istio 使用瞭如下的端口和協議。請確保沒有 TCP Headless Service 使用了 Istio Service 使用的 TCP 端口。
閱讀更多 上海IT故事 的文章
