第3章流控............................................................................................................... 1

3.1 更加智慧的金絲雀........................................................................................ 1

3.2流量路由...................................................................................................... 2

3.2.1路由到特定版本的部署........................................................................ 3

3.2.2 Recommendation服務v2版本的金絲雀部署........................................... 4

3.2.3 繼續加碼recommendation服務的v2版本.............................................. 5

3.2.4 基於HTTP頭的路由.......................................................................... 6

3.3 暗部署......................................................................................................... 8

3.4對外請求（Egress）..................................................................................... 10

第3章流控

前面講過Istio包括一個控制平面和一個數據平面。資料平面由代理組成，代理以邊車容器形式和業務容器共存。前面還介紹了“邊車”這種代理部署方式，其中每個應用例項都有自己專屬的代理，網路流量在到達應用例項之前都會經過該代理。這些邊車代理可以獨立地配置路由、過濾和擴張網路流量。本章中，我們會介紹利用Istio的各種流控模式。你將發現這些模式其實跟一些大的網際網路公司比如Netfilix、Amzaon和Fracebook用的東西差不多。

3.1 更加智慧的金絲雀

過去幾年中金絲雀部署（canary deployment）概念變得越來越流行。這個名字來自於“煤礦中的金絲雀”概念。過去礦工們常把一隻鳥籠中的金絲雀放進礦井中去檢測是否有危險氣體存在，因為金絲雀比人類對這類氣體更加敏感。金絲雀不僅能為礦工們放聲歌唱，而且一旦發現有危險氣體洩露，礦工們就能迅速逃離礦井。

金絲雀部署也有類似作用。在這種部署模式下，你部署一個新版本程式碼到生產環境中，但只允許一部分流量訪問到它。也許只是測試客戶，也許只是組織內部員工，也許只是iOS使用者等等。然後你可以監控這個版本的故障、出錯、SLA的變化等等。如果這個版本沒有問題，那就可以逐步引導更多的流量給到它；如果有問題，那就很容易將它從生產環境中移除。金絲雀部署讓你部署更快，而且將可能的有問題程式碼帶來的影響控制到最小。

預設地，Kubernetes提供Service提供輪詢負債功能能力。如果你只想為最新程式碼pod匯入10%的網路流量，那麼你不得不將新程式碼pod的數目設定為老程式碼pod的十分之一。利用Istio，你可以做到更精細的控制。你可以設定只將20%的網路流量導給三個最新程式碼的pod。Istio還能讓你逐漸增加匯入給新程式碼pod的流量，直到所有流量都被匯入給它，然後老程式碼版本就能從生產環境中移除了。

3.2流量路由

使用Istio，你可以設定路由規則（routing rule）來控制流量匯入指定pod中。特別地，Istio使用DestionationRule和VirtualServer資源來描述這些規則。下面是一個DestionationRule示例：

apiVersion: networking.istio.io/v1alpha3

    kind: DestinationRule

    metadata:

      name: recommendation

      namespace: tutorial

    spec:

      host: recommendation

      subsets:

      - labels:

          version: v1

        name: version-v1

      - labels:

          version: v2

          name: version-v2

下面是一個VirtualServer示例，它通過一個集合（subset）和權重（weighting factor）來指定流量匯入：

apiVersion: networking.istio.io/v1alpha3

    kind: VirtualService

    metadata:

      name: recommendation

      namespace: tutorial

    spec:

      hosts:

      - recommendation

      http:

      - route:

        - destination:

            host: recommendation

            subset: version-v1

            weight: 100

使用此VirtualService定義，你可以配置特定百分比的流量定向到recommendation服務的特定版本上。在上面的例子中，recommendation服務的100％流量將始終流向與標籤version:v1匹配的pod。此處Pod的選擇方式與Kubernetes基於標籤的選擇器模型非常相似。因此，服務網格中與recommendation服務進行通訊的任何流量都將始終被路由到recommendation服務的v1版本。

上述路由行為不僅僅針對進入流量（ingress trafic）。實際上，可針對所有進入了網格的流量。這適用於網格內的所有服務間通訊。如本例所示，這些路由規則適用於可能在服務呼叫圖中的深層服務。如果你將不屬於服務網格的服務部署到Kubernetes，它將不會看到這些規則，而會遵循預設的Kubernetes負載平衡規則。

3.2.1路由到特定版本的部署

為了在類似金絲雀部署的場景中展示Istio更復雜的路由能力，我們來部署recommendation服務的v2版本。首先，你要修改recommendation服務的一些原始碼。修改

com.redhat.developer.demos.recommendation.RecommendationVerticle中的RESPONSE_STRING_FORMAT所定義的字串為“v2”：

private static final String RESPONSE_STRING_FORMAT = "recommendation v2 from '%s': %d\n";

然後再編譯和打包新程式碼為v2版本：

cd recommendation/java/vertx

mvn clean package

docker build -t example/recommendation:v2 .

你可以執行jar檔案以快速測試程式碼修改：

java -jar target/recommendation.jar

然後你在另一箇中斷中執行下面的curl命令：

curl localhost:8080

recommendation v2 from 'unknown': 1

最後，注入Istio邊車代理並部署到Kubernetes中：

oc apply -f <(istioctl kube-inject -f  ../../kubernetes/Deployment-v2.yml) -n tutorial

現在，你可以執行oc get pods命令去檢視pod。如果所有pod都成功執行的話，會是下面這樣子：

NAME                    READY STATUS  RESTARTS     AGE

customer-3600192384-fpljb      2/2     Running   0          17m

preference-243057078-8c5hz     2/2     Running   0          15m

recommendation-v1-60483540     2/2    Running   0          12m

recommendation-v2-99634814     2/2    Running   0          15s

現在，執行curl訪問customer服務端點，就會看到流量在兩個recommendation版本中做負載均衡。你會看到下面這樣子：

#!/bin/bash

    while true

    do curl customer-tutorial.$(minishift ip).nip.io

    sleep .1

    done

    customer => preference => recommendation v1 from '60483540': 29

    customer => preference => recommendation v2 from '99634814': 1

    customer => preference => recommendation v1 from '60483540': 30

    customer => preference => recommendation v2 from '99634814': 2

    customer => preference => recommendation v1 from '60483540': 31

    customer => preference => recommendation v2 from '99634814': 3

現在，建立DestionalRule和VirtualService例項來將所有流量匯入recommendation服務的v1版本。你要轉到原始碼的根目錄，進入istio-tutorial目錄，執行下面的命令：

oc -n tutorial create -f istiofiles/destination-rule-recommendation-v1-v2.yml

oc -n tutorial create -f istiofiles/virtual-service-recommendation-v1.yml

現在，執行curl命令去訪問customer服務的話，你會看到流量全部被導到了v1版本：

customer => preference => recommendation v1 from '60483540': 32

customer => preference => recommendation v1 from '60483540': 33

customer => preference => recommendation v1 from '60483540': 34

VirtualService已經建立了到由DesetionationRule指定的目標子集的路由，子集中只有recommendation服務的v1版本。

3.2.2 Recommendation服務v2版本的金絲雀部署

現在，所有訪問流量都被導向recommendation服務的v1版本。你可以使用建立一個VirtualService例項來進行金絲雀部署：

apiVersion: networking.istio.io/v1alpha3

    kind: VirtualService

    metadata:

      name: recommendation

      namespace: tutorial

    spec:

      hosts:

      - recommendation

      http:

      - route:

        - destination:

            host: recommendation

            subset: version-v1

          weight: 90

        - destination:

            host: recommendation

            subset: version-v2

          weight: 10

這個VirtualService例項指定90%的流量被導向v1版本，10%的流量被導向v2版本。現在，使用這個VirtualService例項來覆蓋之前的例項，使用下面的命令：

oc -n tutorial replace -f istiofiles/virtual-service-recommendation-v1_and_v2.yml

現在，使用curl命令訪問customer服務的話，只有10%的流量被導向recommendation服務的v2版本。V2就是一個金絲雀版本。監控其日誌、指標和跟蹤系統來檢視這個版本有沒有引入任何錯誤或非期望的行為到你的環境中。

3.2.3 繼續加碼recommendation服務的v2版本

現在，如果沒有任何不期望的事情發生，你對recommendation服務的v2版本的信心會大一些了。你可能會想往v2版本匯入更多的流量。此時，你只需要將如下VirtualService定義替換已有的：

apiVersion: networking.istio.io/v1alpha3

    kind: VirtualService

    metadata:

      name: recommendation

      namespace: tutorial

    spec:

      hosts:

      - recommendation

      http:

      - route:

        - destination:

            host: recommendation

            subset: version-v1

          weight: 50

        - destination:

            host: recommendation

            subset: version-v2

          weight: 50

使用這個VirtualService例項後，各有50%的流量會被導向v1和v2版本。要應用該配置，只需要執行下面的命令：

oc -n tutorial replace –f istiofiles/virtual-service-recommendation-v1_and_v2_50_50.yml

執行成功後，你會看到流量行為的變化，一半流量被導向了v2版本，另一半到v2版本。輸出類似下面這樣子：

customer => ... => recommendation v1 from '60483540': 192

customer => ... => recommendation v2 from '99634814': 37

customer => ... => recommendation v2 from '99634814': 38

customer => ... => recommendation v1 from '60483540': 193

customer => ... => recommendation v2 from '99634814': 39

customer => ... => recommendation v2 from '99634814': 40

最後，如果一切正常的話，你可將所有流量導向v2版本，只需應用下面的VirtualService例項：

apiVersion: networking.istio.io/v1alpha3

    kind: VirtualService

    metadata:

      name: recommendation

      namespace: tutorial

    spec:

      hosts:

      - recommendation

      http:

      - route:

        - destination:

            host: recommendation

            subset: version-v2

            weight: 100

現在，你會看到所有流量被導向v2版本：

customer => preference => recommendation v2 from '99634814': 43

customer => preference => recommendation v2 from '99634814': 44

customer => preference => recommendation v2 from '99634814': 45

customer => preference => recommendation v2 from '99634814': 46

customer => preference => recommendation v2 from '99634814': 47

customer => preference => recommendation v2 from '99634814': 48

在繼續下面的步驟前，要恢復到預設流量路由行為，執行下面的命令刪除recommendation服務的VirtualService例項即可，然後你會看到Kubernetes自己的輪詢負載均衡效果：

oc delete virtualservice/recommendation -n tutorial

3.2.4 基於HTTP頭的路由

前面介紹了Istio基於服務的元資料所做的細粒度路由控制。你還可以用Istio基於請求的元資料進行控制。比如，你可以使用匹配原語去建立基於請求的特定路由規則。比如，你想基於請求的地域、移動裝置或者瀏覽器去將部分流量導向特定服務。我們來看下如何利用Istio做到這些。使用Istio，你可以在VirtualService中設定匹配規則。例如下面的VirtualService定義：

apiVersion: networking.istio.io/v1alpha3

    kind: VirtualService

    metadata:

      creationTimestamp: null

      name: recommendation

      namespace: tutorial

spec: hosts:

      - recommendation

      http:

      - match:

        - headers:

            baggage-user-agent:

              regex: .*Safari.*

        route:

        - destination:

            host: recommendation

            subset: version-v2

      - route:

        - destination:

            host: recommendation

            subset: version-v1

這條規則匹配HTTP請求頭，只將由“Safari”瀏覽器發起的請求匯入recommendation服務的v2版本。執行下面的命令以安裝這條規則：

oc -n tutorial create -f istiofiles/virtual-service-safari-recommendation-v2.yml

然後試一下：

curl customer-tutorial.$(minishift ip).nip.io

customer => preference => recommendation v1 from '60483540': 465

如果在curl命令中新增“user-agent：Safari”頭，那麼訪問會被導向v2版本：

curl -H 'User-Agent: Safari' customer-tutorial.$(minishift ip).nip.io

customer => preference => recommendation v2 from '99634814': 318

如果用Firefox瀏覽器，那該訪問會被導向v1版本：

curl -A Firefox customer-tutorial.$(minishift ip).nip.io

customer => preference => recommendation v1 from '60483540': 465

注意：如果你使用真實的瀏覽器進行測試，請注意在macOS系統上Chome瀏覽器會被識別為Safari。

Istio的DestiontionRule和VirtualService物件是使用CRD定義的，你可以象使用Kubernetes原生物件型別（比如Deployment、Pod、Service等）一樣去使用它們。執行下面的命令去獲取跟recommendation有關的Istio物件：

oc get crd | grep virtualservice

kubectl describe destinationrule recommendation -n tutorial

oc get virtualservice recommendation -o yaml -n tutorial

注意：基本上oc和kubectl兩個命令可以交替使用，因為oc是kubectl的一個超級，它多了一些跟login、project和new-app相關的命令，這些命令彌補了原生Kubernetes的一些不足。

繼續下面的步驟前，請使用下面的命令去清理所安裝的Istio物件：

oc delete virtualservice recommendation -n tutorial

oc delete destinationrule recommendation -n tutorial

3.3 暗部署

暗部署（Dark Launch）對不同的人有不同的含義。本質上，暗部署是對客戶不可見的一種生產系統的部署。此時，Istio允許你複製或映象流量到應用的新版本中，然後將其行為與線上應用的行為進行對比。這種方式允許你將生產品質的請求導向新服務，同時不影響生產環境。

例如，recommendation的v1版本是生產環境，而v2版本是新部署環境。可使用Istio將到v1的瀏覽映象到v2。但Istio做瀏覽映象時，它採用“觸發並忘記”（fire-and-forget）模式。其含義是，Istio會做生產瀏覽的非同步映象，將被映象的請求發往測試pod，因此不用擔心它會返回什麼。我們來嘗試下。

首先，請確保環境中沒有DeistionationRule和VirtualService例項存在：

oc get destinationrules -n tutorial

No resources found.

oc get virtualservices -n tutorial

No resources found.

我們來看下配置瀏覽映象的VirtualService定義：

apiVersion: networking.istio.io/v1alpha3

    kind: VirtualService

    metadata:

      name: recommendation

      namespace: tutorial

    spec:

      hosts:

      - recommendation

      http:

      - route:

        - destination:

            host: recommendation

            subset: version-v1

        mirror:

          host: recommendation

          subset: version-v2

該定義中，所有流量被導向recommendation服務的v1版本，在mirror部分，指定了接受映象流量的host和subset。

然後，轉到從Istio Tutorial克隆下來的程式碼的根目錄，執行下面的命令：

oc -n tutorial create -f istiofiles/destination-rule-recommendation-v1-v2.yml

oc -n tutorial create -f istiofiles/virtual-service-recommendation-v1-mirror-v2.yml

在終端中，輸出recommendation服務v2版本pod的日誌：

oc -n tutorial logs -f `oc get pods|grep recommendation-v2|awk  '{ print $1 }'` -c recommendation

你也可以使用stern去檢視recommendation服務的v1和v2版本pod的日誌：

stern recommendation

在另一個視窗中，用curl訪問customer服務：

curl customer-tutorial.$(minishift ip).nip.io

customer => preference => recommendation v1 from '60483540': 466

從輸出中，你能看到recommendation服務的v1版本被訪問到了。再檢視v2版本pod的日誌，你會看到該服務處理進行流量所產生的日誌條目。

流量映象對於釋出前的測試會有很大幫助，但是還是有一些挑戰。比如，一個服務的新版本可能會訪問資料庫或其它關聯服務。要進行微服務中的資料處理，建議你閱讀Edson Yanaga所寫的Migrating to Microservice Databases（O’Reilly）一書。要了解流量映象更多的細節，可閱讀Christian的博文“Advanced Traffic-Shadowing Patterns for Microservices with Istio Service Mesh” （https://blog.christianposta.com/microservices/advanced-traffic-shadowing-patterns-for-microservices-with-istio-service-mesh/）。

請記得在繼續後面的步驟前刪除DestionationRule和VirtualService例項：

oc delete virtualservice recommendation -n tutorial

oc delete destinationrule recommendation -n tutorial

3.4對外請求（Egress）

預設地，服務的所有流量都會通過Istio代理，代理和應用服務部署在一起。這個代理負責校驗路由規則，決定如何轉發請求。Istio很好的一點是它預設阻止所有發到叢集外的請求流量，除非顯式建立規則去允許這種訪問。因此，你可以在不信任網路和傳統私有云環境中使用Istio。這些場景中，Istio會幫助阻止惡意代理訪問應用服務進而獲得網路的完全訪問許可權。通過預設阻止對外訪問請求，並允許利用路由規則去控制內外部流量，你可以更從容地應對外面攻擊，不管它們是從哪裡發起的。

要進行測試驗證，可以進入一個pod，然後用curl發起請求：

oc get pods -n tutorial

    NAME                   READY  STATUS    RESTARTS  AGE

    customer-6564ff969f-jqkkr       2/2    Running   0         19m

    preference-v1-5485dc6f49-hrlxm  2/2    Running   0         19m

    recommendation-v1-60483540      2/2    Running   0         20m

    recommendation-v2-99634814      2/2    Running   0         7m

   

    oc exec -it recommendation-v2-99634814 /bin/bash

    [jboss@recommendation-v2-99634814 ~]$ curl -v now.httpbin.org

    * About to connect() to now.httpbin.org port 80 (#0)

    *   Trying 54.174.228.92...

    * Connected to now.httpbin.org (54.174.228.92) port 80 (#0)

    > GET / HTTP/1.1

    > User-Agent: curl/7.29.0

    > Host: now.httpbin.org

    > Accept: */*

    >

    < HTTP/1.1 404 Not Found

    < date: Sun, 02 Dec 2018 20:01:43 GMT

    < server: envoy

    < content-length: 0

    <

    * Connection #0 to host now.httpbin.org left intact

    [jboss@recommendation-v2-99634814 ~]$ exit

結果你會從now.httpbin.org收到404 NOT Found錯誤資訊。要能正常訪問，你需要定義一個ServiceEntry例項，下面這個正是我們將要應用的：

apiVersion: networking.istio.io/v1alpha3

    kind: ServiceEntry

    metadata:

      name: httpbin-egress-rule

      namespace: tutorial

    spec:

      hosts:

      - now.httpbin.org

      ports:

      - name: http-80

        number: 80

        protocol: http

首先你要建立DesionationRule例項，然後應用ServiceEntry例項：

oc -n tutorial create -f istiofiles/destination-rule-recommendation-v1-v2.yml

oc -n tutorial create -f istiofiles/service-entry-egress-httpbin.yml -n tutorial

現在，你再進入pod，執行curl後你會得到200返回：

oc exec -it recommendation-v2-99634814 /bin/bash

[jboss@recommendation-v2-99634814 ~]$ curl now.httpbin.org

{"now": {"epoch": 1543782418.7876487...

你可以列表所有出口規則：

oc get serviceentry -n tutorial

SERVICE-ENTRY NAME    HOSTS      PORTS     NAMESPACE  AGE

httpbin-egress-rule   now.httpbin.org  http/80   tutorial   5m

最後，清理所有Istio例項，回到預設的Kubernetes行為：

oc delete serviceentry httpbin-egress-rule -n tutorial

oc delete virtualservice recommendation -n tutorial

oc delete destinationrule recommendation -n tutorial

本章中的這些示例都很簡單，但都是你探索Istio流控功能的一個良好的起點。

書籍英文版下載連結為 https://developers.redhat.com/books/introducing-istio-service-mesh-microservices/，作者 Burr Sutter 和 Christian Posta。

本中文譯稿版權由本人所有。水平有限，錯誤肯定是有的，還請海涵。

感謝您的閱讀，歡迎關注我的微信公眾號：

【譯文連載】理解Istio服務網格（第三章流控）

第3章流控

3.1 更加智慧的金絲雀

3.2流量路由

3.2.1路由到特定版本的部署

3.2.2 Recommendation服務v2版本的金絲雀部署

3.2.3 繼續加碼recommendation服務的v2版本

3.2.4 基於HTTP頭的路由

3.3 暗部署

3.4對外請求（Egress）

【譯文連載】理解Istio服務網格（第三章流控）

【譯文連載】理解Istio服務網格（第六章可觀測性）

【譯文連載】理解Istio服務網格（第七章安全）

【譯文連載】理解Istio服務網格（第一章概述）

【譯文連載】理解Istio服務網格（第二章安裝）

【POJ 2482】 Stars in Your Window（線段樹+離散化+掃描線）

【bzoj 2716】[Violet 3]天使玩偶（CDQ+樹狀數組）

【C語言】指標的算術運算（指標+/-整數、指標+/-指標）

【TP5.1】使用者組許可權管理（列表，新增，修改）

【程式設計素質】設計模式-策略模式（Strategy，政策模式Policy）

【軟考】——軟體工程基礎知識（資料流程圖、資料字典）

【比賽報告】CYJian的水題大賽[第三彈]

Atitit soa之道艾提拉著作 SOA概念、技術與設計讀書筆記第3章　理解面向服務 10 第4章　理解面向服務架構 39 第5章　理解服務與微服務的層次 74 第6章　Web服務及微服務的

【BZOJ 1061】 1061: [Noi2008]志願者招募（線性規劃與網路流）**

【JavaScript高階】7、函式高階（作用域與作用鏈）

【轉】Node深入淺出章節總結（第九章 — 玩轉程序）完結篇

【學習總結】C-翁愷老師-入門-第三週<迴圈>

【Learning Notes】生成式對抗網路（Generative Adversarial Networks，GAN）

【無私分享：ASP.NET CORE 專案實戰（第三章）】EntityFramework下領域驅動設計的應用

【計算機網路】:SMTP協議詳解（如何在控制檯發郵件）

【譯文連載】 理解Istio服務網格（第三章 流控）

第3章 流控

3.1 更加智慧的金絲雀

3.2流量路由

3.2.1路由到特定版本的部署

3.2.2 Recommendation服務v2版本的金絲雀部署

3.2.3 繼續加碼recommendation服務的v2版本

3.2.4 基於HTTP頭的路由

3.3 暗部署

3.4對外請求（Egress）

相關推薦

【譯文連載】理解Istio服務網格（第三章流控）

第3章流控