Helm图表之间的依赖关系是否应该反映微服务之间的依赖关系？

Question

考虑到下面的服务方案及其依赖关系，我想设计一组Helm图表。

• API Gateway调用Service A和Service C
• Service A调用Service B
• Service B调用Database
• Service C调用Service B和Service D

目前，我看到了两种选择：

1. 下图中的6个组件都是单个图表，图中的每个箭头都是单个依赖项。

​

1. 有一个Umbrella图表，它依赖于所有其他图表。Database图表是Service B图表的依赖项。

​

舵机文件建议采用备选方案2。但是，由于本地开发和CI/CD管道的容易程度，我更倾向于选择1。

示例场景:开发人员正在重构Service C，他希望运行更改后的代码并对其进行测试。

• 选项1.开发人员只安装Service C图表。
• 选项2:开发人员必须这样做：
  • 安装一个Umbrella图表，这会导致CPU和内存资源的浪费，因为它运行的是不需要的服务，比如Service A或API Gateway，它们不能很好地适应系统的复杂性；
  • 安装Service C，然后是Service B，然后是Service D，这也不能很好地适应系统的复杂性，因为它需要执行许多手动操作，并且还要求开发人员与系统的体系结构保持一致，以便知道需要安装哪些图表。

​

我想作出一个明智的决定，选择哪一种选择。我更热衷于选择1，但是Helm和我在因特网(链接)上找到的几个例子也是与选项2一起使用的，所以我想我可能遗漏了一些东西。

Answer 1

我建议每项服务有一张图表，并进一步简化使“服务B”图表依赖于其数据库。我将使这些图表独立:任何服务都不依赖于任何其他服务。

Helm依赖关系工作良好的地方是有一个嵌入/隐藏其他特定部分的服务的地方。例如，B后面的数据库是一个实现细节，B之外的任何东西都不需要了解它。所以B可以依赖于stable/postgres或其他类似的东西，这在Helm中是很好的。

有一个特殊的机械问题，导致问题的伞-图表方法。假设服务D也依赖于数据库，并且它是相同的“类型”数据库(都使用PostgreSQL，例如)。在操作上，您希望这两个数据库是分开的。Helm将看到两个路径umbrella > B > database和umbrella > D > database，并且只安装数据库图表的一个副本，因此您将得到共享数据库的两个服务。你可能不想那样。

这里使用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-make -*-
all: api-proxy.deployed

%.deployed:
        helm upgrade --install --name $* -f values.yaml ./charts/$*
        touch $@

api-proxy.deployed: a.deployed c.deployed
a.deployed: b.deployed
c.deployed: b.deployed d.deployed