为您的 Istio 控制平面安全可靠地进

mitaparvin

新的控制平面 迁移完全完成后，卸载 Istio 1.6 控制平面 Istio 控制平面金丝雀升级 这种金丝雀升级模型比就地升级工作流程安全得多，主要是因为它可以按照您自己的节奏逐步完成。如果出现问题，最初可能只会影响应用程序的一小部分，如果确实发生这种情况，则仅回滚应用程序的一部分以与原始控制平面一起使用应该会容易得多。 这种升级流程为我们在进行 Istio 升级时提供了更大的灵活性和信心，从而大大降低了服务中断的可能性。 使用Banzai Cloud Istio 操作员进行金丝雀升级 让我们仔细看看该流程如何与我们的开源Banzai Cloud Istio 操作符结合使用。因此，我们的起点是运行的 Istio Operator 和 Istio 1.6 控制平面，以及使用该控制平面版本的应用程序。 部署另一个 Istio 操作器（与前一个操作器一起），它支持 Istio 1.7 将新的 Istio CR 与 Istio 版本 1.7 一起应用，并让操作员协调 Istio 1.7 控制平面。

建议您关闭新控制平面的网关，并将 1.6 网关 Pod 迁移到 1.7 控制平面。这样，入口网关的典型 LoadBalancer 类型的服务将不会被重新创建，云平台管理的 LoadBalancer 也不会被重新创建，因此 IP 地址也不会改变。 这个新的控制平面通常被称为金丝雀，但在实践中，建议根据 Istio 版本命名，因为它将长期保留在集群上。 迁移网关以 电话号码列表 使用新的 Istio 1.7 控制平面 在使用Banzai Cloud Istio 操作员安装新控制平面期间，特意将其保留为手动步骤（与上游 Istio 不同），以便用户可以确保他们已准备好使用其网关的控制平面，并且仅在之后迁移。 迁移数据平面应用程序建议您逐步执行此迁移。在数据平面迁移期间请务必记住，两个 Istio 控制平面共享信任（因为它们使用相同的证书进行加密通信）。因此，当仍然使用 Istio 1.6 控制平面的应用程序 Pod 调用另一个已经使用 Istio 1.7 控制平面的应用程序 Pod 时，由于共享信任，加密通信将会成功。这就是为什么可以逐个命名空间执行此迁移，并且 Pod 的通信不会受到影响。




目前，迁移只能在每个命名空间的基础上进行，因为在 Pod 级别上尚不支持，尽管在未来的版本中可能会支持。 删除 Istio 1.6 控制平面一旦迁移完成，并且我们确保我们的应用程序能够与新控制平面一起正常工作，就可以安全地删除旧的 Istio 1.6 控制平面。建议您在关闭旧控制平面之前花一些时间确保新控制平面上的一切正常运行；它只是一个运行的部署，几乎没有附加任何数据平面 Pod。 istiod 从传统意义上讲，金丝雀升级流程以将旧应用程序滚动更新到新应用程序结束。这不是这里发生的事情。相反，金丝雀控制平面将长期保留在集群中，原始控制平面不会被推出，而是被删除（这就是为什么建议您根据版本号命名新的控制平面，而不是将其命名为金丝雀）。 我们在这里使用“金丝雀升级”这个表达方式，因为这是 Istio 中统一使用的表达方式，而且我们认为它比尝试为流程创造一个新术语来更好地解释它更容易理解和记住。