Openshift 零停机部署 react + rest api

Openshift zero downtime deployment react + rest api

我们有一个使用 React（和 nginx）构建的 Web 界面和一个 Rest API（具有 json 模式验证）。它们在不同的存储库中。我们的集群是私有 openshift (3.11)

我们希望实现零停机部署。让我们假设：

我们有 10 个 pods 用于网络，20 个 pods 用于其他 API。
我们想将 WEB 和 API 从 1.0.0 升级到 2.0.0
新版WEB只支持新版API
每个 repo（WEB 和 API）都有自己的 helm chart（如果需要并且建议这样做，我们可以创建一个额外的存储库，其中包含一个部署 web 和 api 的 helm chart )

我们应该使用哪种部署策略？ (blue/green, 金丝雀, a/b ?)

如何配置新的WEBpods才能打到API唯一的新服务:

我们如何才能在零停机的情况下执行升级？

非常重要的是，在升级的时候，新版本的WEB应该只打新版本的API，而已经部署的pods(1.0.0)应该继续打老版本了API.

考虑到您告诉我们的限制，您唯一的选择是遵循 blue/green 方法。

你有一组一起工作的东西，比方说 A。还有另一个一起工作的东西，B。AB 是不可能的，所以这排除了金丝雀或 a/b 测试。

您需要部署B（绿色），一切正常后，将域从A切换到B。

用 kubernetes 的话来说，您将拥有两个不同的 Deployments 和 Services，就像它们都是独立的应用程序一样。当您确信 v2 正常工作时，您需要更改指向 v1 服务的 LoadBalancer 的 DNS 记录，以指向 v2 的服务

我也这样做过，在 Kubernetes 中，你可以实现这一点。让我们按照下面的方法。

如果你看上面，我正在通过 helm 进行部署，并且所有 K8s 对象（Pods、SVC、ingress）根据版本名称都是唯一的。通过这种方式，我可以通过在我的域后添加上下文来访问我的特定前端版本，例如 https://app.com/1.0 或 https://app.com/2.0。

我想暴露在互联网上的版本，我通过单独的 Ingress 对象（你可以称之为超级入口）控制它，它独立于你的发布，并决定你想要保持哪个版本。通过这种方式，您可以在生产中部署 N 个版本而不会发生任何冲突，并且通过 super-ingress，您可以选择要指向 public 的 svc。