Openshift 零停机部署 react + rest api答案

【问题标题】：Openshift zero downtime deployment react + rest apiOpenshift 零停机部署 react + rest api
【发布时间】：2020-09-10 23:14:31
【问题描述】：

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

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

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

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

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

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

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

【问题讨论】：

集群上是否安装了 istio？您的集群在哪里运行？集群中是否有（Nginx）等应用LB？你能分享更多关于你的集群和安装更多组件的细节吗？
@MickeyHovel 集群是公司集群（openshift），我无权访问它，请求/安装新组件将是一个相当长的过程。抱歉，我不知道 istio 是什么。但是，在我们的命名空间中，我们可以做任何我们想做的事情，如果我们需要在命名空间中使用 nginx 负载均衡器，我们可以部署它

【解决方案1】：

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

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

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

【讨论】：

【解决方案2】：

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

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

你需要部署B（绿色），当一切无误后，将域从A切换到B。

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

【讨论】：

这可以在没有任何额外工具/负载均衡器/特定组件配置的情况下实现吗？是 kubernetes 开箱即用的吗？
@Fabry AFAIK，Kubernetes 中不支持内置蓝色/绿色。你需要一些负责测试和切换 DNS 的东西。通常你会有一个管道应用 k8s 的 yaml，所以这个管道的另一个阶段是更改 DNS。