通用舵图答案

【问题标题】：Generic helm chart通用舵图
【发布时间】：2020-08-21 18:15:28
【问题描述】：

我是舵图模板的初学者，我正在寻找最佳实践。我想创建一个足够泛型的掌舵图表模板，以便为所有团队项目（后端、前端、..）使用相同的图表为了使其成为泛型，我可以让开发人员在 values.yml 中指定许多案例的列表（部署卷、网络策略入口等......）。而且我可以保留 kubernetes 模板部署、服务等。足够的泛型永远不会提及任何特定的键。所以开发者只能修改值 yml 为他们的应用程序行为添加值。

缺点是 kubernetes 泛型模板不会包含任何关于应用程序的逻辑，并且泛型模板将难以维护（因为它会处理所有可能的情况）。好处是开发者不需要了解helm，因为他们不会修改kubernetes模板。

那么你有这方面的经验吗？

【问题讨论】：

我不会推荐它。如果您的要求是服务维护人员最多编写最少的 YAML，那么基于 Go 的 Kubernetes 操作员将比仅使用 Helm 模板系统构建相同的功能更容易编写和维护。正如您所注意到的，“通用模板”最终会变得与 YAML 一样复杂，此时编写（和 Google）标准 YAML 比模板输入更容易。
helm 的优势也是图表版本升级、回滚的发布管理。但是我认为当使用 range 函数和其他函数变得复杂时，操纵 helm 模板 yml 真的很复杂... 对于基于 Kubernetes 的操作员，我可以对已部署的应用程序进行发布管理吗？也许我可以保持 helm 策略，选择客户端开发者选择 helm 后端模板或 helm 前端模板等我已经准备好为 helm 应用程序提供连贯和快速的启动，如果他们需要，他们可以完成 kub 模板。

标签： templates kubernetes kubernetes-helm

【解决方案1】：

您可以使用 _*.tpl 文件来定义通用模板，它们位于 ./templates/_*.tpl（. 是包含全局 Chart.yaml 和 values.yaml 的目录）。同样默认在 helm 全局值覆盖本地值。可以在这里找到解决方案 - https://github.com/helm/helm/issues/5676

通过结合使用这两种技术，您可以制作通用模板，并且只使用 values.yaml 来呈现您想要呈现的内容。

例如：

values.yaml:

global:
  defaults:
    switches:
      volumesEnabled: false
      ingressEnabled: false
    ingress:
      host: "generic-host.com"
    volumes:
      volumeName: "generic-volume-name"

subchart1:
  defaultOverrides:
    switches:
      volumesEnabled: true
  volumes:
    volumeName: "not-so-generic-name"

subchart2:
  defaultOverrides:
    switches:
      volumesEnabled: true
      ingressEnabled: true

然后是模板（java只是为了将模板归为一类，你可以尝试猜测我的后端微服务是用哪种语言编写的:)）

./templates/java/_deployment.tpl:

{{- define "templates.java.deployment" }}
{{- $properties := merge .Values.defaultOverrides $.Values.global.defaults -}}
{{*/ generic deployment structure */}}
{{- if $properties.switches.volumesEnabled -}}
volume: {{ $properties.volumes.volumeName }}
{{- end }}
{{*/ generic deployment structure */}}
{{- end }}

./templates/java/_ingress.tpl:

{{- define "templates.java.ingress" }}
{{- $properties := merge .Values.defaultOverrides $.Values.global.defaults -}}
{{- if $properties.switches.ingressEnabled -}}
host: {{ $properties.ingress.host }}
{{*/ generic ingress structure */}}
{{- end }}
{{- end }}

然后是子图表模板 ./charts/subchart1/templates/deployment.yaml：

{{ include "templates.java.deployment" . }}

./charts/subchart1/templates/ingress.yaml:

{{ include "templates.java.ingress" . }}

subchart2 具有完全相同的包含。

最后我们会有：

子图1：

已部署
volumeName 被本地值覆盖为“not-so-generic-name”
根本不渲染入口

子图2：

已部署
volumeName 是全局值的默认值
入口主机是全局值的默认值

但我会说，泛化太多是一种不好的做法，因为它会使您的模板过于复杂。在我的情况下，我发现了 2 个不同的组，它们在其中具有几乎相同的清单（基本上是前端和后端），并为每个组创建了一组 _*.tpl 文件，并分别在全局 values.yaml 中为每个组设置默认值。

【讨论】：