使用Istio簡化微服務系列三：如何才能做「金絲雀部署」，並通過Istio增加流量？
作者：Nithin Mallya
原文：Simplifying Microservices with Istio in Google Kubernetes Engine?—?Part III
我寫的關於 Istio 的文章是 Istio 網站上文檔的一部分。請閱讀官方文檔以了解更多信息。
在本系列的第一部分中（使用Istio簡化微服務系列一：如何用Isito解決Spring Cloud Netflix部署微服務的挑戰?），我們看到了如何使用 Istio 來簡化我們的微服務之間的溝通。
在本系列的第二部分中（使用Istio簡化微服務系列二：如何通過HTTPS與外部服務進行通信？），我們學會了使用 Istio egress rules 來控制服務網格之外的服務的訪問。
在這一部分中，我們將看到如何才能做「金絲雀部署」（Canary Deployments），並通過 Istio 增加流量。
背景：
在過去的文章中，我詳細解釋了我們如何使用 Kubernetes 進行藍/綠部署。這是一種部署技術，在此技術中，我們部署了與應用程序當前版本和新版本相同的生產環境。這項技術使我們能夠執行零停機時間部署（Zero Downtime Deployments， 簡稱：ZDD），以確保我們的用戶在切換到新版本時不受影響。有了這兩個版本（當前版本和新版本）也使我們能夠在新版本出現任何問題時進行回滾。
我們還需要的是能夠將流量增加(或下降)到我們的應用程序的新版本，並監控它以確保沒有負面影響。實現這一點的一種方法是使用「金絲雀部署」或「金絲雀」發行版。
一個不太有趣的事實：當礦工們帶著金絲雀進入礦場時，任何有毒氣體都會首先殺死金絲雀，並以此警告礦工們離開礦井。
同樣地，在應用程序部署世界中，使用「金絲雀部署」，我們可以將應用程序的新版本部署到生產中，並只向這個新部署發送一小部分流量。這個新版本將與當前版本並行運行，並在我們將所有流量切換到新版本之前提醒我們注意任何問題。
例如：我們應用程序的 v1 可以佔到90%的流量，而 v2 可以得到另外的10%。如果一切看起來都很好，我們可以將 v2 流量增加到25%，50%，最終達到100%。Istio Canary 部署的另一個優勢是，我們可以根據請求中的自定義標頭來增加流量。例如，在我們的應用程序的v2中設置了一個特定 cookie 頭值的流量的10%。
注意：雖然「金絲雀部署」「可以」與 A/B 測試一起使用，以查看用戶如何從業務度量的角度對新版本做出反應，但其背後的真正動機是確保應用程序從功能角度上滿意地執行。此外，企業所有者可能希望在更長的時間內(例如:許多天甚至幾周)進行 A/B 測試，而不是金絲雀碼頭可能採取的措施。因此，把它們分開是明智的。
Lets see it in action
從第一部分我們知道，我們的 PetService 與 PetDetailsService(v1) 和 PetMedicalHistoryService(v1) 進行了會談。對 PetService的調用的輸出如下:
$ curl http://108.59.82.93/pet/123
{
"petDetails": { "petName": "Maximus", "petAge": 5, "petOwner": "Nithin Mallya", "petBreed": "Dog" }, "petMedicalHistory": { "vaccinationList": ["Bordetella, Leptospirosis, Rabies, Lyme Disease"
] }}在上面的回復中，你會注意到 petBreed 說「狗」。然而，Maximus 是德國牧羊犬，這時候我們需要修改 PetDetailsService，以便正確返回品種。
因此，我們創建了 PetDetailsService 的 v2，它將返回「德國牧羊犬」。但是，我們希望確保在將所有流量驅動到 v2 之前，我們可以使用一小部分用戶來測試這個服務的 v2。
在下面的圖1中，我們看到流量被配置成這樣，50%的請求將被定向到 v1 和50%到 v2，我們的 「金絲雀部署」。(它可以是任意數字，取決於變化的大小，並盡量減少負面影響)。
步驟
1、創建 PetDetails Service 的 v2 版本並像以前一樣部署它。 （請參閱 petdetailservice / kube 文件夾下的 petinfo.yaml）
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
petdetailsservice-v1-2831216563-qnl10 2/2 Running 0 19h
petdetailsservice-v2-2943472296-nhdxt 2/2 Running 0 2h
petmedicalhistoryservice-v1-28468096-hd7ld 2/2 Running 0 19h
petservice-v1-1652684438-3l112 2/2 Running 0 19h
2、創建一個RouteRule，將流量分成 petdetailsservice 的50％（v1）和50％（v2），如下所示：
cat <<EOF | istioctl create -f -
apiVersion: http://config.istio.io/v1alpha2kind: RouteRulemetadata:
name: petdetailsservice-defaultspec: destination: name: petdetailsservice route: - labels: version: v1 weight: 50 - labels: version: v2 weight: 50EOF
$ istioctl get routerule
NAME KIND NAMESPACE
petdetailsservice-default http://RouteRule.v1alpha2.config.istio.io default
3、現在，如果你訪問 PetService，你應該看到替代請求分別返回「Dog」和「German Shepherd Dog」，如下所示：
$ curl http://108.59.82.93/pet/123
{
"petDetails": { "petName": "Maximus", "petAge": 5,"petOwner": "Nithin Mallya",
"petBreed": "Dog" }, "petMedicalHistory": { "vaccinationList": [ "Bordetella, Leptospirosis, Rabies, Lyme Disease" ] }}$ curl http://108.59.82.93/pet/123
{
"petDetails": { "petName": "Maximus", "petAge": 5, "petOwner": "Nithin Mallya", "petBreed": "German Shepherd Dog" }, "petMedicalHistory": { "vaccinationList": [ "Bordetella, Leptospirosis, Rabies, Lyme Disease"]
}}It works！
這引出了一個問題：我們不能用 Kubernetes Canary Deployments 來做到這一點嗎？簡短的答案是肯定的。
然而，這樣做的步驟更複雜，也有局限性:
- 你仍然需要創建 PetDetailsService (v1和v2)的兩個部署，但是你需要手動限制在部署過程中 v2 副本的數量，以維護 v1:v2 比。例如:你可以使用10個副本部署 v1，並將v2 部署到2個副本，以獲得10:2的負載平衡，等等。
- 由於所有的 pod 無論版本是否相同，Kubernetes 集群中的流量負載平衡仍然受到隨機性的影響。
- 基於業務量的自動伸縮 pods 也是有問題的，因為我們需要單獨的 autoscale 的2個部署，它可以根據每個服務的流量負載分配來做出不同的行為。
- 如果我們想根據某些標準（如 request headers）僅允許某些用戶使用/限制流量，則Kubernetes Canary Deployments可能無法實現此目標。
結論：你剛剛看到了創建一個「金絲雀部署」和增加 Istio 的流量是多麼容易。馬克西姆斯也很高興！（小數：下圖就是馬克西姆斯...嗯...很帥氣！）
資源：
1、Part I of this article series: https://medium.com/google-cloud/simplifying-microservices-with-istio-in-google-kubernetes-engine-part-i-849555f922b8
2、Part II of this article series: https://medium.com/google-cloud/simplifying-microservices-with-istio-in-google-kubernetes-engine-part-ii-7461b1833089
3、The Istio home page https://istio.io/
4、DevOxx Istio presentation by Ray Tsang: https://www.youtube.com/watch?v=AGztKw580yQ&t=231s
5、Github link to this example: https://github.com/nmallya/istiodemo
6、All things Kubernetes: https://kubernetes.io/
推薦閱讀
為什麼我們需要Istio？四大組件助力Istio突圍！
Service Mesh深度思考 | DreamMesh拋磚引玉(1)-序言
使用Istio簡化微服務系列二：如何通過HTTPS與外部服務進行通信？
使用Istio簡化微服務系列一：如何用Isito解決Spring Cloud Netflix部署微服務
採用Istio實現灰度發布，給運維人員一支強心劑
ServiceMesh中文社區：
ServiceMesh中文社區（http://servicemesh.cn）已上線，Istio、Conduit官方文檔翻譯版已在社區發布，歡迎大家登錄瀏覽。社區翻譯小組志願者招募中，有興趣的私信小數即可~
ServiceMesh微信交流群：
添加微信xiaoshu062，備註：服務網格，即可加入Service Mesh微信交流群。
社區活動：
3月31日（周六），數人云聯合ServiceComb社區，並由ServiceMesh社區支持，開啟meetup系列活動 Building Microservice 第2期 北京站 ：微服務，從架構到發布，已經開始報名啦，掃碼報名！
http://www.huodongxing.com/event/2429503885800 (二維碼自動識別)
推薦閱讀：
※《Cloud Native Go》筆記（十二）使用React構建Web視圖
※《微服務設計》閱讀筆記（十一）規模化微服務
※「演講復盤」技術沙龍(滬江網4月) - 我所遇見的微服務演進這十年
※《微服務設計》閱讀筆記（四）集成