阿里云服务网格ASM支持基于修订与标签的升级模式，以更稳定安全的方式执行新版本控制面的金丝雀升级。在这个新升级模式中，数据面的网格代理将与他们使用的特定控制面版本相关联。这使得新版本能够以较低的风险在集群中部署, 直到用户明确选择之前，没有代理连接到新版本。同时也允许逐渐将工作负载迁移到新的控制面，每个独立的控制面被称为“修订版”并具有istio.io/rev标签。
为了支持这种基于修订的升级，Istio为命名空间引入了一个istio.io/rev标签。它可以指示哪个控制面版本应该为相应命名空间中的工作负载注入Sidecar代理。例如，标签istio.io/rev=1-17-2表示为该命名空间中的工作负载注入1.17.2版本的Sidecar代理。
前提条件
- 已创建ASM企业版或旗舰版实例，且版本为v1.16.4.91或以上版本。具体操作，请参见创建ASM实例。
- 已创建ACK集群, 并已添加集群到ASM实例。具体操作，请参见添加集群到ASM实例。
- 本示例中使用了入门教程Bookinfo示例, 具体操作参见部署bookinfo 应用到ASM 实例。
操作步骤
前置步骤：确认注入策略
由于在金丝雀升级中，验证阶段需要显式地通过命名空间标签来指定注入的Sidecar代理版本，因此金丝雀升级具有对注入策略的前置要求。
- 进入 Sidecar管理（数据面）> 注入策略配置，找到 注入策略配置管理
- 确认注入策略的第一项（即Pod所在命名空间的标签需要满足）为包含istio-injection: enabled
注： istio-injection: enabled 与 istio.io/rev: stable具有相同的语义。在金丝雀升级过程中，我们将使用istio.io/rev: stable为对应命名空间中的Pod注入稳定版本网格代理，使用istio.io/rev: canary为对应命名空间中的Pod注入金丝雀版本的网格代理。
升级完成后，即使不将istio.io/rev:stable替换回istio-injection: enabled ，也可以正常注入，因为这两个标签的语义完全一致。
升级前的状态如下所示：
步骤一：升级ASM 控制面
在ASM 实例控制台下，进入 “升级管理” 菜单下，选择 “金丝雀升级” , 可以看到如下界面：
金丝雀升级最多跨一个次要版本升级，当前实例为1.16，则最高可升级到1.17或者1.18。选择要升级的目标版本，比如本示例中升级到v1.17.2.37。
选择确定要升级的版本后，点击“确认” 按钮，则会部署对应的金丝雀目标版本。金丝雀升级的目标版本部署时会创建与之关联的一个CLB 实例，若没特别需求，CLB 实例选择默认的规格即可。请注意, 新增的CLB实例对应的计费说明参考：https://help.aliyun.com/document_detail/27539.html?spm=5176.13895322.0.0.48e25fcfo3Khca 。
金丝雀版本的部署是一个异步的过程，大致需要几分钟, 需要等待相关组件部署完成。
新版本部署完成之后, 状态如下：
此时状态如下所示：
步骤二：升级review-v2的注入代理到新版本
在步骤一中，我们通过金丝雀升级方式部署了一个v1.17.2版本的Istio控制面。接下来，我们需要验证这个版本是否符合预期。
以下步骤将在前面已部署好的Bookinfo 例子下的reviews-v2 版本更新其注入的网格代理版本到v1.17 。
1) 进入网格实例 > 全局命名空间，找到default命名空间，此时命名空间标签为默认的istio-injection: enabled，说明此时注入的是1.16版本的网格代理。
2) 点击切换为注入1-17-2版本， default全局命名空间的标签将切换为istio.io/rev: canary，并立即将数据面default命名空间标签也同步成istio.io/rev: canary。此时界面显示default注入的是1.17版本的网格代理。
3) 此时，命名空间default 下新创建的工作负载(pod） 将注入1.17版本的网格代理。 其他命名空间的标签未更改，依然注入当前1.16版本的网格代理。
其它路径：金丝雀版本下为命名空间开启自动注入
上面演示的步骤是为一个在升级前已经开启自动注入的命名空间切换注入的Sidecar网格代理版本。对于升级前尚未开启Sidecar网格代理注入的命名空间，我们可以正常地为其开启自动注入，注入时，将选择注入的Sidecar网格代理版本。服务网格将根据您选择的版本，为命名空间打上istio.io/rev:stable或是istio.io/rev:canary的标签。
5) 通过容器服务控制台“重新部署”菜单滚动更新review-v2 工作负载：
6) 检查滚动更新后的review-v2 对应的POD 是否启动成功， 以及新的pod 是否注入了1.17对应的Sidecar代理版本。
可以看到成功注入了v1.17版本的Sidecar网格代理，符合预期。
7) 打开浏览器，访问bookinfo 页面 ，检查流量是否符合预期，应当仍然可以正常访问到review-v2 版本。
此时, 状态如下所示：
步骤三：回滚review-v2 为 1.16 版本
若第二步验证失败，或者其他原因我们需要进行回滚，我们可以按照如下操作执行。若验证成功，我们则可以进一步扩大验证的范围。
1) 进入网格实例 > 全局命名空间，找到default命名空间，此时命名空间标签为istio.io/rev: canary，显示注入的是1.17版本的网格代理。
点击切换为注入1-16-4版本， default全局命名空间的标签将切换为istio.io/rev: stable，并立即将数据面default命名空间标签也同步成istio.io/rev: stable。此时界面显示default注入的是1.16版本的网格代理。
2) 通过容器服务控制台“重新部署”菜单滚动更新review-v2 工作负载：
3) 检查滚动更新后的review-v2 对应的POD 是否启动成功， 以及新的pod 是否注入了1.16对应的Sidecar代理版本。
步骤四：撤销升级
1) 等回滚之后，我们可以撤销金丝雀升级，将ASM 实例更新为最初的1.16 状态。
点击“撤销升级”按钮, 之后将会删除掉升级中的灰度版本的控制面组件（即示例中的1.17版本）, 只保留稳定版本的控制面组件（即示例中的1.16版本）。
注： 如果您选择“撤销升级”，则需首先确保所有命名空间都已注入稳定Sidecar代理版本（例子中是1.16版本），否则无法撤销。
此时状态如下所示：
步骤五、重新升级及验证
此时, 整个ASM实例处于步骤一之前待升级的状态。下面的内容将需要重新执行步骤一, 以使得ASM集群处于升级控制面灰度版本中。
并按照步骤二的内容重新执行来验证注入新版本的代理是否符合预期。例如, 使用容器服务控制台的重新部署，重新部署reviews-v1 、reviews-v2以及reviews-v3无状态工作负载。可以观察到reviews-v1、reviews-v2以及reviews-v3的Pod都注入了1.17版本的Sidecar网格代理。
注： 本例中仅验证reviews-v1、reviews-v2reviews-v3 三个工作负载。根据您的需要，您也可以仿照上述步骤对任意的工作负载进行升级验证，直至您认为验证通过。
步骤六：验证符合预期, 切换为正式版本
通过上述步骤后，我们验证了review-v1、review-v2 使用1.17 (新版本）的网格代理 ，并且功能符合预期。此时，我们则可以进一步决策是否将1.17 版本切换为正式版本。
注意：
- 一旦进行版本切换，意味着升级已经进入旧版本下线阶段，您只能将现有工作负载全部切换成新的1.17版本的Sidecar网格代理，无法再撤销升级。请确保在“部署新版本”阶段完成全部验证工作。
- 在版本切换后，带有istio.io/rev: stable和istio-injection: enabled标签的命名空间将注入新的1.17版本的Sidecar网格代理，而istio.io/rev: canary标签将失去作用。因此，在版本切换时，ASM会自动将所有istio.io/rev: canary标签切换为istio.io/rev: stable。请您在点击版本切换时在界面上确认。
点击版本切换时，将有弹窗提示：在版本切换后，带有istio.io/rev: stable和istio-injection: enabled标签的命名空间将注入新的1.17版本的Sidecar网格代理，而istio.io/rev: canary标签将失去作用。因此，在版本切换时，ASM会自动将所有istio.io/rev: canary标签切换为istio.io/rev: stable。点击确认，正式进行版本切换，将1.17 切换为正式版本。
切换成功后，已经注入的1.16 版本的网格代理依然保留，对应的工作负载不受影响。但重新部署的Pod将全部注入1.17版本的Sidecar代理。
等待切换更新完成后，我们可以看到如下页面：
切换成功后，ASM实例的当前版本为1.17，原有的1.16 会保留，直到完成数据面的全部升级。
此时, 状态如下所示：
步骤七： 数据面升级
此时ASM的当前版本为1.17 ，命名空间标签 istio.io/rev=stable、 istio.io/rev=1-17-2 或 istio-injection=enabled 都是注入1.17 版本的Sidecar网格代理。
通过滚动更新工作负载，可以升级注入的Sidecar网格代理到当前新版本1.17 ，以此完成数据面升级。具体操作如下。
点击 “数据面” 页签，可以看到类似如下界面：
在 “待升级工作负载” 一栏下，我们可以通过切换集群和namespace， 看到未升级到新版本的工作负载。
点击对应的“滚动升级”按钮则可以将工作负载升级到到1.17 新版本。
说明： 列表中不会显示已经升级完成的工作负载。
类似地, 点击滚动即可升级到网关的新版本。
此外, 也可以在“网格状态”下查看全局还剩哪些未升级的工作负载或者网关实例。
此时, 升级完数据面之后, 状态如下所示：
步骤八：下线旧版本
当数据面所有工作负载升级完成，我们则可以将老版本1.16 进行下线操作。点击 “旧版本下线”按钮即可完成旧版本下线。
切记一定要将所有工作负载升级到新版本后，再进行旧版本下线。
此时状态如下所示：
总结
我们在金丝雀升级过程中，可以通过将部分服务先升级的方式来验证目标版本是否符合预期，若验证结果不符合预期，我们可以快速进行回滚来保证服务的稳定性。
版本验证符合预期后，我们将金丝雀版本切换为当前版本，并通过滚动更新方式将所有工作负载升级到最新版本，完成数据面的升级，并卸载老版本完成所有升级步骤。
