https://www.kubernetes.org.cn/7285.html
上一篇文章中，我們講到Istio的基本概念、架構基礎。Istio 作爲 Service Mesh 領域的集大成者, 提供了流控、安全、遙測等模型，其功能複雜，模塊衆多，本篇文章會對Istio 1.3.5 的各組件進行分析，幫助大家瞭解Istio各組件的職責、以及相互的協作關係。
Istio架構回顧
•數據平面：
數據平面由一組 sidecar 的代理（Envoy）組成。這些代理調解和控制微服務之間的所有網絡通信，並且與控制平面的 pilot通訊，接受調度策略。
•控制平面：
控制平面通過管理和配置 Envoy 來管理流量。此外，控制平面pilot下發xds規則來實施路由策略，mixer收集檢測到的監控數據。
雖然Istio 支持多個平臺, 但將其與 Kubernetes 結合使用，其優勢會更大, Istio 對Kubernetes 平臺支持也是最完善的, 本文將基於Istio + Kubernetes 進行展開。
下面就來介紹Istio 架構中每個組件的功能及工作方式。
Istio核心組件
•Sidecar ( 在 Istio 中，默認的 Sidecar 是 Envoy )
Envoy 是使用 C++ 開發的高性能代理，用於調解服務網格中所有服務的入站和出站流量。在 Istio 中，Envoy 被用於 Sidecar ，和對應的應用服務部署在同一個 Kubernetes 的 Pod 中。
Envoy 調解所有出入應用服務的流量。所有經過 Envoy 的流量行爲都會調用 Mixer（只是report功能，check功能可以通過配置關閉），爲Mixer 提供一組描述請求和請求周圍環境的 Attribute 。根據 Envoy 的配置和 Attribute，Mixer 會調用各種後臺的基礎設施資源。而這些 Attribute 又可以在 Mixer 中用於決策使用何種策略，併發送給監控系統，以提供整個網格行爲的信息。
•Pilot
Pilot 爲 Sidecar 提供“服務發現”功能，並管理高級路由( 如 A/B 測試和金絲雀部署 )和故障處理( 超時、重試、熔斷器等 )的流量。Pilot 將這些“高級”的流量行爲轉換爲詳盡的 Sidecar (即 Envoy) 配置項，並在運行時將它們配置到 Sidecar 中。
Pilot 將服務發現機制提煉爲供數據面使用的 API ，即任何 Sidecar 都可以使用的標準格式。這種鬆耦合的設計模式使 Istio 能在多種環境( Kubernetes、Consul 和 Nomad )下運行，同時保持用於流量管理操作的相同。
除了服務發現， Pilot 更重要的一個功能是向數據面下發規則，包括VirtualService 、DestinationRule 、Gateway 、ServiceEntry 等流量治理規則，也包括認證授權等安全規則。Pilot 負責將各種規則轉換成Envoy 可識別的格式，通過標準的XDS 協議發送給Envoy,指導Envoy 完成功作。在通信上， Envoy 通過gRPC 流式訂閱Pilot 的配置資源。如下圖所示， Pilot 將VirtualService 表達的路由規則分發到Evnoy 上， Envoy 根據該路由規則進行流量轉發。
•Mixer
Mixer 是一個獨立於平臺的組件，通過從 Sidecar 和一些其他服務處收集數據，進而在整個 Service Mesh 上控制訪問和執行策略。Sidecar 請求級別的 Attribute 被髮送到 Mixer 進行評估。
Mixer 中還包括一個靈活的插件，使其能接入各種主機環境和基礎設施的後段，並得到 Sidecar 代理和 Istio 所管理的服務。
Mixer 的設計具有以下特點：
◦無狀態：Mixer 本身是無狀態的，它沒有持久化存儲的管理功能。
◦高可用：Mixer 被設計成高度可用的組件，任何單獨的 Mixer 實例實現 > 99.999% 的正常運行時間。
◦緩存和緩衝：Mixer 能夠積累大量短暫的瞬間狀態。
Mixer 是Istio 獨有的一種設計,不同於Pilot ，在其他平臺上總能找到類似功能的服務組件。從調用時機上來說，Pilot 管理的是配置數據，在配置改變時和數據面交互即可；然而，對於Mixer 來說，在服務間交互時Envoy 都會對Mixer 進行一次調用，因此這是一種實時管理。當然，在實現上通過在Mixer 和Proxy 上使用緩存機制，可保證不用每次進行數據面請求時都和Mixer 交互。
◦Istio-telemetry
Istio-telemetry是專門用於收集遙測數據的Mixer服務組件;如下圖所示 所示，當網格中的兩個服務間有調用發生時，服務的代理Envoy 就會上報遙測數據給Istio-telemetry服務組件，Istio-telemetry 服務組件則根據配置將生成訪問Metric等數據分發給後端的遙測服務。數據面代理通過Report 接口上報數據時訪問數據會被批量上報。
◦Istio-policy
Istio-policy 是另外一個Mixer 服務，和Istio-telemetry 基本上是完全相同的機制和流程。如圖所示，數據面在轉發服務的請求前調用Istio-policy 的Check接口檢查是否允許訪問， Mixer 根據配置將請求轉發到對應的Adapter 做對應檢查，給代理返回允許訪問還是拒絕。可以對接如配額、授權、黑白名單等不同的控制後端，對服務間的訪問進行可擴展的控制。
•Citadel
Citadel 通過內置身份和憑證管理提供“服務間”和“最終用戶”身份驗證。Citadel 可用於升級服務網格中未加密的流量，並能夠爲運維人員提供基於服務標識( 如 Kubernetes 中 Pod 的標籤或版本號 )而不是網絡層的強制執行策略。
Citadel 一直監聽Kube-apiserver ，以Secret 的形式爲每個服務都生成證書密鑰，並在Pod 創建時掛載到Pod 上，代理容器使用這些文件來做服務身份認證，進而代理兩端服務實現雙向TLS認證、通道加密、訪問授權等安全功能，這樣用戶就不用在代碼裏面維護證書密鑰了。如下圖所示，frontend 服務對forecast 服務的訪問用到了HTTP 方式，通過配置即可對服務增加認證功能， 雙方的Envoy 會建立雙向認證的TLS 通道，從而在服務間啓用雙向認證的HTTPS 。
•Istio-galley
Istio-galley 並不直接向數據面提供業務能力，而是在控制面上向其他組件提供支持。Galley 作爲負責配置管理的組件，驗證配置信息的格式和內容的正確性，並將這些配置信息提供給管理面的Pilot和Mixer服務使用，這樣其他管理面組件只用和Galley 打交道，從而與底層平臺解耦。在新的版本中Galley的作用越來越核心。
•Istio-sidecar-injector
Istio-sidecar-injector 是負責向動注入的組件，只要開啓了自動注入，在Pod 創建時就會自動調用Istio-sidecar-injector 向Pod 中注入Sidecar 容器。
在Kubernetes環境下，根據自動注入配置， Kube-apiserver 在攔截到Pod 創建的請求時，會調用自動注入服務Istio-sidecar-injector生成Sidecar 容器的描述並將其插入原Pod的定義中，這樣，在創建的Pod 內除了包括業務容器，還包括Sidecar 容器。這個注入過程對用戶透明，用戶使用原方式創建工作負載。
•Istio-ingressgateway
Istio-ingressgateway 就是入口處的Gateway ，從網格外訪問網格內的服務就是通過這個Gateway 進行的。Istio-ingressgateway 比較特別，是一個Loadbalancer 類型的Service,不同於其他服務組件只有一兩個端口, Istio-ingressgateway 開放了一組端口，這些就是網格內服務的外部訪問端口.如下圖 所示，網格入口網關Istio-ingressgateway 的負載和網格內的Sidecar 是同樣的執行體，也和網格內的其他Sidecar 一樣從Pilot處接收流量規則並執行。。Istio 通過一個特有的資源對象Gateway 來配置對外的協議、端口等。
“從小白到專家Istio技術實踐”專題系統講述Istio基本概念、基礎架構及在企業級雲平臺中的實踐。對微服務治理感興趣的企業決策者、技術調研者、架構師、開發人員、運維人員，歡迎持續關注！
