Helm Chart and Template Basics — Part 1

Image for post
Image for post

By Alwyn Botha, Alibaba Cloud Community Blog author.

App management is a challenging aspect of Kubernetes, and the Helm project greatly simplifies this by providing a uniform software packaging method which supports version control. Helm installs and manages packages (called charts in Helm) for Kubernetes, just as yum and apt do.

In this tutorial we are going to let Helm create a basic chart for us. This tutorial assumes you have at least a beginner understanding of what Helm is. If you are not familiar with it, I suggest you to go through this guide before proceeding with the article: https://www.alibabacloud.com/help/doc-detail/86511.htm

We will then gradually make changes to learn how the values file and the template parts work together.

It is easier to work with such a basic working chart, than starting from nothing.

From : https://docs.helm.sh/using_helm/

A Chart is a Helm package. It contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster.

Think of it like the Kubernetes equivalent of a Homebrew formula, an Apt dpkg, or a Yum RPM file

Create complete working chart directory structure

This creates a complete working chart with all its required files in the myhelm directory.

You will be exposed to some of these files throughout this tutorial — only when we need to learn about those specific files.

The purpose here is to use a chart as soon as possible to create a running instance. Then we investigate what the chart created and how it did it.

First up is the values.yaml file. It contains our default values for the Kubernetes objects we want to create.

Near the top we see it uses nginx. That is a 55 MB download. I prefer quick actions during tutorials by using busybox — a 650 KB download.

Original values.yaml

Change values.yaml at the top to use busybox as shown below. Note tag changes as well.

Next is the deployment.yaml file.

This is a deployment like any other you are used to use in Kubernetes. The major difference is that it gets most of its field values from the values file we just edited.

Edit your deployment.yaml file around line 27 … add the command. We are using the busybox image. If we create our Pods they will just exit immediately since there is no command or program running. The command let our busybox Pod sleep for 60 seconds.

( You can see in template extract below how values from values.yaml will be pulled in. We will get to the syntax — we focus on big picture for now. )

Now we are ready to let Helm install our edited chart.

Run helm install ./myhelm1/ and investigate the output.

Helm auto generates a release name for your: NAME: loopy-otter

Yours will be different. I hate those silly names. We will use our own names later.

We see a service, deployment and Pod got created.

Roughly speaking Helm read all the .yaml templates in the templates directory, then interpreted these templates by pulling in values from the values.yaml file.

The notes are for the original nginx application. It is totally wrong for our busybox application.

Those notes are from NOTES.txt, another template file.

A few seconds later we will see our Pod running.

The big-picture overview demo is done. Use helm delete to delete our first release.

From : https://docs.helm.sh/using_helm/

A Release is an instance of a chart running in a Kubernetes cluster.

helmignore NOTES.txt

Now edit the .helmignore file and add NOTES.txt to the bottom.

.helmignore contains a list of filenames and filename patterns we want Helm to ignore.

If you run the install again you will see those notes are no longer shown. ( Later we will use such notes, but here and now that file is of no use to us. )

Delete our test 1 release.

— dry-run — debug

We use — dry-run and — debug to investigate how Helm interprets our template and YAML files in our charts.

This way we do not pollute our Kubernetes node with several unneeded objects.

Let’s try it.

As you can see a release may exist only once.

Check the status of the release ( as they suggest )

We just deleted it.

To test debug we need another release name: we use test2:

Very helpful, but too much information if we want to repeatedly edit and install our chart.

Right now I will not attempt to digest it all, let us reduce the output first.

Under HOOKS there is a test connection. That was useful to test the original nginx. We do not need it.

Around 20 lines later we find # Source: myhelm1/templates/service.yaml … a kind: Service — we do not need that — we only want a running Pod.

Easy to fix, just edit .helmignore and add these 2 file names to the bottom.

Our busybox Pod does not need ports or livenessProbes.

Delete lines 29 to 42 from deployment.yaml

These labels below add no value to this tutorial therefore they are removed from the output from all helm install commands below.

Let’s redo our install.

Considerably shorter and worthy of explanation:

  • USER-SUPPLIED VALUES: we did not supply any, so nothing listed here. We will use this in a moment.
  • COMPUTED VALUES: Shows the calculated values from values.yaml This is shown alphabetically while our file is in random order.
  • HOOKS: not used in this beginner day 1 tutorial
  • At the bottom we see our deployment.yaml. It shows the template with the values pulled from the values.yaml file.

You can repeatedly make changes to your values and templates and test it via — dry-run — debug. It only shows what will happen, without doing it. Very useful: debug a helm install BEFORE it is done.

We are happy with our debug output, let us run the install.

As expected, a deployment and its Pod. A few seconds later the Pod is running.


Values in values.yaml replace their placeholders in the template files.

Template files can also get their values from the user. Users pass values to software they install via — set flag on the install command.

This part of the tutorial demonstrates passing an imagePullPolicy on the command line.

No edit needed, just observe the last line of values file extract below.

The default values file must be named values.yaml.

Now observe where in the template that gets used. ( Around line 22–25 )

.Values.image.pullPolicy gets the value from

  • the values.yaml file … .Values
  • the content of .image.pullPolicy

We used pullPolicy: IfNotPresent up till now in this tutorial. ( You may want to page up and see that is the case everywhere. )

Assume for this test run we do NOT want the image pulled from the repository. ( imagePullPolicy: Never )

From Kubernetes docs:

imagePullPolicy: Never: the image is assumed to exist locally. No attempt is made to pull the image.

See the dry run command below how we specify the policy via — set.

The USER-SUPPLIED VALUES seems correct: imagePullPolicy: Never

The COMPUTED VALUES: indicate we have a problem:

Our — set policy does not replace the image policy.

They have different names and are at different levels in the yaml.

In the deployment we see: imagePullPolicy: IfNotPresent : override not successful.

Let’s fix that: see attempt two below:

Nearly there but still wrong. We now have two policies spelled differently. ( Lowercase first letter is the correct one that appears in the value file ).

Convention states we should name our values starting with a lowercase letter. Our values.yaml is correct. Our command line override is wrong.

Third attempt, see command below.

The deployment above shows imagePullPolicy: Never … override a success.

COMPUTED VALUES show override is done correctly.

Debug output looks good. We are ready to install this release live.

I want to hide all the other values we do not need. We do this by commenting it out. Edit your values file so that only first 5 values and not commented out.

Let’s install our chart.

Values.ingress.enabled is used in myhelm1/templates/ingress.yaml

We do not need ingress — that is part of nginx chart we started with.

Add ingress.yaml at bottom of our ignore file.

Second attempt: install myhelm1 chart with image.pullPolicy=Never

plus we added — set replicaCount=3

— set replicaCount correctly overrides the value in deployment.yaml

Let’s do a live install.

Success. Deployment DESIRED is 3 and we see 3 Pods being created.

Seconds later we have 3 running Pods. Note the use of helm status command.

Demo complete. Delete our release test3.

Define our own new value

So far we have deleted values from values.yaml.

We also passed override values on the command line.

Now we create our own new value: terminationGracePeriodSeconds


Optional duration in seconds the pod needs to terminate gracefully. The grace period is the duration in seconds after the processes running in the pod are sent a termination signal and the time when the processes are forcibly halted with a kill signal. Set this value longer than the expected cleanup time for your process. Defaults to 30 seconds.

Add terminationGracePeriodSeconds: 30 to your values file so that your line 5–12 looks like below:

Edit your deployment file so that it uses this new value ( line 22 to 29 should be as below )

Do a dry run.

Success. COMPUTED VALUES: shows it correctly and deployment at bottom uses it correctly.

One more test: let us debug test override the terminationGracePeriodSeconds value with a 10.

Success. COMPUTED VALUES: shows 10 correctly and deployment at bottom uses 10 correctly.

We did not even look at _helpers.tpl or the charts directory. ( That deals with dependencies. That is a topic for another tutorial in this set. )

We made several changes to our values file as well as the deployment file and saw its results via debug and via live install commands.

You are also able to hide irrelevant files from a chart. ( .helmignore )

At work you will create your own skeleton basic charts that you copy from. Obviously it will start off MUCH more perfectly in line with exactly what you want to do.

We learned basic Helm concepts on day one by hacking a nginx chart to our requirements. — dry-run — debug is Helm’s best feature: dry run and debug before install.

Original Source

Written by

Follow me to keep abreast with the latest technology news, industry insights, and developer trends.

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