Istio 是目前最多人使用的 Service Mesh 解決方案，也是 Anthos Service Mesh 使用的實作，以下會以 Istio 為例，簡單說明相關的架構與機制。
Istio 是什麼？ #
貫徹我喜歡的簡單又粗暴的精神：
- Istio 是一群工具的集合：Istiod (Pilot, ect.), Enovy, Kiali, Prometheus, Guavana, etc.
- Istio 目的在於實作 Service Mesh 的功能
先備知識 Recall #
Service, Deployment 兩者與 Pods 之間的關係是這樣的：
流量的入口是 Service，而它公開的是 Deployment 控制下的所有副本 Pod。
Service 它的名字正象徵了以它為入口的 Pod，共同構成為一個可被叫用的服務。
Istio 概念 #
假設某個叢集中有兩顆 Node，結構如同下圖。
A 應用程式想要打到 B 的服務，實際上在 Istio 是如何達成的呢？
在一顆 Pod 當中，除了應用程式的主容器以外，Istio 會注入一個 sidecar 的 Proxy container：
而這個 proxy container 正是 Enovy：
Envoy #
在概念上來說 ，正是透過 Envoy，我們實現訊息傳遞從應用程式中的完全解耦與透明，而它將會攔截要傳遞出去或進來給這個 pod 的所有流量，甚至可以做一些額外的事情。例如：針對成功的請求做某些事，針對失敗的請求做某些事等等。
回到原來的議題，那麽 envoy 之間是像這樣直接溝通的嗎？
Istiod #
如果有一大堆的 Service 在互打，即使有 proxy container，還是很難管理與監控。
因此為了要方便管理許多 Envoys 之間的通訊，Istio 啟用了一個 Pod，其實它是許多不同功能元件的集合，用來針對不同部分進行管控。
Pilot #
以流量傳輸而言，實際上會由 Pilot 進行中央管理：
當然，Service 與 Service 之間的溝通不會單純只有流量傳輸。
Pilot 會透過 API Server 取得流量轉導規則，用來處理服務發現，並讓所有的 Envoy 都能知道。
憑證管理、 Policy 校驗、資訊收集等等，在 Istio 中也有元件會負責處理，先來提提以下 2 個：
Citadel #
若服務有掛上憑證，Istio 在開始每個 proxy 與彼此透過 Pilot 進行溝通之前，會先以 Citadel 去做 TLS 證書的檢核，達到服務間的溝通安全。
Mixer #
管理者設定的 Policy 則是由 Mixer 進行校驗，並且在檢查條件通過後，從 Envoy 回收資訊，用來進行遙測。
Istiod #
以上這些元件等，一同構成了 Istiod，d 其實是 daemon 的意思。
圖中還有一個元件 Galley 沒有被提到，有機會再來說說他的用法。
Planes #
Control Plane #
我們可以想像成：Istio 中實施管控的部分，我們一同稱呼它們為 Control Plane。
小心別和 Kubernetes 的 Control Plane 搞錯了！
Data Plane #
相對於管控的部分，我們可以想像成：Envoy 負責收集回傳資訊的工作，因此 Envoys 的集合就被稱為 Data Plane：
其實也有很多可以選配的外部元件，能與 Istio 整合對接，例如 Kiali, Prometheus, Guavana 等。
在部署上會和 Istio 的系統機制屬於相同的命名空間。
參考資料 #
Published