Helm图表之间的依存关系是否应该反映微服务之间的依存关系? [英] Should dependencies between Helm charts reflect dependencies between microservices?

问题描述

鉴于以下服务及其依赖性的方案，我想设计一套Helm图表.

Given a following scheme of services and their dependencies I would like to engineer a set of Helm charts.

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

• API Gateway calls Service A and Service C
• Service A calls Service B
• Service B calls Database
• Service C calls Service B and Service D

此刻，我看到两种选择:

At the moment I see two alternatives:

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

1. Each of the 6 components in a diagram below is a single chart and each arrow in a diagram is a single dependency.
   

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

There's an Umbrella chart that has a dependency on all other charts. The Database chart is a dependency of Service B chart.

头盔文档建议选择2.但是，由于易于本地开发和CI/CD开发，因此我更倾向于选项1.

Helm documentation suggest going with option 2. I am however more keen towards option 1 due to an ease of local development and CI/CD pipeline.

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

Example scenario: developer is refactoring Service C and he wants to run the code he changed and test it.

• 选项1.开发人员仅安装Service C图表.
• 选项2:开发人员必须:
  • 安装Umbrella图表，由于运行不必要的服务(例如Service A或API Gateway)，这会浪费CPU和内存资源，而这些服务无法随着系统的复杂性很好地扩展；
  • 先安装Service C，然后依次Service B和Service D，这也不能很好地适应系统的复杂性，因为它需要执行许多手动操作，并且要求开发人员熟悉该体系结构以了解需要安装哪些图表.
  • Option 1. Developer installs a Service C chart only.
  • Option 2: Developer would have to either:
    • install an Umbrella chart which leads to waste of a CPU and memory resources because of running unneeded services like Service A or API Gateway, which doesn't scale well with the complexity of the system;
    • install Service C, then Service B and then Service D, which also doesn't scale well with the complexity of the system because it requires to perform many manual actions and also require from developer to be faimiliar with the architecture of the system in order to know what charts needs to be installed.

    我想就选择哪种选择做出明智的决定.我更热衷于选项1，但可以在Internet上找到Helm文档以及一些示例(

    I would like to make an educated decision on which alternative to take. I am more keen towards option 1, but Helm docs and also few examples I was able to find on the Internet (link) are also going with option 2, so I think I might be missing something.

    推荐答案

    我将为每个服务推荐一个图表，并简化了使服务B"图表依赖于其数据库的过程.我将使这些图表相互独立:所有服务都不依赖于其他任何服务.

    I would recommend one chart per service, with the additional simplification of making the "service B" chart depend on its database. I would make these charts independent: none of the services depend on any other.

    Helm依赖关系运行良好的地方是您可以嵌入/隐藏其他特定部分的服务.例如，B后面的数据库是一个实现细节，B之外的任何事情都不需要知道.因此B可以依赖stable/postgres或类似的东西，这在Helm中效果很好.

    The place where Helm dependencies work well is where you have a service that embeds/hides specific single other parts. The database behind B is an implementation detail, for example, and nothing outside B needs to know about it. So B can depend on stable/postgres or some such, and this works well in Helm.

    有一个特定的机械问题导致伞形图方法出现问题.说服务D也依赖于数据库，并且它是数据库的一种"(例如都使用PostgreSQL).在操作上，您希望这两个数据库是分开的. Helm将看到两个路径umbrella > B > database和umbrella > D > database，并且仅安装数据库图表的一个副本，因此您将获得共享数据库的这两个服务.您可能不想要那个.

    There's one specific mechanical problem that causes problems for the umbrella-chart approach. Say service D also depended on a database, and it was the same "kind" of database (both use PostgreSQL, say). Operationally you want these two databases to be separate. Helm will see the two paths umbrella > B > database and umbrella > D > database, and only install one copy of the database chart, so you'll wind up with the two services sharing a database. You probably don't want that.

    在这里使用Helm依赖项还会遇到的另一个机械问题是，大多数资源都被命名为{{ .Release.Name }}-{{ .Chart.Name }}的某种变体.在选项1中，假设您确实安装了服务C；您最终会使用诸如service-C-C，service-C-B，service-C-database之类的部署.然后，如果您想在服务A旁边部署服务A，则会引入它自己的service-A-B和service-A-database，这又不是您想要的.

    The other mechanical issue you'll encounter using Helm dependencies here is that most resources are named some variant of {{ .Release.Name }}-{{ .Chart.Name }}. In your option 1, say you do just install service C; you'd wind up with Deployments like service-C-C, service-C-B, service-C-database. If you then wanted to deploy service A alongside it, that would introduce its own service-A-B and service-A-database, which again isn't what you want.

    我不知道针对此问题的高级开源解决方案.基于Make的解决方案很容易破解，但是可以正常工作:

    I'm not aware of a great high-level open-source solution to this problem. A Make-based solution is hacky, but can work:

    # -*- 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
    

    这篇关于Helm图表之间的依存关系是否应该反映微服务之间的依存关系?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！