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 文档建议使用选项 2。不过，由于本地开发和 CI/CD 管道的易用性，我更热衷于选项 1。

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

• 选项 1。开发人员仅安装Service C图表。
• 选项 2：开发人员必须：
  • 安装一个Umbrella图表，由于运行不需要的服务（例如Service A或）而导致 CPU 和内存资源的浪费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