1

如何对现有的 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
  1. 安装了 istio。
istioctl install --set profile=default -f /manifests/overlay/overlay.yaml
  1. 针对已部署的清单验证了 istio。
istioctl verify-install -f $HOME/generated-manifest.yaml

计划升级过程参考

  1. 预检查升级。
istioctl x precheck
  1. 使用以下命令将 istio 当前使用的配置导出到 yaml 文件。
kubectl -n istio-system get iop installed-state-install -o yaml > /tmp/iop.yaml
  1. 下载 istio 1.8 二进制文件并解压目录并将目录导航到我们拥有 1.8 版本 istioctl 二进制文件的位置。
cd istio1.8\istioctl1.8
  1. 从新版本的 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
  1. 在此之后，我们需要更改所有需要注入 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)
  1. 一旦我们计划停机并按照我们的决定重新启动部署，请确认所有 pod 现在仅使用 1.8 版的 dataplane 代理注入器
kubectl get pods -n test-ns -l istio.io/rev=1-8
  1. 验证 test-ns 命名空间中的新 pod 是否正在使用与 canary 版本对应的 istiod-canary 服务
istioctl proxy-status | grep ${pod_name} | awk '{print $7}'
  1. 升级控制平面和数据平面后，可以卸载旧的控制平面
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. 不知道如何回滚之间发生的任何问题..在旧控制平面删除之前或之后

4

1 回答 1

1

  1. 不，您应该查看更新日志和升级说明。看看有什么新的，有什么改变，什么被淘汰等。相应地调整你的配置。

  2. 理论上 - 是的，在实践中 - 不。看上面。这就是为什么您应该始终检查升级说明/更改日志并做出相应计划的原因。出错的可能性总是很小。

  3. 它应该，但再次，准备好可能会破坏（再一次 - 浏览变更日志/升级说明，这很重要）。

  4. 不。

  5. 您可以通过以下方式找到所有启用了 Istio 注入的命名空间：

kubectl get namespaces -l=istio-injection=enabled

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

  1. 如果您的旧控制平面没有revision标签，则必须使用其原始安装选项（旧 yaml 文件）将其卸载
istioctl x uninstall -f /path/to/old/config.yaml

如果确实有revision标签：

istioctl x uninstall --revision <revision>
  1. 您可以使用卸载新的控制平面
istioctl x uninstall revision=1-8

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

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

于 2021-06-28T09:32:43.243 回答