删除旧版本之前先回滚一次

在 TT Lab 中继续学习

目标

用修订版金丝雀（Canary）方式，把使用 Istio 1.30.5 的真实网格升级到 1.31.0。并排建起两个控制平面，先迁移一个命名空间，再用修订版标签迁移其余部分，练习回滚，最后删除旧版本。

为什么重要

升级控制平面，是改变整个网格的配置来源。原地升级一旦出问题，所有人会同时遭遇，也很难回滚。使用修订版和修订版标签，可以把影响范围缩小到命名空间级别，并把回滚变成一行操作——前提是遵守顺序。

步骤

用 kubectl apply -f /opt/fixtures/istlab/upgrade-app.yaml 部署材料（shop 中的 web、canary 中的 client——两个命名空间都是 istio.io/rev=prod-stable），等待就绪。然后在 /root/istlab-upgrade/01-before.txt 中写入三行：web_proxy=、client_proxy=（各 Pod 的 istio-proxy 镜像的标签）和 prod_stable=（istioctl tag list 中修订版标签 prod-stable 所指向的修订版）。
把 istioctl x precheck 的输出保存到 /root/istlab-upgrade/02-precheck.txt。
把 1.31.0 作为修订版 1-31-0 安装——istioctl install --set profile=minimal --set revision=1-31-0 --set meshConfig.accessLogFile=/dev/stdout -y。安装后，两个 istiod（istiod-1-30-5、istiod-1-31-0）应同时运行，而工作负载应该还没有任何变化。
把 canary 命名空间的标签改为 istio.io/rev=1-31-0，并重启 client。然后在 /root/istlab-upgrade/04-mixed.txt 中写入三行：client_proxy=、web_proxy=（各代理镜像的标签）和 code=（在 client 中访问 http://web.shop/ 的状态码）。
把修订版标签 prod-stable 和 default 都移到修订版 1-31-0：istioctl tag set <태그> --revision 1-31-0 --overwrite（占位符为修订版标签名）。然后把 canary 的标签改回 istio.io/rev=prod-stable，并重启 shop 中的 web，让它得到 1.31.0 的代理。
在删除之前确认可以回滚——把修订版标签 prod-stable 移到 1-30-5，重启 web，把代理的镜像标签以 after_rollback= 写入 /root/istlab-upgrade/06-rollback.txt，然后再移回 1-31-0，重启 web，并以 after_forward= 追加。
确认所有代理都是 1.31.0 之后，用 istioctl uninstall --revision 1-30-5 -y 删除旧修订版，并等待 istiod-1-30-5 Deployment 和注入 Webhook istio-sidecar-injector-1-30-5 消失。此后 canary 的 client 访问 http://web.shop/ 仍应为 200。
在 /root/istlab-upgrade/08-report.md 中写入五行——old_revision=、new_revision=（修订版名称）、mixed_versions_code=（第 4 步的 code）、rollback_version=（第 6 步的 after_rollback）、old_injector_left=（现在 istio-sidecar-injector-1-30-5 Webhook 仍然存在则为 yes）——并在其下写出学到的内容，至少四行。

参考

这台 VM 的准备需要 2–4 分钟。只安装了修订版 1-30-5（修订版标签 prod-stable），1.31.0 的发行包已下载到 /usr/local/istio-1.31.0。登录 shell 中的 istioctl 是 1.31.0。
代理版本可以在 istioctl proxy-status 的 VERSION 一栏或 Pod 的 istio-proxy 镜像标签中查看。重启之后马上看的 proxy-status 可能会暂时显示旧 Pod，所以用镜像确认更可靠。
修改标签之后，一定要用 kubectl rollout restart 重新创建 Pod。注入发生在 Pod 创建时。
常见错误——在确认回滚之前就删除旧修订版。此后要回滚就得重新安装旧版本。

写下现在什么指向什么

用 kubectl apply -f /opt/fixtures/istlab/upgrade-app.yaml 部署材料（shop 中的 web、canary 中的 client——两个命名空间都是 istio.io/rev=prod-stable），等待就绪。然后在 /root/istlab-upgrade/01-before.txt 中写入三行：web_proxy=、client_proxy=（各 Pod 的 istio-proxy 镜像的标签）和 prod_stable=（istioctl tag list 中修订版标签 prod-stable 所指向的修订版）。

这台 VM 的控制平面只以修订版 1-30-5 安装，工作负载不是通过修订版名称，而是通过修订版标签 prod-stable 获得注入。修订版标签是指向“当前生产使用的修订版”的名牌，所以升级不是逐个修改工作负载标签，而是移动这块名牌。这台 VM 的 istioctl 是 1.31.0，但标签列表与版本无关，都能读取。

升级之前先问一句——precheck

把 istioctl x precheck 的输出保存到 /root/istlab-upgrade/02-precheck.txt。

precheck 会检查集群是否准备好迎接新版本（Kubernetes 版本、权限、旧配置中即将弃用的字段等）。如果这里出现警告，顺序上应当先修复它们，再安装。用 1.31.0 的 istioctl 运行，就以 1.31.0 为基准检查。

把新版本建在旧版本旁边

把 1.31.0 作为修订版 1-31-0 安装——istioctl install --set profile=minimal --set revision=1-31-0 --set meshConfig.accessLogFile=/dev/stdout -y。安装后，两个 istiod（istiod-1-30-5、istiod-1-31-0）应同时运行，而工作负载应该还没有任何变化。

以修订版安装时，会新建名称带有修订版的 istiod 和注入 Webhook（istio-sidecar-injector-1-31-0），旧的则原样保留。没有任何命名空间指向新修订版，所以这一刻流量没有任何变化——因此安装本身随时都可以安全进行。istioctl tag list 中会多出一行没有修订版标签的新修订版。

只把一个命名空间迁到新版本

把 canary 命名空间的标签改为 istio.io/rev=1-31-0，并重启 client。然后在 /root/istlab-upgrade/04-mixed.txt 中写入三行：client_proxy=、web_proxy=（各代理镜像的标签）和 code=（在 client 中访问 http://web.shop/ 的状态码）。

只改标签不会发生任何事。Sidecar 是在 Pod 创建时注入的，所以要重启才能得到新修订版的代理。像这样先只迁移一个命名空间，就是金丝雀——即使出了问题，也只需回滚那个命名空间。官方文档指出，数据平面之间目前所有版本互相兼容（附带今后可能改变的说明），所以即使混合，mTLS 也应该能建立。

移动名牌——用修订版标签升级其余部分

把修订版标签 prod-stable 和 default 都移到修订版 1-31-0：istioctl tag set <태그> --revision 1-31-0 --overwrite（占位符为修订版标签名）。然后把 canary 的标签改回 istio.io/rev=prod-stable，并重启 shop 中的 web，让它得到 1.31.0 的代理。

修订版标签其实就是一个注入 Webhook（istio-revision-tag-prod-stable）。移动修订版标签后，该 Webhook 所指向的 istiod 就变了，使用该标签的命名空间中新创建的 Pod 会得到新修订版的代理。把作为金丝雀迁移过去的 canary 也改回用修订版标签，今后就只需要管理一个修订版标签。default 修订版标签决定使用 istio-injection=enabled 标签的命名空间以及 istioctl 的默认目标。

提前练习回滚

在删除之前确认可以回滚——把修订版标签 prod-stable 移到 1-30-5，重启 web，把代理的镜像标签以 after_rollback= 写入 /root/istlab-upgrade/06-rollback.txt，然后再移回 1-31-0，重启 web，并以 after_forward= 追加。

旧修订版还在的时候，回滚只需改一行修订版标签并重启一次。删除旧修订版之后，就得重新安装那个版本。所以在生产中，要在新版本上充分运行之后才删除旧修订版，并且在此之前实际演练一次回滚路径是否可行。重启之后代理是否改变，用 Pod 的 istio-proxy 镜像来确认。

全部迁移完之后再删除旧版本

确认所有代理都是 1.31.0 之后，用 istioctl uninstall --revision 1-30-5 -y 删除旧修订版，并等待 istiod-1-30-5 Deployment 和注入 Webhook istio-sidecar-injector-1-30-5 消失。此后 canary 的 client 访问 http://web.shop/ 仍应为 200。

指定修订版的 uninstall 只会删除该修订版的控制平面，不会动其他修订版和工作负载。如果还有 Pod 在使用旧修订版的代理，这些 Pod 就会失去配置来源——所以删除之前，要用 istioctl proxy-status 和 Pod 镜像确认没有遗留。刚删除之后可能暂时仍显示为 0/1，请等到它消失。

留下升级记录

在 /root/istlab-upgrade/08-report.md 中写入五行——old_revision=、new_revision=（修订版名称）、mixed_versions_code=（第 4 步的 code）、rollback_version=（第 6 步的 after_rollback）、old_injector_left=（现在 istio-sidecar-injector-1-30-5 Webhook 仍然存在则为 yes）——并在其下写出学到的内容，至少四行。

说明行中请用自己的话写下“用修订版代替原地（in-place）升级能得到什么”以及“什么时候删除旧修订版”。