Diving into HELM: My Exciting First Venture into Chart Crafting!

Pradyuman
Debugging Diaries
Published in
4 min readJan 12, 2024

Introduction

I am a newbie to Kubernetes deployment and a firm believer in learning hands-on. Although there are a lot of drawbacks to this, like slow development, deadline pressure, and sometimes self-doubt, But learning speed becomes really high with this technique.

So continuing with this approach, I took up the task of creating a helm chart for one of our projects.

Understanding HELM

Before we begin, it’s really important that we thoroughly understand what Helm is. In simple words, Helm is the package manager for Kubernetes. Like other package managers, for example, apt for Debian-based packages and yum for RPM-based packages, It was designed to easily find, share, and use packages made for Kubernetes.

Like we have packages for apt and yum, we have Helm charts for Helm.

Getting Started

Helm charts can be created easily, but here are some prerequisites for the same.

  1. helm installed on your system.
  2. Manifest files for the package that you want to convert to Helm (Not mandatory, but good to have.)
  3. Basic understanding of resources in K8s

Crafting Your First HELM Chart

Now that we have a fair understanding of what helm is, let’s dive into creating our own helm chart.

  • The first step is to install Helm on our machine. I had Brew installed on my system, so I used that; otherwise, you can refer to these documents for other installation methods.
brew install helm
  • Now that we have Helm installed on our system, we need to create this Helm repo structure.
helm create <helm-chart-name>
  • You will get a folder structure like this. We will not go into the depths of each file in this article.
example/
├── charts # Charts that this chart depends on
├── Chart.yaml # Information about your chart
├── templates # The template files
│ ├── deployment.yaml
│ ├── _helpers.tpl # Keeps common config for complete manifest
│ ├── hpa.yaml
│ ├── ingress.yaml
│ ├── NOTES.txt
│ ├── serviceaccount.yaml
│ ├── service.yaml
│ └── tests # The test files
│ └── test-connection.yaml
└── values.yaml # The default values for your templates
  • If you already have a manifest file for your project, it would be really helpful in this step. Now that we start writing templates into our helm chart, you can directly copy your manifest and save it in templates.
# pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
  • In this example, we can move a few parameters to the values.yaml file. After moving them to our files, they would look like this:.
# pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: {{ .Values.pod.name }}
spec:
containers:
- name: {{ .Values.container.name }}
image: {{ .Values.container.image.name }}:{{ .Values.container.container.version }}
ports:
- containerPort: {{ .Values.container.httpPort }}
# values.yaml
container:
name: nginx
httpPort: 80
image:
name: nginx
version: 1.14.2

And you have your helm chart ready. You can test this helm locally by running the following command:

helm install <folder_path> <helm_chart_name>

Deploying Your HELM Chart

Now that I had created the helm chart, I wanted to publish it on GitHub so that users could use it. To do that, we follow these steps:

  • We first create a helm package.
helm package example/
  • We need a new file named index.yaml to host our helm chart on GitHub. We can create it using the following command:
helm repo index example/
  • Create a GitHub repo and clone it locally. The repo structure should look something like this:
example.github.io
├── example
│ ├── charts
│ ├── Chart.yaml
│ ├── templates
│ │ ├── _helpers.tpl
│ │ ├── pods.yaml
│ │ └── tests
│ │ └── test-connection.yaml
│ └── values.yaml
├── example-0.1.0.tgz
└── index.yaml
  • Push these changes to GitHub and host them on GitHub pages. Once the GitHub pages are ready, you can use your helm chart on the helm client:
helm repo add example https://example.github.io

helm install example

Lessons Learned and Tips

It always seems impossible until it’s done. — Nelson Mandela

When I was given this task, I was not really confident if I would be able to do it or not. It was feeling like a really big hurdle in my way. But once I started working on it, it became easier and easier.

Conclusion

Now that I have conquered one more conclave I feel really confident in learning and exploring things that I have never learned about. Seems like my approach of learning through hands on is working really well. See you in another article with some new learning.

Additional Resources

--

--

Pradyuman
Debugging Diaries

Architect of Insight: A Devotee to the Art of Observability | Building Next-Gen Observability Solutions @ CtrlB 🔍