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

Question

该应用程序有多个管道，每个管道构建 docker 个图像。多个 API 和一个 React Web 应用程序。

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

这样做意味着整个产品都在一个舵图中，这很好。但是，这意味着当涉及到 CI/CD 时，如果其中一个 API 的标签发生变化，我们需要确定将哪个标签用于其他图像。

我考虑过为每个应用程序创建一个 Helm 图表，但入口控制器将如何工作？您会为每个图表设置一个入口控制器，让 Kubernetes 根据正则表达式规则确定使用哪个吗？

这种事情必须有更好的结构，我被卡住了。我听说过 "Umbrella chart" 这个词，但不太清楚那是什么意思。

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

只有一个入口控制器（复制）和许多入口规则是很常见的。更重要的是，这就是入口控制器的目的：只有一个 "external endpoint" 可以在许多 "internal endpoints".

上路由请求

关于helm结构，一般来说每个应用一个chart比较好，专门用于版本管理。要获得这两个选项中的最佳选择，您可以添加一种 "meta chart"（也称为伞状图表），它只包含一个 requirements.yaml 文件，它将列出所有其他图表。使用这种结构，很容易只部署 CI/CD 所需的特定图表，但您也可以只用一个图表部署整个服务。更重要的是，您可以在完全集成测试后发布 "meta chart"，"certify" 您的所有应用程序版本都可以协同工作。

Helm 官方文档在 https://helm.sh/docs/developing_charts/#complex-charts-with-many-dependencies.

给出了这方面的建议

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

How should I structure Helm charts for an application made up of multiple services?

azure

kubernetes

kubernetes-ingress

azure-aks