Helm release lifecycle architectuur

Helm is meer dan een installatietool — het heeft een eigen lifecycle-model voor het beheren van applicaties op Kubernetes. Dit artikel legt uit hoe de Helm template engine werkt, wat een release is en hoe upgrades en rollbacks zijn geïmplementeerd.

De drie Helm-concepten

• Chart — het pakket: templates, standaardwaarden en metadata. Vergelijkbaar met een rpm of deb-pakket
• Release — een geïnstalleerde instantie van een chart in een cluster, met een unieke naam
• Revisie — elke install of upgrade maakt een nieuwe revisie aan; rollback gaat naar een vorige revisie

Hoe de template engine werkt

Helm gebruikt Go-templates om YAML-manifesten te genereren. De templates bevatten placeholders ({{ .Values.replicaCount }}) die worden gevuld met waarden uit values.yaml en/of commando-line overrides.

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "mijn-app.fullname" . }}
  labels:
    {{- include "mijn-app.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
        {{- if .Values.resources }}
        resources:
          {{- toYaml .Values.resources | nindent 10 }}
        {{- end }}

# values.yaml
replicaCount: 3
image:
  repository: nginx
  tag: "1.25.3"
resources:
  requests:
    cpu: 100m
    memory: 128Mi

Rendering bekijken zonder te installeren

# Templates renderen (ziet precies wat naar het cluster gaat)
helm template mijn-release ./mijn-chart
helm template mijn-release ./mijn-chart -f productie-values.yaml

# Valideren tegen de API server (dry-run)
helm install mijn-app ./mijn-chart --dry-run --debug

# Installeren en dan vergelijken
helm install mijn-app ./mijn-chart
helm get manifest mijn-app     # Bekijk wat er is geïnstalleerd

Waar Helm de release history opslaat

Helm slaat de release history op als Kubernetes Secrets in dezelfde namespace als de release. Elke revisie is een apart secret met de volledige staat (templates + values) gecodeerd in base64.

# Release history bekijken
helm history mijn-app -n mijn-namespace

# Resultaat:
# REVISION  STATUS     CHART              DESCRIPTION
# 1         superseded nginx-15.3.1       Install complete
# 2         superseded nginx-15.3.1       Upgrade complete
# 3         deployed   nginx-15.4.0       Upgrade complete

# Secrets bekijken (Helm-interne opslag)
kubectl get secrets -n mijn-namespace | grep helm
# sh.helm.release.v1.mijn-app.v1   helm.sh/release.v1   ...
# sh.helm.release.v1.mijn-app.v2   helm.sh/release.v1   ...
# sh.helm.release.v1.mijn-app.v3   helm.sh/release.v1   ...

Upgrade en rollback

# Upgrade met nieuwe image-tag
helm upgrade mijn-app ./mijn-chart \
  --set image.tag=2.0.0 \
  -n mijn-namespace

# Upgrade met reuse van vorige values (PLUS de --set override)
helm upgrade mijn-app ./mijn-chart \
  --reuse-values \
  --set image.tag=2.0.0

# Rollback naar vorige revisie
helm rollback mijn-app -n mijn-namespace

# Rollback naar specifieke revisie
helm rollback mijn-app 1 -n mijn-namespace

# Upgrade + installeren als nog niet bestaat (ideaal voor CI/CD)
helm upgrade --install mijn-app ./mijn-chart \
  --namespace mijn-namespace \
  --create-namespace \
  --set image.tag=$CI_COMMIT_SHA \
  --wait \
  --timeout 5m

Helm hooks: pre- en post-lifecycle acties

Helm ondersteunt hooks: jobs of pods die op specifieke momenten in de lifecycle worden uitgevoerd, zoals database-migraties vóór een upgrade:

# templates/migration-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: db-migratie
  annotations:
    "helm.sh/hook": pre-upgrade,pre-install
    "helm.sh/hook-weight": "-5"
    "helm.sh/hook-delete-policy": hook-succeeded
spec:
  template:
    spec:
      containers:
      - name: migratie
        image: mijn-app:{{ .Values.image.tag }}
        command: ["python", "manage.py", "migrate"]
      restartPolicy: Never

Helm-best practices

• Gebruik altijd --reuse-values of geef de volledige values mee bij upgrades — zonder dit worden waarden gereset naar defaults
• Pin chart-versies in je CI/CD — --version 4.9.1 voorkomt verrassingen bij automatische updates
• upgrade --install in CI — werkt bij zowel eerste installatie als updates
• Gebruik --wait in CI — wacht tot de deployment klaar is voor de pipeline doorgaat
• Bewaar values-bestanden per omgeving — values-dev.yaml, values-productie.yaml

Relevantie voor certificeringen

• CKAD — Helm installeren, upgraden, waarden inspecteren, rollback
• CGOA/EX380 — Helm als bronformaat voor Argo CD en Flux GitOps-workflows