Service Mesh與Istio佈署簡介(下)

Service Mesh與Istio佈署簡介(下)

Service Mesh與Istio佈署簡介(下)

回顧:Service Mesh與Istio佈署簡介(上)Service Mesh與Istio佈署簡介(中)

Zipkin佈署

Istio已提供zipkin的yaml addon可以快速佈署zipkin至namespace=istio-system下,執行以下指令即可。

為方便測試,設置node port 讓外部可訪問zipkin,將type: ClusterIP修改為type: NodePort

上述指令修改並儲存後再重複執行一次看node port是多少

查詢該zipkin佈署在哪個node上

其在ubuntu3上,對應ip為10.0.11.13,因此用瀏覽器開啟10.0.11.13:32229,並刷新一下Bookinfo頁面讓zipkin抓資料,開啟後如下圖14

Prometheus佈署

同zipkin佈署方式,執行以下指令並修改該svc為node port,並查詢佈署節點後開啟對應的URL後,結果如圖15監看各流量

Prometheus with Grafana

一樣方式在佈署完prometheus後執行以下指令並開啟URL如圖16所示

Prometheus with Servicegraph

一樣方式在佈署完prometheus後執行以下指令並開啟http://192.168.56.12:30835/dotviz,刷新Bookinfo頁面,執行不同操作讓servicegraph依流量動態產生流量拓樸圖,如圖17所示

Service Mesh與容器安全

由於容器/Pod存在IP變動頻繁的特點,過往針對L3/L4的網路防火牆無法有效的在容器編排環境內作用,因此在容器安全產品該篇中提到有關於目前容器安全的解決方法主要利用container firewall來過濾容器間對於L7的需求連線。對比Service Mesh的架構和想法,兩者可說是一模一樣,此外,其和cilium架構也類似,但cilium對於kernel的要求較高,且佈署相對複雜許多。

針對防火牆的策略,Service Mesh的概念和目前容器安全產品的策略一樣,主要關注在White-list的建立和執行,當然也可設定Black-list拒絕特定連線。此外,Service Mesh主要針對L7的連線作處理,對於服務發現和TLS雙向溝通,可說目前的Service Mesh Project/Product已實現許多容器安全產品的功能,因此導入service mesh除了方便連線上的管理外,也使該容器化服務至少在連線上,具備產品環境的安全需求。

參考資料:A sidecar for your service mesh

由表一可知,基本上Linkerd有的功能,Istio皆有提供,且Istio多了Access Control幫助每個容器設定whitelist/blacklist,在容器安全上,此點扮演著容器防火牆的功能。在Istio集Service Mesh大成及大廠的支持趨勢下,Linkerd也正在與Istio集成,透過Linkerd代替Envoy的Sidecar角色,由Istio Control Plane來操作Linkerd,不過照官方文件所佈署時,在最新版的Istio下,其Pilot無法成功佈署,由於文件上僅描述其支援Istio 0.1.6版本,並未提到是否支援更新版本,因此可能是版本問題不相容。

撰文:呂威廷 迎棧科技工程師