子图表之间无法共享模板？

Question

我正在尝试开发一些与自己的微服务一起使用的 helm 库。

我们的想法是让开发团队能够快速将他们的服务包装在 Helm 伞图中，并在指定为依赖项的“通用”子图中拥有尽可能多的样板和健全的默认值。

一个子图（服务）定义了部署、服务、路由等——经典的通用图。

第二个子图（平台）包含计算各种事物的逻辑，例如

imageRegistryBase

（我们需要从图像代理/缓存中提取所有图像，并且生产和测试需要使用不同的网址 - 但所有这些都可以从kubernetes 命名空间的命名约定）。该图表与平台紧密相关（http-proxy configmaps 等）。这些函数也可以放在第一个子图中，但这会降低其灵活性。

我最好可以将平台子图“注入”到服务子图中，但我认为这是不可能的。
接下来，我认为“模板名称是全局的”意味着我可以简单地对两个图表中的函数使用相同的名称，并使用它来“覆盖”函数。但 Helm 似乎不允许

in subchart A: {{ include something-from-subchart-B .}}

。

关于如何实现这一点的任何想法 - 或者我应该放弃它并让伞图具有更多硬编码值:-)

Answer 1

假设两个图表位于同一版本中，一个图表可以调用另一个图表中的（

include

或

template

）函数

define

d。您在这里描述的不能做的事情是覆盖基本图表的函数定义；相反，您必须将适当的参数传递到模板函数中。

如果您的“平台”图表仅由一堆

define

d 函数组成，那么您的“服务”图表应将其作为正常依赖项包含在内。 Helm 有一个“库图表”的概念，它与这个用例完全匹配。（在 Helm 3 中，您可以在 type: library 文件中包含

Chart.yaml

，但 Helm 2 中也存在该模式。）库图表本身不包含资源，但它可以包含生成整个资源 YAML 规范的模板函数；例如，

charts/platform/templates/_deployment.tpl

可能包含

{{- define "platform.deployment" -}}
---
apiVersion: apps/v1
kind: Deployment
...
{{ end -}}

您的服务图表应作为“普通依赖项”依赖于平台图表。我建议以与任何其他软件相同的方式对库图表进行版本控制，将模板函数及其参数集视为 API，然后将正常的语义版本控制规则应用于库图表的版本。您可能有不同的专用模板来调用库，具体取决于这些函数到底产生什么。

图书馆图表尤其与伞形图表存在一个主要的潜在问题。最终您需要对库图表进行重大更改。当你这样做时，正常的 SemVer 规则会说你应该增加主要版本。但现在 Helm 的依赖扁平化不起作用了：如果服务 A 依赖于库版本 1.x，而服务 B 需要库版本 2.x，则没有可以接受的单一版本的库。

(“所有图表都扁平化在一起”和“图表可以调用彼此的模板”会导致另一个可能的混乱点：如果两个服务图表

define

模板同名，就会出现意想不到的冲突，只有出现在伞里。）

相反，我建议让每个服务都可以独立部署。使 Helm 图表独立，可能对库图表具有版本依赖性。要么为每个服务运行 CI/CD 管道

helm upgrade

，要么使用 Helmfile 等可以管理多个 Helm 版本的高级工具。