轉(zhuǎn)載：https://juejin.im/post/5c5408ee6fb9a049f154a160

ServiceMesher 2019年02月01日 閱讀 70

騰訊云容器團隊內(nèi)部Istio專題分享

本文轉(zhuǎn)載自：zhongfox.github.io/2019/01/30/…

今天分享的內(nèi)容主要包括以下4個話題:

• 1 Service Mesh: 下一代微服務(wù)

• 2 Istio: 第二代 Service Mesh

• 3 Istio 數(shù)據(jù)面

• 4 Istio 控制面

首先我會和大家一起過一下 Service Mesh的發(fā)展歷程, 并看看Istio 為 Service Mesh 帶來了什么, 這部分相對比較輕松. 接下來我將和大家分析一下Istio的主要架構(gòu), 重點是數(shù)據(jù)面和控制面的實現(xiàn), 包括sidecar的注入, 流量攔截, xDS介紹, Istio流量模型, 分布式跟蹤, Mixer 的適配器模型等等, 中間也會穿插著 istio的現(xiàn)場使用demo.

1. Service Mesh: 下一代微服務(wù)

• 應(yīng)用通信模式演進

• Service Mesh(服務(wù)網(wǎng)格)的出現(xiàn)

• 第二代 Service Mesh

• Service Mesh 的定義

• Service Mesh 產(chǎn)品簡史

• 國內(nèi)Service Mesh 發(fā)展情況

1.1 應(yīng)用通信模式演進: 網(wǎng)絡(luò)流控進入操作系統(tǒng)

在計算機網(wǎng)絡(luò)發(fā)展的初期, 開發(fā)人員需要在自己的代碼中處理服務(wù)器之間的網(wǎng)絡(luò)連接問題, 包括流量控制, 緩存隊列, 數(shù)據(jù)加密等. 在這段時間內(nèi)底層網(wǎng)絡(luò)邏輯和業(yè)務(wù)邏輯是混雜在一起.

隨著技術(shù)的發(fā)展，TCP/IP 等網(wǎng)絡(luò)標(biāo)準(zhǔn)的出現(xiàn)解決了流量控制等問題。盡管網(wǎng)絡(luò)邏輯代碼依然存在，但已經(jīng)從應(yīng)用程序里抽離出來，成為操作系統(tǒng)網(wǎng)絡(luò)層的一部分, 形成了經(jīng)典的網(wǎng)絡(luò)分層模式.

1.2 應(yīng)用通信模式演進: 微服務(wù)架構(gòu)的出現(xiàn)

微服務(wù)架構(gòu)是更為復(fù)雜的分布式系統(tǒng)，它給運維帶來了更多挑戰(zhàn), 這些挑戰(zhàn)主要包括資源的有效管理和服務(wù)之間的治理, 如:

• 服務(wù)注冊, 服務(wù)發(fā)現(xiàn)

• 服務(wù)伸縮

• 健康檢查

• 快速部署

• 服務(wù)容錯: 斷路器, 限流, 隔離艙, 熔斷保護, 服務(wù)降級等等

• 認(rèn)證和授權(quán)

• 灰度發(fā)布方案

• 服務(wù)調(diào)用可觀測性, 指標(biāo)收集

• 配置管理

在微服務(wù)架構(gòu)的實現(xiàn)中，為提升效率和降低門檻，應(yīng)用開發(fā)者會基于微服務(wù)框架來實現(xiàn)微服務(wù)。微服務(wù)框架一定程度上為使用者屏蔽了底層網(wǎng)絡(luò)的復(fù)雜性及分布式場景下的不確定性。通過API/SDK的方式提供服務(wù)注冊發(fā)現(xiàn)、服務(wù)RPC通信、服務(wù)配置管理、服務(wù)負(fù)載均衡、路由限流、容錯、服務(wù)監(jiān)控及治理、服務(wù)發(fā)布及升級等通用能力, 比較典型的產(chǎn)品有:

• 分布式RPC通信框架: COBRA, WebServices, Thrift, GRPC 等

• 服務(wù)治理特定領(lǐng)域的類庫和解決方案: Hystrix, Zookeeper, Zipkin, Sentinel 等

• 對多種方案進行整合的微服務(wù)框架: SpringCloud、Finagle、Dubbox 等

實施微服務(wù)的成本往往會超出企業(yè)的預(yù)期(內(nèi)容多, 門檻高), 花在服務(wù)治理上的時間成本甚至可能高過進行產(chǎn)品研發(fā)的時間. 另外上述的方案會限制可用的工具、運行時和編程語言。微服務(wù)軟件庫一般專注于某個平臺, 這使得異構(gòu)系統(tǒng)難以兼容, 存在重復(fù)的工作, 系統(tǒng)缺乏可移植性.

Docker 和Kubernetes 技術(shù)的流行, 為Pass資源的分配管理和服務(wù)的部署提供了新的解決方案, 但是微服務(wù)領(lǐng)域的其他服務(wù)治理問題仍然存在.

1.3 Sidecar 模式的興起

Sidecar(有時會叫做agent) 在原有的客戶端和服務(wù)端之間加多了一個代理, 為應(yīng)用程序提供的額外的功能, 如服務(wù)發(fā)現(xiàn), 路由代理, 認(rèn)證授權(quán), 鏈路跟蹤 等等.

業(yè)界使用Sidecar 的一些先例:

• 2013 年，Airbnb 開發(fā)了Synapse 和 Nerve，是sidecar的一種開源實現(xiàn)

• 2014 年, Netflix 發(fā)布了Prana，它也是一個sidecar，可以讓非 JVM 應(yīng)用接入他們的 NetflixOSS 生態(tài)系統(tǒng)

1.4 Service Mesh(服務(wù)網(wǎng)格)的出現(xiàn)

直觀地看, Sidecar 到 Service Mesh 是一個規(guī)模的升級, 不過Service Mesh更強調(diào)的是:

• 不再將Sidecar(代理)視為單獨的組件，而是強調(diào)由這些代理連接而形成的網(wǎng)絡(luò)

• 基礎(chǔ)設(shè)施, 對應(yīng)用程序透明

1.5 Service Mesh 定義

以下是Linkerd的CEO Willian Morgan給出的Service Mesh的定義:

A Service Mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the Service Mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

服務(wù)網(wǎng)格（Service Mesh）是致力于解決服務(wù)間通訊的基礎(chǔ)設(shè)施層。它負(fù)責(zé)在現(xiàn)代云原生應(yīng)用程序的復(fù)雜服務(wù)拓?fù)鋪砜煽康貍鬟f請求。實際上，Service Mesh 通常是通過一組輕量級網(wǎng)絡(luò)代理（Sidecar proxy），與應(yīng)用程序代碼部署在一起來實現(xiàn)，且對應(yīng)用程序透明。

1.6 第二代 Service Mesh

控制面板對每一個代理實例了如指掌，通過控制面板可以實現(xiàn)代理的訪問控制和度量指標(biāo)收集, 提升了服務(wù)網(wǎng)格的可觀測性和管控能力, Istio 正是這類系統(tǒng)最為突出的代表.

1.7 Service Mesh 產(chǎn)品簡史

• 2016 年 1 月 15 日，前 Twitter 的基礎(chǔ)設(shè)施工程師 William Morgan 和 Oliver Gould，在 GitHub 上發(fā)布了 Linkerd 0.0.7 版本，采用Scala編寫, 他們同時組建了一個創(chuàng)業(yè)小公司 Buoyant，這是業(yè)界公認(rèn)的第一個Service Mesh

• 2016 年，Matt Klein在 Lyft 默默地進行 Envoy 的開發(fā)。Envoy 誕生的時間其實要比 Linkerd 更早一些，只是在 Lyft 內(nèi)部不為人所知

• 2016 年 9 月 29 日在 SF Microservices 上，“Service Mesh”這個詞匯第一次在公開場合被使用。這標(biāo)志著“Service Mesh”這個詞，從 Buoyant 公司走向社區(qū).

• 2016 年 9 月 13 日，Matt Klein 宣布 Envoy 在 GitHub 開源，直接發(fā)布 1.0.0 版本。

• 2016 年下半年，Linkerd 陸續(xù)發(fā)布了 0.8 和 0.9 版本，開始支持 HTTP/2 和 gRPC，1.0 發(fā)布在即；同時，借助 Service Mesh 在社區(qū)的認(rèn)可度，Linkerd 在年底開始申請加入 CNCF

• 2017 年 1 月 23 日，Linkerd 加入 CNCF。

• 2017 年 3 月 7 日，Linkerd 宣布完成千億次產(chǎn)品請求

• 2017 年 4 月 25 日，Linkerd 1.0 版本發(fā)布

• 2017 年 7 月 11 日，Linkerd 發(fā)布版本 1.1.1，宣布和 Istio 項目集成

• 2017 年 9 月, nginx突然宣布要搞出一個Servicemesh來, Nginmesh: github.com/nginxinc/ng…, 可以作為istio的數(shù)據(jù)面, 不過這個項目目前處于不活躍開發(fā)(This project is no longer under active development)

• 2017 年 12 月 5 日，Conduit 0.1.0 版本發(fā)布

Envoy 和 Linkerd 都是在數(shù)據(jù)面上的實現(xiàn), 屬于同一個層面的競爭, 是用 C++ 語言實現(xiàn)的，在性能和資源消耗上要比采用 Scala 語言實現(xiàn)的 Linkerd 小，這一點對于延遲敏感型和資源敏的服務(wù)尤為重要.

Envoy 對 作為 Istio 的標(biāo)準(zhǔn)數(shù)據(jù)面實現(xiàn), 其最主要的貢獻是提供了一套標(biāo)準(zhǔn)數(shù)據(jù)面API, 將服務(wù)信息和流量規(guī)則下發(fā)到數(shù)據(jù)面的sidecar中, 另外Envoy還支持熱重啟. Istio早期采用了Envoy v1 API，目前的版本中則使用V2 API，V1已被廢棄.

通過采用該標(biāo)準(zhǔn)API，Istio將控制面和數(shù)據(jù)面進行了解耦，為多種數(shù)據(jù)面sidecar實現(xiàn)提供了可能性。事實上基于該標(biāo)準(zhǔn)API已經(jīng)實現(xiàn)了多種Sidecar代理和Istio的集成，除Istio目前集成的Envoy外，還可以和Linkerd, Nginmesh等第三方通信代理進行集成，也可以基于該API自己編寫Sidecar實現(xiàn).

將控制面和數(shù)據(jù)面解耦是Istio后來居上，風(fēng)頭超過Service mesh鼻祖Linkerd的一招妙棋。Istio站在了控制面的高度上，而Linkerd則成為了可選的一種sidecar實現(xiàn).

Conduit 的整體架構(gòu)和 Istio 一致，借鑒了 Istio 數(shù)據(jù)平面 + 控制平面的設(shè)計，而且選擇了 Rust 編程語言來實現(xiàn)數(shù)據(jù)平面，以達(dá)成 Conduit 宣稱的更輕、更快和超低資源占用.

1.8 似曾相識的競爭格局

KubernetesIstio

領(lǐng)域	容器編排	服務(wù)網(wǎng)格
主要競品	Swarm, Mesos	Linkerd, Conduit
主要盟友	RedHat, CoreOS	IBM, Lyft
主要競爭對手	Docker 公司	Buoyant 公司
標(biāo)準(zhǔn)化	OCI: runtime spec, image spec	XDS
插件化	CNI, CRI	Istio CNI, Mixer Adapter
結(jié)果	Kubernetes 成為容器編排事實標(biāo)準(zhǔn)	?

google 主導(dǎo)的Kubernetes 在容器編排領(lǐng)域取得了完勝, 目前在服務(wù)網(wǎng)格領(lǐng)域的打法如出一轍, 社區(qū)對Istio前景也比較看好.

Istio CNI 計劃在1.1 作為實驗特性, 用戶可以通過擴展方式定制sidecar的網(wǎng)絡(luò).

1.9 國內(nèi)Service Mesh 發(fā)展情況

• 螞蟻金服開源SOFAMesh：

  • github.com/alipay/sofa…

  • 從istio fork

  • 使用Golang語言開發(fā)全新的Sidecar，替代Envoy

  • 為了避免Mixer帶來的性能瓶頸，合并Mixer部分功能進入Sidecar

  • Pilot和Citadel模塊進行了大幅的擴展和增強

  • 擴展RPC協(xié)議: SOFARPC/HSF/Dubbo

• 華為:

  • go-chassis: github.com/go-chassis/… golang 微服務(wù)框架, 支持istio平臺

  • mesher: github.com/go-mesh/mes… mesh 數(shù)據(jù)面解決方案

  • 國內(nèi)首家提供Service Mesh公共服務(wù)的云廠商

  • 目前(2019年1月)公有云Istio 產(chǎn)品線上已經(jīng)支持申請公測, 產(chǎn)品形態(tài)比較完善

• 騰訊云 TSF:

  • 基于 Istio、envoy 進行改造

  • 支持 Kubernetes、虛擬機以及裸金屬的服務(wù)

  • 對 Istio 的能力進行了擴展和增強, 對 Consul 的完整適配

  • 對于其他二進制協(xié)議進行擴展支持

• 唯品會

  • OSP (Open Service Platform)

• 新浪:

  • Motan: 是一套基于java開發(fā)的RPC框架, Weibo Mesh 是基于Motan

2. Istio: 第二代 Service Mesh

Istio來自希臘語，英文意思是「sail」, 意為「啟航」

• 2.1 Istio 架構(gòu)

• 2.2 核心功能

• 2.3 Istio 演示: BookInfo

2.1 Istio 架構(gòu)

Istio Architecture（圖片來自Isio官網(wǎng)文檔)

• 數(shù)據(jù)面

  • Sidecar

• 控制面

  • Pilot：服務(wù)發(fā)現(xiàn)、流量管理

  • Mixer：訪問控制、遙測

  • Citadel：終端用戶認(rèn)證、流量加密

2.2 核心功能

• 流量管理

• 安全

• 可觀察性

• 多平臺支持

• 集成和定制

下面是我對Istio架構(gòu)總結(jié)的思維導(dǎo)圖:

2.3 Istio 演示: BookInfo

以下是Istio官網(wǎng)經(jīng)典的 BookInfo Demo, 這是一個多語言組成的異構(gòu)微服務(wù)系統(tǒng):

Bookinfo Application（圖片來自Isio官網(wǎng)文檔)

下面我將現(xiàn)場給大家進行演示, 從demo安裝開始, 并體驗一下istio的流控功能:

使用helm管理istio

下載istio release: istio.io/docs/setup/…

安裝istio:

1kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml2helm install install/kubernetes/helm/istio --name istio --namespace istio-system復(fù)制代碼

注意事項, 若要開啟sidecar自動注入功能, 需要:

• 確保 kube-apiserver 啟動參數(shù) 開啟了ValidatingAdmissionWebhook 和 MutatingAdmissionWebhook

• 給namespace 增加 label: kubectl label namespace default istio-injection=enabled

• 同時還要保證 kube-apiserver 的 aggregator layer 開啟: --enable-aggregator-routing=true 且證書和api server連通性正確設(shè)置.

如需卸載istio:

1helm delete --purge istio2kubectl delete -f install/kubernetes/helm/istio/templates/crds.yaml -n istio-system復(fù)制代碼

更多安裝選擇請參考: istio.io/docs/setup/…

安裝Bookinfo Demo:

Bookinfo 是一個多語言異構(gòu)的微服務(wù)demo, 其中 productpage 微服務(wù)會調(diào)用 details 和 reviews 兩個微服務(wù), reviews 會調(diào)用ratings 微服務(wù), reviews 微服務(wù)有 3 個版本. 關(guān)于此項目更多細(xì)節(jié)請參考: istio.io/docs/exampl…

部署應(yīng)用:

1kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml復(fù)制代碼

這將創(chuàng)建 productpage, details, ratings, reviews 對應(yīng)的deployments 和 service, 其中reviews 有三個deployments, 代表三個不同的版本.

1 % kubectl get pod2NAME READY STATUS RESTARTS AGE3details-v1-6865b9b99d-mnxbt 2/2 Running 0 1m4productpage-v1-f8c8fb8-zjbhh 2/2 Running 0 59s5ratings-v1-77f657f55d-95rcz 2/2 Running 0 1m6reviews-v1-6b7f6db5c5-zqvkn 2/2 Running 0 59s7reviews-v2-7ff5966b99-lw72l 2/2 Running 0 59s8reviews-v3-5df889bcff-w9v7g 2/2 Running 0 59s9?10 % kubectl get svc11NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE12details ClusterIP 172.18.255.240 <none> 9080/TCP 1m13productpage ClusterIP 172.18.255.137 <none> 9080/TCP 1m14ratings ClusterIP 172.18.255.41 <none> 9080/TCP 1m15reviews ClusterIP 172.18.255.140 <none> 9080/TCP 1m復(fù)制代碼

對入口流量進行配置:

1kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml復(fù)制代碼

該操作會創(chuàng)建bookinfo-gateway 的Gateway, 并將流量發(fā)送到productpage服務(wù)

1kubectl get gateway2NAME AGE3bookinfo-gateway 1m復(fù)制代碼

此時通過bookinfo-gateway 對應(yīng)的LB或者nodeport 訪問/productpage 頁面, 可以看到三個版本的reviews服務(wù)在隨機切換

基于權(quán)重的路由

通過CRD DestinationRule創(chuàng)建3 個reviews 子版本:

1kubectl apply -f samples/bookinfo/networking/destination-rule-reviews.yaml復(fù)制代碼

通過CRD VirtualService 調(diào)整個 reviews 服務(wù)子版本的流量比例, 設(shè)置 v1 和 v3 各占 50%

1kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml復(fù)制代碼

刷新頁面, 可以看到無法再看到reviews v2的內(nèi)容, 頁面在v1和v3之間切換.

基于內(nèi)容路由

修改reviews CRD, 將jason 登錄的用戶版本路由到v2, 其他用戶路由到版本v3.

1kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml復(fù)制代碼

刷新頁面, 使用jason登錄的用戶, 將看到v2 黑色星星版本, 其他用戶將看到v3 紅色星星版本.

更多BookInfo 示例, 請參閱: istio.io/docs/exampl…, 若要刪除應(yīng)用: 執(zhí)行腳本 ./samples/bookinfo/platform/kube/cleanup.sh

3. Istio 數(shù)據(jù)面

• 3.1 數(shù)據(jù)面組件

• 3.2 sidecar 流量劫持原理

• 3.3 數(shù)據(jù)面標(biāo)準(zhǔn)API: xDS

• 3.4 分布式跟蹤

3.1 數(shù)據(jù)面組件

Istio 注入sidecar實現(xiàn):

• 自動注入: 利用 Kubernetes Dynamic Admission Webhooks 對 新建的pod 進行注入: init container + sidecar

• 手動注入: 使用istioctl kube-inject

注入Pod內(nèi)容:

• istio-init: 通過配置iptables來劫持Pod中的流量

• istio-proxy: 兩個進程pilot-agent和envoy, pilot-agent 進行初始化并啟動envoy

Sidecar 自動注入實現(xiàn)

Istio 利用 Kubernetes Dynamic Admission Webhooks 對pod 進行sidecar注入

查看istio 對這2個Webhooks 的配置 ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration:

1% kubectl get ValidatingWebhookConfiguration -oyaml2% kubectl get mutatingWebhookConfiguration -oyaml復(fù)制代碼

可以看出:

• 命名空間istio-system 中的服務(wù) istio-galley, 通過路由/admitpilot, 處理config.istio.io部分, rbac.istio.io, authentication.istio.io, networking.istio.io等資源的Validating 工作

• 命名空間istio-system 中的服務(wù) istio-galley, 通過路由/admitmixer, 處理其他config.istio.io資源的Validating 工作

• 命名空間istio-system 中的服務(wù) istio-sidecar-injector, 通過路由/inject, 處理其他v1/pods的CREATE, 同時需要滿足命名空間istio-injection: enabled

istio-init

數(shù)據(jù)面的每個Pod會被注入一個名為istio-init 的initContainer, initContrainer是K8S提供的機制，用于在Pod中執(zhí)行一些初始化任務(wù).在Initialcontainer執(zhí)行完畢并退出后，才會啟動Pod中的其它container.

1initContainers:2- image: docker.io/istio/proxy_init:1.0.53 args:4 - -p5 - "15001"6 - -u7 - "1337"8 - -m9 - REDIRECT10 - -i11 - '*'12 - -x13 - ""14 - -b15 - "9080"16 - -d17 - ""復(fù)制代碼

istio-init ENTRYPOINT 和 args 組合的啟動命令:

1/usr/local/bin/istio-iptables.sh -p 15001 -u 1337 -m REDIRECT -i '*' -x "" -b 9080 -d ""復(fù)制代碼

istio-iptables.sh 源碼地址為 github.com/istio/istio…

1$ istio-iptables.sh -p PORT -u UID -g GID [-m mode] [-b ports] [-d ports] [-i CIDR] [-x CIDR] [-h]2 -p: 指定重定向所有 TCP 流量的 Envoy 端口（默認(rèn)為 $ENVOY_PORT = 15001）3 -u: 指定未應(yīng)用重定向的用戶的 UID。通常，這是代理容器的 UID（默認(rèn)為 $ENVOY_USER 的 uid，istio_proxy 的 uid 或 1337）4 -g: 指定未應(yīng)用重定向的用戶的 GID。（與 -u param 相同的默認(rèn)值）5 -m: 指定入站連接重定向到 Envoy 的模式，“REDIRECT” 或 “TPROXY”（默認(rèn)為 $ISTIO_INBOUND_INTERCEPTION_MODE)6 -b: 逗號分隔的入站端口列表，其流量將重定向到 Envoy（可選）。使用通配符 “*” 表示重定向所有端口。為空時表示禁用所有入站重定向（默認(rèn)為 $ISTIO_INBOUND_PORTS）7 -d: 指定要從重定向到 Envoy 中排除（可選）的入站端口列表，以逗號格式分隔。使用通配符“*” 表示重定向所有入站流量（默認(rèn)為 $ISTIO_LOCAL_EXCLUDE_PORTS）8 -i: 指定重定向到 Envoy（可選）的 IP 地址范圍，以逗號分隔的 CIDR 格式列表。使用通配符 “*” 表示重定向所有出站流量。空列表將禁用所有出站重定向（默認(rèn)為 $ISTIO_SERVICE_CIDR）9 -x: 指定將從重定向中排除的 IP 地址范圍，以逗號分隔的 CIDR 格式列表。使用通配符 “*” 表示重定向所有出站流量（默認(rèn)為 $ISTIO_SERVICE_EXCLUDE_CIDR）。10?11環(huán)境變量位于 $ISTIO_SIDECAR_CONFIG（默認(rèn)在：/var/lib/istio/envoy/sidecar.env）復(fù)制代碼

istio-init 通過配置iptable來劫持Pod中的流量:

• 參數(shù)-p 15001: Pod中的數(shù)據(jù)流量被iptable攔截，并發(fā)向15001端口, 該端口將由 envoy 監(jiān)聽

• 參數(shù)-u 1337: 用于排除用戶ID為1337，即Envoy自身的流量，以避免Iptable把Envoy發(fā)出的數(shù)據(jù)又重定向到Envoy, UID 為 1337，即 Envoy 所處的用戶空間，這也是 istio-proxy 容器默認(rèn)使用的用戶, 見Sidecar istio-proxy 配置參數(shù)securityContext.runAsUser

• 參數(shù)-b 9080 -d "": 入站端口控制, 將所有訪問 9080 端口（即應(yīng)用容器的端口）的流量重定向到 Envoy 代理

• 參數(shù)-i '*' -x "": 出站IP控制, 將所有出站流量都重定向到 Envoy 代理

Init 容器初始化完畢后就會自動終止，但是 Init 容器初始化結(jié)果(iptables)會保留到應(yīng)用容器和 Sidecar 容器中.

istio-proxy

istio-proxy 以 sidecar 的形式注入到應(yīng)用容器所在的pod中, 簡化的注入yaml:

1- image: docker.io/istio/proxyv2:1.0.52 name: istio-proxy3 args:4 - proxy5 - sidecar6 - --configPath7 - /etc/istio/proxy8 - --binaryPath9 - /usr/local/bin/envoy10 - --serviceCluster11 - ratings12 - --drainDuration13 - 45s14 - --parentShutdownDuration15 - 1m0s16 - --discoveryAddress17 - istio-pilot.istio-system:1500718 - --discoveryRefreshDelay19 - 1s20 - --zipkinAddress21 - zipkin.istio-system:941122 - --connectTimeout23 - 10s24 - --proxyAdminPort25 - "15000"26 - --controlPlaneAuthPolicy27 - NONE28 env:29 ......30 ports:31 - containerPort: 1509032 name: http-envoy-prom33 protocol: TCP34 securityContext:35 runAsUser: 133736 ......復(fù)制代碼

istio-proxy容器中有兩個進程pilot-agent和envoy:

1~ % kubectl exec productpage-v1-f8c8fb8-wgmzk -c istio-proxy -- ps -ef2UID PID PPID C STIME TTY TIME CMD3istio-p+ 1 0 0 Jan03 ? 00:00:27 /usr/local/bin/pilot-agent proxy sidecar --configPath /etc/istio/proxy --binaryPath /usr/local/bin/envoy --serviceCluster productpage --drainDuration 45s --parentShutdownDuration 1m0s --discoveryAddress istio-pilot.istio-system:15007 --discoveryRefreshDelay 1s --zipkinAddress zipkin.istio-system:9411 --connectTimeout 10s --proxyAdminPort 15000 --controlPlaneAuthPolicy NONE4istio-p+ 21 1 0 Jan03 ? 01:26:24 /usr/local/bin/envoy -c /etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster productpage --service-node sidecar~172.18.3.12~productpage-v1-f8c8fb8-wgmzk.default~default.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warn --v2-config-only復(fù)制代碼

可以看到:

• /usr/local/bin/pilot-agent 是 /usr/local/bin/envoy 的父進程, Pilot-agent進程根據(jù)啟動參數(shù)和K8S API Server中的配置信息生成Envoy的初始配置文件(/etc/istio/proxy/envoy-rev0.json)，并負(fù)責(zé)啟動Envoy進程

• pilot-agent 的啟動參數(shù)里包括: discoveryAddress(pilot服務(wù)地址), Envoy 二進制文件的位置, 服務(wù)集群名, 監(jiān)控指標(biāo)上報地址, Envoy 的管理端口, 熱重啟時間等

Envoy配置初始化流程:

Pilot-agent根據(jù)啟動參數(shù)和K8S API Server中的配置信息生成Envoy的初始配置文件envoy-rev0.json，該文件告訴Envoy從xDS server中獲取動態(tài)配置信息，并配置了xDS server的地址信息，即控制面的Pilot

Pilot-agent使用envoy-rev0.json啟動Envoy進程

Envoy根據(jù)初始配置獲得Pilot地址，采用xDS接口從Pilot獲取到Listener，Cluster，Route等d動態(tài)配置信息

Envoy根據(jù)獲取到的動態(tài)配置啟動Listener，并根據(jù)Listener的配置，結(jié)合Route和Cluster對攔截到的流量進行處理

查看envoy 初始配置文件:

1kubectl exec productpage-v1-f8c8fb8-wgmzk -c istio-proxy -- cat /etc/istio/proxy/envoy-rev0.json復(fù)制代碼

3.2 sidecar 流量劫持原理

sidecar 既要作為服務(wù)消費者端的正向代理，又要作為服務(wù)提供者端的反向代理, 具體攔截過程如下:

• Pod 所在的network namespace內(nèi), 除了envoy發(fā)出的流量外, iptables規(guī)則會對進入和發(fā)出的流量都進行攔截，通過nat redirect重定向到Envoy監(jiān)聽的15001端口.

• envoy 會根據(jù)從Pilot拿到的 XDS 規(guī)則, 對流量進行轉(zhuǎn)發(fā).

• envoy 的 listener 0.0.0.0:15001 接收進出 Pod 的所有流量，然后將請求移交給對應(yīng)的virtual listener

• 對于本pod的服務(wù), 有一個http listener podIP+端口 接受inbound 流量

• 每個service+非http端口, 監(jiān)聽器配對的 Outbound 非 HTTP 流量

• 每個service+http端口, 有一個http listener: 0.0.0.0+端口 接受outbound流量

整個攔截轉(zhuǎn)發(fā)過程對業(yè)務(wù)容器是透明的, 業(yè)務(wù)容器仍然使用 Service 域名和端口進行通信, service 域名仍然會轉(zhuǎn)換為service IP, 但service IP 在sidecar 中會被直接轉(zhuǎn)換為 pod IP, 從容器中出去的流量已經(jīng)使用了pod IP會直接轉(zhuǎn)發(fā)到對應(yīng)的Pod, 對比傳統(tǒng)kubernetes 服務(wù)機制, service IP 轉(zhuǎn)換為Pod IP 在node上進行, 由 kube-proxy維護的iptables實現(xiàn).

3.3 數(shù)據(jù)面標(biāo)準(zhǔn)API: xDS

xDS是一類發(fā)現(xiàn)服務(wù)的總稱，包含LDS，RDS，CDS，EDS以及 SDS。Envoy通過xDS API可以動態(tài)獲取Listener(監(jiān)聽器)， Route(路由)，Cluster(集群)，Endpoint(集群成員)以 及Secret(證書)配置

xDS API 涉及的概念:

• Host

• Downstream

• Upstream

• Listener

• Cluster

Envoy 配置熱更新: 配置的動態(tài)變更，而不需要重啟 Envoy:

新老進程采用基本的RPC協(xié)議使用Unix Domain Socket通訊.

新進程啟動并完成所有初始化工作后，向老進程請求監(jiān)聽套接字的副本.

新進程接管套接字后，通知老進程關(guān)閉套接字.

通知老進程終止自己.

xDS 調(diào)試

Pilot在9093端口提供了下述調(diào)試接口:

1# What is sent to envoy2# Listeners and routes3curl $PILOT/debug/adsz4?5# Endpoints6curl $PILOT/debug/edsz7?8# Clusters9curl $PILOT/debug/cdsz復(fù)制代碼

Sidecar Envoy 也提供了管理接口，缺省為localhost的15000端口，可以獲取listener，cluster以及完整的配置數(shù)據(jù)

可以通過以下命令查看支持的調(diào)試接口:

1kubectl exec productpage-v1-f8c8fb8-zjbhh -c istio-proxy curl http://127.0.0.1:15000/help復(fù)制代碼

或者forward到本地就行調(diào)試

1kubectl port-forward productpage-v1-f8c8fb8-zjbhh 15000復(fù)制代碼

相關(guān)的調(diào)試接口:

1http://127.0.0.1:150002http://127.0.0.1:15000/help3http://127.0.0.1:15000/config_dump4http://127.0.0.1:15000/listeners5http://127.0.0.1:15000/clusters復(fù)制代碼

使用istioctl 查看代理配置:

1istioctl pc {xDS類型} {POD_NAME} {過濾條件} {-o json/yaml}2?3eg:4istioctl pc routes productpage-v1-f8c8fb8-zjbhh --name 9080 -o json復(fù)制代碼

xDS 類型包括: listener, route, cluster, endpoint

對xDS 進行分析: productpage 訪問 reviews 服務(wù)

查看 product 的所有l(wèi)istener:

1% istioctl pc listener productpage-v1-f8c8fb8-zjbhh2ADDRESS PORT TYPE3172.18.255.178 15011 TCP4172.18.255.194 44134 TCP5172.18.255.110 443 TCP6172.18.255.190 50000 TCP7172.18.255.203 853 TCP8172.18.255.2 443 TCP9172.18.255.239 16686 TCP100.0.0.0 80 TCP11172.18.255.215 3306 TCP12172.18.255.203 31400 TCP13172.18.255.111 443 TCP14172.18.255.203 8060 TCP15172.18.255.203 443 TCP16172.18.255.40 443 TCP17172.18.255.1 443 TCP18172.18.255.53 53 TCP19172.18.255.203 15011 TCP20172.18.255.105 14268 TCP21172.18.255.125 42422 TCP22172.18.255.105 14267 TCP23172.18.255.52 80 TCP240.0.0.0 15010 HTTP250.0.0.0 9411 HTTP260.0.0.0 8060 HTTP270.0.0.0 9080 HTTP280.0.0.0 15004 HTTP290.0.0.0 20001 HTTP300.0.0.0 9093 HTTP310.0.0.0 8080 HTTP320.0.0.0 15030 HTTP330.0.0.0 9091 HTTP340.0.0.0 9090 HTTP350.0.0.0 15031 HTTP360.0.0.0 3000 HTTP370.0.0.0 15001 TCP38172.18.3.50 9080 HTTP 這是當(dāng)前pod ip 暴露的服務(wù)地址, 會路由到回環(huán)地址, 各個pod 會不一樣復(fù)制代碼

envoy 流量入口的listener:

1% istioctl pc listener productpage-v1-f8c8fb8-zjbhh --address 0.0.0.0 --port 15001 -o json2[3 {4 "name": "virtual",5 "address": {6 "socketAddress": {7 "address": "0.0.0.0",8 "portValue": 150019 }10 },11 "filterChains": [12 {13 "filters": [14 {15 "name": "envoy.tcp_proxy",16 "config": {17 "cluster": "BlackHoleCluster",18 "stat_prefix": "BlackHoleCluster"19 }20 }21 ]22 }23 ],24 "useOriginalDst": true # 這意味著它將請求交給最符合請求原始目標(biāo)的監(jiān)聽器。如果找不到任何匹配的虛擬監(jiān)聽器，它會將請求發(fā)送給返回 404 的 BlackHoleCluster25 }26]復(fù)制代碼

以下是reviews的所有pod IP

1 % kubectl get ep reviews2NAME ENDPOINTS AGE3reviews 172.18.2.35:9080,172.18.3.48:9080,172.18.3.49:9080 1d復(fù)制代碼

對于目的地址是以上ip的http訪問, 這些 ip 并沒有對應(yīng)的listener, 因此會通過端口9080 匹配到listener 0.0.0.0 9080

查看listener 0.0.0.0 9080:

1% istioctl pc listener productpage-v1-f8c8fb8-zjbhh --address 0.0.0.0 --port 9080 -ojson2 {3 "name": "0.0.0.0_9080",4 "address": {5 "socketAddress": {6 "address": "0.0.0.0",7 "portValue": 90808 }9 },10 ......11?12 "rds": {13 "config_source": {14 "ads": {}15 },16 "route_config_name": "9080"17 },18 ......復(fù)制代碼

查看名為9080 的 route:

1% istioctl pc routes productpage-v1-f8c8fb8-zjbhh --name 9080 -o json2?3[4 {5 "name": "9080",6 "virtualHosts": [7 {8 "name": "details.default.svc.cluster.local:9080",9 "domains": [10 "details.default.svc.cluster.local",11 "details.default.svc.cluster.local:9080",12 "details",13 "details:9080",14 "details.default.svc.cluster",15 "details.default.svc.cluster:9080",16 "details.default.svc",17 "details.default.svc:9080",18 "details.default",19 "details.default:9080",20 "172.18.255.240",21 "172.18.255.240:9080"22 ],23 "routes": [24 {25 "match": {26 "prefix": "/"27 },28 "route": {29 "cluster": "outbound|9080||details.default.svc.cluster.local",30 "timeout": "0.000s",31 "maxGrpcTimeout": "0.000s"32 },33 ......34 {35 "name": "productpage.default.svc.cluster.local:9080",36 "domains": [37 "productpage.default.svc.cluster.local",38 "productpage.default.svc.cluster.local:9080",39 "productpage",40 "productpage:9080",41 "productpage.default.svc.cluster",42 "productpage.default.svc.cluster:9080",43 "productpage.default.svc",44 "productpage.default.svc:9080",45 "productpage.default",46 "productpage.default:9080",47 "172.18.255.137",48 "172.18.255.137:9080"49 ],50 "routes": [ ...... ]51 },52 {53 "name": "ratings.default.svc.cluster.local:9080",54 "domains": [55 "ratings.default.svc.cluster.local",56 "ratings.default.svc.cluster.local:9080",57 "ratings",58 "ratings:9080",59 "ratings.default.svc.cluster",60 "ratings.default.svc.cluster:9080",61 "ratings.default.svc",62 "ratings.default.svc:9080",63 "ratings.default",64 "ratings.default:9080",65 "172.18.255.41",66 "172.18.255.41:9080"67 ],68 "routes": [ ...... ]69 },70 {71 "name": "reviews.default.svc.cluster.local:9080",72 "domains": [73 "reviews.default.svc.cluster.local",74 "reviews.default.svc.cluster.local:9080",75 "reviews",76 "reviews:9080",77 "reviews.default.svc.cluster",78 "reviews.default.svc.cluster:9080",79 "reviews.default.svc",80 "reviews.default.svc:9080",81 "reviews.default",82 "reviews.default:9080",83 "172.18.255.140",84 "172.18.255.140:9080"85 ],86 "routes": [87 {88 "match": {89 "prefix": "/",90 "headers": [91 {92 "name": "end-user",93 "exactMatch": "jason"94 }95 ]96 },97 "route": {98 "cluster": "outbound|9080|v2|reviews.default.svc.cluster.local",99 "timeout": "0.000s",100 "maxGrpcTimeout": "0.000s"101 },102 ......103 },104 {105 "match": {106 "prefix": "/"107 },108 "route": {109 "cluster": "outbound|9080|v3|reviews.default.svc.cluster.local",110 "timeout": "0.000s",111 "maxGrpcTimeout": "0.000s"112 },113 .......114 }115 ]116 }117 ],118 "validateClusters": false119 }120]復(fù)制代碼

可以看到, 在9080 這個route 中, 包含所有這個端口的http 路由信息, 通過virtualHosts列表進行服務(wù)域名分發(fā)到各個cluster.

查看virtualHosts reviews.default.svc.cluster.local:9080 中的routes信息, 可以看到j(luò)ason 路由到了cluster outbound|9080|v2|reviews.default.svc.cluster.local

查看該cluster:

1% istioctl pc cluster productpage-v1-f8c8fb8-zjbhh --fqdn reviews.default.svc.cluster.local --subset v2 -o json2[3 {4 "name": "outbound|9080|v2|reviews.default.svc.cluster.local",5 "type": "EDS",6 "edsClusterConfig": {7 "edsConfig": {8 "ads": {}9 },10 "serviceName": "outbound|9080|v2|reviews.default.svc.cluster.local"11 },12 "connectTimeout": "1.000s",13 "lbPolicy": "RANDOM",14 "circuitBreakers": {15 "thresholds": [16 {}17 ]18 }19 }20]復(fù)制代碼

查看其對應(yīng)的endpoint:

1 % istioctl pc endpoint productpage-v1-f8c8fb8-zjbhh --cluster 'outbound|9080|v2|reviews.default.svc.cluster.local'2ENDPOINT STATUS CLUSTER3172.18.2.35:9080 HEALTHY outbound|9080|v2|reviews.default.svc.cluster.local復(fù)制代碼

該endpoint 即為 reviews 服務(wù) V2 對應(yīng)的 pod IP

XDS服務(wù)接口的最終一致性考慮

遵循 make before break 模型

3.4 分布式跟蹤

以下是分布式全鏈路跟蹤示意圖:

一個典型的Trace案例（圖片來自opentracing文檔中文版)

Jaeger 是Uber 開源的全鏈路跟蹤系統(tǒng), 符合OpenTracing協(xié)議, OpenTracing 和 Jaeger 均是CNCF 成員項目, 以下是Jaeger 架構(gòu)的示意圖:

Jaeger 架構(gòu)示意圖（圖片來自Jaeger官方文檔)

分布式跟蹤系統(tǒng)讓開發(fā)者能夠得到可視化的調(diào)用流程展示。這對復(fù)雜的微服務(wù)系統(tǒng)進行問題排查和性能優(yōu)化時至關(guān)重要.

Envoy 原生支持http 鏈路跟蹤:

• 生成 Request ID：Envoy 會在需要的時候生成 UUID，并操作名為 [x-request-id] 的 HTTP Header。應(yīng)用可以轉(zhuǎn)發(fā)這個 Header 用于統(tǒng)一的記錄和跟蹤.

• 支持集成外部跟蹤服務(wù)：Envoy 支持可插接的外部跟蹤可視化服務(wù)。目前支持有:

  • LightStep

  • Zipkin 或者 Zipkin 兼容的后端（比如說 Jaeger）

  • Datadog

• 客戶端跟蹤 ID 連接：x-client-trace-id Header 可以用來把不信任的請求 ID 連接到受信的 x-request-id Header 上

跟蹤上下文信息的傳播

• 不管使用的是哪個跟蹤服務(wù)，都應(yīng)該傳播 x-request-id，這樣在被調(diào)用服務(wù)中啟動相關(guān)性的記錄

• 如果使用的是 Zipkin，Envoy 要傳播的是 B3 Header。（x-b3-traceid, x-b3-spanid, x-b3-parentspanid, x-b3-sampled, 以及 x-b3-flags. x-b3-sampled）

• 上下文跟蹤并非零修改, 在調(diào)用下游服務(wù)時, 上游應(yīng)用應(yīng)該自行傳播跟蹤相關(guān)的 HTTP Header

4. Istio 控制面

• 4.1 Pilot 架構(gòu)

• 4.2 流量管理模型

• 4.3 故障處理

• 4.4 Mixer 架構(gòu)

• 4.5 Mixer適配器模型

• 4.6 Mixer 緩存機制

4.1 Pilot 架構(gòu)

Pilot Architecture（圖片來自Isio官網(wǎng)文檔)

• Rules API: 對外封裝統(tǒng)一的 API，供服務(wù)的開發(fā)者或者運維人員調(diào)用，可以用于流量控制。

• Envoy API: 對內(nèi)封裝統(tǒng)一的 API，供 Envoy 調(diào)用以獲取注冊信息、流量控制信息等。

• 抽象模型層: 對服務(wù)的注冊信息、流量控制規(guī)則等進行抽象，使其描述與平臺無關(guān)。

• 平臺適配層: 用于適配各個平臺如 Kubernetes、Mesos、Cloud Foundry 等，把平臺特定的注冊信息、資源信息等轉(zhuǎn)換成抽象模型層定義的平臺無關(guān)的描述。例如，Pilot 中的 Kubernetes 適配器實現(xiàn)必要的控制器來 watch Kubernetes API server 中 pod 注冊信息、ingress 資源以及用于存儲流量管理規(guī)則的第三方資源的更改

4.2 流量管理模型

• VirtualService

• DestinationRule

• ServiceEntry

• Gateway

VirtualService

VirtualService 中定義了一系列針對指定服務(wù)的流量路由規(guī)則。每個路由規(guī)則都是針對特定協(xié)議的匹配規(guī)則。如果流量符合這些特征，就會根據(jù)規(guī)則發(fā)送到服務(wù)注冊表中的目標(biāo)服務(wù), 或者目標(biāo)服務(wù)的子集或版本, 匹配規(guī)則中還包含了對流量發(fā)起方的定義，這樣一來，規(guī)則還可以針對特定客戶上下文進行定制.

Gateway

Gateway 描述了一個負(fù)載均衡器，用于承載網(wǎng)格邊緣的進入和發(fā)出連接。這一規(guī)范中描述了一系列開放端口，以及這些端口所使用的協(xié)議、負(fù)載均衡的 SNI 配置等內(nèi)容

ServiceEntry

Istio 服務(wù)網(wǎng)格內(nèi)部會維護一個與平臺無關(guān)的使用通用模型表示的服務(wù)注冊表，當(dāng)你的服務(wù)網(wǎng)格需要訪問外部服務(wù)的時候，就需要使用 ServiceEntry 來添加服務(wù)注冊, 這類服務(wù)可能是網(wǎng)格外的 API，或者是處于網(wǎng)格內(nèi)部但卻不存在于平臺的服務(wù)注冊表中的條目（例如需要和 Kubernetes 服務(wù)溝通的一組虛擬機服務(wù)）.

EnvoyFilter

EnvoyFilter 描述了針對代理服務(wù)的過濾器，用來定制由 Istio Pilot 生成的代理配置.

Kubernetes Ingress vs Istio Gateway

• 合并了L4-6和L7的規(guī)范, 對傳統(tǒng)技術(shù)棧用戶的應(yīng)用遷入不方便

• 表現(xiàn)力不足:

  • 只能對 service、port、HTTP 路徑等有限字段匹配來路由流量

  • 端口只支持默認(rèn)80/443

Istio Gateway:·

• 定義了四層到六層的負(fù)載均衡屬性 (通常是SecOps或NetOps關(guān)注的內(nèi)容)

  • 端口

  • 端口所使用的協(xié)議(HTTP, HTTPS, GRPC, HTTP2, MONGO, TCP, TLS)

  • Hosts

  • TLS SNI header 路由支持

  • TLS 配置支持(http 自動301, 證書等)

  • ip / unix domain socket

Kubernetes, Istio, Envoy xDS 模型對比

以下是對Kubernetes, Istio, Envoy xDS 模型的不嚴(yán)格對比

KubernetesIstioEnvoy xDS

入口流量	Ingress	GateWay	Listener
服務(wù)定義	Service	-	Cluster+Listener
外部服務(wù)定義	-	ServiceEntry	Cluster+Listener
版本定義	-	DestinationRule	Cluster+Listener
版本路由	-	VirtualService	Route
實例	Endpoint	-	Endpoint

Kubernetes 和 Istio 服務(wù)尋址的區(qū)別:

Kubernetes:

kube-dns: service domain -> service ip

kube-proxy(node iptables): service ip -> pod ip

Istio:

kube-dns: service domain -> service ip

sidecar envoy: service ip -> pod ip

4.3 故障處理

隨著微服務(wù)的拆分粒度增強, 服務(wù)調(diào)用會增多, 更復(fù)雜, 扇入 扇出, 調(diào)用失敗的風(fēng)險增加, 以下是常見的服務(wù)容錯處理方式:

控制端目的實現(xiàn)Istio

超時	client	保護client	請求等待超時/請求運行超時	timeout
重試	client	容忍server臨時錯誤, 保證業(yè)務(wù)整體可用性	重試次數(shù)/重試的超時時間	retries.attempts, retries.perTryTimeout
熔斷	client	降低性能差的服務(wù)或?qū)嵗挠绊?/td>	通常會結(jié)合超時+重試, 動態(tài)進行服務(wù)狀態(tài)決策(Open/Closed/Half-Open)	trafficPolicy.outlierDetection
降級	client	保證業(yè)務(wù)主要功能可用	主邏輯失敗采用備用邏輯的過程(鏡像服務(wù)分級, 調(diào)用備用服務(wù), 或者返回mock數(shù)據(jù))	暫不支持, 需要業(yè)務(wù)代碼按需實現(xiàn)
隔離	client	防止異常server占用過多client資源	隔離對不同服務(wù)調(diào)用的資源依賴: 線程池隔離/信號量隔離	暫不支持
冪等	server	容忍client重試, 保證數(shù)據(jù)一致性	唯一ID/加鎖/事務(wù)等手段	暫不支持, 需要業(yè)務(wù)代碼按需實現(xiàn)
限流	server	保護server	常用算法: 計數(shù)器, 漏桶, 令牌桶	trafficPolicy.connectionPool

Istio 沒有無降級處理支持: Istio可以提高網(wǎng)格中服務(wù)的可靠性和可用性。但是，應(yīng)用程序仍然需要處理故障（錯誤）并采取適當(dāng)?shù)幕赝瞬僮鳌＠?#xff0c;當(dāng)負(fù)載均衡池中的所有實例都失敗時，Envoy 將返回 HTTP 503。應(yīng)用程序有責(zé)任實現(xiàn)必要的邏輯，對這種來自上游服務(wù)的 HTTP 503 錯誤做出合適的響應(yīng)。

4.4 Mixer 架構(gòu)

Mixer Topology（圖片來自Isio官網(wǎng)文檔)

Istio 的四大功能點連接, 安全, 控制, 觀察, 其中「控制」和「觀察」的功能主要都是由Mixer組件來提供, Mixer 在Istio中角色:

• 功能上: 負(fù)責(zé)策略控制和遙測收集

• 架構(gòu)上:提供插件模型，可以擴展和定制

4.5 Mixer Adapter 模型

• Attribute

• Template

• Adapter

• Instance

• Handler

• Rule

Attribute

Attribute 是策略和遙測功能中有關(guān)請求和環(huán)境的基本數(shù)據(jù), 是用于描述特定服務(wù)請求或請求環(huán)境的屬性的一小段數(shù)據(jù)。例如，屬性可以指定特定請求的大小、操作的響應(yīng)代碼、請求來自的 IP 地址等.

• Istio 中的主要屬性生產(chǎn)者是 Envoy，但專用的 Mixer 適配器也可以生成屬性

• 屬性詞匯表見: Attribute Vocabulary

• 數(shù)據(jù)流向: envoy -> mixer

Template

Template 是對 adapter 的數(shù)據(jù)格式和處理接口的抽象, Template定義了:

• 當(dāng)處理請求時發(fā)送給adapter 的數(shù)據(jù)格式

• adapter 必須實現(xiàn)的gRPC service 接口

每個Template 通過 template.proto 進行定義:

• 名為Template 的一個message

• Name: 通過template所在的package name自動生成

• template_variety: 可選Check, Report, Quota or AttributeGenerator, 決定了adapter必須實現(xiàn)的方法. 同時決定了在mixer的什么階段要生成template對應(yīng)的instance:

  • Check: 在Mixer’s Check API call時創(chuàng)建并發(fā)送instance

  • Report: 在Mixer’s Report API call時創(chuàng)建并發(fā)送instance

  • Quota: 在Mixer’s Check API call時創(chuàng)建并發(fā)送instance(查詢配額時)

  • AttributeGenerator: for both Check, Report Mixer API calls

Istio 內(nèi)置的Templates: istio.io/docs/refere…

Adapter

封裝了 Mixer 和特定外部基礎(chǔ)設(shè)施后端進行交互的必要接口，例如 Prometheus 或者 Stackdriver

• 定義了需要處理的模板(在yaml中配置template)

• 定義了處理某個Template數(shù)據(jù)格式的GRPC接口

• 定義 Adapter需要的配置格式(Params)

• 可以同時處理多個數(shù)據(jù)(instance)

Istio 內(nèi)置的Adapter: istio.io/docs/refere…

Instance

代表符合某個Template定義的數(shù)據(jù)格式的具體實現(xiàn), 該具體實現(xiàn)由用戶配置的 CRD, CRD 定義了將Attributes 轉(zhuǎn)換為具體instance 的規(guī)則, 支持屬性表達(dá)式

• Instance CRD 是Template 中定義的數(shù)據(jù)格式 + 屬性轉(zhuǎn)換器

• 內(nèi)置的Instance 類型(其實就是內(nèi)置 Template): Templates

• 屬性表達(dá)式見: Expression Language

• 數(shù)據(jù)流向: mixer -> adapter 實例

Handler

用戶配置的 CRD, 為具體Adapter提供一個具體配置, 對應(yīng)Adapter的可運行實例

Rule

用戶配置的 CRD, 配置一組規(guī)則，這些規(guī)則描述了何時調(diào)用特定(通過Handler對應(yīng)的)適配器及哪些Instance

結(jié)語

計算機科學(xué)中的所有問題，都可以用另一個層來解決，除了層數(shù)太多的問題

Kubernetes 本身已經(jīng)很復(fù)雜, Istio 為了更高層控制的抽象, 又增加了很多概念. 復(fù)雜度堪比kubernetes.

可以看出istio 設(shè)計精良, 在處理微服務(wù)的復(fù)雜場景有很多優(yōu)秀之處, 不過目前istio目前的短板還是很明顯, 高度的抽象帶來了很多性能的損耗, 社區(qū)現(xiàn)在也有很多優(yōu)化的方向, 像螞蟻金服開源的SofaMesh 主要是去精簡層, 試圖在sidecar里去做很多mixer 的事情, 減少sidecar和mixer的同步請求依賴, 而一些其他的sidecar 網(wǎng)絡(luò)方案, 更多的是考慮去優(yōu)化層, 優(yōu)化sidecar 這一層的性能開銷.

在Istio 1.0 之前, 主要還是以功能的實現(xiàn)為主, 不過后面隨著社區(qū)的積極投入, 相信Istio的性能會有長足的提升.

筆者之前從事過多年的服務(wù)治理相關(guān)的工作, 過程中切身體會到微服務(wù)治理的痛點, 所以也比較關(guān)注 service mesh的發(fā)展, 個人對istio也非常看好, 剛好今年我們中心容器產(chǎn)品今年也有這方面的計劃, 期待我們能在這個方向進行一些產(chǎn)品和技術(shù)的深耕.

參考資料:

• Service Mesh年度總結(jié)：群雄逐鹿烽煙起
• Why You Should Care About Istio Gateways
• Pattern: Service Mesh
• Mixer Out Of Process Adapter Dev Guide
• Mixer Out of Process Adapter Walkthrough
• Envoy 中的 xDS REST 和 gRPC 協(xié)議詳解
• Delayering Istio with AppSwitch
• servicemesher 中文社區(qū)

總結(jié)

以上是生活随笔為你收集整理的腾讯云容器团队内部Istio专题分享的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。