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?

Deploying Kubernetes Applications with Helm
Deploying Kubernetes Applications with 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.

 

Avatar

Written by

Adam Hawkins

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

Chester Avey
Chester Avey
— November 7, 2019

Cloud Computing Solutions: 7 Trends for the Future

The world of cloud computing is in a state of flux. Not long ago, the cloud was considered an emerging technology, known only to IT specialists. Today it is a part of everyday life – 96% of businesses use the cloud in one form or another, and this number only looks set to grow. Whether ...

Read more
  • Cloud Computing
  • internet of everything
  • multi-cloud
  • Security
  • SEO
Avatar
Cloud Academy Team
— October 23, 2019

Which Certifications Should I Get?

As we mentioned in an earlier post, the old AWS slogan, “Cloud is the new normal” is indeed a reality today. Really, cloud has been the new normal for a while now and getting credentials has become an increasingly effective way to quickly showcase your abilities to recruiters and compan...

Read more
  • AWS
  • Azure
  • Certifications
  • Cloud Computing
  • Google Cloud Platform
Avatar
Walter Stone
— October 10, 2019

8 Surprising Ways Cloud Computing Is Changing Education

Cloud computing: Empowering the education industry Over the years, the education industry has come a long way. Teaching and learning are no longer confined to textbooks and classrooms and now reaches computers and mobile devices. Today, learners are always connected — whether they are ...

Read more
  • Cloud Computing
  • education industry
Avatar
Michael Sheehy
— August 19, 2019

What Exactly Is a Cloud Architect and How Do You Become One?

One of the buzzwords surrounding the cloud that I'm sure you've heard is "Cloud Architect." In this article, I will outline my understanding of what a cloud architect does and I'll analyze the skills and certifications necessary to become one. I will also list some of the types of jobs ...

Read more
  • AWS
  • Cloud Computing
Avatar
Andrew Larkin
— August 7, 2019

Disadvantages of Cloud Computing

If you want to deliver digital services of any kind, you’ll need to estimate all types of resources, not the least of which are 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...

Read more
  • AWS
  • Azure
  • Cloud Computing
  • Google Cloud Platform
Avatar
Adam Hawkins
— June 12, 2019

What is Kubernetes? An Introductory Overview

In part 1 of my webinar series on Kubernetes, I introduced Kubernetes at a high level with hands-on demos aiming to answer the question, "What is Kubernetes?" After polling our audience, we found that most of the webinar attendees had never used Kubernetes before, or had only been expos...

Read more
  • Cloud Computing
  • Kubernetes
Avatar
Scott Huntington
— March 25, 2019

How Does Cloud Computing Work?

Whether you're looking to become a cloud engineer or you're a manager wanting to gain more knowledge, learn the basics of how cloud computing works. Are you wondering about how cloud computing actually works? We can help explain the basic principles behind this technology. Cloud comput...

Read more
  • Cloud Computing
Avatar
Guy Hummel
— March 4, 2019

What is Ansible?

What is Ansible? Ansible is an open-source IT automation engine, which can remove drudgery from your work life, and will also dramatically improve the scalability, consistency, and reliability of your IT environment. We'll start to explore how to automate repetitive system administratio...

Read more
  • Ansible
  • Cloud Computing
Avatar
Cloud Academy Team
— February 11, 2019

What is Puppet? Get Started With Our Course

When it comes to building and configuring IT infrastructure, especially across dozens or even thousands of servers, developers need tools that automate and streamline this process. Enter Puppet, one of the leading DevOps tools for automating delivery and operation of software no matter ...

Read more
  • Cloud Computing
  • Puppet
Avatar
Andrew Larkin
— January 15, 2019

2018 Was a Big Year for Content at Cloud Academy

As Head of Content at Cloud Academy I work closely with our customers and my domain leads to prioritize quarterly content plans that will achieve the best outcomes for our customers. We started 2018 with two content objectives: To show customer teams how to use Cloud Services to solv...

Read more
  • AWS
  • Azure
  • Cloud Computing
  • Google Cloud Platform
Avatar
Cloud Academy Team
— December 21, 2018

2019 Cloud Computing Predictions

2018 was a banner year in cloud computing, with Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) all continuing to launch new and innovative services. We also saw growth among enterprises in the adoption of methodologies supporting the move toward cloud-native...

Read more
  • Cloud Computing
  • Cloud Predictions
Albert Qian
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