如何对现有的 istio 自定义设置进行金丝雀升级？
How to do a canary upgrade of existing istio customised setup?
如何对现有的 istio 自定义设置进行金丝雀升级。
要求：
- 我们有针对 AKS 1.18.14 的现有 istio 1.7.3 自定义设置（使用 istoctl 方法安装，没有为此设置修订版）。
- 现在我们需要在不停机或最少停机的情况下升级到 istio 1.8。
- 升级应该更安全，不会以任何方式破坏我们的生产环境。
我们如何安装当前的istio自定义环境：
- 已创建清单。
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
- 根据部署的清单验证了 istio。
istioctl verify-install -f $HOME/generated-manifest.yaml
计划的升级过程Reference
- 升级预检查。
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
预计它将使用现有的创建新的控制平面
costamised 配置，现在我们将有两个控制平面
部署和服务 运行 并行：
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
- 在此之后，我们需要更改我们需要注入 istio 代理容器的所有集群命名空间的现有标签。需要删除旧的“istio-injection”标签，并添加 istio.io/rev 标签指向金丝雀版本 1-8.
kubectl label namespace test-ns istio-injection- istio.io/rev=1-8
希望，在这一点上，旧的 istio 配置的环境也是稳定的，我们可以决定可以重新启动哪个应用程序 pods 以使新的控制平面根据我们的停机时间进行更改，并且允许运行 一些应用程序具有较旧的控制平面和另一个具有新控制器平面配置的应用程序。例如：
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)
- 一旦我们计划停机并按照我们的决定重新启动部署，请确认所有 pods 现在仅使用 1.8 版的数据平面代理注入器
kubectl get pods -n test-ns -l istio.io/rev=1-8
- 验证 test-ns 命名空间中的新 pods 正在使用与 canary 版本对应的 istiod-canary 服务
istioctl proxy-status | grep ${pod_name} | awk '{print }'
- 控制面和数据面都升级后，可以卸载旧的控制面
istioctl x uninstall -f /tmp/iop.yaml.
升级前需要清除以下几点。
上面为升级准备的所有步骤是否适合高使用率的 Prod 环境？
通过导出已安装状态的 iop 是否足以获取所有自定义步骤以进行 Canary 升级？或者是否有可能阻止升级或丢失任何设置？
上面的第 4 步是否会创建 1.8 istio 控制平面以及我们已经拥有的所有定制而没有任何中断或遗漏？
在第4步之后，是否还需要对istiod服务配置做任何额外的配置>后面的文档没说清楚，
对于上面的第 5 步，我们如何识别所有的命名空间，我们启用了 istio-injection 并且只修改那些命名空间而其他的保持原样？
所以对于上面的第 8 步，如何确保我们只卸载旧的控制平面？我们必须获取旧控制平面的二进制文件（在我的例子中是 1.7）并将该二进制文件与相同的导出 /tmp/iop.yaml?
一起使用
不知道如何回滚之间发生的任何问题.. 在删除旧控制平面之前或之后
没有。你应该通过 changelog and upgrade notes。看看有什么新的，有什么变化，有什么变化等等。相应地调整你的配置。
理论上 - 是的，实际上 - 不是。看上面。这就是为什么您应该经常检查 upgarde notes/changelog 并做出相应的计划。出问题的可能性总是很小的。
它应该再次准备好可能会出现问题（再一次 - 仔细阅读 changelog/upgrade 注释，这很重要）。
没有
您可以找到所有启用了 Istio 注入的命名空间：
kubectl get namespaces -l=istio-injection=enabled
Istio 升级过程应该只修改启用注入的命名空间（和 istio-system 命名空间）。
- 如果您的旧控制平面没有
revision 标签，您必须使用其原始安装选项（旧 yaml 文件）卸载它
istioctl x uninstall -f /path/to/old/config.yaml
如果有 revision 标签：
istioctl x uninstall --revision <revision>
- 您可以使用
卸载新的控制平面
istioctl x uninstall revision=1-8
假设您还没有卸载它，这将恢复到旧的控制平面。但是，您必须手动重新安装旧版本的网关，因为卸载命令不会自动恢复它们。
我强烈建议创建一个临时测试环境。在测试环境中重新创建现有集群。在那里进行升级，并调整过程以满足您的需要。
这样您就可以避免在生产环境中发生灾难性故障。
如何对现有的 istio 自定义设置进行金丝雀升级。
要求：
- 我们有针对 AKS 1.18.14 的现有 istio 1.7.3 自定义设置（使用 istoctl 方法安装，没有为此设置修订版）。
- 现在我们需要在不停机或最少停机的情况下升级到 istio 1.8。
- 升级应该更安全，不会以任何方式破坏我们的生产环境。
我们如何安装当前的istio自定义环境：
- 已创建清单。
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
- 根据部署的清单验证了 istio。
istioctl verify-install -f $HOME/generated-manifest.yaml
计划的升级过程Reference
- 升级预检查。
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
预计它将使用现有的创建新的控制平面 costamised 配置，现在我们将有两个控制平面 部署和服务 运行 并行：
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
- 在此之后，我们需要更改我们需要注入 istio 代理容器的所有集群命名空间的现有标签。需要删除旧的“istio-injection”标签，并添加 istio.io/rev 标签指向金丝雀版本 1-8.
kubectl label namespace test-ns istio-injection- istio.io/rev=1-8
希望，在这一点上，旧的 istio 配置的环境也是稳定的，我们可以决定可以重新启动哪个应用程序 pods 以使新的控制平面根据我们的停机时间进行更改，并且允许运行 一些应用程序具有较旧的控制平面和另一个具有新控制器平面配置的应用程序。例如：
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)
- 一旦我们计划停机并按照我们的决定重新启动部署，请确认所有 pods 现在仅使用 1.8 版的数据平面代理注入器
kubectl get pods -n test-ns -l istio.io/rev=1-8
- 验证 test-ns 命名空间中的新 pods 正在使用与 canary 版本对应的 istiod-canary 服务
istioctl proxy-status | grep ${pod_name} | awk '{print }'
- 控制面和数据面都升级后，可以卸载旧的控制面
istioctl x uninstall -f /tmp/iop.yaml.
升级前需要清除以下几点。
上面为升级准备的所有步骤是否适合高使用率的 Prod 环境？
通过导出已安装状态的 iop 是否足以获取所有自定义步骤以进行 Canary 升级？或者是否有可能阻止升级或丢失任何设置？
上面的第 4 步是否会创建 1.8 istio 控制平面以及我们已经拥有的所有定制而没有任何中断或遗漏？
在第4步之后，是否还需要对istiod服务配置做任何额外的配置>后面的文档没说清楚，
对于上面的第 5 步，我们如何识别所有的命名空间，我们启用了 istio-injection 并且只修改那些命名空间而其他的保持原样？
所以对于上面的第 8 步，如何确保我们只卸载旧的控制平面？我们必须获取旧控制平面的二进制文件（在我的例子中是 1.7）并将该二进制文件与相同的导出
一起使用/tmp/iop.yaml?不知道如何回滚之间发生的任何问题.. 在删除旧控制平面之前或之后
没有。你应该通过 changelog and upgrade notes。看看有什么新的，有什么变化，有什么变化等等。相应地调整你的配置。
理论上 - 是的，实际上 - 不是。看上面。这就是为什么您应该经常检查 upgarde notes/changelog 并做出相应的计划。出问题的可能性总是很小的。
它应该再次准备好可能会出现问题（再一次 - 仔细阅读 changelog/upgrade 注释，这很重要）。
没有
您可以找到所有启用了 Istio 注入的命名空间：
kubectl get namespaces -l=istio-injection=enabled
Istio 升级过程应该只修改启用注入的命名空间（和 istio-system 命名空间）。
- 如果您的旧控制平面没有
revision标签，您必须使用其原始安装选项（旧 yaml 文件）卸载它
istioctl x uninstall -f /path/to/old/config.yaml
如果有 revision 标签：
istioctl x uninstall --revision <revision>
- 您可以使用 卸载新的控制平面
istioctl x uninstall revision=1-8
假设您还没有卸载它，这将恢复到旧的控制平面。但是，您必须手动重新安装旧版本的网关，因为卸载命令不会自动恢复它们。
我强烈建议创建一个临时测试环境。在测试环境中重新创建现有集群。在那里进行升级，并调整过程以满足您的需要。
这样您就可以避免在生产环境中发生灾难性故障。