Istio架構詳解
- 2020 年 4 月 29 日
- 筆記
- Service Mesh
Istio架構及其組件概述
Istio 架構總體來說分為控制面和數據面兩部分。
控制面是 Istio 的核心，管理 Istio 的所有功能，主要包括Pilot、Mixer、Citadel等服務組件;
數據面由伴隨每個應用程式部署的代理程式Envoy組成，執行針對應用程式的治理邏輯。常被稱為「Sidecar」。Sidecar 一般和業務容器綁定在一起（在Kubernets中自動注入方式到業務pod中），來劫持業務應用容器的流量，並接受控制面組件的控制，同時會向控制面輸出日誌、跟蹤及監控數據。
Istio 的主要組件及其相互關係大致如圖所示（摘自《雲原生服務網格Istio》）。
結合上圖我們來理解Istio的各組件的功能及相互之間的協作方式。
1. 自動注入：在創建應用程式時自動注入 Sidecar代理Envoy程式。在 Kubernetes中創建 Pod時，Kube-apiserver調用控制面組件的 Sidecar-Injector服務，自動修改應用程式的描述資訊並注入Sidecar。在 真正創建Pod時，在創建業務容器的Pod中同時創建Sidecar容器。
2. 流量攔截：在 Pod 初始化時設置 iptables 規則，基於配置的iptables規則攔截業務容器的Inbound流量和Outbound流量到Sidecar上。而應用程式感知不到Sidecar的存在，還以原本的方式 進行互相訪問。上圖中，流出frontend服務的流量會被 frontend服務側的 Envoy攔截，而當流量到達forecast容器時，Inbound流量被forecast 服務側的Envoy攔截。
3. 服務發現：服務發起方的 Envoy 調用控制面組件 Pilot 的服務發現介面獲取目標服務的實例列表。上圖中，frontend 服務側的 Envoy 通過 Pilot 的服務發現介面得到forecast服務各個實例的地址。
4. 負載均衡：服務發起方的Envoy根據配置的負載均衡策略選擇服務實例，並連接對應的實例地址。上圖中，數據面的各個Envoy從Pilot中獲取forecast服務的負載均衡配置，並執行負載均衡動作。
5. 流量治理：Envoy 從 Pilot 中獲取配置的流量規則，在攔截到 Inbound 流量和Outbound 流量時執行治理邏輯。上圖中， frontend 服務側的 Envoy 從 Pilot 中獲取流量治理規則，並根據該流量治理規則將不同特徵的流量分發到forecast服務的v1或v2版本。
6. 訪問安全：在服務間訪問時通過雙方的Envoy進行雙向認證和通道加密，並基於服務的身份進行授權管理。上圖中，Pilot下發安全相關配置，在frontend服務和forecast服務的Envoy上自動載入證書和密鑰來實現雙向認證，其中的證書和密鑰由另一個管理面組件 Citadel維護。
7. 服務監測：在服務間通訊時，通訊雙方的Envoy都會連接管理面組件Mixer上報訪問數據，並通過Mixer將數據轉發給對應的監控後端。上圖中，frontend服務對forecast服務的訪問監控指標、日誌和調用鏈都可以通過這種方式收集到對應的監控後端。
8. 策略執行：在進行服務訪問時，通過Mixer連接後端服務來控制服務間的訪問，判斷對訪問是放行還是拒絕。上圖中，Mixer 後端可以對接一個限流服務對從frontend服務到forecast服務的訪問進行速率控制等操作。
9. 外部訪問：在網格的入口處有一個Envoy扮演入口網關的角 色。上圖中，外部服務通過Gateway訪問入口服務 frontend，對 frontend服務的負載均衡和一些流量治理策略都在這個Gateway上執行。
Istio各組件詳解
Istio服務組件有不少，從上面的流程中也基本能看出每個組件如何協作的，下面具體講解每個組件的具體用途和功能。
$ kubectl get svc -n istio-system |grep istio |awk '{print $1}' istio-citadel istio-egressgateway istio-galley istio-ingressgateway istio-pilot istio-policy istio-sidecar-injector istio-telemetry istiod
Pilot
Pilot 是 Istio 的主要控制組件，下髮指令控制客戶端。在整個系統中，Pilot 完成以下任務：
• 從 Kubernetes 或者其他平台的註冊中心獲取服務資訊，完成服務發現過程。
• 讀取 Istio 的各項控制配置，在進行轉換之後，將其發給數據面進行實施。
Pilot 將配置內容下發給數據面的 Envoy，Envoy 根據 Pilot 指令，將路由、服務、監聽、集群等定義資訊轉換為本地配置，完成控制行為的落地。
Telemetry
Telemetry是專門用於收集監測數據的Mixer服務組件。Istio控制面部署了兩個Mixer組件：istio- telemetry和istio-policy，分別處理監測數據的收集和策略的執行，兩個組件的 Pod 鏡像都是 mixer。
從調用時機上來說，Pilot管理的是配置數據，在配置改變時和數據面交互即可，對於Mixer來說，在服務間交互時Envoy都會對Mixer進行一次調用，因此這是一種實時管理。
如圖所示，當網格中的兩個服務間有調用發生時，服務的代理 Envoy就會上報監測數據給 istio-telemetry 服務組件，istio-telemetry 則根據配置將生成訪問的 Metric等數據分發給後端的監測服務，如Prometheus等。
Policy
Policy是另外一個Mixer服務，和Telemetry基本上是完全相同的機制和流程。如圖所示，數據面在轉發服務的請求前調用 istio-policy的Check介面檢查是否允許訪問，把結果返回給Envoy。可以對接如配額、授權、黑白名單等不同的控制後端，對服務間的訪問進行可擴展的控制。
Citadel
Citadel是 Istio的核心安全組件，提供了自動生 成、分發、輪換與撤銷密鑰和證書功能。Citadel一直監聽 Kube- apiserver，以 Secret的形式為每個服務都生成證書密鑰，並在Pod創建時掛載到Pod上，代理容器使用這些文件來做服務身份認證，進而代 理兩端服務實現雙向TLS認證、通道加密、訪問授權等安全功能。如圖 所示，frontend 服 務對 forecast 服務的訪問用到了HTTP方式，通過配置即可對服務增加認證功能，雙方的Envoy會建立雙向認證的TLS通道，從而在服務間啟用雙向認證的HTTPS。
Sidecar-injector
Sidecar-injector是負責自動注入的組件，只要開啟了自動注 入，在Pod創建時就會自動調用istio-sidecar-injector向Pod中注入Sidecar 容器。
在 Kubernetes環境下，根據自動注入配置，Kube-apiserver在攔截到 Pod創建的請求時，會調用自動注入服務 istio-sidecar-injector 生成 Sidecar 容器的描述並將其插入原 Pod的定義中，這樣，在創建的 Pod 內除了包括業務容器，還包括 Sidecar容器，這個注入過程對用戶透明。
Proxy
Proxy的運行容器時istio-proxy，容器中除了有Envoy，還有一個pilot-agent的守護進程。
Envoy是用C++開發的非常有影響力的輕量級高性能開源服務代理。作為服務網格的數據面，Envoy提供了動態服務發現、負載均 衡、TLS、HTTP/2 及 gRPC代理、熔斷器、健康檢查、流量拆分、灰度發布、故障注入等功能，本篇描述的大部分治理能力最終都落實到 Envoy的實現上。
在Istio中，規則的描述對象都是類似forecast服務的被訪問者，但是真正的規則執行位置對於不同類型的動作可能不同，可能在被訪問服務的 Sidecar 攔截到 Inbound 流量時執行，也可能在訪問者的Sidecar 攔截到Outbound流量時執行，一般後者居多。當給forecast服務定義流量規則時，所有訪問forecast服務的Sidecar都收到規則，並且執行相同的治理邏輯，從而對目標服務執行一致的治理。下表列出了常用的服務訪問治理規則和其執行位置。
Ingressgateway
Ingressgateway 就是入口處的 Gateway，從網格外訪問網格內的服務就是通過這個Gateway進行的。istio-ingressgateway是一個Loadbalancer類型的Service，不同於其他服務組件只有一兩個端 口，istio-ingressgateway 開放了一組埠，這些就是網格內服務的外部訪問埠。如下圖所示，網格入口網關istio-ingressgateway的負載和網格內的Sidecar是同樣的執行流程，也和網格內的其他 Sidecar一樣從 Pilot處接收流量規則並執行。
其他組件
除了以「istio」為前綴的Istio自有組件，在集群中一般還安裝Jaeger-agent、Jaeger-collector、Jaeger-query、Kiali、Prometheus、Grafana、 Tracing、Zipkin等組件，這些組件提供了Istio的調用鏈、監控等功能，可以選擇安裝來完成完整的服務監控管理功能。
