Kubernetes Helm

What is Kubernetes Helm?

Kubernetes Helm is a package manager for Kubernetes, analogous to Yum or Apt. It makes it possible to organize Kubernetes objects in a packaged application that anyone can download and install in one click, or configure to their specific needs. In Helm, these packages are called charts (similar to debs or rpms).

When a user installs a Helm chart, Helm deploys a Kubernetes cluster in the background, as specified in the chart’s configuration.

Helm is organized around several key concepts:

• A chart is a package of pre-configured Kubernetes resources
• A release is a specific instance of a chart which has been deployed to the cluster using Helm
• A repository is a group of published charts which can be made available to others

Kubernetes Helm was developed by Google and Deis and introduced as part of the Kubernetes 1.4 release in 2016. Because Helm is relatively new, there are few public repositories for Helm packages – one public repo is hub.kubeapps.com. Publicly available, stable Helm charts include:

What Does Kubernetes Helm Solve?

Kubernetes is known as a complex platform with a steep learning curve. Kubernetes Helm helps make Kubernetes easier and faster to use:

• Improves productivity – instead of spending time on deploying test environments to test their Kubernetes clusters, developers can deploy a pre-tested app via a Helm chart and focus on developing their applications.
• Existing Helm Charts – allow developers to get a working database, big data platform, CMS, etc. deployed for their application with one click. Developers can modify existing charts or create their own to automate dev, test or production processes.
• Easier to start with Kubernetes – it can be difficult to get started with Kubernetes and learn how to deploy production-grade applications. Helm provides one click deployment of apps, making it much easier to get started and deploy your first app, even if you don’t have extensive container experience.
• Reduced complexity – deployment of Kubernetes-orchestrated apps can be extremely complex. Using incorrect values in configuration files or failing to roll out apps correctly from YAML templates can break deployments. Helm Charts allow the community to preconfigure applications, defining values that are fixed and others that are configurable with sensible defaults, providing a consistent interface for changing configuration. This dramatically reduces complexity, and eliminates deployment errors by locking out incorrect configurations. 
• Production ready – running Kubernetes in production with all its components (pods, namespaces, deployments, etc.) is difficult and prone to error. With a tested, stable Helm chart, users can deploy to production with confidence, and reduce the complexity of maintaining a Kubernetes App Catalog.
• No duplicated effort – once a developer has created a chart, tested and stabilized it once, it can be reused across multiple groups in an organization and outside it. Previously, it was much more difficult (but not impossible) to share Kubernetes applications and replicate them between environments. 

Kubernetes Helm Architecture

Helm consists of two main components:

• Helm Client – allows developers to create new charts, manage chart repositories, and interact with the tiller server.
• Tiller Server – runs inside the Kubernetes cluster. Interacts with Helm client, and translates chart definitions and configuration to Kubernetes API commands. Tiller combines a chart and its configuration to build a release. Tiller is also responsible for upgrading charts, or uninstalling and deleting them from the Kubernetes cluster.

After Helm is installed, the helm init command installs the Tiller server to your running Kubernetes cluster. It is then possible to search for charts and install them to the cluster.

Basic Operations: Working with Helm Charts and Releases

To search for available charts, run the command helm search. You can add a search query at the end of the command to filter your search, like this: helm search nginx 

The output looks like this:

$ helm search
NAME VERSION DESCRIPTION
stable/drupal 0.3.2 One of the most versatile open source content m...
stable/jenkins 0.1.0 A Jenkins Helm chart for Kubernetes.
stable/mariadb 0.5.1 Chart for MariaDB
stable/mysql 0.1.0 Chart for MySQL

To install a package using Helm, run helm install NAME – specifying the name of the chart. Here is an example of output when deploying the MariaDB 0.3.0 Helm chart:

$ helm install stable/mariadb
Fetched stable/mariadb-0.3.0 to /Users/mattbutcher/Code/Go/src/k8s.io/helm/mariadb-0.3.0.tgz
happy-panda
Last Deployed: Wed Sep 28 14:02:15 2018
Namespace: default
Status: DEPLOYED
Resources:
==> extensions/Deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
happy-panda-mariadb 1 0 0 0 1s
==> v1/Secret
NAME TYPE DATA AGE
happy-panda-mariadb Opaque 2 1s
==> v1/Service
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
happy-panda-mariadb 10.0.0.70 <none> 3306/TCP 1s

Installing a package creates a releaseon the Kubernetes cluster. In the above example the release name is happy-panda.

You can customize a chart before installing by running helm inspect values, seeing the current configuration, and then overriding it during installation, like this:

$ echo '{mariadbUser: user0, mariadbDatabase: user0db}' > config.yaml
$ helm install -f config.yaml stable/mariadb

This example overrides the MariaDB credentials, but accepts the rest of the defaults for the chart. There are several ways to override configuration data during install, each with its specific format and limitations – see more details.

To keep track of a deployed release’s status or see its configuration, run the command helm status RELEASE_NAME

To upgrade a deployed release when a new version of the Helm chart is released, use the command helm upgrade RELEASE_NAME. The release is upgraded with the same chart, but a new YAML file.

To roll back to the previous version of a release after upgrading, use the command rollback RELEASE_NAME 1 – the number specifies how many versions to roll back. the first revision number is always 1. So if you have only upgraded once, you should select 1. If you upgraded four times, you can specify 3 to roll back to the very first version.

To list all running release, use helm list – see options.

To create a new chart,run the command helm create NAME. Helm creates a directory structure like this – let’s say the deployed app is mysql:

mysql/
 |
 |- .helmignore # patterns to ignore when packaging Helm charts.
 |
 |- Chart.yaml # information about the chart
 |
 |- values.yaml # default values for templates
 |
 |- charts/ # other charts the current chart depends on
 |
 |- templates/ # template files

We’ll explain dependencies and templates below.

To fetch a chart and unpack it in a local directory, useful for inspecting, modifying or repackaging charts, run:

helm fetch [flags] [chart URL | repo/chartname]

There are several options for verifications to perform on the chart, and how it should be unpacked.

To download a named release currently installed on the cluster, run:

helm get [flags] RELEASE_NAME

There are several options, mainly for enabling TLS for the download. It is also possible to get hooks, manifest and values for the release, explained below.

To delete a release and uninstall it from the Kubernetes cluster, use helm delete [flags] RELEASE_NAME. There are several options, including the ability to perform a dry run and simulate a deletion of the release. The purge flag removes the release from the store and makes its name free for later use by other releases.

Learn more about basic chart operations in the Helm: Quick Start Guide ›

For a quick reference of all commands see: Helm Commands Documentation ›

Chart Dependencies

In Helm, one chart may depend on one or more other charts. Dependencies can be dynamically linked through the requirements.yaml file or represented in the charts/ subfolder within the chart directory. It might be easier to manually manage dependencies via the charts folder at first, but the recommended method is requirements.yaml.

The requirements.yaml file looks like this:

dependencies:
- name: apache
version: 1.2.3
repository: http://example.com/charts
- name: mysql
version: 3.2.1
repository: http://another.example.com/charts

The command helm dependency update uses your dependency file to download all specified charts into the charts directory automatically. Dependencies are stored as compressed .tgz files in the charts folder.

There are many advanced options for specifying dependencies including tags, conditions and child values.

For more details see Helm Documentation: Chart Dependencies ›

Chart Templates and Values

A Chart template is a mechanism by which the creator of the chart can define variables that users can modify when installing the chart. Those variables are called values, and the chart must define reasonable defaults for all values to ensure the chart installs correctly out of the box.

Chart templates are written in Go. All template files are stored in a chart’s templates/ folder. When Helm accesses a chart, every file in that directory is rendered via the template engine.

To provide values for a template in a specific chart:

• You can provide a file called values.yaml inside of a chart, which contains default values.
• Chart users may supply a YAML file that contains values. This can be provided in the helm install command. User-provided values override the default values in the values.yaml file.

Following is an example of a template file:

apiVersion: v1
kind: ReplicationController
metadata:
  name: deis-database
  namespace: deis
  labels:
    heritage: deis
spec:
  replicas: 1
  selector:
    app: deis-database
  template:
    metadata:
      labels:
        app: deis-database
    spec:
      serviceAccount: deis-database
      containers:
        - name: deis-database
          image: {{.Values.imageRegistry}}/postgres:{{.Values.dockerTag}}
          imagePullPolicy: {{.Values.pullPolicy}}
          ports:
            - containerPort: 5432
          env:
            - name: DATABASE_STORAGE
              value: {{default "minio" .Values.storage}}

There are several pre-defined values in Helm templates which cannot be overridden, such as Release.Name, Release.Time and Release.Namespace.

Following is an example of a values.yaml file:

imageRegistry: "quay.io/deis"
dockerTag: "latest"
pullPolicy: "Always"
storage: "s3"

Values files can specify global or local values – indicating whether values should apply only to this chart or to its dependencies as well.

For more details see Helm Documentation: Chart Templates and Values ›

Hooks

Helm provides a hook mechanism, which allows a developer to intervene at specific points in a release’s life cycle. The available hooks are:

• pre-install: after templates are rendered, but before resources created in Kubernetes.
• post-install: after all resources are loaded 
• pre-delete: on deletion request before any resources are deleted
• post-delete: on a deletion request after all of the resources have been deleted
• pre-upgrade: on an upgrade request after templates are rendered, before any resources are loaded
• post-upgrade: on an upgrade after all resources have been upgraded
• pre-rollback: on a rollback after templates are rendered, but before any resources have been rolled back
• post-rollback: on a rollback request after all resources have been modified

Technically, hooks are Kubernetes manifest files with special annotations in the metadata section. They are template files, so you can use all the regular template features. Here is an example of a job declared to be run on post-install:

apiVersion: batch/v1
kind: Job
metadata:
  name: "{{.Release.Name}}"
  labels:
    heritage: {{.Release.Service | quote }}
    release: {{.Release.Name | quote }}
    chart: "{{.Chart.Name}}-{{.Chart.Version}}"
  annotations:
    # This is what defines this resource as a hook. Without this line, the
    # job is considered part of the release.
    "helm.sh/hook": post-install
    "helm.sh/hook-weight": "-5"
    "helm.sh/hook-delete-policy": hook-succeeded
spec:
  template:
    metadata:
      name: "{{.Release.Name}}"
      labels:
        heritage: {{.Release.Service | quote }}
        release: {{.Release.Name | quote }}
        chart: "{{.Chart.Name}}-{{.Chart.Version}}"
    spec:
      restartPolicy: Never
      containers:
      - name: post-install-job
        image: "alpine:3.3"
        command: ["/bin/sleep","{{default "10" .Values.sleepyTime}}"]

Hooks are managed separately from releases so you should be aware that deleting a release may not delete its associated hooks.

For more details see Helm Documentation: Hooks ›

Helm Repositories

A chart repository is a server that houses packaged charts. Any HTTP server that can serve YAML files and tar files can be used as a repository server. Helm does not provide tools for uploading charts to remote repository servers. 

A repository has a special file called index.yaml that lists all the packages, together with data that allows retrieving and verifying those packages.

On the client side, repositories are managed with the helm repo commands.

For more details, see Helm Documentation: Repo Commands ›

Summary

In this page we introduced Helm – an important new component of Kubernetes that simplifies deployments and get you up and running much more quickly. Helm is a package manager, like Yam or Apt, which lets you package together objects comprising a Kubernetes application and install them with one click. 

We covered important Helm concepts such as charts, releases and repositories, explained Helm’s client-server architecture, and provided the basics:

• Working with charts and releases
• Defining dependencies between charts
• Defining templates with default values and overriding default values during installation
• Setting up hooks to intervene at specific points during the release lifecycle
• Working with Helm repositories that allow others to view and consume charts you create

This was only a brief guide – we strongly encourage reading Helm’s comprehensive documentation to fully understand how Helm works, and how to create charts that will be truly stable and reusable. In particular, review Helm’s Best Practices which contains important conventions and practices for creating working charts.

Top Helm Tutorials from the Community

Top Helm Videos from the Community