[筆記] 淺入淺出 Istio (1) — 架構簡說
Published in
6 min readDec 12, 2020
自從踏入了 k8s 深淵後,才逐步了解從傳統 Monolithic(單體式架構)的服務要轉成 Micro Service(微服務)有許多的架構設計問題需要去思考。而即便順利的將服務搬到 k8s 上,萬一之後在上面的 service 越長越多,系統越來越龐大,在各 service 間網路控管、系統的監控便會造成困難。
好在 Istio 的出現,相當方便幫助因 k8s 而造成的新時代產物 — DevOps 工程師們解決了以上煩惱。而此篇以一個初入 Istio 不久的使用者(剛出新手村!?)角度,記錄一下踏入這坑的雜記,若有誤希望不吝指教。
What’s Istio?
- Istio is a service mesh.
這句話有點繞口,但須先理解的是何為 Service Mesh?
這邊簡單說一下(想更深入可看這篇),在 Microservice 的架構下,各個 Service 間的溝通可能需要不同的實作方式(流量控管、連線數、效能監控等等你常見的網路機制)會變得很複雜,原先可能需要開發者們在程式內實作,但有了 service mesh 就不用了!
Service Mesh 的基本概念就是在每個 pod 旁增加一個 side car,把關於流量網路的雜事都抽離出來,接下來所有經過 pod 的 request 都是經由 side car 轉導,大大減輕開發者們的負擔。
而 Istio 其實就是 Service Mesh 的一種實作,這部分應該是百家爭鳴拉,常見的還有 Linkerd ,但筆者用 Istio 就是了。
- Implement network mechanism.
上點已略為提到,各個 pod 間的網路雜事,甚至是 API gateway 等設定,總之關於 “網路” 的通通抽離出來,Istio 統一做管理與設定,讓開發者能更能專注於功能的開發上。 - Integrate with many observability tools.
上面已了解到 Service Mesh 是透過 side car 來轉發 request 的,所以當然也記錄了許多 request/response 等相關 metrics。而 Istio 也順帶整合了許多第三方的觀測工具(e.g. Prometheus, Kiali, Grafana, etc.) - Handle microservice challenges.
承開頭所提及的,在 microservice 架構下當 service/pod 一多,要去管控各個 service 間的網路連線是非常頭痛的,下圖是 Twitter 所公布其系統的 架構圖(想看原文點這),看了就覺得頭痛了吧! 這也是 microservice 架構常見的棘手難題之一,好在 Istio 能幫助減輕這問題。
Architecture
這邊以循序的方式說明下 Istio 的架構。
- 在 K8S 上,若沒有 Service Mesh 的幫助,一般 Service/Pod 間可能需如下圖,自行去實作 Service 間的網路機制。
- 而若套用 Service Mesh,便會在各個 Pod 旁 Inject side car,而上層則會多一個 control plane,開發者可以透過一些指令/設定去統一管控 Service/Pod 間的網路機制。
- 這邊提醒一點,下圖的部分其實嚴格說來有點畫錯(但沒辦法,Istio 官方架構圖也這樣畫(攤手),應該是
=> 對 Pod 去 Inject side car
=> 對 Pod 去 Inject side car
=> 對 Pod 去 Inject side car
而不是對 Service,因為一個 Service 下可能有很多個 Pod。
舉例而言有一個 Rest API 的服務在 K8S 上,但有很多 Pod 為不同 Version,以 Microservice 架構來看,我們可將這 Rest API 視為一個 Service,但其之下其實是有很多 Pod 代表不同 Version。
- 而 Istio 的架構可以看出與上圖頗為相似,在各個 Pod (但 Istio Document 上還是畫 Service 這邊很容易混淆)旁會有個名為 istio-proxy 的 side car,來幫助我們轉發 request、蒐集資訊等。
而 Control Plane 層則會有個名為 istiod 的 Pod 來幫助我們控管服務。
而 istiod 中間的 Pilot、Citadel、Galley 等細節有興趣的可以啃這 (中文版 Istio Doc) 英文版的相同頁面就不知道為何沒提到這段。不過這幾個元件應該有個概念就可以了,一般 Istio 操作上應該是不會遇到它們。
- 最後來對比一下 Istio 與一般 K8S 在 Pod 溝通機制上的差異。在原生 K8S 上,各 Pod 間的溝通是透過 Node 上的 kube-proxy(它會紀錄其他節點上的 Pod iptables)並做 request 轉發。
而在 Istio 上,則不用透過原生機制,因為每個 Side car 就是個 proxy,所以直接幫你做 request 轉發。