Question

该应用程序具有多个在每个管道上构建docker映像的管道。多个API和一个React Web应用程序。

当前的头盔图表设置为具有多个服务和部署以及一个入口控制器。

以这种方式进行操作意味着整个产品都在一个头盔图中，这很好。但是，这意味着，对于CI / CD，如果其中一个API的标签更改了，我们需要找出用于其他图像的标签。

我已经考虑过为每个应用程序创建Helm图表，但是入口控制器将如何工作？您是否为每个图表都有一个入口控制器，并让Kubernetes根据正则表达式规则找出要使用哪个入口控制器？

这种事情必须有更好的结构，我被困住了。我听说过“伞形图”一词，但并不太确定这意味着什么。

Answer 1

这实际上取决于您的期望，可以为所有内容创建一个图表，也可以为每个应用程序创建图表。

如果为每个应用程序创建图表，则只需为每个应用程序创建一个入口，它将它们合并为一个入口定义（种类）。这就是我的样子：

metadata:
  name: service1
spec:
  rules:
  - host: service1.domain.com
    http:
      paths:
      - backend:
          serviceName: service1
          servicePort: 80
        path: /

，然后进行第二项服务：

metadata:
  name: service2
spec:
  rules:
  - host: service2.domain.com
    http:
      paths:
      - backend:
          serviceName: service2
          servicePort: 80
        path: /

，他们将在一起工作而不会发生冲突。如果您使用的是基于路径的路由，则必须确保路径不会冲突。

Answer 2

只有一个具有多个入口规则的入口控制器（已复制）是很常见的。更重要的是，这是入口控制器的目的：只有一个“外部端点”可以在许多“内部端点”上路由请求。

关于头盔结构，通常最好每个应用程序都有一张图表，特别是用于版本管理。为了充分利用这两个选项，可以添加一种“元图表”（也称为伞形图表），该“元图表”仅包含requirements.yaml文件，该文件将列出所有其他图表。使用这种结构，可以轻松地仅部署CI / CD所需的特定图表，但是您也可以仅使用一个图表来部署整个服务。甚至，您还可以在全面的集成测试后发布“元图表”，以“证明”所有应用程序版本都可以协同工作。

Helm的官方文档正在https://helm.sh/docs/developing_charts/#complex-charts-with-many-dependencies上提供建议。

如何为由多个服务组成的应用程序构建Helm图表？

2 个答案: