Kubernetes and Helm: Create Your Own Helm Chart

Jonathan Campos
Aug 28, 2018 · 7 min read

You ever have a technology block in your head? There is just some piece of technology that your brain doesn’t want to let you understand? I felt this way with creating my own Helm Chart. Prior to creating my own Helm Chart I had made many Kubernetes YAML files to describe my own Kubernetes Clusters. Furthermore, I had been using Helm to incorporate other Helm Charts into my Kubernetes Clusters.

“Lines and sails on a yacht sailing on a lake” by Ian Keefe on Unsplash

However, for whatever reason, I just couldn’t mentally put together my own Helm Chart. Then, like how most things get accomplished, I decided that I should just do it. A few minutes later, I had a working Helm Chart. Really, it only took a few minutes. It was easy. The mental block was gone and I was able to start creating Helm Charts left and right. And you can too. In this article we are going to look at how to create your own Helm Chart for your Kubernetes Cluster.

If you haven’t gone through or even read the first part of this series you might be lost, have questions where the code is, or what was done previously. Remember this assumes you’re using GCP and GKE. I will always provide the code and how to test the code is working as intended.

Install The Helm Command Line Tool

If you’re trying to install Helm (and Tiller) into your Kubernetes Cluster… this isn’t the article right now — you should check out my other articles on just that topic.

What you need to do now is install the Helm Command Line Tool onto your development environment.

Luckily the Helm Github documents provides a good walkthrough for you. This should be super easy for you and take just a few minutes. You can see the link to the download information here.

For my own environment I simply ran the following command to include Helm into my computer:

$ brew install kubernetes-helm

After a moment Helm will be installed and you’ll be good to go.

Run Helm Create

With Helm’s Command Line Tool installed on your compute we can get to work. First, go to your wonderful Kubernetes ready service that you need to turn into a Helm Chart. I have need a microservice to play with in my repo if you need one.

With your service ready you just need to go to the directory and run the helm create command.

$ cd /to/your/folder
$ helm create endpoints
# endpoints is the name of your chart

This will create a Helm Chart setup that you will need to edit into your perfect Helm Chart.

The Basic Helm Chart Folder Structure

Next we will go into editing the deployment.yaml and service.yaml files.

Note: If you change the name of your Chart in the yaml files then you will need to update the folder name for your Chart to match the new name. I know because I wanted the folder to be named helm/ and the build step complained about the difference in name.

Start With Your Basic Kubernetes YAML File

Do you have working Kubernetes YAML files? Do you want to just use those files? Great! We can do just that. The easiest, most basic Chart is just your original Kubernetes YAML files. We can just copy over the deployment.yaml and service.yaml files without any editing and you’re done. You don’t even have to read about putting templates and variables in your Charts.

Just A Basic Copy/Replace Of The deployment.yaml And service.yaml Files

Obviously you’ll want to go further than this though. The variables are what make this effort worthwhile.

Customize With Template Variables

If you looked at the generated deployment.yaml and service.yaml files you would see a lot of the following code.

apiVersion: apps/v1beta2
kind: Deployment # it is a deployment
name: {{ template “chart.fullname” . }} # name of the Deployment
# any Pods with matching labels are included in this Deployment
app: {{ template “chart.name” . }}
chart: {{ template “chart.chart” . }}
release: {{ .Release.Name }}
heritage: {{ .Release.Service }}
# ReplicaSet specification
replicas: {{ .Values.replicaCount }} # we are making 3 Pods

These are values that are inserted when the Helm Chart is installed. This helps you customize the Chart to your liking by injecting new values or providing a custom values.yaml. Speaking of values.yaml, it is important that we look at where all of these values come from for our template.

There are three types of variables I’ve highlighted in the above snippet.

{{ template “chart.fullname” . }} # values from Chart.yaml 
{{ .Release.Name }} # built in Release object
{{ .Values.replicaCount }} # value from values.yaml

You can edit the “chart.____” values in the Chart.yaml file. You can add your own values into the values.yaml to effect .Values._____ values. The .Release.______ values are based on the built-in Release object.

There are more built-in types that I haven’t touched on along with some cool templating features to checkout.

By editing the values you can eventually get to a good custom template that has all the right values and can do all the things you need.

Best Practices

The Helm Documentation has a really well written Best Practices section that includes many finer points than I will include here. My one piece of advise: Move as many variables out of your template and into the values.yaml file. This way you can easily update and inject new values at install-time. You’ll see how to do that next.

Install Your Helm Chart

Now we are ready to install our endpoints Helm Chart onto any Kubernetes Cluster. Right now we are going to look at running this install locally from your bash environment. You could also run the install from a published Helm Chart.

Let’s say you have an installable Helm Chart ready, we can install it into our active Kubernetes Cluster with the following command.

$ helm install --name endpoints path/to/chart/endpoints

This will install the Helm Chart using all of the defaults built into the Chart. What if we wanted to change a single value in the values.yaml file? We can do that easily with the set command.

$ helm install --name endpoints path/to/chart/endpoints \
--set image.project=my-project

Changed. This is why you put all of your variables into the values.yaml file.

Want to see output before it is installed to ensure things look correct? Try the following command.

$ helm install --name endpoints path/to/chart/endpoints \
--set image.project=my-project \
--dry-run --debug

By adding the dry-run and debug flags I’ve stopped the Helm Chart from installing and viewed the output.

Make A Private Helm Repo For Your Organization

I was going to write-up an entire section on how to create a private Helm Repo — because not everything can be public. But I really don’t see a point. It is important, but there is already an wonderfully written article with this exact information. Feel free to read it here.


Hopefully all this helped and I am definitely getting to the end of “generic” Helm information that isn’t very specific to the needs of a deployment. I highly recommend creating Charts when necessary as they help harden your development practices and make your Kubernetes deployments much more reusable.

Other Posts In This Series

Questions? Feedback? I’m very interested to hear what issues you might run across or if this helped you understand a bit better. If there is something I missed feel free to share that too. We are all in this together!

Jonathan Campos is an avid developer and fan of learning new things. I believe that we should always keep learning and growing and failing. I am always a supporter of the development community and always willing to help. So if you have questions or comments on this story please ad them below. Connect with me on LinkedIn or Twitter and mention this story.

Google Cloud - Community

Google Cloud community articles and blogs

Google Cloud - Community

A collection of technical articles and blogs published or curated by Google Cloud Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

Jonathan Campos

Written by

Excited developer and lover of pizza. CTO at Alto. Google Developer Expert.

Google Cloud - Community

A collection of technical articles and blogs published or curated by Google Cloud Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store