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

Question

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

要求:

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

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

1. 已创建 list 。

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

已安装 istio。

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

根据部署的 list 验证 istio。

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

计划的升级过程 ^Reference

1. 预检查升级。

istioctl x precheck

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

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

下载 istio 1.8 二进制文件并解压目录，然后将该目录导航到我们拥有 1.8 版本 istioctl 二进制文件的位置。

cd istio1.8\istioctl1.8

从新版本的 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 

此后，我们需要更改所有需要注入(inject) istio 代理容器的集群命名空间的现有标签。需要删除旧的“istio-injection”标签，并添加 istio.io/rev 标签以指向金丝雀修订版 1-8。

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

希望，此时旧的 istio 配置环境也稳定，我们可以决定哪些应用程序 Pod 可以重新启动，以便根据我们的停机时间进行新的控制平面更改，并允许使用旧版本运行一些应用程序控制平面和另一个具有新 Controller 平面的配置此时。例如:

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)

一旦我们计划好停机时间并按照我们的决定重新启动部署，请确认所有 Pod 现在仅使用 1.8 版的 dataplane 代理注入(inject)器

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

验证 test-ns 命名空间中的新 Pod 是否正在使用与金丝雀修订版相对应的 istiod-canary 服务

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

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

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

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

1. 上述为升级准备的所有步骤是否适合高使用率的 Prod 环境？

2. 通过导出已安装状态 iop 是否足以获取所有自定义步骤来进行金丝雀升级？或者是否有可能阻止升级或丢失任何设置？

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

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

5. 对于上面的第 5 步，我们如何识别启用了 istio-injection 的所有命名空间，并且仅单独修改这些命名空间，而将其他命名空间保留为之前的样子？

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

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

Answer 1

1. 没有。您应该通过changelog和 upgrade notes 。查看新增内容、更改内容、废弃内容等。相应地调整您的配置。

2. 理论上 - 是的，但实际上 - 不是。往上看。这就是为什么你应该经常检查升级说明/变更日志并做出相应的计划。出问题的可能性总是很小。

3. 应该再次做好可能出现故障的准备(再一次 - 查看变更日志/升级说明，这很重要)。

4. 没有。

5. 您可以通过以下方式查找启用 Istio 注入(inject)的所有命名空间:

kubectl get namespaces -l=istio-injection=enabled

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

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

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

如果它确实有修订标签:

istioctl x uninstall --revision <revision>

您只需卸载新的控制平面即可

istioctl x uninstall revision=1-8

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

---

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