如何对现有的 istio 自定义设置进行金丝雀升级

Question

如何对现有的 istio 自定义设置进行金丝雀升级。

要求：

• 我们有针对 AKS 1.18.14 的 istio 1.7.3 的自定义设置(使用 istoctl 方法安装，没有为此设置修订版)。
• 现在我们需要升级到 istio 1.8，没有停机时间或最少的时间。
• 升级应该更安全，并且不会以任何方式破坏我们的生产环境。

我们如何安装当前的 istio 定制环境：

1. 已创建清单。

istioctl manifest generate --set profile=default -f /manifests/overlay/overlay.yaml > $HOME/generated-manifest.yaml

2. 已安装的 istio。

istioctl install --set profile=default -f /manifests/overlay/overlay.yaml

已
3. 针对已部署的清单验证了 istio。

istioctl verify-install -f $HOME/generated-manifest.yaml

计划的升级过程^参考

1. 预检查升级。

istioctl x precheck

2. 使用以下命令将当前使用的 istio 配置导出到 yaml 文件中。

kubectl -n istio-system get iop installed-state-install -o yaml > /tmp/iop.yaml

下载 istio 1.8 二进制
3. 文件并解压缩目录并将目录导航到我们拥有 1.8 版本 istioctl 二进制文件的目录。

cd istio1.8istioctl1.8

4. 从新版本 istio 目录中，为 istio(1.8) 创建一个具有正确修订集的新控制平面，并使用之前导出的安装状态 "iop.yaml"。

./istioctl1.8 install --set revision=1-8 --set profile=default -f /tmp/iop.yaml

期望它将使用现有的创建新的控制平面 成本化配置，现在我们将有两个控制平面 并行运行的部署和服务：

kubectl get pods -n istio-system -l app=istiod
NAME                                    READY   STATUS    RESTARTS   AGE
istiod-786779888b-p9s5n                 1/1     Running   0          114m
istiod-1-7-6956db645c-vwhsk             1/1     Running   0          1m 

5. 在此之后，我们需要更改所有集群命名空间的现有标签，我们需要在其中注入 istio 代理容器。需要去掉旧的"istio-injection"标签，并添加 istio.io/rev 标签以指向金丝雀修订版 1-8。

kubectl label namespace test-ns istio-injection- istio.io/rev=1-8

希望，在这一点上，环境在旧的 istio 配置下也是稳定的，我们可以决定哪些应用程序 pod 可以重新启动以根据我们的停机时间进行新的控制平面更改，并且允许它运行一些具有较旧控制平面的应用程序和另一个具有新控制器平面配置的应用程序此时。 例如：

kubectl rollout restart deployment -n test-ns  (first) 
kubectl rollout restart deployment -n test-ns2 (later)
kubectl rollout restart deployment -n test-ns3 (again after sometieme later)

6. 一旦我们计划停机时间并按照我们的决定重新启动部署，请确认所有 Pod 现在仅使用版本 1.8 的数据平面代理注入器

kubectl get pods -n test-ns -l istio.io/rev=1-8

7. 验证 test-ns 命名空间中的新 pod 是否正在使用与 Canary 修订版对应的 istiod-Canary 服务

istioctl proxy-status | grep ${pod_name} | awk '{print $7}'

升级控制平面
8. 和数据平面后，可以卸载旧的控制平面

istioctl x uninstall -f /tmp/iop.yaml.

升级前需要清除以下几点。

1. 对于高度使用的产品环境，为上述升级准备的所有步骤是否都适合继续？

2. 通过导出已安装的状态 iop 足以获得所有自定义步骤以进行金丝雀升级？ 还是有可能制动升级或缺少任何设置？

3. 上面的步骤 4 是否会创建 1.8 istio 控制平面，其中包含我们已经拥有的所有自定义，而不会有任何中断或遗漏某些内容？

4. 在步骤 4 之后，我们是否需要任何与 Istiod 服务配置相关的额外配置>以下文档对此并不清楚，

5. 对于上面的第 5 步，我们如何识别所有启用了 Istio 注入的命名空间，并且只单独修改这些命名空间，而让其他命名空间保持原样？

6. 因此，对于上面的步骤8，如何确保我们仅卸载旧的控制平面？ 我们必须获取旧控制平面的二进制文件(在我的情况下为 1.7)并将该二进制文件与相同的导出/tmp/iop.yaml一起使用？

7. 不知道如何在删除旧控制平面之前或之后回滚中间发生的任何问题

Answer 1

1. No.您应该浏览更改日志和升级说明。查看新增功能、更改内容、已实践内容等。相应地调整您的配置。

2. 理论上 - 是的，在实践中 - 不。见上文。这就是为什么您应该始终检查升级说明/更新日志并相应地计划。出现问题的可能性总是很小的。

3. 它应该，但同样，准备好某些东西可能会损坏(再一次 - 浏览更改日志/升级说明，这很重要)。

4. 不。

5. 你可以找到所有启用了 Istio 注入的命名空间：

kubectl get namespaces -l=istio-injection=enabled

Istio 升级过程应该只修改启用了注入(和istio-system命名空间)的命名空间。

6. 如果您的旧控制平面没有revision标签，则必须使用其原始安装选项(旧的 yaml 文件)将其卸载

istioctl x uninstall -f /path/to/old/config.yaml

如果它确实有revision标签：

istioctl x uninstall --revision <revision>

7. 您可以使用

istioctl x uninstall revision=1-8

这将恢复到旧的控制平面，假设您尚未卸载它。但是，您必须手动重新安装旧版本的网关，因为卸载命令不会自动还原它们。

---

我强烈建议创建一个临时测试环境。在测试环境中重新创建现有集群。在那里执行升级，并调整过程以满足您的需要。
这样，您将避免生产环境中出现灾难性故障。