Helm: The Package Manager for Kubernetes

Why it exists

Deploying a real-world application on Kubernetes often requires managing dozens of interdependent YAML files for Deployments, Services, ConfigMaps, and more. Keeping these files in sync across different environments (dev, staging, prod) is complex and error-prone. Helm was created to solve this "YAML sprawl" by packaging everything into a single, versioned, and configurable unit.

The mental model

Think of Helm as a package manager like apt for Debian or Homebrew for macOS, but specifically for Kubernetes applications. Instead of installing a .deb file, you install a "Chart". A Chart is just a collection of files in a specific directory structure that describes a related set of Kubernetes resources. It bundles the YAML definitions with a templating engine, allowing you to customize installations without manually editing YAML.

How it works

A Helm Chart contains templates for your Kubernetes resource definitions (like deployment.yaml and service.yaml). It also includes a values.yaml file that provides default configuration values. When you run helm install, Helm's template engine combines the templates with the values you provide to generate the final Kubernetes manifest files. It then sends these manifests to the Kubernetes API server. This process creates a "Release," which is a specific instance of a Chart running in your cluster.

When to use it

Use Helm to install complex, off-the-shelf software into your cluster (e.g., Prometheus or a database). It's also the standard for packaging your own applications for distribution or for managing deployments across multiple environments. You can override default values for each environment (e.g., use a different database URL for production vs. staging) from a single Chart.

When not to use it

For very simple applications with only one or two YAML files, Helm might be overkill. If your configuration needs are minimal, using kubectl apply -f with simple environment variable substitution might be easier. Also, be wary of overly complex "umbrella charts" that try to manage dozens of microservices; they can become a bottleneck and a single point of failure for deployments.

One canonical example

A common task is installing a PostgreSQL database. Instead of writing a StatefulSet, Service, and PersistentVolumeClaim YAML from scratch, you can add a chart repository and run one command: helm install my-release bitnami/postgresql. You can customize the installation by passing values, like setting the admin password: helm install my-release bitnami/postgresql --set auth.postgresPassword=my-secret-pw.