前言
自 1.5 版本開始，Istio 就棄用了之前使用
Helm
的安裝方式。而 1.6 釋出也有一段時間了，目前都已經到了
1.6.4
版本，就更新部分，Istio 1.6 推出了漸進式的更新方式：金絲雀更新，為相對頭疼的 Istio 更新問題提供了一種解決方案。
Istio 不支援跨版本更新。本文僅講解從 1.5 版本更新到 1.6 版本。如果您使用的是舊版本，請先更新到 1.5 版本。
金絲雀更新
顧名思義，金絲雀更新可以讓新老版本的
istiod
同時存在，并允許将所有流量在由新版控制平面
istiod-canary
控制之前，先将一小部分工作負載交由新版本
istiod-canary
控制，并進行監控，漸進式的完成更新。該方式比原地更新安全的多，也是現在推薦的更新方式。
控制平面更新
首先需要
下載下傳新版本 Istio并切換目錄為新版本目錄。
安裝
canary
版本，将
revision
字段設定為
canary
：
$ istioctl install --set revision=canary 這裡會部署新的
istiod-canary
，但并不會對原有的控制平面造成影響，部署成功後會看到兩個并行的
istiod
$ kubectl get pods -n istio-system
NAME READY STATUS RESTARTS AGE
pod/istiod-85745c747b-knlwb 1/1 Running 0 33m
pod/istiod-canary-865f754fdd-gx7dh 1/1 Running 0 3m25s 這裡還可以看到新版的
sidecar injector
配置：
$ kubectl get mutatingwebhookconfigurations
NAME CREATED AT
istio-sidecar-injector 2020-07-07T08:39:37Z
istio-sidecar-injector-canary 2020-07-07T09:06:24Z 資料平面更新
隻安裝
canary
版本的控制平面并不會對現有的代理造成影響，要更新資料平面，并将他們指向新的控制平面，就需要在 namespace 中插入
istio.io/rev
标簽。
例如，想要要更新
default
namespace 的資料平面，需要添加
istio.io/rev
标簽并删除
istio-injection
标簽，以指向
canary
版本的控制平面：
$ kubectl label namespace default istio-injection- istio.io/rev=canary 注意：
istio-injection
标簽必須删除，因為該标簽的優先級高于
istio.io/rev
标簽，保留該标簽将導緻無法更新資料平面。
在 namespace 更新成功後，需要重新開機 Pod 來重新注入 Sidecar：
$ kubectl rollout restart deployment -n default 當重新開機成功後，該 namespace 的 pod 将被配置指向新的
istiod-canary
控制平面，使用如下指令檢視啟用新代理的 Pod：
$ kubectl get pods -n default -l istio.io/rev=canary 同時可以使用如下指令驗證新 Pod 的控制平面為
istiod-canary
$ istioctl proxy-config endpoints ${pod_name}.default --cluster xds-grpc -ojson | grep hostname
"hostname": "istiod-canary.istio-system.svc" 這時
default
namespace 内的 Pod 就完成了金絲雀更新，接下來就可以進行驗證，确定這些 Pod 有沒有因為 Istio 更新而導緻功能異常。
原地更新 & 降級
目前原地更新有很大的機率通不過更新檢測，導緻無法更新，不推薦這種更新方式，這裡就不做介紹了，詳情見
官方文檔。
并且雖然 Istio 提供了降級方式，但是經過測試降級的體驗并不好，并且出現了由于不支援的 CRD
apiVersion
導緻無法降級的情況，是以請謹慎更新。
總結
總體來說，金絲雀更新的出現很好的解決了控制平面漸進式更新的需求，但是由于
istioctl upgrade
指令支援的場景和版本太少以及 Istio 整體架構的更改，目前的原地更新體驗很差。
最近還爆出了谷歌将把 Istio 捐給一個新成立基金會的消息，看來 Istio 要走的路還很長。
