Service Mesh with Istio
繼上一次我們介紹了Anthos 的其中一個元件功能GKE on-prem，這一篇我們要來介紹Anthos 的第二個元件 – Istio。如果用過Istio的朋友基本上這一篇可以跳過，不了解的朋友請繼續往下看。
先來定義一下什麼是Service Mesh
Service Mesh 就是一個專屬的infra layer，專門控制每個Micro Service之間的網路通訊。簡單來說就是在每一個Micro Service對外的通訊都需要透過這一個服務，你可以把它想成是一個Proxy Layer代替Micro Service對外的網路溝通。
而這當中Istio是目前最廣為人知的Service Mesh服務了
為什麼需要這個服務呢？
因為當你有一百個甚至一千個的微服務需要互相溝通時時，要控制這些微服務相互間的溝通。例如只允許Micro service A與B溝通而不允許 Ａ與C溝通，或者是我們要控制L7的attributes。另外透過這個機制我們也能知道，哪個Micro Service正在與誰溝通，不論是對外或對內。另外我們也可以透過這一個服務來觀察我們整個資料流是慢在哪一段網路之間或哪一個Micro Service。
Service Mesh有三個面向
1. Traffic Control
2. Observability
4. Security
顧名思義，可以控制微服務之間的資料流
提供效能的可視性，提供視覺化讓你很快能夠辨認問題點
如之前所提到的，可以控制每個Micro Service之間的網路通訊，每個Micro Service 之間的connect都可以被很精確的控制，並且有authentication, authorization, rate limiting 的功能，並且能將將防火牆功能部署在ingress/egress中。
而Anthos Service Mesh一樣可以跨越到地端機房，並實行上述所說的功能。（如下圖）
Istio介紹
Istio is an open framework for connecting, securing, managing and monitoring services, even across environments。
由上面的定義可以知道，Istio是針對一個可以跨不同環境連結與管理不同微服務工具，它不只可以在容器上運行也可以運行在虛擬機上。
Istio提供了以下的功能
routing, load-balancing, throttling, telemetry, circuit-breaking, authenticating and authorizing
為什麼可以提供這一些功能呢？
如同之前提到，Istio本身就是一個proxy的機制放在每一個continer的對外溝通的路徑上，這種方式叫做sidecar model。（可參照下圖）
從上圖可以得知，Istio機制在每一個K8s Pod裡都有一個Istion的container用來處理所有你的服務的對外溝通，這意味著在這裡你的程式不需要去處理網路層級的事情，交給Istio來處理即可。
這一個Proxy的container我們在Istio稱做它 Envoy
哪在每一個Envoy之間就必續就必須要有一個控管的機制來控制可能是成千上萬的Pod裡的Envoy container。這個機制我們稱呼它叫做”Pilot”。
Pilot提供了以下的功能
Service Discovery / Traffic Management /Intelligent Routing / Resiliency
其中Intelligent Routing功能可以提供A/B 測試 / canary rollouts 等， Resiliency 提供 timeouts, retries, circuit breakers等功能。
有了這些實際實行服務的功能也就是我們上面說的Service Mesh三個面向的第一個面向 “Traffic control”，Istio也提供了監測的功能，也就是Service Mesh第二個面向”Observability” –可視性，在Istio裡我們稱做”Mixer”(如下圖）
Mixer在Istio裡是一個獨立的元件，專門負責監控資料的收集以及Istio裡Policy的設定。你可以用GCP本身的監控Stackdriver來收集或其他第三方的tool來收集這些數據資料。
最後一個是security，在Istio每一個 proxy與proxy之間的溝通都需要經過加密與驗證。這一部分Istio裡我們稱做Citadel(如下圖）
Citadel在Istio裡就是一個憑證管理平台，負責所有Proxy之間的憑證管理。透過這一個方式我們就能達到微服務與微服務之間的溝通機制安全。
以下我們透過一個例子來展示一下Istio整個traffic的歷程。
Service A的Container開始啟用了，同一時間跟Service A裡的Envoy也啟用了。Envoy會從Pilot把一些Routing/LB的configuration policy的資訊匯入進來，如果驗證功能也有啟用的話也會從Citadel這邊把憑證的資訊匯入。
Service A要呼叫Service B，這個呼叫被Envoy攔截，Envoy從剛剛Pilot匯入的資訊知道要去哪邊呼叫Service B.
Service A的 Envoy將呼叫透過加密的方式往Service B的Envoy傳送。
Service B的Envoy會去跟Mixer驗證這一個呼叫是否是合法的並且檢查ACL/quota/policy等等的限制。
Mixer會驗證後回傳送一個true/false給Service B的Envoy
驗證正確後，Envoy會將這個由Service A 的Envoy來的呼叫往Service B傳送。
Envoy將Service B的回應再傳回給Service A的Envoy
Service B的Envoy也會將監控到的資料回傳給Mixer
最後Service A的Envoy再將由Service B回來的回應再傳回給Service A
如同Service B的Envoy一樣，在呼叫回傳後。Service A的Envoy也會把這一次呼叫的監控資料回傳給Mixer。
以上這些就是一個簡單的範例，在Service Mesh之外的Ingress/Egress我們如何控制呢？Istio提拱Gateways的方式負責整個Service Mesh的對外溝通(參考下圖）
在Gateways這裏我們可以控制要用什麼Ports/Protocol/Hosts可以進入。
另外Istio也提供了Virtual Service的功能
這個功能與K8s的Service很類似，但它比K8s 的service能做到較多細緻化的控制。
以上就是Anthos Service Mesh的簡單介紹