Architecture 使用Kubernetes架构在不同节点上部署应用程序的标准方式的可行性

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

应用的性质

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

我当前的设计

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

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

---

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

我想到了几件事：

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

---

谢谢您的回复，先生。非常荣幸。我理解你的观点，建议使用3个大师。谢谢但是根据你的第三点和第四点，我又感到困惑了。为什么你说这种设计中的部署会很糟糕？那么，我如何以适当的方式管理我的交付/部署？因为我打算在这里用詹金斯。我已经为客户配置了一个具有不同配置文件的SpringCloudConfig服务器。我认为我可以使用每个客户的特定配置文件/配置轻松地为他们启动应用程序。你能推荐一种标准的部署方式吗？这里的代码是一样的。当我启动应用程序时，我可以为不同的客户启动docker镜像。当我探索时，我发现，我可以使用Jenkins自动化工具来构建镜像和部署。这就是我目前计划安排这次部署的方式。让我知道你那边的要点，先生？很乐意帮忙，先生。詹金斯擅长自动化。我所做的观察更多的是关于租赁模式。如果50个客户中的每一个都在运行15个应用程序中的每一个，那就是750个应用程序实例，750个JVM。由于有时应用程序和VM等出现故障，因此可能需要为每个客户运行每个应用程序的2或3个实例，以维护SLA。这是数千个JVM，这对于5个VM节点来说是一个延伸。此外，每个客户肯定会未充分利用为其提供的资源，给运营商带来高昂的固定成本。关于CD的具体问题实际上也是关于租赁的——对每个客户提供的应用程序执行连续交付将在后勤上变得复杂，因为每次应用程序更改都会影响50-100个实例。如果一次可以更改/交付多个应用程序，那么对于难以追踪的特定客户，将出现关键案例错误。我的建议是，每个客户的应用程序实例的租赁模式比其他模式更昂贵和复杂。是的，我理解你的租赁观察。但我不理解你的上一句话——“我的建议是，每个客户的应用程序实例的租赁模型要比替代模型昂贵和复杂得多。”。先生，你能澄清一下声明吗？