Service Mesh：Istio1.0在Openshift3.10上的實踐

1、實驗環境

實驗環境使用最新版本的Openshift：V3.10.

Istio使用最新V1.0版本

Istio已經以容器的方式，部署到Openshift的一個項目中：

查看項目中的pod：

查看mvn的版本：

瀏覽器登陸Openshift 3.10：

2、部署三個微服務

本實驗中有三個微服務，它們按如下順序連接在一塊兒，具備以下的調用關係：

gateway（網關） -> partner（合做夥伴） -> catalog(目錄服務)

部署目錄服務版本1（v1）

Istio引入了服務版本的概念，這是一種經過版本（v1，v2）或環境（staging，prod）細分服務實例的更細粒度的方法。 這些變體不必定是不一樣的API版本：它們能夠是對同一服務的迭代更改，部署在不一樣的環境（prod，staging，dev等）中。 使用它的常見方案包括A / B測試或金絲雀發佈。 Istio的流量路由規則能夠引用服務版本，以提供對服務之間流量的額外控制。

如今讓咱們首先將目錄服務部署到OpenShift,sidecar代理將自動注入。

首先經過maven編譯一個jar，而後經過docker build的方式，將jar部署到docker image中：

爲目錄服務建立docker鏡像。 此外，驗證映像是否位於本地docker存儲庫中。

首先查看Dockerfile：

sudo docker build -t example/catalog:v1 . sudo docker images | grep example/catalog

部署目錄服務並注入istio sidecar。

因爲目錄服務位於咱們的服務鏈（網關 - >合做夥伴 - >目錄）的末尾，所以它不會暴露給外部世界。

部署合做夥伴服務：

爲合做夥伴服務建立docker鏡像。 此外，驗證映像是否位於本地docker存儲庫中。

sudo docker build -t example/partner:v1 . sudo docker images | grep example/partner

部署合做夥伴服務並注入istio sidecar。

部署網關服務：

最後，咱們將網關服務部署到OpenShift。 這將完成咱們的服務列表：

部署網關服務並注入istio sidecar。

因爲網關服務是咱們的用戶將與之交互的服務，所以咱們添加一個公開該端點的OpenShift路由。

檢索網關服務的URL

測試網關服務

gateway => partner => catalog v1 from '57bcbf87dc-cslxn': 1

3、帶有Istio的動態路由測試

隨着基於微服務的應用程序變得愈來愈流行，它們的交互的數量和複雜性都會增長。 到目前爲止，管理這些複雜的微服務交互的大部分負擔已經放在應用程序開發人員身上，根據語言和框架對微服務概念提供不一樣或不存在的支持。

服務網格概念將此職責推向基礎架構，具備流量管理，分佈式跟蹤和可觀察性，策略實施和服務/身份安全性等功能，使開發人員可以專一於業務價值。 在本次實踐課程中，您將學習如何將這些功能中的一些應用於使用Istio開發的基於OpenShift的簡單多語言微服務應用程序，Istio是一個鏈接，管理和保護微服務的開放平臺。

Istio是一個鏈接，管理和保護微服務的開放平臺。 Istio提供了一種經過負載平衡，服務到服務身份驗證，監控等建立已部署服務網絡的簡便方法，無需對應用程序代碼進行任何更改。 OpenShift能夠在您的環境中自動注入特殊的邊車代理，以便爲您的應用程序啓用Istio管理。 此代理攔截您的微服務微服務之間的全部網絡通訊，並使用Istio的控制平面功能進行配置和管理 - 而不是您的應用程序代碼

本實驗中有三個微服務，它們按如下順序連接在一塊兒：

網關 - >合做夥伴 - >目錄

在本實驗中，您將使用Istio動態更改服務之間的路由。

部署目錄服務版本2（v2）

修改應用的源碼：

mvn clean package 

sudo docker build -t example/catalog:v2 .

部署目錄服務版本2

您可使用如下命令查看運行的兩個版本的目錄窗格：

默認狀況下，Istio會將傳入的請求循環到目錄服務，以便v1和v2 pod都得到相同數量的流量。

將全部流量發送到目錄：v2

路由規則控制請求在Istio服務網格中的路由方式。

能夠根據源和目標，HTTP標頭字段以及與各個服務版本關聯的權重來路由請求。例如，路由規則能夠將請求路由到不一樣版本的服務。

除了常見的OpenShift對象類型（如BuildConfig，DeploymentConfig，Service和Route）以外，還有新的對象類型做爲Istio的一部分安裝，如RouteRule。將這些對象添加到正在運行的OpenShift集羣是如何爲Istio配置路由規則。

DestinationRule定義在路由發生後應用於服務的流量的策略。這些規則指定負載平衡的配置，來自sidecar的鏈接池大小，以及異常檢測設置，以從負載平衡池中檢測和驅逐不健康的主機。

VirtualService定義了一組要在主機被尋址時應用的流量路由規則。每一個路由規則定義特定協議的流量的匹配標準。若是流量匹配，則將其發送到註冊表中定義的命名目標服務（或其子集/版本）。流量來源也能夠在路由規則中匹配。這容許爲特定客戶端上下文定製路由。

istiofiles/virtual-service-catalog-v2.yml

此定義容許您配置必定百分比的流量並將其定向到特定版本的目錄服務。 在這種狀況下，目錄服務的100％流量（權重）將始終轉到與標籤版本匹配的pod：v2。 這裏的pod的選擇很是相似於基於標籤的Kubernetes選擇器模型。 所以，嘗試與目錄服務通訊的服務網格中的任何服務將始終路由到目錄服務的v2。

使用配置文件將全部流量路由到v2：

oc create -f istiofiles/destination-rule-catalog-v1-v2.yml -n $OCP_TUTORIAL_PROJECT --as=system:admin 

oc create -f istiofiles/virtual-service-catalog-v2.yml -n $OCP_TUTORIAL_PROJECT --as=system:admin

將全部流量發送到目錄：v1

配置必定比率的訪問：

4、斷路器實驗室

本實驗介紹瞭如何注入錯誤並測試應用程序的彈性。 Istio提供了一組故障恢復功能，能夠經過應用程序中的服務進行利用。 功能包括：

Pool Ejection出或異常值檢測是一種彈性策略，只要咱們有一個實例/ pod池來爲客戶端請求提供服務，就會發生這種策略。 若是請求被轉發到某個實例而且它失敗（例如返回50x錯誤代碼），那麼Istio將從池中彈出該實例以得到某個sleep windows。 在咱們的示例中，睡眠窗口配置爲15秒。 經過確保只有健康的pod參與實例池，這能夠提升總體可用性。

首先，您須要確保有一個目標規則和虛擬服務，以便向服務發送流量。

oc create -f istiofiles/destination-rule-catalog-v1-v2.yml -n $OCP_TUTORIAL_PROJECT --as=system:admin 

oc create -f istiofiles/virtual-service-catalog-v1_and_v2_50_50.yml -n $OCP_TUTORIAL_PROJECT --as=system:admin

測試行爲沒有失敗的實例：

將一些請求發送到網關服務：

您應該看到兩個不一樣版本的目錄服務之間的負載平衡50/50。

在v2版本中，您還會看到一些請求由一個pod處理，一些請求由另外一個pod處理。

一樣是版本v2，全部請求都有三秒鐘的延遲。 所以測試運行須要更長的時間。

測試具備失敗實例且沒有Pool Ejection的行爲

如今咱們將鏈接到一個pod並在其上添加一些不穩定的行爲。

使用如下命令鏈接到其中一個pod：

上面的操做，至關於觸發應用中的源碼變動，讓這個pod被訪問的時候，永遠會報錯：

測試具備失敗實例和Pool Ejection的行爲

若是請求被轉發到某個實例而且它失敗（例如返回50x錯誤代碼），那麼Istio將從池中彈出該實例以得到某個睡眠窗口。 在咱們的示例中，睡眠窗口配置爲15秒。 經過確保只有健康的pod參與實例池，這能夠提升總體可用性。

如今讓咱們添加Pool Ejection行爲：

oc replace -f istiofiles/destination-rule-catalog_cb_policy_pool_ejection.yml -n $OCP_TUTORIAL_PROJECT --as=system:admin

再次發起請求，咱們看到，出現一次報錯後，被Pool Ejection，就再也不報錯了：

在被Pool Ejection後，並睡眠窗口到期以前它再也不接收任何請求 - 這至少須要15秒。

等待15秒再次運行測試。 您偶爾會看到503錯誤，但在第一次嘗試後它將在15秒窗口期間消失。

具備重試、斷路器和池Pool Ejection的終極彈性解決方案

即便有Pool Ejection，你的應用程序看起來也不那麼有彈性， 這多是由於咱們仍然讓一些錯誤傳播給咱們的客戶。 但咱們能夠改善這一點。 若是咱們有足夠的實例和/或特定服務版本運行到咱們的系統中，咱們能夠結合多個Istio功能來實現最終的後端彈性：

• 斷路器以免對實例的多個併發請求

• Pool Ejection從響應實例池中刪除失敗的實例

• 重試將請求轉發給另外一個實例，以防萬一咱們獲得開路斷路器和/或池彈出;

經過簡單地向咱們當前的虛擬服務添加劇試配置，咱們將可以徹底擺脫咱們的`503的請求。 這意味着每當咱們從彈出的實例收到失敗的請求時，Istio會將請求轉發給另外一個能夠保持健康的實例。

添加劇試配置

oc replace -f istiofiles/virtual-service-catalog-v1_and_v2_retry.yml -n $OCP_TUTORIAL_PROJECT --as=system:admin

再次發起請求，咱們不會再收到503的了。 可是目錄`v2的請求仍然須要更多時間才能獲得回覆。所以被Pool Ejection的pod的請求，將會被轉發到好的pod實例。