【從小白到專家】Istio技術實踐專題（四）：應用接入Istio的正確姿式

上一篇文章中，咱們介紹了Istio針對單集羣的三種主流部署安裝方式：使用Istioctl安裝、使用Helm自定義安裝、獨立Operator安裝。本文將向你們介紹kubernetes中的應用接入Istio。主要包括kubernetes 中應用接入Istio使用實例、應用技巧、基本知識點總結和須要注意事項。

用什麼姿式接入 istio？

雖然 istio 能解決那麼多的問題，可是引入 istio 並非沒有代價的。最大的問題是 istio 的複雜性，強大的功能也意味着 istio 的概念和組件很是多，要想理解和掌握 istio ，併成功在生產環境中部署須要很是詳細的規劃。通常狀況下，集羣管理團隊須要對kubernetes很是熟悉，瞭解經常使用的使用模式，而後採用逐步演進的方式把 istio 的功能分批掌控下來。

咱們設定如下目標：

•istio部署

•dfb相關服務部署

•網關功能

•流量分配，按比例，header

•超時，重試

Istio的幾個基本資源對象：

1. VirtualService配置影響流量路由的參數，VirtualService 定義了對特定目標服務的一組流量規則。如其名字所示， VirtualService在形式上表示一個虛擬服務，將知足條件的流量都轉發到對應的服務後端，這個服務後端能夠是一個服務，也能夠是在Dest in at i onRu l e 中定義的服務的子集。
2. DestinationRule配置目標規則,DestinationRule定義了在路由發生後應用於服務流量的策略。這些規則指定負載平衡的配置，邊車的鏈接池大小以及離羣值檢測設置，以從負載平衡池中檢測和清除不正常的主機。
3. Gateway服務網關，入口.Gateway描述了一個負載均衡器，該負載均衡器在網格的邊緣運行，以接收傳入或傳出的HTTP / TCP鏈接。
4. Service Entry外部服務配置,經過ServiceEntry，能夠在Istio的內部服務註冊表中添加其餘條目，以便網格中自動發現的服務能夠訪問/路由到這些手動指定的服務。

網關功能：Gateway

Gateway 在網格邊緣接收外部訪問，並將流量轉發到網格內的服務。Istio經過Gateway將網格內的服務發佈成外部可訪問的服務，還能夠經過Gateway 配置外部訪問的端口、協議及與內部服務的映射關係。

網關功能常見的應用：

1. 將網格內的HTTP 服務發佈爲HTTP 外部訪問
2. 將網格內的HTTPS 服務發佈爲HTTPS 外部訪問
3. 將網格內的HTTP 服務發佈爲HTTPS 外部訪問
4. 將網格內的HTTP 服務發佈爲雙向HTTPS 外部訪問
5. 將網格內的HTTP 服務發佈爲HTTPS 外部訪問和HTTPS 內部訪問

在實踐中。咱們更多須要的是1，3兩個場景。

在dfb服務中，dfb-login 做爲最外層的前端，是幾個服務中惟一和外部用戶產生交互的服務。所以咱們經過網關功能，將dfb-login 經過域名暴露給用戶。

建立gateway 的yml文件：

建立virtualservice.yml：

咱們建立了兩個資源對象，一個VirtualService 用來描述流量的路由關係。全部url 前綴爲/ 的請求都route 到後端dfb-login.dfb-istio.svc.cluster.local 服務。

這個virtuaservice 經過gateways 字段和咱們申明的另外一個gateway 資源相互綁定。在Gateway 資源對象中。定義了入口的域名，協議，以及TLS 相關的配置。在istio 中。默認的ingressgateway 會監聽gateway 資源對象的變動。多個ingressgateway 經過selector 進行選擇.默認ingressgateway 是一個loadbalancer的service 。

咱們將這個ingressgateway 修改成宿主機網絡，並固定到一個單獨的節點。這樣咱們就能夠經過將域名解析到這個node節點的方式訪問部署好的入口。

流量分配：按比例，根據請求內容

咱們設置了兩個版本的login 服務。V1 版本用戶登陸後顯示的餘額是從數據庫取出來的。V2版本則是0。根據這兩個版本的差別來判斷流量的流向。

首先經過DestinationRule定義兩個版本：

根據比例：

此時屢次刷新頁面。能夠看到用戶的現金帳戶餘額在0 和真實額度之間變更。

根據請求內容決定路由：

修改上文yml 。經過postman請求dfb服務/home頁面。默認狀況下會路由指向V1版本的login服務。在請求頭添加version=v2的header。則會轉到v2的服務。

超時，重試功能

咱們首先在擴容dfb-api 這個服務爲2個pod，在其中一個pod中攔截用戶資產接口， 直接返回500 ，另外一個pod 正常返回。此時在dfb-login服務中請求。咱們能夠發現，接口500 和200 狀態碼交替出現。

location =/user/account/list/338fbcd2-1be6-4dde-9918-84b7629b1ba5 {           
return500;       

}

此時應用下面的重試規則，再次調用接口。此時接口狀態碼一直返回200。

經過jaeger查看調用鏈，能夠看到調用了兩次dfb-api。雖然中間調用失敗了，可是最終的狀態碼是200。