Deploying Applications with Helm

Helm is the package manager for Kubernetes. A chart is a versioned bundle of templated manifests — Chart.yaml for metadata, values.yaml for the defaults its templates fill in, and a templates/ directory of the manifests themselves. A release is one named, installed instance of a chart in a namespace; the same chart can back several independent releases at once, each with its own values.

Helm 3 — the current major version — removed Tiller, the server-side component Helm 2 required inside the cluster. The helm CLI now talks to the Kubernetes API directly using the same credentials kubectl uses, so there is nothing extra to install or secure beyond the cluster itself. helm install <release> <chart> creates a release; helm upgrade <release> <chart> -f values.yaml updates one that already exists; helm upgrade --install does either, which makes it the natural choice for an idempotent pipeline step that shouldn't care whether the release exists yet.

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install my-nginx bitnami/nginx \
  --namespace web --create-namespace \
  --set replicaCount=3

Helm keeps a release's history the way a Deployment keeps ReplicaSet revisions. helm history <release> lists past revisions; helm rollback <release> <revision> restores the release's Kubernetes resources to that revision's state. Passing --atomic to helm install or helm upgrade makes Helm roll the release back automatically if the operation fails or times out, instead of leaving it half-applied. helm uninstall <release> removes every resource the release created; add --keep-history if you want the revision record to survive an uninstall.

A value set with --set on the command line overrides the same key in values.yaml; a -f other-values.yaml file overrides it too, and later flags win over earlier ones when both are given. Nothing about this requires editing the chart's own templates.