1 Istio 架構(gòu)

Istio的架構(gòu)，分為控制平面和數(shù)據(jù)面平兩部分。
- 數(shù)據(jù)平面：由一組智能代理（[Envoy]）組成，被部署為 sidecar。這些代理通過一個通用的策略和遙測中心傳遞和控制微服務(wù)之間的所有網(wǎng)絡(luò)通信。
- 控制平面：管理并配置代理來進(jìn)行流量路由。此外，控制平面配置 Mixer 來執(zhí)行策略和收集遙測數(shù)據(jù)。

下圖展示了組成每個平面的不同組件：

架構(gòu)圖可以看到，主要分為兩個平面，控制面主要包括Istio的一些組件，例如：Pilot、Mixer、Citadel等服務(wù)組件；數(shù)據(jù)面由伴隨每個應(yīng)用程序部署的代理程序Envoy組成，執(zhí)行針對應(yīng)用程序的治理邏輯。為了避免靜態(tài)、刻板地描述組件，在介紹組件的功能前，我們先通過一個動態(tài)場景來了解圖架構(gòu)圖中對象的工作機(jī)制，即觀察前端服務(wù)對后臺服務(wù)進(jìn)行一次訪問時，在 Istio 內(nèi)部都發(fā)生了什么，以及 Istio 的各個組件是怎樣參與其中的，分別做了哪些事情。

先簡單理解

Pilot：提供服務(wù)發(fā)現(xiàn)功能和路由規(guī)則

Mixer：策略控制，比如：服務(wù)調(diào)用速率限制

Citadel：起到安全作用，比如：服務(wù)跟服務(wù)通信的加密

Sidecar/Envoy: 代理，處理服務(wù)的流量

架構(gòu)圖上帶圓圈的數(shù)字代表在數(shù)據(jù)面上執(zhí)行的若干重要動作。雖然從時序上來講，控制面的配置在前，數(shù)據(jù)面執(zhí)行在后，但為了便于理解，在下面介紹這些動作時以數(shù)據(jù)面上的數(shù)據(jù)流為入口，介紹數(shù)據(jù)面的功能，然后講解涉及的控制面如何提供對應(yīng)的支持，進(jìn)而理解控制面上組件的對應(yīng)功能。

（1）自動注入：（由架構(gòu)圖得知前端服務(wù)跟后端服務(wù)都有envoy,我們這里以前端服務(wù)envoy為例說明）指在創(chuàng)建應(yīng)用程序時自動注入 Sidecar代理。那什么情況下會自動注入你？在 Kubernetes場景下創(chuàng)建 Pod時，Kube-apiserver調(diào)用管理平面組件的 Sidecar-Injector服務(wù)，然后會自動修改應(yīng)用程序的描述信息并注入Sidecar。在真正創(chuàng)建Pod時，在創(chuàng)建業(yè)務(wù)容器的同時在Pod中創(chuàng)建Sidecar容器。

# 原始的yaml文件
apiVersion: apps/v1
kind: Deployment
spec: 
	containers: 
	- name: nginx  
		image: nginx  
		...省略

調(diào)用Sidecar-Injector服務(wù)之后，yaml文件會發(fā)生改變

# 原始的yaml文件
apiVersion: apps/v1
kind: Deployment
spec: 
	containers: 
	- name: nginx  
		image: nginx  
		...省略
# 增加一個容器image地址		
	containers: 
	- name: sidecar  
		image: sidecar  
		...省略	

總結(jié)：會在pod里面自動生產(chǎn)一個代理，業(yè)務(wù)服務(wù)無感知

（2）流量攔截：在 Pod 初始化時設(shè)置 iptables 規(guī)則，當(dāng)有流量到來時，基于配置的iptables規(guī)則攔截業(yè)務(wù)容器的入口流量和出口流量到Sidecar上。但是我們的應(yīng)用程序感知不到Sidecar的存在，還以原本的方式進(jìn)行互相訪問。在架構(gòu)圖中，流出前端服務(wù)的流量會被 前端服務(wù)側(cè)的 Envoy攔截，而當(dāng)流量到達(dá)后臺服務(wù)時，入口流量被后臺服務(wù)V1/V2版本的Envoy攔截。

總結(jié)：每個pod中都會有一個代理來來攔截所有的服務(wù)流量（不管是入口流量還是出口流量）

（3）服務(wù)發(fā)現(xiàn)：前端服務(wù)怎么知道后端服務(wù)的服務(wù)信息呢？這個時候就需要服務(wù)發(fā)現(xiàn)了，所以服務(wù)發(fā)起方的 Envoy 調(diào)用控制面組件 Pilot 的服務(wù)發(fā)現(xiàn)接口獲取目標(biāo)服務(wù)的實(shí)例列表。在架構(gòu)圖中，前端服務(wù)內(nèi)的 Envoy 通過 控制平面Pilot 的服務(wù)發(fā)現(xiàn)接口得到后臺服務(wù)各個實(shí)例的地址，為訪問做準(zhǔn)備。

總結(jié)：Pilot提供了服務(wù)發(fā)現(xiàn)功能，調(diào)用方需要到Pilot組件獲取提供者服務(wù)信息

（4）負(fù)載均衡：數(shù)據(jù)面的各個Envoy從Pilot中獲取后臺服務(wù)的負(fù)載均衡衡配置，并執(zhí)行負(fù)載均衡動作，服務(wù)發(fā)起方的Envoy（前端服務(wù)envoy）根據(jù)配置的負(fù)載均衡策略選擇服務(wù)實(shí)例，并連接對應(yīng)的實(shí)例地址。

總結(jié)：Pilot也提供了負(fù)載均衡功能，調(diào)用方根據(jù)配置的負(fù)載均衡策略選擇服務(wù)實(shí)例

（5）流量治理：Envoy 從 Pilot 中獲取配置的流量規(guī)則，在攔截到 入口 流量和出口 流量時執(zhí)行治理邏輯。比如說，在架構(gòu)圖中，前端服務(wù)的 Envoy 從 Pilot 中獲取流量治理規(guī)則，并根據(jù)該流量治理規(guī)則將不同特征的流量分發(fā)到后臺服務(wù)的v1或v2版本。當(dāng)然，這只是Istio流量治理的一個場景，Istio支持更豐富的流量治理能力。

總結(jié)：Pilot也提供了路由轉(zhuǎn)發(fā)規(guī)則

（6）訪問安全：在服務(wù)間訪問時通過雙方的Envoy進(jìn)行雙向認(rèn)證和通道加密，并基于服務(wù)的身份進(jìn)行授權(quán)管理。在架構(gòu)圖中，Pilot下發(fā)安全相關(guān)配置，在前端模塊服務(wù)和后端服務(wù)的Envoy上自動加載證書和密鑰來實(shí)現(xiàn)雙向認(rèn)證，其中的證書和密鑰由另一個控制平面組件Citadel維護(hù)。

總結(jié)：Citadel維護(hù)了服務(wù)代理通信需要的證書和密鑰

（7）服務(wù)遙測：在服務(wù)間通信時，通信雙方的Envoy都會連接控制平面組件Mixer上報(bào)訪問數(shù)據(jù)，并通過Mixer將數(shù)據(jù)轉(zhuǎn)發(fā)給對應(yīng)的監(jiān)控后端。比如說，在架構(gòu)圖中，前端模塊服務(wù)對后端服務(wù)的訪問監(jiān)控指標(biāo)、日志和調(diào)用鏈都可以通過Mixer收集到對應(yīng)的監(jiān)控后端。

總結(jié)：Mixer組件可以收集各個服務(wù)上的日志，從而可以進(jìn)行監(jiān)控

（8）策略執(zhí)行：在進(jìn)行服務(wù)訪問時，通過Mixer連接后端服務(wù)來控制服務(wù)間的訪問，判斷對訪問是放行還是拒絕。在架構(gòu)圖中，數(shù)據(jù)面在轉(zhuǎn)發(fā)服務(wù)的請求前調(diào)用Mixer接口檢查是否允許訪問，Mixer 會做對應(yīng)檢查，給代理（Envoy）返回允許訪問還是拒絕, 比如：可以對前端模塊服務(wù)到后臺服務(wù)的訪問進(jìn)行速率控制。

總結(jié)：Mixer組件可以對服務(wù)速率進(jìn)行控制（也就是限流）

（9）外部訪問：在架構(gòu)圖中，外部服務(wù)通過Gateway訪問入口將流量轉(zhuǎn)發(fā)到服務(wù)前端服務(wù)內(nèi)的Envoy組件，對前端服務(wù)的負(fù)載均衡和一些流量治理策略都在這個Gateway上執(zhí)行。

**總結(jié)：**這里總結(jié)在以上過程中涉及的動作和動作主體，可以將其中的每個過程都抽象成一句話：服務(wù)調(diào)用雙方的Envoy代理攔截流量，并根據(jù)控制平面的相關(guān)配置執(zhí)行相應(yīng)的服務(wù)治理動作，這也是Istio的數(shù)據(jù)平面和控制平面的配合方式。

2 Istio組件介紹

2.1 Pilot

Pilot在Istio架構(gòu)中必須要有

思考: 為什么Envoy能夠服務(wù)發(fā)現(xiàn)？并且Envoy為什么可以流量控制？

就是因?yàn)镻ilot存在

什么是Pilot

Pilot類似傳統(tǒng)C/S架構(gòu)中的服務(wù)端Master，下發(fā)指令控制客戶端完成業(yè)務(wù)功能。和傳統(tǒng)的微服務(wù)架構(gòu)對比，Pilot 至少涵蓋服務(wù)注冊中心和向數(shù)據(jù)平面下發(fā)規(guī)則 等管理組件的功能。

服務(wù)注冊中心

如圖下圖所示，Pilot 為 Envoy sidecar 提供服務(wù)發(fā)現(xiàn)、用于智能路由的流量管理功能（例如，A/B 測試、金絲雀發(fā)布等）以及彈性功能（超時、重試、熔斷器等）。

Pilot本身不做服務(wù)注冊，它會提供一個API接口，對接已有的服務(wù)注冊系統(tǒng)，比如Eureka，Etcd等。
說白了，Pilot可以看成它是Sidecar的一個領(lǐng)導(dǎo)

(1)Platform Adapter是Pilot抽象模型的實(shí)現(xiàn)版本，用于對接外部的不同平臺
(2)Polit定了一個抽象模型(Abstract model)，處理Platform Adapter對接外部不同的平臺， 從特定平臺細(xì)節(jié)中解耦
(3)Envoy API負(fù)責(zé)和Envoy的通訊，主要是發(fā)送服務(wù)發(fā)現(xiàn)信息和流量控制規(guī)則給Envoy

流程總結(jié)： service服務(wù)C會注冊到Pilot注冊中心平臺適配器(Platform Adapter)模塊上（假如對接的是Eureka, 那么service服務(wù)C會注冊到Eureka里面），然后抽象模型(Abstract model)進(jìn)行平臺細(xì)節(jié)的解耦并且用于處理Platform Adapter對接外部的不同平臺，最后通過Envoy API負(fù)責(zé)和Envoy的通訊，主要是發(fā)送服務(wù)發(fā)現(xiàn)信息和流量控制規(guī)則給Envoy

數(shù)據(jù)平面下發(fā)規(guī)則

Pilot 更重要的一個功能是向數(shù)據(jù)平面下發(fā)規(guī)則，Pilot 負(fù)責(zé)將各種規(guī)則轉(zhuǎn)換換成 Envoy 可識別的格式，通過標(biāo)準(zhǔn)的 協(xié)議發(fā)送給 Envoy，指導(dǎo)Envoy完成動作。在通信上，Envoy通過gRPC流式訂閱Pilot的配置資源。

Pilot將表達(dá)的路由規(guī)則分發(fā)到 Evnoy上，Envoy根據(jù)該路由規(guī)則進(jìn)行流量轉(zhuǎn)發(fā)，配置規(guī)則和流程圖如下所示。

規(guī)則如下：

# http請求
http:
-match: # 匹配
 -header: # 頭部
   cookie:
   # 以下cookie中包含group=dev則流量轉(zhuǎn)發(fā)到v2版本中
    exact: "group=dev"
  route:  # 路由
  -destination:
    name: v2
  -route:
   -destination:
     name: v1 

2.2 Mixer

Mixer在Istio架構(gòu)中不是必須的

Mixer分為Policy和Telemetry兩個子模塊，Policy用于向Envoy提供準(zhǔn)入策略控制，黑白名單控制，速率限制等相關(guān)策略；Telemetry為Envoy提供了數(shù)據(jù)上報(bào)和日志搜集服務(wù)，以用于監(jiān)控告警和日志查詢。

Telemetry介紹

Mixer是一個平臺無關(guān)的組件。Mixer的Telemetry 在整個服務(wù)網(wǎng)格中執(zhí)行訪問控制和策略使用，并從 Envoy 代理和其他服務(wù)收集遙測數(shù)據(jù)，流程如下圖所示。

• 遙測報(bào)告上報(bào)，比如從Envoy中收集數(shù)據(jù)[請求數(shù)據(jù)、使用時間、使用的協(xié)議等]，通過Adapater上

報(bào)給Promethues、Heapster等

說白了，就是數(shù)據(jù)收集，然后通過adapter上傳到監(jiān)控容器里面

policy介紹

policy是另外一個Mixer服務(wù)，和istio-telemetry基本上是完全相同的機(jī)制和流程。數(shù)據(jù)面在轉(zhuǎn)發(fā)服務(wù)的請求前調(diào)用istio-policy的Check接口是否允許訪問，Mixer 根據(jù)配置將請求轉(zhuǎn)發(fā)到對應(yīng)的 Adapter 做對應(yīng)檢查，給代理返回允許訪問還是拒絕?？梢詫尤缗漕~、授權(quán)、黑白名單等不同的控制后端，對服務(wù)間的訪問進(jìn)行可擴(kuò)展的控制。

• 策略控制：檢查請求釋放可以運(yùn)行訪問

2.3 Citadel

Citadel在Istio架構(gòu)中不是必須的

Istio的認(rèn)證授權(quán)機(jī)制主要是由Citadel完成，同時需要和其它組件一起配合，參與到其中的組件還有Pilot、Envoy、Mixer，它們四者在整個流程中的作用分別為：

• Citadel：用于負(fù)責(zé)密鑰和證書的管理，在創(chuàng)建服務(wù)時會將密鑰及證書下發(fā)至對應(yīng)的Envoy代理中；
• Pilot: 用于接收用戶定義的安全策略并將其整理下發(fā)至服務(wù)旁的Envoy代理中；
• Envoy：用于存儲Citadel下發(fā)的密鑰和證書，保障服務(wù)間的數(shù)據(jù)傳輸安全；
• Mixer: 負(fù)責(zé)核心功能為前置條件檢查和遙測報(bào)告上報(bào);

流程如下

具體工作流程可描述如下：

• Kubernetes某集群節(jié)點(diǎn)新部署了服務(wù)Service，此時集群中有兩個Pod被啟動，每個Pod由Envoy代理容器和Service容器構(gòu)成，在啟動過程中Istio的Citadel組件會將密鑰及證書依次下發(fā)至每個Pod中的Envoy代理容器中，以保證后續(xù)服務(wù)A，B之間的安全通信。
• 用戶通過Rules API下發(fā)安全策略至Pilot組件，Pilot組件通過Pilot-discovery進(jìn)程整理安全策略中Kubernetes服務(wù)注冊和配置信息并以Envoy API方式暴露給Envoy。
• Pod 中的Envoy代理會通過Envoy API方式定時去Pilot拉取安全策略配置信息，并將信息保存至Envoy代理容器中。
• 當(dāng)pod內(nèi)的服務(wù)相互調(diào)用時，會調(diào)用各自Envoy容器中的證書及密鑰實(shí)現(xiàn)服務(wù)間的通信，同時Envoy容器還會根據(jù)用戶下發(fā)的安全策略進(jìn)行更細(xì)粒度的訪問控制。
• Mixer在整個工作流中核心功能為前置條件檢查和遙測報(bào)告上報(bào)，在每次請求進(jìn)出服務(wù)時，服務(wù)中的Envoy代理會向Mixer發(fā)送check請求，檢查是否滿足一些前提條件，比如ACL檢查，白名單檢查，日志檢查等，如果前置條件檢查通過，處理完后再通過Envoy向Mixer上報(bào)日志，監(jiān)控等數(shù)據(jù)，從而完成審計(jì)工作。

使用場景：

在有一些場景中，對于安全要求是非常高的，比如支付，所以Citadel就是用來保證安全的。

回顧kubernetes API Server的功能：

* 提供了集群管理的REST API接口(包括認(rèn)證授權(quán)、數(shù)據(jù)校驗(yàn)以及集群狀態(tài)變更)；
* 提供其他模塊之間的數(shù)據(jù)交互和通信的樞紐（其他模塊通過API Server查詢或修改數(shù)據(jù)，只有API Server才直接操作etcd）;
* 資源配額控制的入口；
* 擁有完備的集群安全機(jī)制.

總結(jié)：

用于負(fù)責(zé)密鑰和證書的管理，在創(chuàng)建服務(wù)時會將密鑰及證書下發(fā)至對應(yīng)的Envoy代理中

2.4 Galley

Galley在istio架構(gòu)中不是必須的

Galley在控制面上向其他組件提供支持。Galley作為負(fù)責(zé)配置管理的組件，并將這些配置信息提供給管理面的 Pilot和 Mixer服務(wù)使用，這樣其他管理面組件只用和 Galley打交道，從而與底層平臺解耦。

galley優(yōu)點(diǎn)

• 配置統(tǒng)一管理，配置問題統(tǒng)一由galley負(fù)責(zé)
• 如果是相關(guān)的配置，可以增加復(fù)用
• 配置跟配置是相互隔離而且，而且配置也是權(quán)限控制，比如組件只能訪問自己的私有配置

MCP協(xié)議

Galley負(fù)責(zé)控制平面的配置分發(fā)主要依托于一一種協(xié)議，這個協(xié)議叫（MCP）

MCP提供了一套配置訂閱和分發(fā)的API，里面會包含這個幾個角色：

• source: 配置的提供端，在istio中Galley即是source 說白了就是Galley組件，它提供yaml配置
• sink:配置的消費(fèi)端，istio組件中Pilot和Mixer都屬于sink
• resource: source和sink關(guān)注的資源體，也就是yaml配置

Galley 代表其他的 Istio 控制平面組件，用來驗(yàn)證用戶編寫的 Istio API 配置。Galley 接管 Istio 獲取配置、 處理和分配組件的頂級責(zé)任。它將負(fù)責(zé)將其他的 Istio 組件與從底層平臺（例如 Kubernetes）獲取用戶配置的細(xì)節(jié)中隔離開來。
說白了：這樣其他控制平面（Pilot和 Mixer）面組件只用和 Galley打交道，從而與底層平臺解耦。

2.5 Sidecar-injector

Sidecar-injector 是負(fù)責(zé)自動注入的組件，只要開啟了自動注入，那么在創(chuàng)建pod的時候就會自動調(diào)用Sidecar-injector 服務(wù)

配置參數(shù)：istio-injection=enabled，我們后面會有案例演示

在istio中sidecar注入有兩種方式

• 需要使用istioctl命令手動注入 （不需要配置參數(shù)：istio-injection=enabled）
• 基于kubernetes自動注入（配置參數(shù)：istio-injection=enabled）

手動注入和自動注入會在istio安裝之后案例演示

兩種區(qū)別：

手動注入需要每次在執(zhí)行配置都需要加上istioctl命令

自動注入只需要做一下開啟參數(shù)即可

sidecar模式具有以下優(yōu)勢

• 把業(yè)務(wù)邏輯無關(guān)的功能抽取出來（比如通信），可以降低業(yè)務(wù)代碼的復(fù)雜度
• sidecar可以獨(dú)立升級、部署，與業(yè)務(wù)代碼解耦

注入流程

在 Kubernetes環(huán)境下，根據(jù)自動注入配置，Kube-apiserver在攔截到 Pod創(chuàng)建的請求時，會調(diào)用自動注入服務(wù) istio-sidecar-injector 生成 Sidecar 容器的描述并將其插入原 Pod的定義中，這樣，在創(chuàng)建的 Pod 內(nèi), 除了包括業(yè)務(wù)容器，還包括 Sidecar容器。這個注入過程對用戶透明，用戶使用原方式創(chuàng)建工作負(fù)載。

總結(jié)：sidecar模式具有以下優(yōu)勢

• 把業(yè)務(wù)邏輯無關(guān)的功能抽取出來（比如通信），可以降低業(yè)務(wù)代碼的復(fù)雜度
• sidecar可以獨(dú)立升級、部署，與業(yè)務(wù)代碼解耦

2.6 Proxy(Envoy)

Proxy是Istio數(shù)據(jù)平面的輕量代理。
Envoy是用C++開發(fā)的非常有影響力的輕量級高性能開源服務(wù)代理。作為服務(wù)網(wǎng)格的數(shù)據(jù)面，Envoy提供了動態(tài)服務(wù)發(fā)現(xiàn)、負(fù)載均衡、TLS、HTTP/2 及 gRPC代理、熔斷器、健康檢查、流量拆分、灰度發(fā)布、故障注入等功能。
Envoy 代理是唯一與數(shù)據(jù)平面流量交互的 Istio 組件。

Envoy組件解析

為了便于理解Istio中Envoy與服務(wù)的關(guān)系，如圖所示：

一個pod里面運(yùn)行了一個Envoy容器和service A容器，而Envoy容器內(nèi)部包含了兩個進(jìn)程，分別是Pilot-agent和Envoy兩個進(jìn)程

pilot-agent

pilot-agent跟Envoy打包在同一個docker鏡像里面

• pilot-agent作用

* 生成envoy配置
* 啟動envoy
* 監(jiān)控envoy的運(yùn)行狀態(tài)，比如envoy出錯是pilot-agent負(fù)責(zé)重啟envoy,huozhe envoy配置變更之后reload envoy

Envoy

負(fù)責(zé)攔截pod流量，負(fù)責(zé)從控制平面pilot組件獲取配置和服務(wù)發(fā)現(xiàn)，上報(bào)數(shù)據(jù)給mixer組件

2.7 Ingressgateway

ingressgateway 就是入口處的 Gateway，從網(wǎng)格外訪問網(wǎng)格內(nèi)的服務(wù)就是通過這個Gateway進(jìn)行的。ingressgateway比較特別，是一個Loadbalancer類型的Service，不同于其他服務(wù)組件只有一兩個端口，ingressgateway 開放了一組端口，這些就是網(wǎng)格內(nèi)服務(wù)的外部訪問端口。
網(wǎng)格入口網(wǎng)關(guān)ingressgateway和網(wǎng)格內(nèi)的 Sidecar是同樣的執(zhí)行體，也和網(wǎng)格內(nèi)的其他 Sidecar一樣從 Pilot處接收流量規(guī)則并執(zhí)行。因?yàn)槿肟谔幍牧髁慷甲哌@個服務(wù)。

流程圖如下

由于gateway暴露了一個端口，外部的請求就可以根據(jù)這個端口把請求發(fā)給gateway了然后由gateway把請求分發(fā)給網(wǎng)格內(nèi)部的pod上

2.8 其他組件

在Istio集群中一般還安裝grafana、Prometheus、Tracing組件，這些組件提供了Istio的調(diào)用鏈、監(jiān)控等功能，可以選擇安裝來完成完整的服務(wù)監(jiān)控管理功能。

總結(jié)文章來源地址http://www.zghlxwxcb.cn/news/detail-438974.html

主要介紹了一些常見的istio組件，其中有一些組件是istio默認(rèn)就已經(jīng)使用了，有一些組件我們后面也會來演示。

到了這里，關(guān)于云原生Istio架構(gòu)和組件介紹的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！