金丝雀升级
升级 Istio 可以首先运行新控制平面的金丝雀部署，允许您在将所有流量迁移到新版本之前，使用一小部分工作负载监控升级效果。这比执行就地升级安全得多，并且是推荐的升级方法。
安装 Istio 时，可以使用revision安装设置同时部署多个独立的控制平面。可以通过在旧控制平面旁边安装新 Istio 版本的控制平面（使用不同的revision设置）来启动升级的金丝雀版本。每个版本都是一个完整的 Istio 控制平面实现，具有自己的Deployment、Service等。
升级前
在升级 Istio 之前，建议运行istioctl x precheck命令以确保升级与您的环境兼容。
$ istioctl x precheck
✔ No issues found when checking the cluster. Istio is safe to install or upgrade!
To get started, check out https://istio.ac.cn/latest/docs/setup/getting-started/
控制平面
要安装一个名为canary的新版本，您将如下设置revision字段
$ istioctl install --set revision=canary
运行该命令后，您将有两个控制平面部署和服务并行运行。
$ kubectl get pods -n istio-system -l app=istiod
NAME READY STATUS RESTARTS AGE
istiod-1-23-1-bdf5948d5-htddg 1/1 Running 0 47s
istiod-canary-84c8d4dcfb-skcfv 1/1 Running 0 25s
$ kubectl get svc -n istio-system -l app=istiod
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istiod-1-23-1 ClusterIP 10.96.93.151 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 109s
istiod-canary ClusterIP 10.104.186.250 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 87s
您还会看到有两个 sidecar injector 配置，包括新的修订版本。
$ kubectl get mutatingwebhookconfigurations
NAME WEBHOOKS AGE
istio-sidecar-injector-1-23-1 2 2m16s
istio-sidecar-injector-canary 2 114s
数据平面
请参阅 网关金丝雀升级 以了解如何运行 Istio 网关的特定于修订版本的实例。在本例中，由于我们使用default Istio 配置文件，因此 Istio 网关不会运行特定于修订版本的实例，而是就地升级以使用新的控制平面修订版本。您可以通过运行以下命令来验证istio-ingress网关是否正在使用canary修订版本。
$ istioctl proxy-status | grep "$(kubectl -n istio-system get pod -l app=istio-ingressgateway -o jsonpath='{.items..metadata.name}')" | awk -F '[[:space:]][[:space:]]+' '{print $8}'
istiod-canary-6956db645c-vwhsk
但是，仅仅安装新的修订版本并不会影响现有的 sidecar 代理。要升级这些代理，您必须将它们配置为指向新的istiod-canary控制平面。这是在基于命名空间标签istio.io/rev的 sidecar 注射过程中控制的。
创建一个启用了istio-injection的命名空间test-ns。在test-ns命名空间中，部署一个示例 curl pod。
创建一个命名空间
test-ns。$ kubectl create ns test-ns使用
istio-injection标签标记命名空间。$ kubectl label namespace test-ns istio-injection=enabled在
test-ns命名空间中启动一个示例 curl pod。$ kubectl apply -n test-ns -f samples/curl/curl.yaml
要升级命名空间test-ns，请移除istio-injection标签，并添加istio.io/rev标签以指向canary修订版本。必须移除istio-injection标签，因为它优先于istio.io/rev标签，以确保向后兼容性。
$ kubectl label namespace test-ns istio-injection- istio.io/rev=canary
命名空间更新后，您需要重新启动 pod 以触发重新注入。重新启动命名空间test-ns中所有 pod 的一种方法是使用
$ kubectl rollout restart deployment -n test-ns
pod 重新注入后，将被配置为指向istiod-canary控制平面。您可以使用istioctl proxy-status进行验证。
$ istioctl proxy-status | grep "\.test-ns "
输出将显示使用金丝雀修订版本的命名空间下的所有 pod。
稳定版本标签
在将命名空间迁移到新修订版本时手动重新标记命名空间可能很繁琐且容易出错。修订版本标签解决了此问题。修订版本标签是稳定的标识符，指向修订版本，可用于避免重新标记命名空间。网格运营商无需重新标记命名空间，只需更改标签以指向新的修订版本即可。所有使用该标签标记的命名空间将同时更新。用法
假设一个集群安装了两个修订版本，1-23-1和1-24-0。集群运营商创建一个修订版本标签prod-stable，指向较旧的稳定版本1-23-1，以及一个指向较新版本1-24-0的修订版本标签prod-canary。可以通过以下命令达到该状态。安装两个控制平面的修订版本。
$ istioctl install --revision=1-23-1 --set profile=minimal --skip-confirmation $ istioctl install --revision=1-24-0 --set profile=minimal --skip-confirmation创建
stable和canary修订版本标签，并将它们与相应的修订版本关联。$ istioctl tag set prod-stable --revision 1-23-1 $ istioctl tag set prod-canary --revision 1-24-0标记应用程序命名空间以映射到相应的修订版本标签。
$ kubectl create ns app-ns-1 $ kubectl label ns app-ns-1 istio.io/rev=prod-stable $ kubectl create ns app-ns-2 $ kubectl label ns app-ns-2 istio.io/rev=prod-stable $ kubectl create ns app-ns-3 $ kubectl label ns app-ns-3 istio.io/rev=prod-canary在每个命名空间中启动一个示例 curl pod。
$ kubectl apply -n app-ns-1 -f samples/curl/curl.yaml $ kubectl apply -n app-ns-2 -f samples/curl/curl.yaml $ kubectl apply -n app-ns-3 -f samples/curl/curl.yaml使用
istioctl proxy-status命令验证应用程序到控制平面的映射。$ istioctl ps NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION curl-78ff5975c6-62pzf.app-ns-3 Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-24-0-7f6fc6cfd6-s8zfg 1.24.0 curl-78ff5975c6-8kxpl.app-ns-1 Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-23-1-bdf5948d5-n72r2 1.23.1 curl-78ff5975c6-8q7m6.app-ns-2 Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-23-1-bdf5948d5-n72r2 1-23.1
修订版本、标签和命名空间之间的最终映射如下所示。
除了标记的命名空间之外，集群运营商还可以通过istioctl tag list命令查看此映射。
$ istioctl tag list
TAG REVISION NAMESPACES
default 1-23-1 ...
prod-canary 1-24-0 ...
prod-stable 1-23-1 ...
集群运营商对标记为prod-canary的控制平面的稳定性感到满意后，可以通过修改prod-stable修订版本标签以指向较新的1-24-0修订版本，通过一个操作更新标记为istio.io/rev=prod-stable的命名空间。
$ istioctl tag set prod-stable --revision 1-24-0 --overwrite
现在，修订版本、标签和命名空间之间的更新映射如下所示。
重新启动标记为prod-stable的命名空间中的注入工作负载现在将导致这些工作负载使用1-24-0控制平面。请注意，迁移工作负载到新修订版本不需要重新标记命名空间。
$ kubectl rollout restart deployment -n app-ns-1
$ kubectl rollout restart deployment -n app-ns-2
使用istioctl proxy-status命令验证应用程序到控制平面的映射。
$ istioctl ps
NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION
curl-5984f48bc7-kmj6x.app-ns-1 Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-24-0-7f6fc6cfd6-jsktb 1.24.0
curl-78ff5975c6-jldk4.app-ns-3 Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-24-0-7f6fc6cfd6-jsktb 1.24.0
curl-7cdd8dccb9-5bq5n.app-ns-2 Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-24-0-7f6fc6cfd6-jsktb 1.24.0
默认标签
标签default指向的修订版本被认为是默认修订版本，并且具有其他语义含义。默认修订版本执行以下功能。
- 为
istio-injection=enabled命名空间选择器、sidecar.istio.io/inject=true对象选择器和istio.io/rev=default选择器注入 sidecar。 - 验证 Istio 资源。
- 从非默认修订版本中窃取领导者锁，并执行单例网格职责（例如更新资源状态）。
要将修订版本1-24-0设为默认值，请运行
$ istioctl tag set default --revision 1-24-0
default标签时，建议移除旧的MutatingWebhookConfiguration（通常称为istio-sidecar-injector），以避免旧版和新版控制平面都尝试进行注入。卸载旧控制平面
升级控制平面和数据平面后，您可以卸载旧的控制平面。例如，以下命令卸载修订版本为1-23-1的控制平面。
$ istioctl uninstall --revision 1-23-1 -y
如果旧的控制平面没有修订版本标签，请使用其原始安装选项卸载它，例如
$ istioctl uninstall -f manifests/profiles/default.yaml -y
确认旧的控制平面已移除，并且集群中仅存在新的控制平面。
$ kubectl get pods -n istio-system -l app=istiod
NAME READY STATUS RESTARTS AGE
istiod-canary-55887f699c-t8bh8 1/1 Running 0 27m
请注意，以上说明仅移除指定控制平面修订版本的资源，而不是与其他控制平面共享的集群范围资源。要完全卸载 Istio，请参阅 卸载指南。
卸载金丝雀控制平面
如果您决定回滚到旧的控制平面，而不是完成金丝雀升级，您可以使用以下命令卸载金丝雀修订版本。
$ istioctl uninstall --revision=canary -y
但是，在这种情况下，您必须首先手动重新安装上一个修订版本的网关，因为卸载命令不会自动还原之前就地升级的网关。
清理
清理创建的修订版本标签。
$ istioctl tag remove prod-stable $ istioctl tag remove prod-canary清理用于金丝雀升级并带有修订版本标签的命名空间示例。
$ kubectl delete ns istio-system test-ns清理用于金丝雀升级并带有修订版本标签的命名空间示例。
$ kubectl delete ns istio-system app-ns-1 app-ns-2 app-ns-3