Helm Chart values.yaml
External
Internal
Overview
A file that contains the default configuration values for a chart. The file is mandatory. The content of this file can be displayed with the helm show values command. The values specified in this file can be accessed in templates as part of the Values template object. Note that the effective value applied to a template is the result of overlaying this value.yaml file with values coming from other sources.
Syntax
value.yaml contains YAML-structured configuration data, where YAML path are referred to as field names.
Field Names and Dashes
⚠️ Field names, or in case of structured configuration, constituent elements of field names, may not contain dashes, even if YAML format allows that.
A field name that contains dashes may not be read from a template in a straightforward way. For example, configuration expressed as:
district:
sub-division: north
may not be rendered in a straightforward way in a template, as:
data:
value: {{ .Values.district.sub-division }}
fails when rendered:
Error: parse error at (simplest/templates/configmap.yaml:6): bad character U+002D '-'
There is an inelegant workaround, though:
data:
value: {{ index .Values "district" "sub-division" }}
values.yaml Best Practices
Variable name should begin with a lowercase letter, and words should be separated with camelcase. All of Helm’s built-in variables begin with an uppercase letter to easily distinguish them from user-defined values.
All string values should be quoted, everything else should use implicit type conversion. Also see YAML Data Types.
Values specified in this file can be potentially overridden by values specified with --set, so it is a good idea to come up with variable names that can be easily overridden this way. For example:
servers: first: port: 80
if preferable to:
servers: - name: first port: 80
because in the first case the override is:
--set servers.first.port=81
while in the second case is:
--set servers[0].port=81
which is sensitive to the potential change in order.
Every defined property should be documented. The documentation string should begin with the name of the property that it describes, and then give at least one sentence description. Beginning each comment with the name of the parameter it documents makes it easy to grep out documentation, and will enable documentation tools to reliably correlate doc strings with the parameters they describe:
# serverHost is the host name for the webserver serverHost: "example"
Example
imageRegistry: "quai.io/something" dockerTag: "latest" pullPolicy: "always" storage: "s3"
Organizatorium
TO PROCESS: