Best practices for deploying to Kubernetes using Helm

This is part of a series on pragmatic, safe and repeatable ways of deploying to Kubernetes. These posts are built as part of building Deliverybot, the missing link between deploying to Kubernetes from GitHub.

In the last post we discussed deploying using bare Kubernetes manifests with Kustomize to deploy applications. This post discusses one of the most common deployment tools for Kubernetes. Helm is the “package manager for Kubernetes” and therefore has become one of the most common tools for managing application deployments.

Helm, however, is a package format. Not a workflow for deploying code into Kubernetes. In this post I want to discuss how to use Helm in different types of workflows the most effectively to provide easy and safe deployments for your infrastructure on Kubernetes.

Helm is structured around charts. These, fundamentally, are sets of Yaml files which are evaluated using the go templating language. Charts allow us to build modules for Kubernetes. We can declare a set of values in Helm that a user supplies when deploying a chart to release an application that abstracts away some of the complexities of releasing certain applications to Kubernetes.

A basic Helm chart

~/charts/app
├── Chart.yaml
├── README.md
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── ingress.yaml
│   ├── secret.yaml
│   └── service.yaml
└── values.yaml

The basics of a Helm chart consists of a chart metadata (“Chart.yaml” and “values.yaml”) as well as the templates that make up your main chart. The main chart configuration consists of naming and versioning for your chart. The values file is where we declare values that are read internally by the templates of your chart that can be declared externally by users of your chart. This is Helm as an abstraction layer, simplifying a set of values that can be expanded into a multitude of Kubernetes manifests under the hood.

A Deployment, a service and an ingress

This is the core of most Helm charts that focus on releasing networked applications. These three resources are the key to getting your application deployed and to be able to talk to it from outside…