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

Question

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

• API Gateway呼叫Service A和Service C
• Service A呼叫Service B
• Service B呼叫Database
• Service C呼叫Service B和Service D

此刻，我看到两种选择：

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

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

Helm documentation建议采用选项2。但是，由于易于本地开发和CI / CD流程，我更倾向于选项1。

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

• 选项1.开发人员仅安装Service C图表。
• 选项2：开发人员必须：
  • 安装Umbrella图表，由于运行不必要的服务（例如Service A或API Gateway）会导致CPU和内存资源的浪费，而这些服务并不能很好地扩展系统；
  • 先安装Service C，然后依次安装Service B和Service D，由于系统需要执行许多手动操作，并且还需要开发人员进行操作，因此它无法很好地适应系统的复杂性熟悉系统的体系结构以便知道需要安装哪些图表。

我想就选择哪种选择做出明智的决定。我更热衷于选项1，但是Helm文档以及我在Internet上可以找到的几个示例（link）也都使用了选项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旁边部署服务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