---

導(dǎo)言：灰度發(fā)布是指在項目迭代的過程中用平滑過渡的方式進行發(fā)布?；叶劝l(fā)布可以保證整體系統(tǒng)的穩(wěn)定性，在初始發(fā)布的時候就可以發(fā)現(xiàn)、調(diào)整問題，以保證其影響度。作為Istio體驗系列的第一站，本文基于Istio的流量治理機制，針對最簡單的幾種業(yè)務(wù)場景進行了實踐，為后續(xù)的探索學(xué)習(xí)提供了一個思路和實踐案例。

文章目錄

• 一、背景介紹
• 1.1 灰度發(fā)布概述
• 1.2 基于kubernetes的灰度發(fā)布
• 1.3 基于Istio的灰度發(fā)布
• 二、前置條件
• 2.1 實驗環(huán)境搭建
• 2.2 服務(wù)網(wǎng)格監(jiān)控組件的安裝與配置
• 2.2.1 Kiali的安裝
• 2.2.2 配置Kiali控制面板對外訪問
• 2.3 實驗項目部署
• 2.3.1 項目簡介
• 2.3.2 Weather Forecast 部署
• 三、實驗過程
• 3.1 初始狀態(tài)部署
• 3.2 基于流量比例的路由
• 3.3 基于請求內(nèi)容的發(fā)布
• 3.4 多服務(wù)同時發(fā)布
• 3.5 自動化部署
• 四、總結(jié)

一、背景介紹

1.1 灰度發(fā)布概述

在新版本上線時，不管是在技術(shù)上考慮產(chǎn)品的穩(wěn)定性等因素，還是在商業(yè)上考慮新版本被用戶接受的程度，直接將老版本全部升級是非常有風(fēng)險的。所以一般的做法是，新老版本同時在線，新版本只切分少量流量出來，在確認新版本沒有問題后，再逐步加大流量比例。這正是灰度發(fā)布要解決的問題。其核心是能配置一定的流量策略，將用戶在同一個訪問入口的流量導(dǎo)到不同的版本上。有如下幾種典型場景。

• 藍綠發(fā)布

藍綠發(fā)布是指不停止老版本，部署新版本，然后進行測試，確認沒有問題之后，再將流量全量切到新版本，然后老版本同時也升級到新版本。這樣做的好處是無需停機，并且風(fēng)險較小。

其發(fā)布的步驟大致如下：

1. 部署版本1的應(yīng)用（一開始的狀態(tài)），所有外部請求的流量都打到這個版本上；
2. 部署版本2的應(yīng)用，版本2的代碼與版本1不同（新功能、Bug修復(fù)等）；
3. 將流量從版本1切換到版本2，即流量從v1：v2為100：0，切換為0：100；

4. 如果版本2存在問題，需要回滾到版本1，進行流量切換回v1：v2為100：0。

   • A/B測試
     A/B測試的場景比較明確，就是同時在線上部署A和B兩個對等的版本來接收流量，按一定的目標選取策略讓一部分用戶使用A版本，讓一部分用戶使用B版本，收集這兩部分用戶的使用反饋，即對用戶采樣后做相關(guān)比較，通過分析數(shù)據(jù)來最終決定采用哪個版本。藍綠發(fā)布則主要用于安全穩(wěn)定地發(fā)布新版本應(yīng)用，而A/B測試則是用來測試應(yīng)用功能表現(xiàn)的一種方法。
   • 金絲雀發(fā)布
     金絲雀發(fā)布是指通過讓一小部分用戶流量引入的新版本進行測試，就像把一個金絲雀塞到瓦斯井里面一樣，探測這個新版本在環(huán)境中是否可用，在觀察到新版本沒有問題后再增加切換的比例，直到全部切換完成，是一個漸變、嘗試的過程。如在過程中出現(xiàn)任何問題，則可以中止并回滾到舊版本。最簡單的方式是隨機選擇百分比請求到金絲雀版本，但在更復(fù)雜的方案下，則可以基于請求的內(nèi)容、特定范圍的用戶或其他屬性等。
     ![在這里插入圖片描述][Image 1]

     

1.2 基于kubernetes的灰度發(fā)布

在Kubernetes環(huán)境下可以基于Pod的數(shù)量比例分配流量。如下圖所示，B服務(wù)的兩個版本v2和v1分別有2個和3個實例，當(dāng)流量被均衡地分發(fā)到每個實例上時，前者可以得到40%的流量，后者可以得到60%的流量，從而達到流量在兩個版本間分配的效果。
?

給v1和v2版本設(shè)置對應(yīng)比例的Pod數(shù)量，依靠Kube-proxy把流量均衡地分發(fā)到目標后端，可以解決一個服務(wù)的多個版本分配流量的問題，但是限制非常明顯：首先，要求分配的流量比例必須和Pod數(shù)量成比例，試想，基于這種方式支持 3:97 比例的流量基本上是不可能的；另外，這種方式不支持根據(jù)請求的內(nèi)容來分配流量，比如要求Chrome瀏覽器發(fā)來的請求和IE瀏覽器發(fā)來的請求分別訪問不同的版本。有沒有一種更細粒度的分流方式？答案當(dāng)然是有，Istio就可以。Istio疊加在Kubernetes之上，從機制上可以提供比Kubernetes更細的服務(wù)控制粒度及更強的服務(wù)管理能力。

1.3 基于Istio的灰度發(fā)布

Istio本身并沒有關(guān)于灰度發(fā)布的規(guī)則定義，灰度發(fā)布只是流量治理規(guī)則的一種典型應(yīng)用，在進行灰度發(fā)布時，只要寫個簡單的流量規(guī)則配置即可。Istio在每個Pod里都注入了一個Envoy，因而只要在控制面配置分流策略，對目標服務(wù)發(fā)起訪問的每個Envoy便都可以執(zhí)行流量策略，完成灰度發(fā)布功能。

在使用Istio實現(xiàn)灰度發(fā)布的情況下，流量路由和副本部署是兩個完全獨立的功能。服務(wù)的pod數(shù)量可以根據(jù)流量負載靈活伸縮，與版本流量路由的控制完全無關(guān)。這在自動縮放的情況下能夠更加簡單地管理金絲雀版本。Istio的路由規(guī)則非常靈活，可以支持細粒度控制流量百分比（例如，路由1%的流量而不需要100個pod），也可以使用其他規(guī)則來控制流量（例如，將特定用戶的流量路由到金絲雀版本）。

為了更加直觀的驗證和說明，接下來我們就通過搭建實驗環(huán)境來模擬各種業(yè)務(wù)場景下的灰度發(fā)布。

二、前置條件

2.1 實驗環(huán)境搭建

由于個人電腦的網(wǎng)絡(luò)和內(nèi)存限制，本人是直接選擇了在騰訊云服務(wù)器上安裝Minikube和Kubectl，然后下載最新版本的Istio1.9，最后通過istioctl工具進行安裝。安裝過程不再贅述，具體可參考:
http://km.oa.com/group/34294/articles/show/410837

不過安裝較新版本Istio的同學(xué)需要注意一下的是Istio 1.9 支持的kubernets版本要求不能低于v1.17，所以在用minikube啟動kubernetes集群時必須指定好版本：

1. $ minikube start --vm-driver=none --kubernetes-version v1.18.15

具體環(huán)境和版本清單如下：

• 64位Cenos7.6：2核4G(最低配置要求)
• Minikube == v1.17.1
• Docker == v1.13.1
• Kubernetes == v1.18.15
• Istio == v1.9.0

2.2 服務(wù)網(wǎng)格監(jiān)控組件的安裝與配置

2.2.1 Kiali的安裝

Kiali 是一個為 Istio 提供圖形化界面和豐富觀測功能的 Dashboard 的開源項目，其名稱源于希臘語，意思是望遠鏡。用戶利用 Kiali 可以監(jiān)測網(wǎng)格內(nèi)服務(wù)的實時工作狀態(tài)，管理Istio的網(wǎng)絡(luò)配置，快速識別網(wǎng)絡(luò)問題。但是從Istio 1.7開始，默認不安裝控制面板Kiali等組件，所以需要用戶自行單獨安裝控制面板Kiali及相關(guān)的組件。

首先進入到Istio的安裝包解壓目錄下，然后通過以下命令安裝：

1. [root@chon istio-1.9.0]# kubectl apply -f samples/addons
2. [root@chon istio-1.9.0]# kubectl apply -f samples/addons/extras

安裝時，由于網(wǎng)絡(luò)原因，可能會報錯，重試幾次就好了。安裝完成后，通過kubectl 命令查詢相關(guān)pod的運行狀態(tài):

1. [root@chon istio-1.9.0]# kubectl get pod -n istio-system
2. NAME READY STATUS RESTARTS AGE
3. grafana-94f5bf75b-fvlrt 1/1 Running 0 7h14m
4. istio-egressgateway-5b475b9856-lzwwm 1/1 Running 0 24h
5. istio-ingressgateway-648778567c-4gddl 1/1 Running 0 24h
6. istiod-7cccc657f6-ng9r2 1/1 Running 0 24h
7. jaeger-5c7675974-fmw4n 1/1 Running 0 7h14m
8. kiali-d4fdb9cdb-wdj2v 1/1 Running 0 7h14m
9. prometheus-7d76687994-p6whv 2/2 Running 0 7h14m
10. zipkin-679599ffd8-xxb8l 1/1 Running 0 7h1m

2.2.2 配置Kiali控制面板對外訪問

查看kiali服務(wù)，發(fā)現(xiàn)其類型為ClusterIP，沒有對外暴露端口，無法從外部訪問：

1. [root@chon istio-1.9.0]# kubectl get service kiali -n istio-system
2. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
3. kiali ClusterIP 10.105.136.82 <none> 20001:/TCP,9090/TCP

所以此時需要通過NodePort的方式對外暴露控制面板，我們將原來的ClusterIP類型的service導(dǎo)出yaml文件，通過刪除注解、創(chuàng)建信息、狀態(tài)字段及ClusterIP等信息將類型改NodePort，然后使用kubectl apply -f 創(chuàng)建：

1. [root@chon istio-1.9.0]# kubectl get svc -n istio-system kiali -o yaml > kiali-nodeport.yaml
2. [root@chon istio-1.9.0]# vi kiali-nodeport.yaml
3. #主要刪除metadata下的annotation, resourceVersion,seflFlink, uid; 以及spec下的ClusterIP,修改類型為NodePort， 同時刪除status狀態(tài)字段即可。
4. [root@chon istio-1.9.0]# kubectl apply -f kiali-nodeport.yaml

此時再查看kiali的service，可以看到已經(jīng)可以端口已經(jīng)暴露出來：

1. [root@chon istio-1.9.0]# kubectl get service kiali -n istio-system
2. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
3. kiali NodePort 10.105.136.82 <none> 20001:32662/TCP,9090:31692/TCP 7h44m

然后在瀏覽器中輸入“http：//＜ip address＞：32662/kiali”打開Kiali的登錄頁面，登錄成功后，Kiali的總覽視圖如下所示：

2.3 實驗項目部署

2.3.1 項目簡介

下面通過經(jīng)典的 Weather Forecast 進行部署實踐，它是一款查詢城市天氣信息的應(yīng)用實例，一共包含4個微服務(wù)，它們之間的調(diào)用關(guān)系如下：

• frontend：前臺服務(wù)，會調(diào)用 advertisement 和 forecast 這兩個服務(wù)，展示整個應(yīng)用的頁面;
• advertisement：廣告服務(wù)，返回的靜態(tài)的廣告圖片;
• forecast：添加預(yù)報服務(wù)，返回相應(yīng)城市的天氣數(shù)據(jù);
• recommendation：推薦服務(wù)，根據(jù)天氣情況向用戶推薦穿衣和運行等信息。
  其中，frontend 服務(wù)的有兩個版本:
• v1 版本的界面按鈕為綠色。
• v2 版本的界面按鈕為藍色。
  forecast 服務(wù)有兩個版本：
• v1 版本會直接返回天氣信息；
• v2 版本會請求 recommendation 服務(wù)，獲取推薦信息，并結(jié)合天氣信息一起返回數(shù)據(jù)。

2.3.2 Weather Forecast 部署

Step1：?下載項目源碼。由于官方代碼的 Kubernetes api 版本未及時更新肯能會導(dǎo)致報錯問題，所以這里不建議使用官，本文提供一個較新的源碼：

1. $ git clone https://github.com/slzcc/cloud-native-istio.git

Step2：?添加 v1 版本的服務(wù)

1. $ kubectl create ns weather
2. $ kubectl label namespace weather istio-injection=enabled
3. $ kubectl apply -f install/weather-v1.yaml -n weather

等待服務(wù)安裝成功：

Step3：?添加網(wǎng)關(guān)資源 Gateway。

1. $ kubectl apply -f install/weather-gateway.yaml

Step4：?驗證訪問頁面。添加網(wǎng)關(guān)資源 Gateway 創(chuàng)建完成后訪問 istio-ingressgateway 地址即可訪問，或者訪問其 NodePort 端口：

1. [root@chon ~]# kubectl get svc -n istio-system istio-ingressgateway
2. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
3. istio-ingressgateway LoadBalancer 10.102.172.210 <pending> 15021:32492/TCP,80:31844/TCP,443:32460/TCP,31400:30568/TCP,15443:31743/TCP 25h

點擊查詢：

至此，初始實驗環(huán)境就全部搭建部署完成，接下來就正式開啟Istio灰度發(fā)布功能的體驗之旅。

三、實驗過程

實驗中有兩個核心配置文件貫穿始終，有必要先提前認識和區(qū)分一下：

• VirtualService：路由規(guī)則配置（虛擬服務(wù)），定義路由規(guī)則，可以將滿足條件的流量都轉(zhuǎn)發(fā)到對應(yīng)的服務(wù)后端；
• DestinationRule：目標規(guī)則配置，定義發(fā)生路由后應(yīng)用于服務(wù)流量的策略，描述到達目標的請求怎么處理。
  目標規(guī)則是配合虛擬服務(wù)來使用的，主要用來定義子集，子集實際上就是具體的目標地址，除此以外，它主要描述的是到達目標請求后如何去處理，所謂的目標就是子集，而如何處理就是指具體的策略。

3.1 初始狀態(tài)部署

在開始實驗前，首先對每個服務(wù)都創(chuàng)建各自的 VirtualService 和 DestinationRule 資源，將訪問請求路由到所有服務(wù)的 v1 版本：

1. $ kubectl apply -f install/destination-rule-v1.yaml -n weather
2. $ kubectl apply -f install/virtual-service-v1.yaml -n weather

查看配置的路由規(guī)則，以 forecast 服務(wù)為例：

1. [root@chon ~]# kubectl get vs -n weather forecast-route -o yaml
2. apiVersion: networking.istio.io/v1beta1
3. kind: VirtualService
4. ...
5. name: forecast-route
6. namespace: weather
7. ...
8. spec:
9. hosts:
10. - forecast
11. http:
12. - route:
13. - destination:
14. host: forecast
15. subset: v1

在瀏覽器中多次加載前臺頁面，并查詢城市的天氣信息，確認顯示正常。然后打開Kiali控制臺，查看各個服務(wù)之間的調(diào)用關(guān)系，如下圖所示：

3.2 基于流量比例的路由

場景一：用戶需要軟件能夠根據(jù)不同的天氣情況推薦合適的穿衣和運動信息。于是開發(fā)的同學(xué)增加了 recommendation 新服務(wù)，并升級 forecast 服務(wù)到 v2 版本來調(diào)用 recommendation 服務(wù)。在新特性上線時，運維的同學(xué)首先部署 forecast 服務(wù)的 v2 版本和 recommendation 服務(wù)，并對 forecast 服務(wù)的 v2 版本進行灰度發(fā)布。

Step1：?部署 recommendation 服務(wù)和 forecast 服務(wù)的 v2 版本。

1. [root@chon cloud-native-istio]# kubectl apply -f install/recommendation-service/recommendation-all.yaml -f install/forecast-service/forecast-v2-deployment.yaml -n weather

查看服務(wù)狀態(tài):

Step2：?更新 forecast 服務(wù) v2 版本的 DestinationRule。

1. [root@chon cloud-native-istio]# kubectl apply -f install/forecast-service/forecast-v2-destination.yaml -n weather

查看下發(fā)成功的配置，可以看到增加了 v2 版本 subset 的定義：

1. [root@chon cloud-native-istio]# kubectl get dr forecast-dr -o yaml -n weather
2. ...
3. host: forecast
4. subsets:
5. - labels:
6. version: v1
7. name: v1
8. - labels:
9. version: v2
10. name: v2

這時去瀏覽器中查詢天氣，顯然還不會出現(xiàn)推薦信息，因為所有流量依然都被路由到 forecast 服務(wù)的 v1 版本，不會調(diào)用 recommendation 服務(wù)。

Step3：?配置 forecast 服務(wù)的 VirtualService 配置，其中的 weight 字段顯示了相應(yīng)服務(wù)的流量占比，可以看到此時為 v1:v2 = 1:1。

1. [root@chon cloud-native-istio]# kubectl apply -f chapter-files/canary-release/vs-forecast-weight-based-50.yaml -n weather

Step4：?在瀏覽器中查看配置后的效果。多次刷新查詢天氣頁面，可以發(fā)現(xiàn)大概約 50% 的情況下不顯示推薦服務(wù)，表示調(diào)用了 forecast 服務(wù)的 v1 版本；在另外 50% 的情況下表示推薦服務(wù)，調(diào)用了 forecast 服務(wù)的 v2 版本（刷新頁面基本上是兩個版本交替著來）。

Step5：?繼續(xù)增加 forecast 服務(wù)的 v2 版本的流量比例，直到流量全部被路由到 v2 版本。

1. [root@chon cloud-native-istio]# kubectl apply -f chapter-files/canary-release/vs-forecast-weight-based-v2.yaml -n weather

Step6：?在瀏覽器中查看配置后的效果。多次刷新頁面查詢天氣，每次都會出現(xiàn)推薦信息，說明訪問請求都被路由到了 forecast 服務(wù) v2 版本。

查看Kiali控制臺:

Step7：?保留 forecast 服務(wù)的老版本 v1 一段時間，再確認 v2 版本的各性能指標穩(wěn)定后，刪除老版本 v1 的所有資源，完成灰度發(fā)布。

3.3 基于請求內(nèi)容的發(fā)布

場景二：在生產(chǎn)環(huán)境中同時上線了 forecast 服務(wù)的 v1 和 v2 版本，運維同學(xué)期望讓不同的終端用戶訪問不同的版本，例如：讓使用 Chrome 瀏覽器的用戶看到推薦信息，但讓使用其他瀏覽器的用戶看不到推薦信息。

有了上面場景一的經(jīng)驗，依葫蘆畫瓢，只需要修改 forecast 服務(wù) v2 版本的 DestinationRule中的 match 條件，使來自Chrome瀏覽器的請求路由到 v2 版本，其余的不變即可：

在瀏覽器中查看配置后的效果：用 Chrome 瀏覽器多次查詢天氣信息，發(fā)現(xiàn)始終顯示推薦信息，說明訪問到 forecast 服務(wù)的 v2 版本；用 360 或 Firefox 瀏覽器多次查詢天氣信息，發(fā)現(xiàn)始終不顯示推薦信息，說明訪問到 forecast 服務(wù)的 v1 版本。

谷歌瀏覽器查詢訪問結(jié)果：

360瀏覽器查詢訪問結(jié)果：

現(xiàn)在已經(jīng)掌握了兩種路由規(guī)則的配置和應(yīng)用之后，感興趣的同學(xué)可以自己動手試一試，模擬將兩種路由規(guī)則組合在一起的場景，比如：在生產(chǎn)環(huán)境中同時上線了 frontend 服務(wù)的 v1 和 v2 版本（v1 版本的按鈕顏色是綠色的，v2 版本的按鈕顏色是藍色的），運維同學(xué)期望使用 Android 操作系統(tǒng)的一半用戶看到的是 v1 版本，另一半用戶看到的是 v2 版本；使用其他操作系統(tǒng)的用戶看到的總是 v1 版本。

3.4 多服務(wù)同時發(fā)布

場景三：運維同學(xué)為 frontend 和 forecast 兩個服務(wù)同時進行灰度發(fā)布，frontend 服務(wù)新增 v2 版本（界面的按鈕為藍色）；forecast 服務(wù)新增 v2 版本（增加了推薦信息）。測試人員在用賬戶 tester 訪問天氣應(yīng)用時會看到這兩個服務(wù)的 v2 版本，其他用戶只能看到兩個服務(wù)的 v1 版本，要求不會出現(xiàn)服務(wù)版本交叉調(diào)用的情況。

在場景一中我們已經(jīng)部署過了非入口服務(wù) recommendation 和 forecast 的 v2 版本，并更新了 forecast 服務(wù)的 DestinationRule?，F(xiàn)在我們在集群中來部署入口服務(wù) frontend 的 v2 版本，并更新其 DestinationRule。

Step1：?部署入口服務(wù) frontend 的 v2 版本。

1. [root@chon cloud-native-istio]# vi install/frontend-service/frontend-v2-deployment.yaml
2. apiVersion: apps/v1
3. kind: Deployment
4. metadata:
5. name: frontend-v2
6. labels:
7. app: frontend
8. version: v2
9. spec:
10. replicas: 1
11. selector:
12. matchLabels:
13. app: frontend
14. template:
15. metadata:
16. labels:
17. app: frontend
18. version: v2
19. spec:
20. containers:
21. - name: frontend
22. image: istioweather/frontend:v2
23. imagePullPolicy: IfNotPresent
24. ports:
25. - containerPort: 3000
26. [root@chon cloud-native-istio]# kubectl apply -f install/frontend-service/frontend-v2-deployment.yaml -n weather

查看部署情況：

Step2：?更新 frontend 服務(wù)的 DestinationRule，增加對 v2 版本 subset 的定義：

1. [root@chon cloud-native-istio]# vi frontend-service/frontend-v2-destination.yaml
2. apiVersion: networking.istio.io/v1alpha3
3. kind: DestinationRule
4. metadata:
5. name: frontend-dr
6. spec:
7. host: frontend
8. subsets:
9. - name: v1
10. labels:
11. version: v1
12. - name: v2
13. labels:
14. version: v2
15. [root@chon cloud-native-istio]# kubectl apply -f install/frontend-service/frontend-v2-destination.yaml -n weather

Step3：?配置 frontend 服務(wù)的基于訪問內(nèi)容的路由規(guī)則，將測試賬戶（Cookie 帶有 “user=tester”）信息的請求流量導(dǎo)入到 frontend 服務(wù)的 v2 版本的 Pod 實例。

1. apiVersion: networking.istio.io/v1alpha3
2. kind: VirtualService
3. metadata:
4. name: frontend-route
5. spec:
6. hosts:
7. - "*"
8. gateways:
9. - istio-system/weather-gateway
10. http:
11. - match:
12. - headers:
13. cookie:
14. regex: ^(.*?;)?(user=tester)(;.*)?$
15. route:
16. - destination:
17. host: frontend
18. subset: v2
19. - route:
20. - destination:
21. host: frontend
22. subset: v1
23. [root@chon cloud-native-istio]# kubectl apply -f chapter-files/canary-release/vs-frontend-multiservice-release.yaml -n weather

Step4：?配置非入口服務(wù) forecast 的路由規(guī)則，使得只有帶“version：v2”標簽的 Pod 實例的流量，才能進入 forecast 服務(wù)的新版本 v2 實例：

1. [root@chon canary-release]# vi chapter-files/canary-release/vs-forecast-multiservice-release.yaml
2. apiVersion: networking.istio.io/v1alpha3
3. kind: VirtualService
4. metadata:
5. name: forecast-route
6. spec:
7. hosts:
8. - forecast
9. http:
10. - match:
11. - sourceLabels:
12. version: v2
13. route:
14. - destination:
15. host: forecast
16. subset: v2
17. - route:
18. - destination:
19. host: forecast
20. subset: v1
21. [root@chon cloud-native-istio]# kubectl apply -f chapter-files/canary-release/vs-forecast-multiservice-release.yaml -n weather

Step5：?查看配置后的效果。
用 tester 賬戶登錄并訪問前臺頁面，界面的按鈕是藍色的，表示訪問到的是 frontend 服務(wù)的 v2 版本。在查詢天氣時會顯示推薦信息，表示可以訪問到 forecast 服務(wù)的 v2 版本:

不登入或者使用其他用戶則訪問的是 v1 版本看不到推薦信息:

可視化視圖查看服務(wù)間調(diào)用關(guān)系：

3.5 自動化部署

前面介紹的灰度發(fā)布的策略配置都需要人工干預(yù)。在持續(xù)交付過程中，為了解決部署和管理的復(fù)雜性，往往需要通過自動化工具實現(xiàn)基于權(quán)重的灰度發(fā)布。

Flagger 是一個基于 Kubernetes 和 Istio 提供灰度發(fā)布、監(jiān)控和告警等功能的開源軟件，通過使用 Istio 的流量路由和 Prometheus 指標來分析應(yīng)用程序的行為，從而實現(xiàn)灰度版本的自動部署，可以使用 Webhook 擴展 Canary 分析，已運行集成測試、壓力測試或其他自定義測試。

其部署流程如上圖所示，由于篇幅有限，這里就不再進行贅述，有興趣的同學(xué)可以進一步進行實踐體驗。

四、總結(jié)

作為Istio入門體驗系列的第一篇文章，關(guān)于灰度發(fā)布的實踐暫時就先到這里了。對于一名剛接觸Istio的小白，通過基于流量比例、基于請求內(nèi)容以及多服務(wù)場景下的灰度發(fā)布的實踐，Get到了它區(qū)別于Kubernetes的部署方式，也切身感受到了Istio在各種規(guī)則業(yè)務(wù)場景下的靈活性。當(dāng)然，作為系列文章，接下來我也將繼續(xù)學(xué)習(xí)探索，持續(xù)輸出，還望各位同學(xué)多多關(guān)注，提出寶貴建議！

[文章來源地址http://www.zghlxwxcb.cn/news/detail-664474.html