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

问题描述 投票：2回答：1

鉴于以下服务方案及其依赖关系，我想设计一组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 docs以及我能在互联网上找到的几个例子（link）也会选择2，所以我想我可能会遗漏一些东西。

kubernetes kubernetes-helm
1个回答
2
投票

我建议每个服务一个图表，另外简化使“服务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
最新问题
© www.soinside.com 2019 - 2024. All rights reserved.