Tanzu Service Mesh（TSM）以Istio 1.3及VMware所開發的AllSpark Operator來簡化Istio的安裝，提供了強大的功能。那麼追本溯源，若使用開源的Istio是否也能達到類似的效果？本文將使用Istio 1.5.4版本，並透過GKE開啟兩個K8S叢集來做驗證。
前期文章跟大家分享了Tanzu Service Mesh（TSM），其組成是以Istio 1.3以及VMware所開發的AllSpark Operator來簡化Istio的安裝。前文中主要展示了三個TSM的強大功能，包含叢集拓樸、服務效能監控以及跨叢集部署三個部分。
這次要來看如果使用開源的Istio是否也可以達到類似的效果？本文使用Istio 1.5.4版本，並透過GKE開啟兩個K8S叢集，進行驗證。主要依照Istio開源文件內Replicated Control Planes的架構，建置此次的實驗環境，Istio還支援Shared Control Plane機制，但這不在此次討論的範圍內。
預先準備
此次，在Client機器上，將安裝istioctl、ansible-playbook以及Checkout Github專案：
istioctl（v1.5.4）：由Istio下載網頁（https://github.com/istio/istio/releases/download/1.5.4/istio-1.5.4-linux.tar.gz）取得，然後透過tar zxvf指令安裝。
ansible-playbook（v2.2.9）：由ansible頁面說明（https://docs.ansible.com/ansible/latest/installation_guide/）安裝。
Checkout Github專案：依照以下的方式，下載筆者幫大家準備的入門Lab：
// Download istio lab code mkdir -p istio cd istio git init git remote add -f origin https:// github.com/shawnho1018/K8S-Lab.git git config core.sparseCheckout true echo "istio" >> .git/info/sparse- checkout git pull origin master
安裝/設定/展示Cross Cluster功能
如圖1所示，首先提供兩個叢集的Context名稱，至install-istio.yaml裡的cluster1與cluster2變數，或是透過rename context為sm1、sm2：
圖1 設定跨叢集服務的分解步驟（Replicated Control Plane架構）。
kubectl config rename-context [ori ginal-context-cluster1] sm1 kubectl config rename-context [ori ginal-context-cluster2] sm2
接著進入cross-cluster檔案夾，並執行以下命令：
ansible-playbook install-istio.yaml --tag istio
這一段主要透過istioctl在兩個叢集安裝Istio，其中重要的步驟如下：
‧提供各叢集中繼憑證，作為發證服務使用：由於Istio支援微服務動態加密，而服務間憑證，會透過Istio內的Citadel提供憑證簽核。本Lab會驗證跨叢集服務，因此必須讓兩個叢集的簽證服務均能信任同樣的CA。
‧這個機制若在生產環境中，應透過企業內的根憑證，簽出兩張中繼憑證，提供給兩個叢集的Citadel服務使用。在Lab裡，透過專案所提供的中繼憑證、Root CA，以及驗證使用的憑證（在這裡同中繼憑證），相關Istio憑證說明，可參考本文件。
‧設定kalia的預設帳密：定義於bookinfo/kiali-secret.yaml名稱為kiali的secret值，供部署成功後Kiali的預設帳密。
‧設定Istio安裝的內容：定義於cross-cluster.ayml，預設安裝Istio時應同時包含istiocoredns（用於設定Global Namespace）、Kiali（監控微服務間網路流分析）、Grafana、Prometheus、Tracing（服務間的呼叫延遲），Ingress與Egress Gateway（跨叢集網路流使用）等元件。
安裝成功後，可以看到兩個叢集都產生istio-system的名稱空間，並確認Ingress Gateway產生出對應的External IP位置，如圖2所示。
圖2 兩個叢集都產生istio-system的名稱空間，ingress gateway產生對應的External IP位置。
安裝跨叢集的Bookinfo服務
以下的步驟主要是要在兩個叢集間建立Bookinfo服務，先執行以下的命令：
ansible-playbook install-istio.yaml --tag bookinfo
部署完成後的拓樸圖，將如圖3所示。
圖3 執行完 — tag bookshelf後的拓樸圖（虛線尚未連通）。
此時已可透過Istio Ingress Gateway的External IP位置連入Bookinfo的服務中，記得測試時，由於Match Rule為productpage，要加在subpath中（圖4）。
圖4 進行測試。
產生跨叢集的服務定義
最後一步，是為了打通雙邊的服務，將productpage可以連到reviews-v2/reviews-v3：
ansible-playbook install-istio.yaml --tag cross
這裡是為了建立橫跨兩邊的serviceentry（在前篇TSM裡，稱為Global Namespace），手法包含以下三個步驟：
ServiceEntry可以用來設定跨叢集的服務流，以下設定是當本地叢集需要連結到Hostname為reviews.default.global（命名規則為service-name.namespace.global）會由本地叢集的istio-egress-gateway流出，並指向遠端叢集的istio-ingress-gateway進入。當進入遠端叢集後，reviews.default.global會被轉連至本地名稱為reviews.default.svc.cluster.local的服務。
指定本地叢集的目的地規則（DestinationRule），當前端的虛擬服務（virtualservice）的主機名稱指定為reviews.default.global時，連結上述指定的serviceentry，若主機名稱為reviews.default.svc.cluster.local時，則將服務導向本地Reviews服務：
DestinationRule for cluster-1
DestinationRule for cluster-2
這個步驟透過不同的比對原則，將productpage往後連接的reviews.default.svc.cluster.local，轉接到不同的目的地。若登入使用者為jason，透過目的地規則導向本地的Reviews服務，但其他使用者，則導向遠端的Reviews服務。
成果展示
設定完畢，接下來將透過實際操作來展示成果。
跨叢集服務
透過上述的設定，測試productpage，可以看到當Jason登入時，Review呈現不帶Rating的評論，如圖5所示。
圖5 以Jason登入productpage，連至本地叢集內的Review服務。
若非Jason登入時，Reviews呈現評論外，還加上了紅色或黑色的Rating，如圖6所示。
圖6 以Shawn登入productpage，被導向另一個叢集。
網路流呈現
透過Istio 1.5.4安裝，一併安裝的Kiali，登入後（使用本文件安裝，預設帳密為admin/admin）即可看到完整的網路拓樸：
// 若Client有UI (e.g. Ubuntu Desktop) istioctl dashboard kiali // 若Client沒有UI，可將kiali服務種類， 由ClusterIP修改為LoadBalancer kubectl edit svc kiali -n istio-system
如圖7所示，紫色部分（箭頭指向）表示該服務為虛擬服務，可能有一個或是多個目的地規則可供選擇。
圖7 可能有一個或是多個目的地規則可供選擇。
在點選reviews服務的時候，可以展開後端的連線，亦即圖中綠色線（箭頭指向）為有流量的連線，最後的結果就如圖8所示一般。
圖8 展開後端的連線。
接著如圖9所示點選對應微服務（Applications），也可看到該服務的效能與延遲的統計狀況（如p50、p95、p99）。
圖9 點選對應微服務，可以查看該服務的效能與延遲的統計狀況。
微服務間的延遲狀況
Istio 1.5.4也提供了Jaeger這樣的工具，可以做微服務間的延遲統計。如果與Kiali相比，Jaeger除了提供Kiali有的延遲資訊之外，還包含了每段服務間的延遲追蹤。
如圖10所示，是依照延遲排序，這裡發現一件有趣的事，追蹤段有包含到Reviews的延遲較短。這個原因應該是Jaeger無法追蹤到跨叢集的服務。因此，有收到Review延遲的，表示該Request登入使用者是Jason，使用本地的Review服務。而圖11顯示登入者為Jason的本地查詢，所有微服務間的延遲。
圖10 連線延遲統計（由短到長）。
圖11 包含本地Review服務的追蹤。
圖12顯示跨叢集的查詢，由於遠端叢集的Istio Agent無法回報到本地Jaeger，因此看不到Review與productpage間的延遲。
圖12 Tracer看不到遠端Review服務的延遲狀況。
結語
希望透過這篇文章，讓大家認識以開源Istio實作的ServiceMesh機制，相較於之前Tanzu Service Mesh（TSM），這裡以表1做比較。由表1可知，基於Istio的TSM的優勢如下所示：
‧跨叢集服務拓樸顯示：透過TSM的註冊介面，可以呈現跨叢集的服務拓樸，但是Istio的Kiali無法得知跨叢集的連線狀況，因此只能夠呈現單一叢集內的拓樸。
‧簡易的Global Namespace設定：TSM有Global Namespace的設置，可以快速地將跨叢集的Namespace打通，不需要手動設計ServiceEntry或是DestinationRule等等。
但由於目前TSM使用的Istio版本過舊，造成周邊監控（例如Jaeger、prometheus等等）必須額外安裝。希望在未來TSM升級後，這個問題可以解決。下一次，就來研究Google的Anthos Service Mesh（ASM）。
＜本文作者：Shawn Ho，致力推動雲端運算服務加速企業創新研發能力，現任開源容器K8S技術的佈道者，希望透過新技術加速企業內的流程改造。Shawn喜歡以終為始，持續學習新技術，閒暇時考考證照來娛樂自己。近來發現社群裡有更多志同道合的夥伴一起玩技術，所以開始寫部落格《輕鬆小品：PKS和K8S的點滴》，歡迎切磋（https://tinyurl.com/ycmkzxg8）！＞