Helm Charts: Kubernetes Packaging Done Right

Helm charts are like package managers for Kubernetes, letting you define, install, and upgrade even the most complex Kubernetes applications.

Let’s see Helm in action. Imagine you’re deploying a simple Nginx web server.

First, you need a Helm chart. You can find pre-made charts on Artifact Hub or create your own. For Nginx, a basic chart might look like this (simplified Chart.yaml):

apiVersion: v2
name: nginx
version: 0.1.0
appVersion: 1.16.0
description: A simple Nginx web server chart

And in templates/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:

  name: {{ include "nginx.fullname" . }}

  labels:

    {{- include "nginx.labels" . | nindent 4 }}

spec:

  replicas: {{ .Values.replicaCount }}

  selector:
    matchLabels:

      {{- include "nginx.selectorLabels" . | nindent 6 }}

  template:
    metadata:
      labels:

        {{- include "nginx.selectorLabels" . | nindent 8 }}

    spec:
      containers:
        - name: nginx

          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"

          ports:
            - containerPort: 80
              name: http

And values.yaml:

replicaCount: 1

image:
  repository: nginx
  tag: "" # Defaults to appVersion

To install this, you’d navigate to the chart’s directory and run:

helm install my-nginx ./nginx-chart

Helm takes your chart definition, merges it with the values.yaml (and any overrides you provide), and generates Kubernetes manifest files. It then applies these manifests to your cluster. The my-nginx is the release name, a unique identifier for this specific deployment instance.

The real power comes when you need to upgrade. Suppose you want to scale Nginx to 3 replicas. You’d modify values.yaml:

replicaCount: 3

image:
  repository: nginx
  tag: ""

Then, run:

helm upgrade my-nginx ./nginx-chart

Helm compares the new state defined by your chart and values with the current state of the my-nginx release in your cluster. It identifies that only the replicaCount needs to change and issues the necessary Kubernetes API calls to update the deployment. This creates a new revision of your release. You can view history with helm history my-nginx.

Helm also manages dependencies. If your Nginx chart needed a separate database chart, you’d list it in Chart.yaml’s dependencies section, and helm dependency update would fetch it.

The Helm templating engine (Go’s text/template) is what makes charts dynamic. It uses Go’s templating syntax (like {{ .Values.replicaCount }}) to substitute values from values.yaml into your Kubernetes manifests. This allows you to create generic charts that can be configured for various environments (dev, staging, prod) simply by changing the values.

A common misconception is that Helm is Kubernetes. It’s not. Helm is a tool that uses Kubernetes’ API to deploy and manage applications. It’s an abstraction layer that simplifies complex deployments by packaging them into reusable, configurable units.

One of the most powerful, yet often overlooked, features is Helm’s ability to manage release hooks. These are Kubernetes resources (like Jobs or Pods) that Helm can execute at specific points in the release lifecycle – before installation, after installation, before upgrade, after upgrade, before deletion, and after deletion. This allows you to perform actions like database migrations, pre-deployment checks, or post-deletion cleanup automatically as part of your Helm operations.

The next step is often exploring more advanced templating functions and managing secrets securely within Helm deployments.