Deploying Kubernetes Applications with Helm

I recently completed a webinar on deploying Kubernetes applications with Helm. The webinar is the first of a two-part series on the Kubernetes ecosystem. It builds on the two introductory Kubernetes webinars that we hosted earlier this year: Hands on Kubernetes and Ecosystem & Production Operations.
In this post, I’ll be recapping this week’s webinar on Kubernetes and Helm.

What is Helm?

Helm is a package manager for Kubernetes applications. Helm packages all of the different Kubernetes resources (such as deployments, services, and ingress) into a chart, which may be hosted in a repository. Users can pull down charts and install them on any number of Kubernetes clusters. Helm’s approach scales from monoliths to complex micro service applications. Here are some of Helm’s main features:

  • Find and use popular software packaged as Kubernetes charts
  • Distribute your own applications (either private or FOSS)
  • A defined structure for managing Kubernetes resource manifests
  • Preconfigured installations
  • Parameterized installations by overriding defaults
  • Automatic revision history for all releases
  • Seamless upgrades and rollbacks between chart versions
  • Hooks for chart authors to manage the life cycle
  • Support for running tests after installing a chart

If you’ve used a package manager like apt, yum, brew, or portage before, you will be familiar with these features. Helm recently graduated from the Kubernetes incubator, which gives it more official standing in the Kubernetes community.
Helm itself uses a client-server model. The helm command (the client) talks to the tiller  (the server). The Helm client may interact with any number of different tiller services. In practice, there is a single tiller service running one Kubernetes cluster. This helps teams collaborate. It also means that Helm may run anywhere, such as on your CI servers or on your own computer. Tiller does the work to coordinate with Kubernetes and get the chart installed.
Installed charts are called “releases” because they may be installed multiple times. Consider a chart for something like Redis. You may need to install the Redis chart twice, each for different applications, as well as with different values. Let’s see how this works by going through the common workflow for chart authors and users.

Deploying Kubernetes Applications with Helm: Workflow

Let’s assume that most Helm users are chart authors rather than chart consumers. This is a bit different compared to how we tend to interact with our package managers. We may use brew or apt hundreds of times, but how many of us have actually created a brew or deb package? I’m guessing the answer is not much. Odds are, you’ll be a chart author and consumer since Helm targets engineers/teams looking to deploy their applications. To do this, you need to create a chart. To get started, you will need to initialize your cluster:

helm init

This command creates your ~/.helm  and deploys (via a Kubernetes Deployment ) tiller  to your Kubernetes cluster. Now, you’re ready to author and install charts. Helm automatically adds the stable charts repository. The charts repository contains “official” charts for various applications. It’s one of the most activated repositories on the Kubernetes github, and it’s an excellent reference for chart authors. You can use helm search to see what charts are available in the configure repositories. Naturally, you may create your own repository for your team’s charts.
Here is a snippet for charts that is available out of the box:

$ helm search
NAME                	VERSION	DESCRIPTION
local/demo          	0.1.1  	A Helm chart for Kubernetes
stable/datadog      	0.1.0  	DataDog Agent
stable/drupal       	0.3.8  	One of the most versatile open source content m...
stable/etcd-operator	0.1.0  	CoreOS etcd-operator Helm chart for Kubernetes
stable/factorio     	0.1.2  	Factorio dedicated server.
stable/ghost        	0.4.0  	A simple, powerful publishing platform that all...
stable/jenkins      	0.1.4  	A Jenkins Helm chart for Kubernetes.
stable/joomla       	0.4.0  	PHP content management system (CMS) for publish...
stable/mariadb      	0.5.4  	Chart for MariaDB
stable/mediawiki    	0.4.0  	Extremely powerful, scalable software and a fea...
stable/memcached    	0.4.0  	Chart for Memcached
stable/minecraft    	0.1.0  	Minecraft server
stable/mongodb      	0.4.0  	Chart for MongoDB
stable/mysql        	0.2.1  	Chart for MySQL
stable/owncloud     	0.4.0  	A file sharing server that puts the control and...
stable/phpbb        	0.4.0  	Community forum that supports the notion of use...
stable/postgresql   	0.2.1  	Chart for PostgreSQL
stable/prometheus   	1.3.1  	A Prometheus Helm chart for Kubernetes. Prometh...
stable/rabbitmq     	0.4.0  	Open source message broker software that implem...
stable/redis        	0.4.1  	Chart for Redis
stable/redmine      	0.3.5  	A flexible project management web application.
stable/spark        	0.1.1  	A Apache Spark Helm chart for Kubernetes. Apach...
stable/spartakus    	1.0.0  	A Spartakus Helm chart for Kubernetes. Spartaku...
stable/testlink     	0.4.0  	Web-based test management system that facilitat...
stable/traefik      	1.1.1-a	A Traefik based Kubernetes ingress controller w...
stable/uchiwa       	0.1.0  	Dashboard for the Sensu monitoring framework
stable/wordpress    	0.3.2  	Web publishing platform for building blogs and ...

Let’s say that we wanted to install the Redis chart. We can do this via helm install . Here are some examples:

$ helm install redis                     # Install the redis chart with an auto-generated release name
$ helm install --name appa redis         # Install the redis chart using a specified release name
$ helm install --set image=redis:2 redis # Override the default values (--set may be specified many times)
$ helm install -f custom.yml redis       # Override default values specified in a file
$ helm install --wait redis              # Wait for all Kubernetes resources to enter the ready state
$ helm install --namespace staging redis # Install the chart in a different Kubernetes namespace

You can check all of the charts with helm ls .

$ helm ls
NAME            	REVISION	UPDATED                 	STATUS  	CHART     	NAMESPACE
funny-starfish  	1       	Fri Mar  3 21:43:34 2017	FAILED  	demo-0.1.0	default
jazzy-macaw     	3       	Fri Mar  3 21:58:06 2017	DEPLOYED	demo-0.1.0	default
opining-tortoise	1       	Fri Mar  3 21:46:22 2017	FAILED  	demo-0.1.0	default
original-panda  	1       	Fri Mar  3 21:54:02 2017	DEPLOYED	demo-0.1.0	default
yellow-gopher   	1       	Fri Mar  3 21:44:32 2017	DEPLOYED	demo-0.1.0	default
zooming-pig     	1       	Fri Mar  3 21:51:33 2017	DEPLOYED	demo-0.1.0	default

This is a snapshot of my development environment. You can see the releases (in the NAME column) and various metadata. Specifically, you can see REVISION, STATUS, and CHART. Chart includes the name and version. With this information, we can:

  • Rollback to a specified revision of a given release. This is the helm rollback command. Here, you specify a --revision and release name.
  • Upgrade a release to the latest chart version or a specified version. This is the helm upgrade  command. Compared to other package managers, Helm allows releases to “upgrade” to completely different charts. You can upgrade the funny-starfish release to a completely different chart. This is a quirky feature, but you never know when it may be useful!
  • Delete a release. This is similar to uninstall. You may also purge a release. Normally, deleting reserves the release name so it may not be used in the future. Purging frees up the release name so that it may be reused.

The workflow becomes much more powerful when you author your own charts.

Deploying Kubernetes Applications with Helm: Authoring Charts

A chart contains Chart.yml that describes the chart (this includes the name, description, and version information that we saw in helm search earlier), and one or more Kubernetes manifest templates (deployment, pod, service, etc.). A chart also commonly contains an optional third item, values.yml. This file declares the default values used at the time of installation. These may be overridden at installation via the --set or -f flags. You may create new templates with helm create .

$ helm create sample
Creating sample
$ tree sample
sample
├── Chart.yaml
├── charts
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml

You can see that Helm generated the directory structure. This boilerplate chart deploys nginx.  The template directory contains all of the manifest files. Let’s take a close look at one of the yaml templates.

$ cat sample/templates/deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: {{ template "fullname" . }}
  labels:
    chart: "{{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}"
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    metadata:
      labels:
        app: {{ template "fullname" . }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        ports:
        - containerPort: {{ .Values.service.internalPort }}
        livenessProbe:
          httpGet:
            path: /
            port: {{ .Values.service.internalPort }}
        readinessProbe:
          httpGet:
            path: /
            port: {{ .Values.service.internalPort }}
        resources:
{{ toYaml .Values.resources | indent 12 }}

There’s a lot going on in this template. First, all files are passed through Helm’s template engine. Helm users go to the template library. It is a logicless template language with a simple control flow (if and loops). Variables are denoted by {{ }}. There are also calls to {{ .Values }}. These refer to the final computed values (the defaults in Values.yml and overrides on the CLI).
There is also a call to a toYAML helper. This is particularly useful because you may keep data in values.yaml that matches the expected manifest format. This makes it easy to dump large portions of YAML into the final manifest. Line 5 calls the template helper with the fullname “partial.” This generates a unique name to avoid any duplicate names in Kubernetes resources (remember that one chart may be installed multiple times). We can edit these files until everything is correct. Next, it’s time to test.
This is a two-step process that begins with helm lint and ends with helm install –dry-run . helm lint checks your semantics. helm install --dry-run is the real deal. The --dry-run mode sends the generated YML to the Kubernetes API for validation, but nothing is created. You will also need to combine --dry-run with --debug. --debug prints the generated YML. This is critical for debugging complex charts because YML is a whitespace sensitive language, which makes it easy to make a mistake or assume that something else has been generated.
The next step is to publish your chart to a repository. Helm chart repositories are simple web servers that serve an index.yaml file. The file declares the charts (and their version, description, etc) along with download URLs for each. You can use Google Cloud Platform buckets or S3 buckets to host your chart repository.
Publishing your chart involves three commands. The first command is helm package to generate a tar archive, followed by helm repo index to download an existing index.yml and merge it with the local chart. Then, it requires a command outside of Helm to upload the new index.yaml to the chart repository, and finally helm repo add to add your shiny new repo. This process is also covered in the official Chart Repository documentation.

Deploying Kubernetes Applications with Helm: Wrap Up

Helm is becoming increasingly important and common for Kubernetes end users, and it’s a powerful tool for your Kubernetes tool belt. You can watch the full webinar on Deploying Applications on Helm.
Here are also some links to help you use Helm:

Also, don’t hesitate to join #helm on the Kubernetes slack team.
Coming up next, I’ll be hosting the second webinar in this series on Kops.  

Written by

Passionate traveler (currently in Bangalore, India), Trance addict, Devops, Continuous Deployment advocate. I lead the SRE team at Saltside where we manage ~400 containers in production. I also manage Slashdeploy.

Related Posts

Albert Qian
— August 28, 2018

Introducing Assessment Cycles

Today, cloud technology platforms and best practices around them move faster than ever, resulting in a paradigm shift for how organizations onboard and train their employees. While assessing employee skills on an annual basis might have sufficed a decade ago, the reality is that organiz...

Read more
  • Cloud Computing
  • Product Feature
  • Skill Profiles
— July 31, 2018

Cloud Skills: Transforming Your Teams with Technology and Data

How building Cloud Academy helped us understand the challenges of transforming large teams, and how data and planning can help with your cloud transformation.When we started Cloud Academy a few years ago, our founding team knew that cloud was going to be a revolution for the IT indu...

Read more
  • Cloud Computing
  • Skill Profiles
— June 26, 2018

Disadvantages of Cloud Computing

If you want to deliver digital services of any kind, you’ll need to compute resources including CPU, memory, storage, and network connectivity. Which resources you choose for your delivery, cloud-based or local, is up to you. But you’ll definitely want to do your homework first.Cloud ...

Read more
  • AWS
  • Azure
  • Cloud Computing
  • Google Cloud
Albert Qian
— May 23, 2018

Announcing Skill Profiles Beta

Now that you’ve decided to invest in the cloud, one of your chief concerns might be maximizing your investment. With little time to align resources with your vision, how do you objectively know the capabilities of your teams?By partnering with hundreds of enterprise organizations, we’...

Read more
  • Cloud Computing
  • Skill Profiles
— April 5, 2018

A New Paradigm for Cloud Training is Needed (and Other Insights We Can Democratize)

It’s no secret that cloud, its supporting technologies, and the capabilities it unlocks is disrupting IT. Whether you’re cloud-first, multi-cloud, or migrating workload by workload, every step up the ever-changing cloud capability curve depends on your people, your technology, and your ...

Read more
  • Cloud Computing
— March 29, 2018

What is Chaos Engineering? Failure Becomes Reliability

In the IT world, failure is inevitable. A server might go down, an app may fail, etc. Does your team know what to do during a major outage? Do you know what instances may cause a larger systems failure? Chaos engineering, or chaos as a service, will help you fail responsibly.It almost...

Read more
  • Cloud Computing
  • DevOps
— November 22, 2017

AWS re:Invent 2017: Themes and Tools Shaping Cloud Computing in 2018

As the sixth annual re:Invent approaches, it’s a good time to look back at how the industry has progressed over the past year. How have last year’s trends held up, and what new trends are on the horizon? Where is AWS investing with its products and services? How are enterprises respondi...

Read more
  • AWS
  • Cloud Adoption
  • Cloud Computing
  • reInvent17
— October 27, 2017

Cloud Academy at Cloud Expo Santa Clara, Oct 31 – Nov 2

71% of IT decision-makers believe that a lack of cloud expertise in their organizations has resulted in lost revenue.1  That’s why building a culture of cloud—and the common language and skills to support cloud-first—is so important for companies who want to stay ahead of the transfor...

Read more
  • Cloud Computing
  • Events
— October 24, 2017

Product News: Announcing Cloud Academy Exams, Improved Filtering & Navigation, and More

At Cloud Academy, we’re obsessed with creating value for the organizations who trust us as the single source for the learning, practice, and collaboration that enables a culture of cloud.Today, we’re excited to announce the general availability of several new features in our Content L...

Read more
  • Cloud Computing
— August 29, 2017

On 'the public understanding of encryption' Tweet by Paul Johnston

Some of the questions by journalists about encryption prove they don't get it. Politicians don't seem to get it either (most of them). In fact, outside technology, there are some ridiculous notions of what encryption means. Over and over again, the same rubbish around encrypti...

Read more
  • Cloud Computing
— July 13, 2017

Our Hands-on Labs have a new look

Building new hands-on labs and improving our existing labs is a major focus of Cloud Academy for 2017 and beyond. If you search "types of adult learning," you will get approximately 16.9 gazillion hits. Many will boast about how they meet the needs of a certain type of learner (up to 70...

Read more
  • Cloud Computing
  • hands-on labs
— July 11, 2017

New infographic: Cloud computing in 2017

With 83% of businesses ranking cloud skills as critical for digital transformation in 2017, it’s great news for anyone with cloud architecting experience, and for those considering a career in cloud computing. In our new infographic, we compiled some of the latest industry research to l...

Read more
  • Cloud Computing