[筆記] 淺入淺出 Istio (1) — 架構簡說

自從踏入了 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 就是了。

Service Mesh

• 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 能幫助減輕這問題。

Twitter’s system

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 轉發。

Reference

Observability at Twitter

What's a service mesh?

架构

Architecture