Values Files

    • The values.yaml file in the chart
    • If this is a subchart, the values.yaml file of a parent chart
    • A values file is passed into helm install or helm upgrade with the -f flag (helm install -f myvals.yaml ./mychart)
    • Individual parameters passed with --set (such as helm install --set foo=bar ./mychart)

    The list above is in order of specificity: values.yaml is the default, which can be overridden by a parent chart’s values.yaml, which can in turn be overridden by a user-supplied values file, which can in turn be overridden by --set parameters.

    Values files are plain YAML files. Let’s edit mychart/values.yaml and then edit our ConfigMap template.

    Removing the defaults in values.yaml, we’ll set just one parameter:

    Now we can use this inside of a template:

    1. apiVersion: v1
    2. kind: ConfigMap
    3. metadata:
    4.   name: {{ .Release.Name }}-configmap
    5. data:
    6.   myvalue: "Hello World"
    7.   drink: {{ .Values.favoriteDrink }}

    Let’s see how this renders.

    1. $ helm install --dry-run --debug ./mychart
    3. CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart
    4. TARGET NAMESPACE:   default
    5. CHART:  mychart 0.1.0
    6. MANIFEST:
    7. ---
    8. # Source: mychart/templates/configmap.yaml
    9. apiVersion: v1
    10. kind: ConfigMap
    11. metadata:
    12.   name: geared-marsupi-configmap
    13. data:
    14.   myvalue: "Hello World"
    15.   drink: coffee

    Because favoriteDrink is set in the default values.yaml file to coffee, that’s the value displayed in the template. We can easily override that by adding a --set flag in our call to helm install:

    Since --set has a higher precedence than the default values.yaml file, our template generates drink: slurm.

    Values files can contain more structured content, too. For example, we could create a favorite section in our values.yaml file, and then add several keys there:

    2.   drink: coffee
    3.   food: pizza
    1. kind: ConfigMap
    2. metadata:
    3.   name: {{ .Release.Name }}-configmap
    4. data:
    5.   myvalue: "Hello World"
    6.   drink: {{ .Values.favorite.drink }}
    7.   food: {{ .Values.favorite.food }}

    While structuring data this way is possible, the recommendation is that you keep your values trees shallow, favoring flatness. When we look at assigning values to subcharts, we’ll see how values are named using a tree structure.

    If you need to delete a key from the default values, you may override the value of the key to be null, in which case Helm will remove the key from the overridden values merge.

    For example, the stable Drupal chart allows configuring the liveness probe, in case you configure a custom image. Here are the default values:

    If you try to override the livenessProbe handler to exec instead of httpGet using --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt], Helm will coalesce the default and overridden keys together, resulting in the following YAML:

    1. livenessProbe:
    2.   httpGet:
    3.     path: /user/login
    4.     port: http
    5.   exec:
    6.     command:
    7.     - cat
    8.     - docroot/CHANGELOG.txt

    At this point, we’ve seen several built-in objects, and used them to inject information into a template. Now we will take a look at another aspect of the template engine: functions and pipelines.