Istio 基礎(chǔ)架構(gòu)及應(yīng)用

前幾天被問到項目中使用的服務(wù)網(wǎng)格核心 Istio 的架構(gòu)及改進問題，一時語塞！??

當(dāng)時項目緊急只顧著調(diào)研方案及快速應(yīng)用了，并未對其清奇骨骼及豐膩肌理進行深入了解，Istio 是怎么進行流量攔截治理的，Istio 架構(gòu)都包含哪些組件，分別負(fù)責(zé)什么功能？

本著對行業(yè)發(fā)展主流技術(shù)的好奇和敏感，隨即系統(tǒng)性學(xué)習(xí)了解了下，分享給大家，有不對的地方還望見諒并幫忙批評指正~~

一、服務(wù)網(wǎng)格ServiceMesh

作為技術(shù)背景，談?wù)?Istio 之前不能免俗必得談及服務(wù)網(wǎng)格 ServiceMesh。

時下微服務(wù)大行其道，單體應(yīng)用被拆分為較多相對獨立的微小服務(wù)，單個服務(wù)的復(fù)雜度及維護成本大幅降低，卻碰壁了另外一個難題--眾多微服務(wù)之間的通信聯(lián)動管理及監(jiān)控，如服務(wù)發(fā)現(xiàn)、負(fù)載均衡、版本控制、故障轉(zhuǎn)移、灰度發(fā)布、熔斷限流及監(jiān)控追蹤等。

業(yè)界大牛們解決這個難題也經(jīng)過了多次架構(gòu)演進，大致分為服務(wù)內(nèi)嵌代理、代理分離多服務(wù)復(fù)用、代理和服務(wù)一對一匹配(sidecar 邊車模式) 三個階段。

Service Mesh 就是為微服務(wù)而生的專用基礎(chǔ)設(shè)施層，像網(wǎng)格一樣連接所有的微服務(wù)通信，是一套輕量級高性能網(wǎng)絡(luò)代理。它提供安全的、快速的、可靠地服務(wù)間通訊，與實際應(yīng)用部署一起，但對應(yīng)用透明。

二、Istio 核心架構(gòu)

ServiceMesh 和 sidecar 都是一種架構(gòu)思想，具體的技術(shù)生態(tài)比較龐大，Istio、Envoy、MOSN、Linkerd、Kong、Nginxmesh、Jaeger、Zipkin、Kiali、Grafana、Prometheus等等。我們今天不發(fā)散，集中看下 Istio。?

Istio 是由 IBM、Google 和 Lyft 開發(fā)的一套服務(wù)網(wǎng)格的開源實現(xiàn)。目前 Istio 市場占有率70%+，已經(jīng)算是事實上的服務(wù)網(wǎng)格技術(shù)標(biāo)準(zhǔn)。

Istio 默認(rèn)使用 Lyft 的 Envoy 作為數(shù)據(jù)平面 sidecar 控制器，控制平面控制器則主要包括 Pilot 司令官、Mixer 守護神、安全碉堡 Citadel 、配置中心 Galley 等。（Istio1.5之后整體架構(gòu)變動較大，將控制平面眾多組件合為一體收歸Istiod 統(tǒng)一控制，但為了更清楚的講述我們暫且先分開看）

Envoy數(shù)據(jù)代理

Envoy 是用 C++ 開發(fā)的高性能網(wǎng)絡(luò)代理，它是 Istio 數(shù)據(jù)平面的核心組件。

它作為 sidecar 和服務(wù)部署在同一個 Pod 中，通過 sidecar-injector 自動注入，通過容器啟動時初始化設(shè)定一堆 ipatables 規(guī)則來攔截代理服務(wù)網(wǎng)格中所有服務(wù)的入站和出站流量，從而進行相應(yīng)的服務(wù)及流量治理維護，這塊的詳細內(nèi)容上一篇文章中已經(jīng)詳細講述了，可以參見 ?從iptables談ServiceMesh流量攔截。

istio-iptables?-p?15001?-z?15006?-u?1337?-m?REDIRECT?-i?'*'?-x?""?-b?'*'

Pilot司令官

Pilot 是 Istio 控制平面流量管理的核心組件。管理和配置部署在 Istio 服務(wù)網(wǎng)格中的所有 Envoy 數(shù)據(jù)代理實例，允許用戶配置 Envoy 代理之間的流量轉(zhuǎn)發(fā)路由規(guī)則及故障轉(zhuǎn)移恢復(fù)如超時重試熔斷等。

Pilot-agent 代理守護進程

Pilot-agent 在啟動 Envoy 時將 xDS server 信息通過靜態(tài)資源的方式配置到 Envoy 的初始化配置文件中，Envoy 啟動后再通過 xDS server 獲取網(wǎng)格中的服務(wù)信息、路由規(guī)則等動態(tài)資源。

$?ps?-ef
UID??????????PID????PPID??C?STIME?TTY??????????TIME?CMD
istio-p+???????1???????0??0?Mar25??????????00:30:10?/usr/local/bin/pilot-agent?proxy?sidecar?--domain?bpd-ie.svc
istio-p+??????70???????1?30?Mar25??????????16-14:25:11?/usr/local/bin/envoy?-c?etc/istio/proxy/envoy-rev0.json?-
istio-p+??????95???????0??0?08:24?pts/0????00:00:00?/bin/sh
istio-p+?????104??????95??0?08:33?pts/0????00:00:00?ps?-ef

Mixer守護神

Mixer 是 Istio 中負(fù)責(zé)執(zhí)行服務(wù)間的訪問策略和收集遙測數(shù)據(jù)的組件。服務(wù)間請求轉(zhuǎn)發(fā)時，Envoy 會對 Mixer 發(fā)起 check 和 report 兩次請求執(zhí)行訪問策略與管理配額，并在請求轉(zhuǎn)發(fā)后上報遙測數(shù)據(jù)。我們看到的可視化的日志監(jiān)控，jaeger、zipkin、kiali、prometheus 等基礎(chǔ)設(shè)施的數(shù)據(jù)都是Mixer 通過 Adapter 機制遙測上報的。

Citadel安全碉堡

Citadel 主要負(fù)責(zé) Istio 的安全問題。負(fù)責(zé)證書的頒發(fā)及校驗，通過內(nèi)置身份和憑證管理提供強大的服務(wù)間和最終用戶身份驗證。

Galley配置中心

Galley 主要負(fù)責(zé)用戶配置信息的管理，從底層平臺接受并驗證分發(fā)配置信息到其他組件。

Istio1.5 版本后架構(gòu)變動較大，全面擁抱變化的一個版本，重建了整個控制平面，將各個組件多進程合并打造了全新的部署模式 istiod，降低部署成本；摒棄了拖累系統(tǒng)性能的 Mixer；保證兼容性也不忘持續(xù)優(yōu)化和引入新的功能。在徹底拋棄歷史包袱的同時，Istio 團隊也用他們的勇氣踐行了敏捷開發(fā)的真諦，并且功能、性能、靈活性等各方面都得到了改進。

三、Istio 應(yīng)用

接下來結(jié)合我們項目中實際應(yīng)用簡單介紹 Istio 的一些規(guī)則配置用法，主要包括 Virtualservice、DestinationRule、GateWay、ServiceEntry、Sidecar等。

先看基礎(chǔ)服務(wù)搭建好（我這里用的是Istio 1.7）以后系統(tǒng)中都有哪些組件（不一定都一樣，可以自己選擇遙測相關(guān)組件）。搭建過程略，大家可以參考官網(wǎng)詳細說明。

kubectl?get?svc?-n?istio-system?--kubeconfig?~/.kube/config.thanos

VirtualService

定義了一組路由規(guī)則，當(dāng)流量進入時逐個規(guī)則進行匹配，直到匹配成功后將流量轉(zhuǎn)發(fā)給給定的路由地址，同時可以進行灰度發(fā)布、超時重試、故障轉(zhuǎn)移、流量鏡像等多種服務(wù)治理。

apiVersion:?networking.istio.io/v1beta1
kind:?VirtualService
metadata:
??name:?**-virtualservice
??namespace:?**
spec:
??hosts:
????-?**.**.svc.cluster.local
????-?**.**
??gateways:
????-?istio-system/default-gateway
????-?mesh
??http:
????-?match:???
????????-?port:?9090???##?rpc走9090端口
??????route:
????????-?destination:
????????????host:?**.**.svc.cluster.local
????????????port:
??????????????number:?9090
????-?route:??????????##?http默認(rèn)走8080端口
????????-?destination:
????????????host:?**.**.svc.cluster.local
????????????port:
??????????????number:?8080

還可以應(yīng)用更多治理策略, 下面簡單列舉幾個，具體參見官網(wǎng)規(guī)則。

????-?match:
????????-?uri:???##?流量重定向
????????????prefix:?/checkparam
????????rewrite:
????????????uri:?/check
????????route:
????????-?destination:
????????????host:?**
????????????subset:?v1???##灰度
????????timeout:?0.5s??##?超時重試?重試條件?重試間隔?重試次數(shù)等
????????retries:
??????????attempts:?3
??????????perTryTimeout:?1s
??????????retryOn:?5xx
????????mirror:???????##?流量鏡像
??????????host:?**
??????????subset:?v2
????????mirror_percent:?100??##鏡像比例

DestinationRule

定義了網(wǎng)格中某個 Service 對外提供服務(wù)的策略及規(guī)則，這包括負(fù)載均衡策略、異常點檢測、熔斷控制、訪問連接池等。負(fù)載均衡策略支持簡單的負(fù)載策略（ROUND_ROBIN、LEAST_CONN、RANDOM、PASSTHROUGH）、一致性 Hash 策略和區(qū)域性負(fù)載均衡策略。我們服務(wù)中用的比較簡單這里就不列了。

Gateway

定義了所有 HTTP/TCP 流量進入網(wǎng)格或者從網(wǎng)格中出站的統(tǒng)一入口和出口。它描述了一組對外公開的端口、協(xié)議、負(fù)載均衡、以及 SNI 配置。Istio Gateway 包括 Ingress Gateway 與 Egress Gateway，分別用來配置網(wǎng)格的入口流量與出口流量。這個可以多服務(wù)復(fù)用。

ServiceEntry

可以將網(wǎng)格外的服務(wù)注冊到 Istio 的注冊表中去，這樣就可以把外部服務(wù)當(dāng)做網(wǎng)格內(nèi)部的服務(wù)一樣進行管理和操作。

Sidecar

主要用來定義控制 Envoy 代理轉(zhuǎn)發(fā)和接收的端口協(xié)議等，并可以限制 Sidecar 出站流量允許到達的目標(biāo)服務(wù)集合。

最終，我們服務(wù)通過 Kiali 展示的服務(wù)拓?fù)鋱D如下所示。

相應(yīng)的 jaeger 和 prometheus 等展示的追蹤及監(jiān)控也都一應(yīng)俱全，這里就不展示了。

總結(jié)

結(jié)合服務(wù)網(wǎng)格的實際應(yīng)用，我們一起回顧了微服務(wù)治理的架構(gòu)演進，一起簡單探討了 Istio 的核心架構(gòu)及1.5版本以后的變革，進而簡單介紹了 Istio 服務(wù)治理的一些簡單應(yīng)用規(guī)則配置。至于單個組件的具體工作深入原理后面有機會我們再逐個探討。本人也是一邊學(xué)一邊用，過程中如果有什么描述不恰當(dāng)?shù)牡胤竭€請各位看官見諒。

[1]Istio架構(gòu) https://istio.io/latest/docs/ops/deployment/architecture/

[2] 《云原生服務(wù)網(wǎng)格Istio》????? https://cloud.tencent.com/developer/article/1519639?from=article.detail.1519637