使用 Kubernetes 架构在不同节点部署应用的标准方式的可行性答案

【问题标题】：Feasibility of standard way of application deployment in different nodes using Kubernetes architecture使用 Kubernetes 架构在不同节点部署应用的标准方式的可行性
【发布时间】：2018-10-10 20:43:27
【问题描述】：

我计划使用 Kubernetes 和 Jenkins 进行微服务部署。

应用性质

我总共有 15 个 Spring Boot 微服务。并且需要为不同的客户部署所有这 15 种微服务——每个人都使用相同的代码，但需要单独部署。意味着每个客户都有自己的部署。总共我有 5 个客户（这是假设。不准确。它将从 20 到 50 不等）。

我目前的设计

我目前计划使用 5 个 Kubernetes 节点。意味着一个集群主节点加上 5 个节点。总共 6 个虚拟机。并计划在这 5 个节点中为 5 个客户部署这 15 个微服务中的每一个。所以每个人都会得到自己的部署。我还将在我的 Kubernetes 集群主 VM 中安装 Jenkins 以创建 CI/CD 管道。

所以这些是关于所有架构的。我只是云应用程序架构和设计的初学者。在这里我需要知道与此架构相关的任何问题。我需要确认它的可行性。

请消除我对当前方法的困惑。如果这是一个好的，我可以继续。我只是在搜索这是使用 Kubernetes 的工业标准方式。这种方式是一种好的架构吗？

【问题讨论】：

标签： architecture kubernetes

【解决方案1】：

我想到了几件事：

一个主控是不够的。该虚拟机、底层硬件的丢失或主服务器上的服务故障将导致所有客户中断，并可能导致灾难性的数据丢失。至少运行 3 个 master。
运行每个服务的不同副本的每个客户端都是次优的租赁模型。在很多情况下都需要这样做，但在这些情况下，每个客户端通常都在运行自己不同的服务版本。在微服务架构中管理它是很糟糕的。
CD 在每个客户端都运行自己的服务副本（可能每个客户端都有自己的版本）的环境中是不可能的。
JVM 消耗大量 CPU 和内存。单个 JVM 旨在支持多个工作负载。所以容器资源管理和JVM资源管理，以及运行JVM微服务之间可能存在冲突

【讨论】：

谢谢您的回复先生。非常高兴。我通过建议使用 3 个大师来理解您的观点。谢谢。但是根据您的第 3 点和第 4 点，我再次感到困惑。为什么您说这种设计中的部署会变得很糟糕？那么我如何以适当的方式管理我的交付/部署？因为我打算在这里使用 Jenkins。我已经为客户配置了一个具有不同配置文件的 spring 云配置服务器。我认为我可以轻松地为每个具有特定配置文件/配置的客户启动应用程序。你能推荐一种标准的部署方式吗？
这里的代码是一样的。当我启动应用程序时，我可以为不同的客户启动 docker 镜像。当我探索时，我发现，我也可以使用 Jenkins 自动化工具来构建镜像和部署。这就是我目前计划安排此部署的方式。先生，让我知道您的观点吗？
很高兴为您提供帮助，先生。 Jenkins 非常适合自动化。我所做的观察更多的是关于租赁模型。如果 50 个客户中的每一个都在运行 15 个应用程序中的每一个，那就是 750 个应用程序实例，750 个 JVM。由于有时应用程序和虚拟机等会出现故障，因此可能需要为每个应用程序运行 2 或 3 个实例（针对每个客户）以维护 SLA。那是数千个 JVM，相当于 5 个 VM 节点。此外，每个单独的客户肯定会未充分利用为他们提供的资源，从而使运营商背负着高昂的固定成本。
关于 CD 的具体点实际上也与租户有关——对每个客户的预置应用程序执行持续交付在逻辑上会很复杂，因为每次应用程序更改都会影响 50-100 个实例。如果可以一次更改/交付多个应用程序，则会出现特定客户难以追踪的极端情况错误。我的建议是，每客户应用程序实例的租赁模型比替代方案更昂贵和复杂。
是的，我理解您对租约的看法。但我不明白你的最后一句话 - “我的建议实际上只是每个客户的应用程序实例的租赁模型比替代方案更昂贵和复杂”。先生，您能澄清一下声明吗？