Adam Hawkins

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.

 

  • Cloud Computing

  • Kubernetes

Cloud Academy