Helm and Kustomize

Why packages for Kubernetes?

A real app needs many objects: a Deployment, a Service, an Ingress, a ConfigMap, an HPA, maybe a ServiceAccount. Now you need it in dev, staging and production, with different replica counts, image tags and host names. Copying five YAML files three times and editing them by hand leads to mistakes that only show up in production.

Helm solves this the way apt or npm do for software: it packages all the YAML of an app into one unit you can install, upgrade, roll back and remove with one command, and it lets you change settings without touching the YAML itself.

The words

• Chart: a package, a folder with Chart.yaml, values.yaml and a templates/ folder.
• Values: the settings a chart accepts, with defaults in values.yaml.
• Release: one installed copy of a chart in a cluster, with a name. Install the same chart twice and you have two releases.
• Revision: every install, upgrade or rollback of a release gets a new number, so Helm can go back.
• Repository: a place to share charts, either an HTTP server with an index or an OCI container registry.

shop-api/
  Chart.yaml          # name, chart version, app version
  values.yaml         # default settings
  templates/
    deployment.yaml
    service.yaml
    ingress.yaml
    _helpers.tpl      # small reusable template snippets

# Chart.yaml
apiVersion: v2
name: shop-api
description: The shop API
version: 0.3.0        # the chart's own version (semver)
appVersion: "1.4.2"   # the version of the app it deploys
---
# values.yaml
replicaCount: 2
image:
  repository: registry.example.com/shop-api
  tag: "1.4.2"
service:
  port: 80

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}
    spec:
      containers:
        - name: api
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"

The everyday commands

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update                                   # refresh the list of charts
helm install shop-api ./shop-api -n shop --create-namespace
helm upgrade --install shop-api ./shop-api -n shop -f values-prod.yaml --set image.tag=1.4.3
helm list -n shop                                  # releases and their revisions
helm history shop-api -n shop
helm rollback shop-api 2 -n shop                   # go back to revision 2
helm template shop-api ./shop-api -f values-prod.yaml   # print the YAML, change nothing
helm uninstall shop-api -n shop

Overriding values, and who wins

Helm starts from the chart's values.yaml, then merges each -f file in order (later files win), then applies --set values, which win over everything. Maps (nested keys) are merged key by key; lists are replaced as a whole.

Kustomize: the template-free alternative

Kustomize is built into kubectl. Instead of templates with blanks, you keep plain YAML in a base folder and small patches in one overlay folder per environment. kubectl apply -k overlays/prod builds the final YAML and applies it.

# overlays/prod/kustomization.yaml
resources:
  - ../../base
namespace: shop-prod
images:
  - name: registry.example.com/shop-api
    newTag: "1.4.3"
patches:
  - path: replicas.yaml   # a small patch that sets replicas: 6

Helm 3 removed Tiller, the old server-side component, so Helm now talks to the API server with your own kubeconfig permissions. Helm 4 was released in late 2025; the core commands in this lesson work the same, but check the Helm docs for what changed.