升级就是挪动名牌

一句话总结

用修订版（revision）安装时，新版本的控制平面会建在旧版本旁边。工作负载只需要知道修订版标签，升级就变成把标签指向的位置移走、再重启工作负载。在删除旧版本之前，回滚只需改一行修订版标签。

为什么需要它

原地升级（in-place）Istio 时，istiod 一被替换，整个网格就会同时连到新的控制平面上。新版本出问题，所有工作负载会一起受影响，要回滚还得重新安装旧版本。Sidecar 是在 Pod 创建时注入的，所以更换控制平面之后，直到所有 Pod 重启完毕，两个版本的代理混合运行的这段时间也无法避免。

修订版把这段混合时间变成可控的顺序。把新版本以单独的名称（istiod-1-31-0）建起来，一次迁移一个命名空间并观察，全部迁移完之后再删除旧版本。

工作原理

安装修订版——istioctl install --set revision=1-31-0 会创建名称带有修订版的 istiod 和注入 Webhook（istio-sidecar-injector-1-31-0）。旧修订版的那些则原样保留。

由命名空间标签决定接收哪个版本的 sidecar。

标签	含义
istio.io/rev=1-31-0	由该修订版的 Webhook 注入
istio.io/rev=prod-stable	由修订版标签 prod-stable 所指向的修订版注入
istio-injection=enabled	由 default 修订版标签（或没有修订版的安装）注入

修订版标签就是一个 Webhook。istioctl tag set prod-stable --revision 1-31-0 会让名为 istio-revision-tag-prod-stable 的注入 Webhook 去调用 1-31-0 的 istiod。如果工作负载的标签指向 prod-stable，只需移动修订版标签，之后创建的 Pod 就会得到新版本。已经在运行的 Pod 需要重启才会改变。

所以顺序是这样的。

1. precheck                    새 판이 이 클러스터에 올라가도 되는가
2. 새 리비전 설치               istiod-1-31-0 가 옆에 선다 (트래픽 변화 없음)
3. 카나리 네임스페이스 이동      라벨을 1-31-0 으로 + 재시작 → 섞인 상태에서 통신 확인
4. 태그 이동 + 나머지 재시작     prod-stable → 1-31-0
5. 되돌리기 연습               태그를 옛 리비전으로 옮겨 재시작 → 다시 앞으로
6. 옛 리비전 제거              모든 프록시가 옮긴 뒤 uninstall --revision 1-30-5

两个版本的代理混合期间仍然能够通信，是得益于官方文档写明的兼容规则——数据平面之间目前所有版本互相兼容（附带今后可能改变的说明），控制平面可以比数据平面新一个版本，但不能落后。所以文档推荐能消除版本差异本身的修订版方式，迁移顺序也是“先控制平面，后代理”。

在现场相遇的样子

“改了标签，代理版本却没变”——没有重启 Pod。注入发生在 Pod 创建的时刻。

“删除旧修订版后，部分 Pod 收不到配置”——没有重启的 Pod 仍连在旧的 istiod 上。删除之前，用 istioctl proxy-status 确认没有代理还连在旧修订版上。

“安装了新修订版，现有 Pod 却没有任何变化”——这是正常的。安装修订版不会改变流量——在运行的 Pod 仍然连在旧 istiod 上，新 Webhook 只会在标签指向该修订版的命名空间中新创建 Pod 时才被调用。

“没用修订版标签，而是在每个命名空间里写了修订版名称”——每次升级都得修改所有命名空间的标签。修订版标签把这件事缩减为一行。

官方文档：Canary Upgrades、Supported releases、istioctl tag、istioctl x precheck

下一项实验要做什么

在配方只用修订版 1-30-5 安装好的网格上运行 precheck，并把 1.31.0 作为修订版 1-31-0 建在旁边。先只迁移 canary 命名空间，确认两个版本混合时仍能通信，再移动修订版标签升级其余部分，并练习一次回滚。最后删除旧修订版。