Istio技術與實踐05：如何用istio實現流量管理

Istio是什麼？

Istio 1.0版本於8月1號凌晨準點發佈，核心特性已支持上生產環境，各大微信公衆號、博客紛紛發文轉載。那麼 Istio 究竟是什麼？能解決問題什麼？

• Istio 是 Google 繼 Kubernetes 以後的又一開源力做，主要參與的公司包括 Google，IBM，Lyft 等，它提供了完整的非侵入式的微服務治理解決方案，解決微服務的管理、網絡鏈接以及安全管理等應用網絡治理問題
• 它無需修改任何代碼就可以實現微服務的負載均衡，服務與服務之間的認證受權以及流量監控和治理。從整個基礎設施角度上看，能夠將它理解爲 PaaS 平臺上的一個面向微服務管理平臺的補充。

Istio與Kubernetes

Kubernetes 提供了部署、升級和有限的運行流量管理能力，利用 service 的機制來作服務註冊和發現，轉發，經過 kubeproxy 有必定的轉發和負載均衡能力。但並不具有上層如熔斷、限流降級、調用鏈治理等能力。 Istio 則很好的補齊了 k8s 在微服務治理上的這部分能力，同時是基於 k8s 構建的，但不是像 SpringCloud Netflix 等徹底從新作一套。Istio 是谷歌微服務治理上的很是關鍵的一環。

Istio流量管理能力介紹

Istio，用於鏈接、保護、控制和觀測服務。今天，咱們就來談談 Istio 第一主打功能——鏈接服務。那麼，便引出3個問題：

• Istio 如何實現服務之間的鏈接？
• 鏈接後具有哪些流量管理能力？
• 如何告訴 Istio 發揮這些能力？

一、 Istio 如何實現服務的鏈接？

如上圖所示的 Istio 架構圖，讓咱們關注控制面的 Pilot，它是 Istio 實現流量管理的核心組件。 而在數據面，每一個 Service，都會被注入1個 Proxy。Istio 經過 Pilot 下發配置信息給數據面每1個 Service 的 Proxy，從而經過這些 Proxy，間接地控制每1個Service之間以及和外部的鏈接。Proxy 一般採用另外一個知名的開源項目 Envoy 來實現。 1個 Pilot 和(N+N)個( Service + Proxy )組合，便造成了 Service Mesh，即服務網格。有了這一套服務網格系統，對服務之間的流量進行管理，便不在話下。

二、鏈接後具有哪些流量管理能力？

從服務間的流量管理角度而言，Istio能夠實現這4項功能：請求路由、服務發現和負載均衡、故障處理和故障注入。

A.請求路由

如上圖所示，Istio 引入了服務版本的概念，能夠經過(Current Version，Canary Version )2個版本對服務進行進一步的細分。基於這種劃分，經過 Pilot，能夠下發配置到 Service A 的 Proxy，使得其95%的流量路由至 Service B的 Current 版本，5%的流量路由至 Service B 的 Canary 版本。固然也能夠選擇雨露均沾，各分50%流量，或者霸道總裁，讓 Canary 版本佔有100%的流量。

如上圖所示， 除了按照百分比在不一樣版本之間分發流量，你還能夠按照請求內容，將請求路由至不一樣的版本。例如，你能夠發佈一個 Canary 版本，只讓用着 Macbook 筆記本，且安裝了 windows 操做系統，還使用着360瀏覽器的用戶可以訪問到。 這一切改變，都只須要你改動一個叫 VirtualService 的配置文件（詳見下章），眨個眼的功夫，Istio 就已經經過 Pilot 幫你把新的配置下發下去了。

B.服務發現和負載均衡

如上圖所示， 服務網格存在3個生命週期的動態循環：服務註冊、服務發現、負載均衡。

一般 kubernetes，mesos 等容器管理平臺已經提供了服務註冊表，以跟蹤服務的負載實例，因此 Pilot 能垂手可得地獲知服務網格內的全部服務註冊信息，並將這些信息告知全部服務裏的 Proxy，Proxy 根據這些信息執行服務發現，並相應地動態更新其負載均衡池。一個服務一般有多個負載實例，Service A 請求 ServiceB 時，能夠配置不一樣的負載均衡模式：輪詢、隨機和帶權重的最少請求。假設此時Service B的某個負載實例出現故障，由於 Service A 中的 Proxy 會按期地執行服務發現，從而能及時將故障實例從其負載均衡池裏排出。

C.故障處理

Envoy 提供了一套開箱即用，可選的故障處理功能，對應用中的服務大有裨益。這些功能包括：

• 超時
• 具有超時預算，並進行有限重試，重試之間的時長可抖動
• 併發鏈接數和上游服務請求數限制
• 對負載均衡池中的每一個成員進行主動（按期）運行健康檢查
• 細粒度熔斷器（被動健康檢查）- 適用於負載均衡池中的每一個實例

以 Service A 請求調用 Service B 爲例。

對於功能1。若 Service B 明確地知道10s之後的超時，一定會帶來失敗，那將超時時長縮短，使得 Service A 能夠更快得知結果並做出應對，不失爲一個明智之舉。

對於功能2。對超載的 Service B 來講，重試之間的抖動極大的下降了重試形成的影響，而超時預算確保 Service A在可預測的時間範圍內得到響應（成功/失敗）。

對於功能3。限制 Service A 或其餘服務對 Service B的鏈接數和請求數，可使得 Service B免於遭遇 DDOS 攻擊，或承受太重的流量負擔而崩潰。

對於功能4和5。主動和被動健康檢查的組合最大限度地減小了在負載平衡池中訪問不健康實例的機會。當與平臺級健康檢查（例如由 Kubernetes 或 Mesos 支持的檢查）相結合時，應用程序能夠確保將不健康的負載實例快速地從服務網格中去除，從而最小化請求失敗和延遲產生影響。

總之，這些功能使得服務網格可以耐受故障節點，並防止本地故障致使的其餘節點的穩定性降低。

D.故障注入

雖然 Proxy 爲在 Istio 上運行的服務提供了上節所言的大量故障處理機制，但測試整個服務網格所組成應用的端到端的故障恢復能力依然是必須的。錯誤配置的故障恢復策略（例如，跨服務調用的不兼容/限制性超時）可能致使應用程序中的關鍵服務持續不可用，從而破壞用戶體驗。

Istio 能在不殺死負載實例的狀況下，將協議特定的故障注入到網絡中，在 TCP 層製造數據包的延遲或損壞。咱們的理由是，不管網絡級別的故障如何，應用層觀察到的故障都是同樣的，而且能夠在應用層注入更有意義的故障（例如，HTTP 經典的4xx和5xx錯誤代碼），以檢驗和改善應用的韌性。

運維人員能夠爲符合特定條件的請求配置故障，還能夠進一步限制遭受故障的請求的百分比。能夠注入兩種類型的故障：延遲和中斷。延遲是計時故障，模擬網絡延遲上升或上游服務超載的狀況。中斷是模擬上游服務的崩潰故障。中斷一般以 HTTP 錯誤代碼或 TCP 鏈接失敗的形式表現。

依舊以 Service A 請求調用 Service B 爲例。

若給 Service B設定了10s的延時或503中斷，則 Service A將至少10s後才能獲得請求的響應或請求的響應爲503錯誤，經過多種場景覆蓋測試，能夠獲得 Service A 面對這些場景時的綜合表現狀況，從而作出針對性的改良，增長其韌性。

三、如何告訴Istio發揮這些能力？

Istio有4個配置文件，幫咱們全方位地定製以上全部流量管理需求: VirtualService, DestinationRule, ServiceEntry和 Gateway:

• 經過配置 VirtualService，能夠實現請求路由的功能；
• 經過配置 DestinationRule，能夠實現服務發現和負載均衡、故障處理和故障注入的功能；
• 經過配置 ServiceEntry，讓服務網格內的服務，能夠看到外面的世界；
• 經過配置 Gateway，讓服務網格的服務，能夠被全世界看到；

有了以上4大法寶，咱們對服務網格進行流量管理的全部需求，均可以被知足了。

限於篇幅，讓咱們舉3個簡單的栗子：

假設咱們的服務網格存在1個服務 explorer，只有1個v1版本；存在另1個服務 helloworld，有v1,v2兩個版本。

①若要使得 explorer 發起的全部請求，以75%的機率走向 helloworld 的v1版本，以25%走向v2版本，只要配置以下兩個文件 VirtualService 和 DestinationRule，即可實現：

apiVersion:networking.Istio.io/v1alpha3
kind:VirtualService
metadata:
  name:helloworld
spec:
  hosts:
    - helloworld
  http:
  - route:
    - destination:
        host:helloworld
        subset:v1
      weight:75
    - destination:
        host: helloworld
        subset: v2
     weight: 25

apiVersion:networking.Istio.io/v1alpha3
kind:DestinationRule
metadata:
  name: helloworld
spec:
  host: helloworld
  subsets:
  - name:v1
    labels:
      version: v1
  - name: v2
   labels:
      version: v2
複製代碼

②若是 helloworld 內部須要經過訪問www.google.com 來獲取一些信息，才能告訴 explorer 這個世界是怎麼樣的，須要配置以下2個文件 ServiceEntry 和 DestinationRule：

apiVersion:networking.Istio.io/v1alpha3
kind:ServiceEntry
metadata:
  name: googleapis
spec:
  hosts:
  - "*.google.com"
  ports:
  - number:443
    name:https
    protocol:http
 
apiVersion:networking.Istio.io/v1alpha3
kind:DestinationRule
metadata:
 name: googleapis
spec:
  host: "*.google.com"
複製代碼

③若是 helloworld 須要被服務網格外，而不只僅是 explorer 服務訪問到，則須要配置以下2個文件 Gateway 和 VirtualService：

apiVersion:networking.Istio.io/v1alpha3
kind:Gateway
metadata:
 name: helloworld-gateway
spec:
   selector:
     Istio:ingressgateway
 servers:
 - port:
     number: 80
     name: http
     protocol: HTTP
   hosts:
   - 'helloworld.com'
  
apiVersion:networking.Istio.io/v1alpha3
kind:VirtualService
metadata:
name: bookinfo
spec:
hosts:
   - 'helloworld.com'
 gateways:
 - helloworld-gateway
 http:
 - route:
  - destination:
       host: helloworld
       port:
         number: 9080
複製代碼

至此，咱們作一個簡單的總結：Istio 提供的 Pilot 和 Proxy，將成百上千個服務組成了一個服務網格。基於此，咱們能夠實現請求路由、服務發現和負載均衡、故障處理以及故障注入等流量管理能力，這一切，咱們只須要經過對 VirtualService, DestinationRule, ServiceEntry 和 Gateway 這4個資源作簡單的配置，便可實現。