0

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

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

  1. 我们有 10 个用于 Web 的 pod 和 20 个用于 Rest API 的 pod。
  2. 我们想将 WEB 和 API 从 1.0.0 升级到 2.0.0
  3. 新版WEB只支持新版API
  4. 每个 repo（WEB 和 API）都有自己的 helm chart（如果需要并且推荐，我们可以创建一个额外的存储库，其中包含一个部署 web 和 api 的 helm chart）

我们应该使用哪种部署策略？（蓝/绿、金丝雀、a/b？）

我们如何配置新的 WEB pod 以访问 API 的唯一新服务：

  • WEB 1.0.0 --> API 1.0.0
  • WEB 2.0.0 --> API 2.0.0

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

非常重要的是，在升级过程中，WEB 的新版本应该只打新版本的 API，而已经部署的 pods（1.0.0）应该继续打旧版本的 API。

4

2 回答 2

2

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

在此处输入图像描述

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

我想向互联网公开的版本，我通过单独的 Ingress 对象（您可以称为 super-ingress）控制它，它独立于您的版本并决定您要保持哪个版本。这样，您可以在生产中部署 N 个版本而不会发生任何冲突，并且通过 super-ingress，您可以选择要指向公共的 svc。

于 2020-05-24T09:48:11.667 回答
0

鉴于您告诉我们的限制，您唯一的选择是遵循蓝/绿方法。

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

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

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

于 2020-05-24T08:51:41.500 回答