When deploying multiple resources to Kubernetes, it is often challenging to keep track of all the resources, image tags, and environment variables distributed across multiple manifest files. To address this issue, manifest templating tools such as Kustomize and Helm exist, simplifying large, complex manifest files to templates with customization available through values.yaml. This provides flexibility with a single template across multiple environments (e.g., QA, staging, production), with changes configured via the values.yaml file. Additionally, it offers ease-of-use for end-users to deploy into any new environment with just a single command. However, solving one set of problems often introduces new challenges. Creating individual Helm charts can become difficult to manage as applications increase. It becomes essential to track changes across all Helm charts used by an organization, consuming significant engineering hours. Using community charts poses the challenge of pulling and customizing new charts, maintaining separate copies in the Helm repository, and consuming considerable time to pull and run these charts. Just as we've created a Helm chart for each application, bundling all required resources into a single chart, it would be advantageous to bundle all these micro-services into a single chart. Kubernetes Introducing Helm Sub-charts: Helm sub-charts are like mini-charts residing inside a larger Helm chart, akin to different players in your favorite video game. It's Helm's way of implementing inheritance. Charts can have dependencies, called , each with its values and templates. subcharts Why Do We Need Sub-charts? Sub-charts help break down large applications into more manageable parts, akin to splitting your favorite game into different levels. Breaking Down Big Stuff: Sub-charts can be reused in different projects, similar to using a favorite weapon or skill in various game levels. Reuse the Good Stuff: Sub-charts enable working on different parts of an app without accidentally affecting other parts, similar to cooking different dishes in separate pots. Keeping Things Separate: Things to Consider When Creating Helm Sub-charts: Before creating sub-charts, consider the following: A sub-chart is considered "stand-alone," meaning it can never explicitly depend on its parent chart. Consequently, a sub-chart cannot access the values of its parent, but a parent chart can override values for sub-charts. Helm sub-charts work well when the charts you want to deploy are used in combination with each other but are not directly dependent on each other's resources. Helm sub-charts work well when the charts you want to deploy are used in combination with each other but are not directly dependent on each other's resources. When a Helm chart has multiple Helm sub-charts, specifying the specific order can be challenging. Let's Build Some Helm Sub-charts: To create a master Helm with sub-charts, consider a master Helm chart example deploying Nginx and PostgreSQL. The folder structure is as follows: To create Helm sub-charts within the master Helm chart, add the following to the values.yaml file, describing the name of the Helm charts along with their versions and repositories. apiVersion: v2
name: my-master-chart
description: A Helm chart to deploy Nginx and PostgreSQL
version: 0.1.0
dependencies:
  - name: nginx
    version: 15.4.3
    repository: https://charts.bitnami.com/bitnami
  - name: postgresql
    version: 13.2.16
    repository: https://charts.bitnami.com/bitnami After adding the above to the values, run the following command to pull and add these dependencies to the charts folder. helm dependency update Once pulled, the folder structure should have .tgz files in the charts folder. To untar the .tgz file, use the command: tar -zxvf nginx-15.4.3.tgz After extraction, your file structure would resemble the one below: Just as we can manipulate inputs from the values file in individual Helm charts, we can use the global values.yaml file to manipulate the values of each of these Helm charts. By doing so, we can use the base Helm charts as templates and make all modifications from the global values.yaml file. This reduces complexity and simplifies the management of different input values in various Helm charts. Consider the following example to illustrate the use case. The values for Nginx mention the image tag, and PostgreSQL mentions the image tag along with the port number at which the PostgreSQL deployment runs. Here are the default values passed in the Nginx and PostgreSQL values.yaml files: Now, change the values in the master values.yaml file at the top level. Change the Nginx image from to and the PostgreSQL image from to . Also, change the PostgreSQL default port from to . 1.25.3-debian-11-r1 1.24.0-debian-11-r153 16.1.0-debian-11-r9 15.5.0-debian-11-r9 5432 5111 The values for both Nginx and images have changed, and the PostgreSQL port has been updated. PostgreSQL Liked my content? Feel free to reach out to my for interesting content and productive discussions. LinkedIn

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Helm Sub-Charts Demystified: A Guide to Efficient Deployments

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Building a Custom Homebrew Formula: A Case on tfblueprintgen

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

Building a Custom Homebrew Formula: A Case on tfblueprintgen

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps