Helm: Child chart to Parent chart data exchange

Asish M Madhu
FAUN — Developer Community 🐾
3 min readJun 18, 2021

--

“Behind every young child who believes in self, is a parent who believed first.” — Mathew Jacobson

Photo Credit: Derek Thomson | https://unsplash.com/photos/M1jCmRxO7cY

Helm helps you manage and organise your applications in Kubernetes. You can group the kubernetes objects for your applications, like deployment, services, ingress etc as a helm chart and package them and distribute them. You get complete control and flexibility through its templating engine, that these artifacts can be hosted in git repositories and version controlled. This is the default choice when you progress to gitops model for continuous deployment of your applications.

But as your application grows, there will be a lot of dependent applications and you might want to define these dependencies as parent child charts. Your main project application consists of many k8s artifacts and the dependent artifacts. In this article, I am trying to relate the main chart and its dependent subcharts as parent and child charts and explain a simple and not so used dimension in exchanging values from child chart to parent chart.

In helm the parent chart overrides values in child charts. For this in Chart.yaml, we override the values for each child chart by having a section with the name of the subchart. We can also use global property which becomes accesible to all child charts and can be accessed easily in both.

global:
my_global_var: "value"

This is accessed as {{ . Values.global.my_global_var }} across all parent and child charts. Thus the values defined in the parent chart takes precedence over values defined in child chart.

There will be situation, where we might need to pass variables from child chart to parent chart. This means the child's values override the parents' values. This is a rare situation, but often good to know about this feature in helm. “Let the child's words be heard.”

There are 2 ways to make the childs value available to the parent.

Using exports

Use an exports property in the sub chart (child chart) values.yaml as below

exports:
data:
db_url:
username: admin
url: <http://myurl>

Then in the parent Chart.yaml (or requirements.yaml for helm2) ,under dependencies section, in the block corresponding to the subchart, use a field “import-values” as below:

dependencies:
- name: child1
verison: 1.1.0
repository: http://reponame
import-values:
- data

Now this child chart data can be accessed in the parent chart templates

{{ .Values.db_url.url }}

This technique has some limitations, like the values of the child chart should be defined under a export property. There is also a possibility of named conflicts, it is used in multiple child charts. There is other way to achieve this.

Using child parent mapping

Here for the section corresponding to the child chart under dependencies section in Chart.yaml, add a “import-values” section with two subproperties. A child property with the name of the child property that has to be exported and the parent property containing the name of the parent property mapped to the child property.

Chart.yaml (parent chart)

dependencies:
- name: child1
version: 1.1.0
repository: http://myrepo
import-values:
- child: data
parent: child1_data

values.yaml (child chart)

data:
remote_location:
ip: 10.1.1.1
user: admin

values.yaml (parent chart)

child1_data:
remote_location:
ip: 1.1.1.1
user: user1

This data can be accessed in the parent chart as

{{ .Values.child1_data.remote_location.ip }}

Conclusion

These techniques are rarely used normally in helm charts. We can use global variables in parent chart, which becomes available to all subcharts. But the flexibility of helm gives users the power to go beyond normal. Thanks for the read !!!

Join FAUN: Website 💻|Podcast 🎙️|Twitter 🐦|Facebook 👥|Instagram 📷|Facebook Group 🗣️|Linkedin Group 💬| Slack 📱|Cloud Native News 📰|More.

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇

--

--

I enjoy exploring various opensource tools/technologies/ideas related to CloudComputing, DevOps, SRE and share my experience, understanding on the subject.