模板

模板

最佳实践指南的这一部分重点介绍模板。

templates 目录结构

templates 目目录的结构应如下所示：

如果他们产生 YAML 输出，模板文件应该有扩展名 .yaml。扩展名. tpl 可用于产生不需要格式化内容的模板文件。
模板文件名应该使用横线符号（my-example-configmap.yaml），而不是 camelcase。
每个资源定义应该在它自己的模板文件中。
模板文件名应该反映名称中的资源种类。例如 foo-pod.yaml， bar-svc.yaml

定义模板的名称

定义的模板（在 {{ define }} 指令内创建的模板）可以全局访问。这意味着 chart 及其所有子 chart 都可以访问所有使用 {{ define }} 创建的模板。

出于这个原因，所有定义的模板名称应该是带有某个 namespace。

正确：

{{- define "nginx.fullname" }}
{{ /* ... */ }}
{{ end -}}

不正确：

{{- define "fullname" -}}
{{/* ... */}}
{{ end -}}

强烈建议通过 helm create 命令创建新 chart，因为根据此最佳做法自动定义模板名称。

格式化模板

模板应该使用两个空格缩进（不是制表符）。

模板指令在大括号之后和大括号之前应该有空格：

正确：

{{ .foo }}
{{ print "foo" }}
{{- print "bar" -}}

不正确：

{{ .foo }}
{{ print "foo" }}
{{-print "bar"-}}

模板应尽可能地填充空格：

foo:
  {{- range .Values.items }}
  {{ . }}
  {{ end -}}

块（如控制结构）可以缩进以指示模板代码的流向。

{{ if $foo -}}
  {{- with .Bar}}Hello{{ end -}}
{{- end -}}

但是，由于 YAML 是一种面向空格的语言，因此代码缩进有时经常不能遵循该约定。

生成模板中的空格

最好将生成的模板中的空格保持最小。特别是，许多空行不应该彼此相邻。但偶尔空行（特别是逻辑段之间）很好。

这是最好的：

apiVersion: batch/v1
kind: Job
metadata:
  name: example
  labels:
    first: first
    second: second

这没关系：

apiVersion: batch/v1
kind: Job
metadata:
  name: example
  labels:
    first: first
    second: second

但这应该避免：

apiVersion: batch/v1
kind: Job
metadata:
  name: example
  labels:
    first: first
    second: second

Resource Naming in Templates

将 name: 硬编码到资源中通常被认为是不好的做法。名称对于 release 应该是唯一的。因此，我们可能希望通过插入 release 名称来生成 name 字段，例如：

apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}-myservice

Or if there is only one resource of this kind then we could use .Release.Name or the template fullname function defined in _helpers.tpl (which uses release name):

或者，如果只有一个此类资源，那么可以使用 .Release.Name 或 _helpers.tpl（使用 release 名称）中定义的模板 fullname 函数：

apiVersion: v1
kind: Service
metadata:
  name: {{ template "fullname" . }}

尽快如此，可能还存在不会来自固定名称的命名冲突的情况。在这些情况下，固定名称可能使应用程序更容易找到诸如服务之类的资源。如果需要固定名称，那么一种可能的管理方法是通过使用 values.yaml 中的 service.name 值来显式设置名称（如果提供的话）:

apiVersion: v1
kind: Service
metadata:
  {{- if .Values.service.name }}
    name: {{ .Values.service.name }}
  {{- else }}
    name: {{ template "fullname" . }}
  {{- end }}

注释（YAML 注释与模板注释）

YAML 和头盔模板都有注释标记。

YAML 注释：

# This is a comment
type: sprocket

模板注释：

{{- /*
This is a comment.
*/ -}}
type: frobnitz

记录模板功能时应使用模板注释，如解释定义的模板：

{{- /*
mychart.shortname provides a 6 char truncated version of the release name.
*/ -}}
{{ define "mychart.shortname" -}}
{{ .Release.Name | trunc 6 }}
{{- end -}}

在模板内部，当 Helm 用户可能（有可能）在调试过程中看到注释时，可以使用 YAML 注释。

# This may cause problems if the value is more than 100Gi
memory: {{ .Values.maxMem | quote }}

上面的注释在用户运行 helm install --debug 时可见，而在 {{- /* */ -}} 部分中指定的注释不是。

在模板和模板输出中使用 JSON

YAML 是 JSON 的超集。在某些情况下，使用 JSON 语法可以比其他 YAML 表示更具可读性。

例如，这个 YAML 更接近表达列表的正常 YAML 方法：

arguments:
  - "--dirname"
  - "/foo"

但是，当折叠为 JSON 列表样式时，它更容易阅读：

arguments: ["--dirname", "/foo"]

使用 JSON 增加易读性是很好的。但是，不应该使用 JSON 语法来表示更复杂的构造。

在处理嵌入到YAML中的纯JSON时（例如init容器配置），使用JSON格式当然是合适的。