In the Kubernetes world, Helm umbrella charts allow the provisioning of sub-charts through the parent-child mechanism. A child chart placed in the the charts folder in Helm can be deployed by declaring the sub-chart in the parent’s Charts.yaml file. One neat feature of Helm is the ability to push values from parent (umbrella) charts down to sub-charts by making use of global variables as shown below.

global:
  foo: bar

By specifying the global variable, sub-charts can now reference the global value in the parent’s values.yaml file as follows.

{{- if .Values.global.foo }}
  key1: {{ .Values.global.foo }}
{{- else }}
  key1: {{ .Values.foo }}
{{- end }}

This achieves what we want. If the foo global variable is declared in the parent chart, the sub chart will use its value, effectively overriding the value in its own values.yaml file. Problem solved! Not quite…it turns out that attempting to deploy just the child chart causes problems when doing this as the templating engine attempts to resolve all variables from the sub-charts values.yaml file. Since the global variable doesn’t exist you get something along these lines:

[bash]: helm lint .
[ERROR] templates/: render error in "myproject/templates/deployment.yaml": template: 
myproject/templates/deployment.yaml:8:40: executing "myproject/templates/deployment.yaml" at
 <.Values.global.foo>: can't evaluate field namespace in type interface {}

Seemingly, there is no way around this and common answers online point out that you must pass in the parent’s values file when running helm, thereby passing the global variables into the sub chart and allowing it to run. This is, however, not an optimal solution. All is not lost, I found out that this can solved by simply omitting the variable name itself.

{{- if .Values.global }}
  key1: {{ .Values.global.foo }}
{{- else }}
  key1: {{ .Values.foo }}
{{- end }}

The templating engine will evaluate the IF -statement first. Since the global variable is not found, the internal scope is not evaluated and linting completes successfully. In the case above, the local values.yaml file will be used. It seems like the templating engine will throw an error if two subsequent parts of the variable are not found, or perhaps it’s because the global variable type is a reserved keyword. Either way, I’m glad it worked for our project!

Simple fix when I look back, but sometimes the simplest solutions are the hardest to find.

Read on Medium.com