Values
This part of the best practices guide covers using values. In this part of theguide, we provide recommendations on how you should structure and use yourvalues, with focus on designing a chart’s values.yaml
file.
Naming Conventions
Variables names should begin with a lowercase letter, and words should beseparated with camelcase:
Correct:
chicken: true
chickenNoodleSoup: true
Incorrect:
Chicken: true # initial caps may conflict with built-ins
chicken-noodle-soup: true # do not use hyphens in the name
Note that all of Helm’s built-in variables begin with an uppercase letter toeasily distinguish them from user-defined values: .Release.Name
,.Capabilities.KubeVersion
.
Flat or Nested Values
YAML is a flexible format, and values may be nested deeply or flattened.
Nested:
server:
name: nginx
port: 80
Flat:
serverName: nginx
serverPort: 80
In most cases, flat should be favored over nested. The reason for this is thatit is simpler for template developers and users.
For optimal safety, a nested value must be checked at every level:
{{ if .Values.server }}
{{ default "none" .Values.server.name }}
{{ end }}
For every layer of nesting, an existence check must be done. But for flatconfiguration, such checks can be skipped, making the template easier to readand use.
{{ default "none" .Values.serverName }}
When there are a large number of related variables, and at least one of them isnon-optional, nested values may be used to improve readability.
Make Types Clear
YAML’s type coercion rules are sometimes counterintuitive. For example, foo:false
is not the same as foo: "false"
. Large integers like foo: 12345678
will get converted to scientific notation in some cases.
The easiest way to avoid type conversion errors is to be explicit about strings,and implicit about everything else. Or, in short, quote all strings.
Often, to avoid the integer casting issues, it is advantageous to store yourintegers as strings as well, and use {{ int $value }}
in the template toconvert from a string back to an integer.
In most cases, explicit type tags are respected, so foo: !!string 1234
shouldtreat 1234
as a string. However, the YAML parser consumes tags, so the typedata is lost after one parse.
Consider How Users Will Use Your Values
There are three potential sources of values:
- A chart’s
values.yaml
file - A values file supplied by
helm install -f
orhelm upgrade -f
- The values passed to a
—set
or—set-string
flag onhelm install
orhelm upgrade
When designing the structure of your values, keep in mind that users of yourchart may want to override them via either the-f
flag or with the—set
option.
Since —set
is more limited in expressiveness, the first guidelines forwriting your values.yaml
file is make it easy to override from —set
.
For this reason, it’s often better to structure your values file using maps.
Difficult to use with —set
:
servers:
- name: foo
port: 80
- name: bar
port: 81
The above cannot be expressed with —set
in Helm <=2.4
. In Helm 2.5, theaccessing the port on foo is —set servers[0].port=80
. Not only is it harderfor the user to figure out, but it is prone to errors if at some later time theorder of the servers
is changed.
Easy to use:
servers:
foo:
port: 80
bar:
port: 81
Accessing foo’s port is much more obvious: —set servers.foo.port=80
.
Document values.yaml
Every defined property in values.yaml
should be documented. The documentationstring should begin with the name of the property that it describes, and thengive at least a one-sentence description.
Incorrect:
# the host name for the webserver
serverHost: example
serverPort: 9191
Correct:
# serverHost is the host name for the webserver
serverHost: example
# serverPort is the HTTP listener port for the webserver
serverPort: 9191
Beginning each comment with the name of the parameter it documents makes it easyto grep out documentation, and will enable documentation tools to reliablycorrelate doc strings with the parameters they describe.