Kubernetes 掌舵图之间的依赖关系是否应该反映微服务之间的依赖关系？

给定以下服务方案及其依赖关系，我想设计一组掌舵图

• API网关

  调用

  服务A

  和

  服务C

• 服务A

  呼叫

  服务B

• 服务B

  调用

  数据库

• 服务C

  调用

  服务B

  和

  服务D

目前，我看到两种选择：

下图中的6个组件中的每一个都是一个单独的图表，图中的每个箭头都是一个单独的依赖项

有一个

伞形图

图表依赖于所有其他图表。

数据库

图表是

服务B

图表的依赖项。

建议选择2。然而，由于本地开发和CI/CD管道的便利，我更热衷于选择1

示例场景：开发人员正在重构

服务C

，他希望运行他更改的代码并对其进行测试

• 备选案文1。开发者仅安装

  服务C

  图表
• 选项2：开发商必须：
  • 安装一个

    伞形图

    ，由于运行不必要的服务，如

    服务a

    或

    API网关

    ，导致CPU和内存资源的浪费，这与系统的复杂性不匹配
  • 安装

    服务C

    ，然后安装

    服务B

    ，然后安装

    服务D

    ，这也不能很好地适应系统的复杂性，因为它需要执行许多手动操作，还需要开发人员熟悉系统的体系结构，以便知道需要安装哪些图表

---

我想做出一个明智的决定，选择哪种替代方案。我对选项1更感兴趣，但Helm docs和我在互联网上找到的几个例子（）也与选项2一起使用，因此我认为我可能遗漏了一些东西。

我建议每个服务一个图表，并进一步简化“服务B”图表依赖于其数据库的过程。我将使这些图表独立：没有任何服务依赖于任何其他服务

掌舵依赖关系工作良好的地方是您拥有嵌入/隐藏特定单个其他部分的服务的地方。例如，B后面的数据库是一个实现细节，B之外的任何东西都不需要知道。因此，B可以依赖于

stable/postgres

或类似的东西，这在Helm中非常有效

有一个特定的机械问题导致伞形图方法出现问题。比如说服务D也依赖于一个数据库，它是同一种“类型”的数据库（比如说，两者都使用PostgreSQL）。在操作上，您希望这两个数据库分开。Helm将看到两个路径

umbrane>B>数据库

和

umbrane>D>数据库

，并且只安装数据库图表的一个副本，因此您将看到两个服务共享一个数据库。你可能不想那样

在这里使用Helm依赖项会遇到的另一个机械问题是，大多数资源都被命名为

{{.Release.Name}-{{.Chart.Name}

的某个变体。在选项1中，假设您只安装了服务C；最后，您将进行部署，如

service-C-C

，

service-C-B

，

service-C-database

。如果您想在它旁边部署服务A，那么将引入它自己的

service-A-B

和

service-A-database

，这同样不是您想要的

我不知道有什么好的高级开源解决方案可以解决这个问题。基于Make的解决方案是有缺陷的，但可以工作：

#-*-gnu制造-*-
全部：api-proxy.deployed
%.部署：
头盔升级--安装--名称$*-f values.yaml./charts/$*
触碰$@
api-proxy.deployed:a.deployed c.deployed
a、 部署：b.部署
c、 部署的；部署的

感谢您的回复。这与我的观察相符。我读的关于赫尔姆的书越多，我就越意识到赫尔姆并不能解决这个问题。它被宣传为包管理器，但与其他包管理器不同，正如您所指出的，Helm在使用选项1时会以不同的名称安装资源的副本。