前言
自 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 要走的路還很長。
