Introduction 💡

Helm is widely known as "the package manager for Kubernetes".
Helm Charts help you define, install, and upgrade even the most complex Kubernetes application. Charts are easy to create, version, share, and publish — so start using Helm and stop the copy-and-paste. It is a CNCF Project.
Consider it the same as apt, homebrew, or pacman of some popular OS.

The Purpose of Helm ✨

Helm is a tool for managing Kubernetes packages called charts. Helm can create new charts from scratch, interact with chart repositories where charts are stored, and most importantly install and uninstall charts into an existing Kubernetes cluster.

For Helm, there are three important concepts:

The chart is a bundle of information necessary to create an instance of a Kubernetes application.
The config contains configuration information that can be merged into a packaged chart to create a releasable object.
A release is a running instance of a chart, combined with a specific config.

Components ⚙️

Helm is an executable that is implemented into two distinct parts:

Helm Client is a command-line client for end users. The client is responsible for the local chart development, managing repositories, and more.
Helm Library provides the logic for executing all Helm operations. It interfaces with the Kubernetes API server and provides installing charts into Kubernetes, providing the subsequent release object, and upgrading and uninstalling charts by interacting with Kubernetes.

The Helm client and library are written in the Go programming language.
The library uses the Kubernetes client library to communicate with Kubernetes. Currently, that library uses REST+JSON. It stores information in Secrets located inside Kubernetes. It does not need its database. Configuration files are, when possible, written in YAML.

Hatching the Helm chart 🐣

Say I want to build a Helm chart for a project called CircuitVerse

1. Create the Helm Chart

Open the directory in your terminal and command:

helm create

This creates a scaffold with sample files that you can modify to build your custom chart. This command generates a couple of files in the folder.

The folder will start to look like this in structure:

2. Updating the Values for our Project

This file declares variables to be passed into the templates. We will modify the file to include our Docker image hosted on our Container registry, tag, service name, ports, type, database values, and other parameters as per requirement.
Set up the pullPolicy for the chart. There are three possible values for the pullPolicy:

Always – Pulls the image on every restart or deployment.
Latest – Pulls the most up-to-date version available.
IfNotPresent – Downloads a new version of the image if one does not exist in the cluster. If a user of your chart wanted to change the default configuration, they could provide overrides directly on the command line.

A sample of the values.yaml:

3. Setting up the Template file

The most important piece of the puzzle is the templates/directory. This is where Helm finds the YAML definitions for your Services, Deployments, and other Kubernetes objects. This file contains the instructions to launch the application container. We will update the values as per requirements.
Now, our Helm chart has its values and the right configs in the service.yaml we can test the chart locally on minikube or kind cluster. We will use the command:

helm install <full name override> <chart name>/ --values <chart name>/values.yaml

4. Publishing the Helm chart

Now, that the helm chart is working and tested on our local cluster we can move forward to publishing it. Publishing it will help any developer to install CircuitVerse on any Kubernetes cluster without much hassle. This will also help in the automation of installing updates and upgrading as per releases or need.

References 📚

I will add links to most of the topics in case you want to read more about them:

Helm Documentation: Here
How to make Helm Charts: Here

Thanks for reading my article :)

Hatching a Helm Chart

Prerequisites ✅