公告支持 1.8 到 1.10 的直接升级

随着服务网格技术从前沿技术发展到稳定的基础设施，许多用户表达了希望减少服务网格升级频率的意愿，因为验证新的次要版本需要花费大量时间。对于不经常关注新版本的用户来说，升级可能会特别困难，因为 Istio 之前不支持跨多个次要版本的升级。要从 1.6.x 升级到 1.8.x，用户必须先升级到 1.7.x，然后再升级到 1.8.x。

随着 Istio 1.10 的发布，我们宣布支持从 Istio 1.8.x 直接升级到 1.10.x（Alpha 阶段），无需升级到 1.9.x。我们希望这能够减少运行 Istio 的操作负担，这与我们 2021 年改善 Day 2 运维的主题相一致。

从 1.8 升级到 1.10

对于直接升级，我们建议使用金丝雀升级方法，以便在将工作负载切换到新版本之前验证控制平面的功能。我们还将在本指南中使用 版本标签，这是在 1.10 中引入的 canary 升级改进，因此用户在升级时无需更改命名空间的标签。

首先，使用 1.10 或更高版本的 istioctl，创建一个指向您现有 1.8 版本的版本标签 stable。从现在开始，我们假设此版本称为 1-8-5

$ istioctl x revision tag set stable --revision 1-8-5

如果您的 1.8 安装没有关联的版本，我们可以使用以下命令创建此版本标签：

$ istioctl x revision tag set stable --revision default

现在，将之前使用 istio-injection=enabled 或 istio.io/rev=<REVISION> 标记的命名空间重新标记为 istio.io/rev=stable。下载 Istio 1.10.0 版本并使用版本安装新的控制平面

$ istioctl install --revision 1-10-0 -y

现在评估 1.10 版本是否已正确启动并处于健康状态。一旦对新版本的稳定性感到满意，您可以将版本标签设置为新版本

$ istioctl x revision tag set stable --revision 1-10-0 --overwrite

验证版本标签 stable 是否指向新版本

$ istioctl x revision tag list
TAG    REVISION NAMESPACES
stable 1-10-0        ...

准备好将现有工作负载迁移到新的 1.10 版本后，必须重新启动工作负载，以便 sidecar 代理使用新的控制平面。我们可以逐个遍历命名空间并将工作负载切换到新版本

$ kubectl rollout restart deployments -n …

在将工作负载推出到新的 Istio 版本后发现问题？没问题！由于您正在使用金丝雀升级，因此旧的控制平面仍在运行，我们可以切换回旧版本。

$ istioctl x revision tag set prod --revision 1-8-5

然后在触发另一次 rollout 后，您的工作负载将回到旧版本。

我们期待了解您使用直接升级的体验，并期待在未来改进和扩展此功能。