上一篇文章中,我們講到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基本概念、基礎架構及在企業級云平臺中的實踐。對微服務治理感興趣的企業決策者、技術調研者、架構師、開發人員、運維人員,歡迎持續關注!