Managing Kubernetes applications with Helm

This is standard, open-source Kubernetes tooling, not specific to any provider. It works the same way on a cluster running on Bare Metal Compute, Flexible VPS, or Private Cloud, or anywhere else.

Why a package manager for Kubernetes

A moderately complex application can easily need a dozen or more Kubernetes manifests: deployments, services, config maps, secrets, an ingress, maybe a persistent volume claim. Writing and maintaining all of that by hand for every environment gets repetitive fast, and it's easy for environments to drift apart. Helm addresses that by letting you template the manifests once, as a chart, and supply a different set of values per environment or per install.

Charts vs. releases

• Chart. The package itself: a directory (or packaged archive) containing templated Kubernetes manifests, a Chart.yaml with metadata, and a default values.yaml. Charts can be written in-house, pulled from a public chart repository, or both, many popular applications ship an official Helm chart.
• Release. A specific, named instance of a chart installed into a cluster with a particular set of values. You can install the same chart multiple times under different release names, for example separate releases of the same application in staging and production, or multiple tenants of the same tool.

Basic lifecycle commands

Installing a chart from a repository, giving the release a name:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

helm install my-app bitnami/nginx \
  --namespace shop \
  --create-namespace \
  -f values.yaml

Checking what's currently installed, and the history of a release:

helm list --namespace shop
helm history my-app --namespace shop

Upgrading a release, whether that's a new chart version, new image tag, or changed configuration, uses the same values file pattern:

helm upgrade my-app bitnami/nginx \
  --namespace shop \
  -f values.yaml

If an upgrade turns out to be broken, helm rollback reverts the release to a previous revision without needing to reconstruct the old manifests by hand:

# roll back to the previous revision
helm rollback my-app --namespace shop

# roll back to a specific revision number, from helm history
helm rollback my-app 3 --namespace shop

Removing a release entirely:

helm uninstall my-app --namespace shop

values.yaml and configuration overrides

A chart's default values.yaml defines every configurable setting, replica count, image tag, resource limits, whether an ingress is enabled, and so on, with sensible defaults. Rather than editing the chart itself, you override just the values that need to differ for your install:

replicaCount: 3

image:
  repository: my-registry.example.com/shop-frontend
  tag: "1.4.2"

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

ingress:
  enabled: true
  hosts:
    - host: shop.example.com

Keeping a separate values file per environment, values-staging.yaml, values-production.yaml, is a common way to reuse one chart across environments while keeping the differences between them explicit and version-controlled, rather than scattered across manual kubectl edit changes.